The Hacker, the Academic, and the Corporation

I regularly hear and see people ask question such as "which programming language should I learn?" There is never agreement in the advice they receive. I believe, however, that responses to questions like this can be divided roughly into three categories, corresponding to three different points of view of the people giving the answers. These points of view are described here, as something to show for having wasted far too much of my time actually reading language flamewars.
The Hacker thinks computers are neat. The hacker mentality is described in the jargon file (see entries for hacker and larval stage). The hacker can be and often is motivated to do things because they're neat. This is the sort of motivation seen in people who climb a mountain "because it's there." The hacker, if old enough, probably spent hours programming extremely primitive devices and experiencing rapture when the LEDs blinked in order. If a hacker couldn't play with computers, he'd probably play with electronics instead.

The hacker usually believes in learning to program from the bottom up. One should start with languages which are closely related to the hardware, such as assembly (or maybe C these days), and then move on to more abstract languages once one can understand how they're implemented. Some languages, like Pascal, are pointlessly crippling, and are generally quite worthless.

The Academic thinks that computers are a necessary evil. Abstractly, they're wonderful, but the physical implementations of them are horribly hackish, often to the point of being painful to deal with. The Academic therefore prefers to abstract away the physical computer as far as possible, or even not use one at all. If an academic weren't solving problems related to computers, he'd probably be in some other field of applied or abstract mathematics.

The academic favors those languages which are closely related to mathematics and proofs. This usually means functional languages instead of procedural ones, where constructs like recursion dominate iteration. Languages closer to the hardware should be learned only when required, and often never at all. Pascal is a boon because it stops you from being distracted by the unimportant things.

The Corporate programmer thinks that computers are a means to an end. His objective is to get the job done, and he wants to use whichever technologies do this best given constraints on time and budget. If the Corporate programmer weren't solving problems with today's computers, he'd probably be solving similar problems with whatever technology he did have available.

The corporate programmer favors whichever language seems to be best for the job. Often, technical considerations form only a minor part of this - a language may be "best" due to requirements for integration with an existing system, vendor support, or even internal corporate politics. The corporate programmer would probably recommend learning starting with a language with high commercial demand, such as Visual Basic or Java. Pascal is OK if it's Borland's Delphi.

The corporate point of view is in may ways the most rational and efficient. However, it is also the least given to the sort of inspiration which is often required for real brilliance. It is more likely to produce "good" results than the other points of view, but less likely to produce "great" results.

It may be tempting to find the category above into which you seem to fit best and then conclude that the world's problems stem from the incompetence of the others. Don't kid yourself. If you think any of these categories are inherently better than the others, you're certainly entitled to your opinion, but it's a religion, not a fact. All, furthermore, have done impressive things. The hacker mentality made Linux, the academic mentality made Gnu, and the corporate mentality made money hand over fist.

Consider an example. Suppose a hacker says to a novice: "You should learn to program in C, because it is easy and simple." An academic replies: "No, you should learn to program in Haskell! C is much too hard." A corporate programmer then says: "No, go with Java. You'll spend forever reinventing the wheel with those others." It may at first seem that they are disagreeing about the properties of the languages, but I do not believe this is so. They are disagreeing because they are evaluating "simplicity" and "ease" in terms of their own objectives, which are not the same. The hacker evaluates simplicity in terms of understanding the physical implementation. The things that are easy to do in machine language are easy to do in C. One can look at a C program and tell approximately what it will look like in assembly. There's no way you can possibly do this with a Haskell program, and thus the hacker thinks of Haskell as hard and complex - it is in fact very hard to tell what it's "really doing." The Academic evaluates simplicity by completely different criteria. He's interested in expressing structures such as trees and graphs, and evaluates a language based on how easy it is to do that. He sees that in Haskell it can be done easily, with simple syntax, and that in C it is long and takes somewhat complicated and arcane syntax. He thinks that the beginner will surely be discouraged before he gets to the point of implementing interesting structures in C, and therefore recommends Haskell, where it can be done more easily and quickly. The corporate programmer thinks of Java as simple because it provides many useful libraries to do the sort of work he is actually doing. If he had to do his work in C or Haskell, he'd be spending months creating the equivalent of these stock classes. He's have to be sadist to tell a beginner to do that!

Of course, any of these answers would likely be wrong, in the same way that "I'm cold; you should put on a sweater" is bad advice. The correct advice for a beginner depends not on the point of view of the person giving the advice, but on the point of view of the beginner himself, which must be ascertained before any worthwhile advice can be given. If the beginner likes soldering bits, tell him to learn C. If he spent the last three years proving theorems, tell him to learn Haskell. If he's in it for the money, tell him to learn Java. It doesn't matter which of these is easiest for you, it matters which would be easiest for him.

This table lists a few languages I generally associate with each of the points of view described above. It is by no means exhasutive or even correct. Some boxes are blank (for example, academics generally just don't do embedded systems).
Hacker Academic Corporate
Paradigm Procedural Functional Object-Oriented
General Languages assembly, C, Perl Haskell, Lisp, ML, Smalltalk Java, C++, C#
Web Languages Perl, C, PHP Python, Lisp Java, Visual Basic
Embedded Languages Assmebly, C - C++