This article, while designed for someone who hasn’t yet started programming, must needs contain some technical terminology. I originally considered littering the text with footnotes, but who likes reading footnotes? (Unless they’re written by Dave Barry, of course!) Instead, read this glossary thingy first, which should serve a as a mild introduction to some basic “lingo.”

This is obviously going to be for a very specialized audience–the intersection of the set of people who read my blog and the set of people who aren’t programmers but could see themselves maybe becoming one someday. Hopefully it will be at least mildly interesting to those of us who don’t belong to the empty set :)

My reasoning behind my suggestions is based on equipping you not only with a tool that will help you accomplish some task, but that will stimulate you intellectually and help you think about programming. It will also hopefully provide a solid foundation that you can build upon so that you will find it easier to program in future languages you may learn (perhaps ones that are more task-oriented).

As such, I will start with some I think you should not learn as your first language, and why. Obviously, I’m not saying you should never learn these (quite the opposite in the case of some); just that they maybe shouldn’t come first.

• C – An excellent language, and incredibly useful (still today one of the most-used languages in spite of its simplicity). It also has a small syntax and standard library, making learning it on a superficial level quite easy. However, based on the criteria I mentioned above, I cannot recommend it as a first language. It lacks too many helpful abstractions, and indeed tends to force you into pretty specific coding styles. This is a pity, because I’d really love to recommend it on the virtue of what it teaches you about how many other programming languages work “under the hood.” Learn it second!
• C++ – Built off C, C++ had the aim to deal with the aforementioned lack of abstraction–in other words, just as you don’t need to know how a car works to drive one, you shouldn’t necessarily have to know how a computer works to write programs for it–but still be compatible with C code. It became quite popular in its day, and indeed there is still an enormous amount of programs written in C++ around. However, while I applaud its goals, its execution is lacking. It’s ridiculously complicated in about every way you can think of, and when you combine that with the lack of any training wheels or even safety belt (a wrong move can crash your program or corrupt data, and often it is unable to tell you why)… you’re asking for trouble. There are certainly C++ zealots around, but I’m just as certainly not the only one who thinks that learning it well is not worth the titanic time investment.
• Java – Many people will disagree with my putting Java on the not-learn-first list; indeed it’s the one they teach you first at BYU and lots of other schools (although only ones striving to be “practical”–Computer Science programs that take a more academic approach tend to use other example languages). Java came along as an answer to the madness that was/is C++, and became very popular in the business world. I reckon it’s still the Biggun’. One of its most interesting features is that it is cross-platform–that is, your program will run on Windows, Mac OS X, Linux, etc. (This is not a typical thing!)

  I say don’t learn Java first, because quite frankly of the Java-like languages it’s not the best. It lacks some features and is quite verbose; you end up writing a lot of boiler-plate code all the time. I can also say that from personal experience, if you learn it first, it makes you think “in Java.” And in hindsight, that’s not how I want to think :)

• Javascript and PHP – Two good languages, and ones you more-likely-than-not will learn eventually. I don’t recommend them as first languages for a couple reasons. For one thing, they are very loosely typed–this means they are very willing to “try and guess what you meant.” This is a pro as well as a con, but I think you will appreciate it more–and it will bite you in the butt less–when you have some experience under your belt and you actually understand what “loosely typed” means and how it applies to code you write. Another reason to steer clear of them is that they are almost the trademark “newbie languages.” This has a number of implications:
  • No real community to speak of. Most of the people who program in them do so not out of a love for the language, but out of desire to get something done quick. The “community” is a lot of people who would be new like you–and when you’re new to a language, I’ve found it’s helpful to know where to find experienced people.
  • Lots of code for these languages that’s out there on the internet–both example code and libraries (that is, code that others have written to perform a task so you don’t have to write it) are written by people new like you. Again, as a newbie programmer, you want to learn from and use code that is as close to professional quality as possible.
  • Security gotchas. Though this kind of thing does of course get better as time goes on, rapscallions are well aware that code in these languages is both very popular and often written naively. Thus if there are vulnerabilities, they are going to be found out and exploited.
  • General lack of emphasis on proper coding style, algorithms, etc. As very permissive languages, they permit you to write steaming piles of… code.
