The nice people over at InformIT recently asked a bunch of authors of programming language books for advice on how to learn a new (to you) programming language; they were kind enough to ask me my opinion which I happily gave. Check it out here.
My candidate for best quote is from Bjarne Stroustrup: It is not easy to tell good advice from the far more plentiful harmful nonsense. It’s true! And that is good advice.
Fabulous adventures in coding 
Another choice Bjarne quote:
The typical mistake when first approaching a new language is to write in the style of some older language: “You can write Fortran in any language”
One thing that’s often a double-edged sword is similarity between a new language and an old one. C# has a strong resemblance to C and C++, but many constructs which have a certain meaning in those other languages are valid in C# *but have a very different meaning*. For example, in C or C++, if one has a variable that holds some kind of indirect reference to an object (e.g. a pointer) but does not hold it directly, one would access members of that object using the `->` token. The `.` token, by contrast, operates directly on the variable itself. If one sees the code “X=Y; Y->foo=5;” one would expect that it would also change “X->foo;”, but if one sees the code “X=Y; Y.boz=5;” one would expect X.boz to remain unaffected. Unfortunately, because .NET makes no distinction between “direct” and “indrect” member access, C# doesn’t either, and instead uses “.” for both, giving it a very different meaning from C [where it always implies direct access] or C++ [where it generally does], or Java [where it always implies indirect access].
While trying to learn a language which is totally different from anything else one knows is often intimidating, it can sometimes be less confusing than trying to learn a language which looks like another but works differently.
I work on a node-based, visual programming plugin for a 3D CAD platform. This plugin itself also allows users to enter VB.NET, C# and Python code. I do often get questions from CAD users (these are people with full-time jobs mind you) on how to start programming both visually and textually.
I feel that Cay Horstmann (“Put the language to work in a project that interests you.”) and Jennifer Kyrnin (“The trick here is to come up with something real to build.”) give the best advice here for people who want to learn their first programming language.
I tell people to pick a problem that they know inside-out and have solved manually many times. Then try and convert that algorithm into code. Doing dry employee-paycheck-inheritance examples isn’t going to help you get some passion for programming.
Also, “the only stupid question is the one you should have asked but didn’t” is excellent advice in my opinion.
Whereas Stephen Walther’s advice “Buy a book. A book enables you to learn the most important stuff fast.” is total bollocks as far as I’m concerned. Unless you are exceptionally lucky to find a book that is exquisitely tailored to your interests and needs, it is more likely to bore, confuse and frustrate you. Buying and reading books about programming languages is something you should do to become a good programmer. But first you have to become a bad programmer just by doing horrible stuff that kinda sorta works.
Thanks David!
I find it’s most useful to have an understanding (and some experience) of different programming paradigms. Most languages can be separated into one of a few categories; working in a new language within a particular category is then just a case of learning that language’s quirks and preferences.
Here’s the taxonomy as I see it.
Is the language declarative or imperative?
If declarative, is it functional, logical, or array-based or set based? Is it pure? Is it lazy by default?
If imperative, is it procedural or OO or procedural-with-interfaces?
Orthogonally to all that: does it have a rich type system? Are the types statically checked? Is it a scripting language? Does it give you access to the bare metal (or, at least, does it expose naked pointers)?
My favorite trick: start to implement an interpreter or compiler for the tricky parts of the language. It’s OK if you never get your interpreter to run — just designing and thinking about how you *would* implement the language feature is enough.
Thanks a lot for sharing this. It covers a lot of questions that were bugging me for some time. I started a blog recently about my journey to become a professional programmer, decided that it might be cool for people to see the entire process. Please let me know what you think: http://www.syntaxthis.com.
Buying a book is what I’d recommend too. It seems to be a dying medium but e.g. The Ruby Way taught me more about that language than any collection of disparate 500 word articles ever would.