Index  Comments

In general, I learn a new programming language by reading the standards document and an introductory text, in either order. I believe it fair to write this approach seeks a complete understanding from the beginning, and it's saved me from wasting my time before. Surprisingly, this seems uncommon for others, as I've had such remarked to me before.

Of course, it helps a great deal to already have familiarity with the act of programming, and of the prospective learned language, varying. If a language lacks a standards document, that may be a good reason to avoid it. If it lacks a standard or anything resembling one and multiple implementations, it's probably not worth learning, unless it's a very particular language, such as TeX, say.

In learning Common Lisp, I read ``Common Lisp, the Language: 2nd Edition'', followed by corrections, and I've read several books concerning the language at various levels, since. I still often use the HyperSpec as a reference, but the language helps avoid this, through documentation strings and heavy introspective abilities which come standard. It would've been more difficult were I unfamiliar with Lisp at the time, certainly. Common Lisp is a language with which one wants at least some knowledge of beforehand and reading one of the several introductory texts first would likely suit others well.

With APL I read ``APL: An Interactive Approach: Third Edition'', followed by the standards document; this was a good decision, as I'd little familiarity with APL beforehand, and the approach of showing interactive sessions throughout and introducing the system in an order intended for people was good. The standards document is well-written and an enjoyable read, but can be difficult to read at times, as each function and primitive is defined in the most general of terms and I didn't find it uncommon to need to visualize some through the zeroeth, first, second, and third dimensions before I properly understood them. APL is certainly a language one wants to have good knowledge of before reading the standard.

For Ada, I started by reading that most recent Ada Reference Manual, but this was somewhat difficult reading and it was suggested I continue by reading ``Programming in Ada 2012'', which was a pleasant choice; as Ada is a language designed for ease of comprehension by humans rather than uniformity and simplicity of internal rules, it seems sufficient to know how and why something operates, instead of the precise rules, although those are still good to know. I can recommend reading some introductory texts before the standards document with Ada, as well.

In my machine code meddling, I've always read the instruction set and machine document first. Being familiar with what machine code is, of course, helps here. A general machine code is merely numbers which command the machine, and it's best in my eyes to think of them as puzzles; you've certain data formats and instructions which operate on them, and from these you must build your solution, so that the desired transformations or operations are achieved, ideally in the smallest and fastest form.

With regards to C, reading a comprehensive document saved me from believing the lies concerning that disgusting language. Some often recommend C, with the belief it's a simple language with close ties to the underlying hardware on which it runs and yet acquaintance with the standards document reveals this as a lie. In merely reading of the syntax, with its sequence points, exceptions, and other odd qualities, I recognized this language wasn't simple at all, but grotesquely complicated. My reading of the absurd amounts of undefined behaviour and yet more had me easily disregard this language.

In sum, another good thought for learning a new programming language is to learn one entirely unlike the others one already knows. There exist people who believe differences between languages are only syntactical in nature, as they know no different. This basic idea is outlined well:

A language that doesn't affect the way you think about programming, is not worth knowing.''
--Alan Perlis

I learn new programming languages on a whim, and this has served me well; once you become skilled in learning new languages, yet more will come yet more easily, and this is a good way to improve.