• Perl – I have a soft spot for Perl, but as one of the most organic languages out there, it has become a bit overgrown with decade-old weeds. Additionally, it has a lot of subtlety and complexity, and lots of syntax. Unlike C++, it can’t wreak havoc on your whole system, but I have accidentally erased files before by getting the file-opening syntax wrong. (I know that came off as anecdotal FUD, but I was merely listing an example. Again, I like the language, in spite of its quirks.)

  Perl has a dedicated and experienced community behind it, that I’ve found to be helpful and excellent. It’s also got probably the largest collection of freely-available libraries of any language out there. But in reality, I wouldn’t recommend it as a first language, and even as a second language I’d recommend waiting for its next incarnation to come out (which has been in the works for many years now. The language’s designer recognized that Perl needed a complete rewrite, and so it’s taking awhile).

• Visual Basic – If we were speaking of “classic ASP” or Visual Basic 6, all of the above commentary would apply, and then some. Nowadays, however, you’d be more likely to encounter VB.NET, which is built on the .NET framework and (though I’m overgeneralizing) is essentially a way to write the same code as you could in C#, but with different syntax. However, that being said, there are no benefits to doing so, and the code you write is both ugly and dissimilar to any good language. So there’s simply not a reason to start here.

I believe that about covers the most common starting points for a new programmer that I wouldn’t endorse. There may be others, but I don’t feel qualified to comment on languages that I myself haven’t learned to at least some degree.

Anyway, the more interesting stuff: what do you learn, then? Haven’t I just ruled out like every popular language?

Well, understand it is quite random which languages end up becoming popular; indeed, the only thing they really have in common is that they are generally not the best of their kind–or even if they were originally, others took what they did right and combined them with other stuff done better.

Assuming you fall into my target audience (you want to learn what will be helpful in the long run, recognizing that as a brand new programmer you won’t be writing 3D games and huge financial systems for a while anyway), you are have lots of pretty good options available. Here’s a list! I’m going to put it in order of “amount of brain-stretching required”–you can decide for yourself, based on your various capabilities, which might work best for you.

• C# – I’m a tad hesitant to recommend this as a first language. It was my first language, and it is a good language, yadda yadda. Syntactically, you can think of it as a significantly better version of Java: it has several constructs that Java doesn’t, making it much nicer to code in. It’s also got tremendous IDE support, which I think is good and bad as a programmer seeking to learn the ropes (but that’s a topic for a different blog). And when it all comes down to it, it will get you in a mode of thinking that is similar to a Java programmer’s: somewhat roundabout, somewhat repetitive, somewhat verbose.

  If you do choose C#, try and take advantage of the features that new versions have offered, and continue to make a great effort to do so as future versions are released. One of its big advantages over Java is it continues to introduce solid ideas from other languages every couple years. Note that it isn’t strictly Windows-only anymore; the effort to get it on other platforms has been actually quite successful.

• D – I’m going to make an exception to my rule here, and list a language I’ve never learned. I do so because D is one of the languages I’ve only ever heard good things about–which is rare in the world of programming languages. D is, in short, what C++ should have been (or should be). It’s even designed to be able to fill that close-to-the-machine niche if needed. If you learn it, let me know how it goes!
• Python – This is probably the most popular language out there that is the most solid and straightforward. It was designed to avoid trickiness and to be very uniform; indeed, their motto (paraphrased) is “There should be one way to do things.” This even includes how the code looks on a piece of paper: all very uniform. There are lots of newbie resources available, tons of example projects written in good style that you can study, and plenty of libraries to help you do all sorts of stuff.

  With as much praise as I have for it, I’m actually not the hugest fan of the language, simply because I tend to prefer a system that allows for a bit more cleverness. (There are also some aesthetic quibbles I have with it.) But you could do a lot worse than learning Python first. It will especially help with getting you in the habit of writing well-formed code, in any language.

