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.
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++ |