• Ruby – Ruby is similar to Python in some ways, but different in philosophy and in the sort of coder it tends to attract. It was my favorite language for a long time, and I think it scales well: you can start by writing in Python-like style, and as you learn new tricks, incorporate them. The result is both simple and concise. It commonly uses certain programming constructs that, while they may exist in a language like C#, don’t play as big a role–therefore in Ruby you get to appreciate their power more frequently and understand them sooner.

  Ruby was also designed with “metaprogramming” in mind–that is, you can play with how the language works. This isn’t really important to know as a newbie; I mention it as part of showing that there’s definitely “growing room” for your brain as you learn this language.
  Note: Don’t confuse Ruby with “Ruby on Rails,” which is a framework written in Ruby. I don’t recommend jumping into Rails right off the bat, without learning Ruby first.

• Scheme – Scheme is a great little language, unfettered by frivolous syntax and unnecessary complexity. It is a “Lisp,” meaning one of a family of languages that share an important trait: they are incredibly easy for humans and computers to parse. This means you can easily write code that writes code. Programming in a Lisp is very fun if you don’t mind stretching your brain a bit–and I’m writing this blog for those that don’t.

  One nice thing about Scheme, is it is used as the example language in several books about how to learn programming the right way. (Most programming books are closer to either “how to learn Language X the right way” or “how to do task X with Language X”.) Also great is a couple of these books are free: SICP and How to Design Programs. I also recommend The Little Schemer.

• Haskell – I’m learning Haskell now, and consider it to be the closest thing out there to the “holy grail” of languages. It’s incredibly well-designed, and is packed with cool features, and it has one of the most helpful communities I’ve yet encountered. It’s also the most brain-stretching of any language I’ve mentioned on this page. Though I’m sure some would disagree with me, I am of the opinion that it was designed by smart people, for smart people. Or, that is to say, that smart people will be able to harness it best. (Standard disclaimer about not measuring your self-worth by whether you can code in Haskell, yadda yadda [even though I personally measure my self-worth by everything I can't do... but that's for another blog.]

  I just mean that there is a lot you can do with a language like it if you have the tools upstairs, unlike, say, PHP–which is like “programming to the lowest common denominator.”) I won’t launch into any significant description of the language here, as someday I plan on writing about it more–hopefully in a fairly approachable way.

Of course, there are many other good languages out there. Again, I’m a bit limited by what I’ve had time to digest personally. Also, some languages are worth learning, but perhaps not first. Let your intuition guide you–learning a language should be fun and interesting, and if it’s not, something is going wrong. If you absolutely aren’t enjoying one of my recommendations, don’t let that turn you away from programming in general; by all means give something else a shot.

I’m only able to speak out of hindsight, and indeed it’s probably that warped kind of hindsight wherein if you went back to your old self and gave him advice, he’d probably just look at you funny. But such is life, and such is programming.

• Syntax – This basically amounts to what you have to physically write in order to make a program do what you want it to do. If your language has “lots of syntax,” you need to remember how lots of symbols interact with each other. (Note that “symbols” here can mean words or word-looking things, not just brackets and stuff.)

  A “lots of syntax” example (from C++) (of course!):

    template <typename _id_t, typename _mem_t>
    void exchange(map<_id_t, _mem_t>& ref, const _id_t& id1, const _id_t& id2)
    {
        typename map<_id_t, _mem_t>::iterator it1 = ref.find(id1);
        typename map<_id_t, _mem_t>::iterator end = ref.end();
   
        if (it1 != end)
        {
            typename map<_id_t, _mem_t>::iterator it2 = ref.find(id1);
            if (it2 != end)
            {
                _mem_t tmp = it2->second;
                it2->second = it1->second;
                it1->second = tmp;
            }
        }
    }

• Libraries, Standard Library – Where do you go to get books you didn’t write? The library! (Okay, pay no more heed to that analogy before it starts to fail.) A library refers to code that someone else has written that you can use. The “standard library” of a language refers to libraries that are included with the language itself; you don’t need to buy them or go find them on the internet or anything like that.
• Abstraction – A way to view something in more simple terms. You can view a toaster as a fairly complicated combination of small circuits and whatnot, or you can view it as something that you put bread into and get toast out of. This is very important in programming, as at the lowest level you are dealing with a bunch of 1′s and 0′s–but you can get more work done if you don’t have to worry about them.
• (Strongly/Loosely) Typed – This one is harder to simplify, because the issue of “types” in programming is a fairly complex one. But basically, it is talking about how much leeway your language gives you when you make computations. If you give a program something that’s not a number, but looks like a number, should your language treat it as a number? But what if it does and you weren’t expecting that? The less permissive languages (the “strongly typed” ones) tend to require more input from you, the programmer, on how to handle things, but they tend to alert you of potential errors sooner. Like many things in programming, there are tradeoffs.
• Community – There are lots of communities on the internet. Each programming language has one too–a group of people of varying levels of experience and background who use that language. A friendly community is important, because that is where you go when you are stuck. Certain programming communities are quite elitist and, well, made up of jerks. (I’m looking at you, Common Lisp…)
• Algorithm – A formalized procedure or formula for doing something. You use these all the time without maybe realizing it. For example, how do you choose which way to drive home from Point X? Do you pick certain streets with less stop signs? Avoid that place with the bad speed bump? Choose a different route during rush hour? These are all part of your algorithm for getting home.
• ASP, .NET, Ruby on Rails – These things are not programming languages, but rather frameworks that are connected with programming languages. See below.
• Framework – A framework is a broad term for a collection of libraries (see above) and recommended ways to use those libraries. You might have a framework for making websites, or a framework for interacting with graphics, etc.
• IDE – This stands for “Integrated Development Environment,” which is a big huge program that helps you write programs. They can do anything from telling you when you forgot to type a semicolon to helping you debug and test your program.
• Platform – A platform is a place where programs can be run–that is, a place that is programmable in one way or another. Windows, Linux, and OS X are platforms, as are the Xbox 360, the iPhone, and big-ass tables – to name a few.
• Metaprogramming – “Sup, dawg. I heard you like programming so I put programming in your programming!” When you can program your programming language, this is called metaprogramming.
• Parse – To parse means to interpret or understand. We do it as humans when we read written language: we look for the combination of verbs, nouns, adjectives, and punctuation that delimits a thought. Computers do the same thing when reading your code: they turn your ideas, represented by syntax (see above), into tangible instructions it can use. (A bit of an oversimplification, but that’s the general idea.)

One commonly held belief is that it doesn’t matter what language you learn first. Whether we are talking English vs. Spanish or Java vs. Scheme, there seems to be a fairly common opinion that “the ends justify the means;” programming languages are Turing-complete and natural languages are merely a conduit for expressing what every human can express. “The only difference is in what concepts the language makes easy,” it is said. However, notwithstanding practical concerns (this is not going to be a practical post in the sense of “them’s the ropes: learn English or C# or whatever for business reasons”), I would go so far as to say that our first language is very important in shaping how we think and approach expression.

If you’re reading this blog, you know I served a mission for my church in Russia, and as such had the opportunity to learn a second language with a reasonable degree of fluency. Additionally, I got to do this at a time in my life when I was already an adult, and could note with some interest particular peculiarities in differences of expression. Some things “are merely different”–for example, a lack of articles [the, a, an] doesn’t seem to hamper understandability, given the proper modifiers. “I see cat here.” “I see orange cat of which you speak.” Funny-sounding, perhaps, but understandable. What’s significant, however, is not that it’s understandable–not that it’s merely an alternate form of expressing the same concept. What strikes me is how difficult it is for Russians to properly use English articles. Here is a case of the difference between “acceptable fluency” and true fluency. It’s a separation, as it were, between brute-force means-justified ends, and intuitive comprehension of a concept.

Should Russians feel short-changed that they didn’t get this intuition “for free”? Perhaps. But by the same token, Russian is full of things that are definitely not intuitive for English-speakers, and which in turn provide entirely different dimensions of expression–flexible word order and particles come to mind. Sorry English, but Russian poetry kicks yours’ butt. Which brings me to my next point: it would be awesome if we could pick which natural language to use for specific tasks that were suited for it.

We’ve actually seen examples of this in history — Italian is the universal language for music (though it can be argued that this is arbitrary. It has seemed to work well, though). Certainly most treaties are written in French (because they maintain stricter control over changes to the semantics of the language), and most men would use it for their sweet nothings if they could. I’m from California, which has a large population of people who have grown up with both English and Spanish simultaneously, and consequently switch between both languages in casual conversation with others like them–they pick the most convenient one for the thought (which might be only part of a sentence), and do so automatically.

However, we aren’t all free to do this. Indeed, it can be argued that even in my last example, such people are often sacrificing some degree of fluency in one language or the other. With natural languages, it just plain comes down to us not having any choice, most of the time. We didn’t choose where we were born, most high schools don’t even offer Russian, and there is no guarantee that the people you want to communicate with have made the same investment as you. Alas, being able to tailor our spoken language to the situation will likely never be a reality, but it does not change that the language we were raised with has, to one degree or another, shaped how we think.

I find programming languages fascinating. Many of the principles of natural languages apply, yet the scale is small enough that one can become “fluent” in multiple programming languages without investing years conversing with others who know it (though if you think about it, that can be helpful) or becoming immersed in another culture (though often it seems like you are). Additionally, programming languages are designed from the ground up, which tends to make them more uniform and consistent to a given purpose than natural languages, which grow out of a hodgepodge of history and intermingling. (It is interesting to note, however, that in a similar manner, many programming languages borrow from other programming languages, and some languages indeed develop quite haphazardly, organically, arbitrarily, and often stupidly… I’m looking at you, PHP.)

The biggest difference I’d like to point out is that you have the choice of which programming languages to learn, and especially which to learn first. I find it quite unfortunate that people tend to make this choice somewhat blindly (though they often think they are being pragmatic about it). This is a sensitive subject for programmers, especially ones who look at their craft primarily or solely as a way to put food on the table. To them, their language defines them, because it defines what jobs they can apply for. Without their language, they are without their job. Thus, they are going to press forward and try to ensure that they remain marketable by doing what they can to make their language marketable. Similarly, some find any, even temporary, decrease in perceived output unacceptable. These are the people who are still reaching for their mouse to correct a mistake made 3 lines previous, and who didn’t in fact notice their mistake at all until their IDE informed them of it after they clicked the little “go” button. Such people certainly aren’t going to learn a new language, no matter how much better it is, and when their language of choice adds new features, they bitch and moan.

These are all valid human emotions, and valid ways to approach programming. Certainly, much has been accomplished by programmers who work from 9 to 5 and don’t think about code again till after coffee the next morning. Programming is a valid profession, and it does make pretty good money. Indeed, it is even a safe profession–if you learn PHP or Java, you will always be able to get a job (at least until the industry changes–but hey, that’s never happened… right?). Besides, once you’ve learned one language, is just a matter of learning the syntax of a new one if you have to, right?

I contend that it is not. In the same way that I still can’t use particles correctly in Russian after living there for over two years, our first language–and by this I mean the first language really learned in depth–shapes how we think. We won’t use new, more powerful constructs if we don’t think to use them–it just never occurs to us. Or if you can’t find a spot for a new concept from the perspective of your current way of doing things, you won’t think to incorporate it. You’ll do it the old way. You may even modify company policy to make the new way illegal or discouraged–because you know how change is! Always bringing those temporary decreases in efficiency! Learning stuff, humbug! And it is easy to staunchly defend your decision; you can’t be swayed when you have no sense of comparison.

Certainly, I ran across this often in my attempts to share with others why religion is a quintessential part of my life. They don’t agree because they haven’t tried it, and they won’t try it because they don’t agree. Though certainly less important to the soul, the same thing happens in the world of programming.

A Java programmer has no idea what concise code looks like: Java doesn’t let you write it. You say “concise” to them, and they can only think “incomplete” or “cryptic”–because certainly you can code in those ways in Java, and just as certainly it’s not a good idea to do so. A PHP programmer has no concept of “ugly code,” because all of his code is ugly–the language is just that way. The C++ programmer does not know what “cruft” means. The Visual Basic programmer… well, even the aforementioned programmers pick on him. In fact, they all pick on each other, constantly and vitriolically. Why such bickering? For all of the reasons of the previous paragraphs: when Language A is your bread and butter, damn straight Language B shouldn’t exist.

And as I said earlier, people tend to rush into learning programming, and indeed you can’t blame them. How are they to know any differently? Just like politics, you are going to choose, as a new programmer, whatever people you look up to choose. Or, you let your pressing need completely govern your choice–I have to make my web page tell you when you typed something wrong, or I have to make a Windows form, or I have to add functionality to my WordPress blog, or I have to use a Mac, or whatever. (You programmers reading this will know which language fits the stereotypical mold for each of those tasks.) Remember what everybody says! “Languages don’t differ in what they can do, only in what they make easy.” That’s fine and great, until you’ve gotten quite proficient in that language doing the tasks it makes easy, and then you run into tasks that would be better “suited” to other languages. But by that time, there’s an investment, and after all, it would take longer to learn Language B than to just figure out an acceptable way to do it in Language A, right? Gee, it’d be nice to have a program that runs on my (or my client’s) OS natively, but I know PHP… hmm… well, I’ll just make it web-based.

On the other end of the spectrum, some languages get so pigeonholed into a niche that nobody considers them for what they are. Javascript is a fine example. Sure, it ain’t perfect, but it’s actually nicer than a lot of popular languages out there. But nope, it’s for Wendy Webdesigner to piddle around in when she wants to make a button clear the form fields on her web page. (Yes, “Web 2.0″ has changed this slightly, but it’s just a different stereotype: now it’s for making cool fadey effects!) However, not even Javascript suffers the scorn of the truly unconsidered languages–the so-called “academic” ones. Lisp? Haskell? Perish the thought!

Ugh, sorry. I’ve gotten way too soapboxy–to the point where I’m fortunate that no strangers read this blog, or I’d be getting hate mail from apologists everywhere. (And yes, all the apologists make more money than me.) My point, if you can remember my point, is that our pragmatism is affecting us more than we know. Programming is a field where you can literally always be learning, and where better ways to do things will forever be invented. Often these better ways will involve effort on our part if we want to harness them–new paradigms that we must tackle intellectually. It’s not just learning new syntax. And the relative difficulty of adapting is indeed affected by what we have learned previously.

I know I’ve been overly sardonic in this article because programming is my hobby as well as my profession, and programming languages as means of expression and problem-solving are of particular interest to me. But I do genuinely believe that aside from personal interest, these things have an impact on what kind of programmer you are and what kind of programmer you become. I don’t think it’s unreasonable to assume that a programmer who has learned new languages as part of helping him develop new ways of thinking–to obtain new tools to deal with various problems–might have some advantage over one who learned Language A because there are a lot of jobs for Language A.

It is my hope that some employers will consider this, and instead of just looking for Language A programmers because your competitor does, perhaps considering Language B. Or C. (Haha! C joke.) Likewise, I would hope that some Language A programmers would take the opportunity to broaden their horizons personally–chances are, it will even make you a better Language A Programmer. And it’s fun! I promise. And to aspiring programmers: it’s worthwhile to invest some time researching before polishing the {curly-braces} on your keyboard. Seek out a polyglot–we’d love to offer some advice.