I would rephrase this to learn a new programming paradigm. There are fundamental differences between static typing and dynamic typing, object orientation and functional, manual memory management and garbage collection. There are also "pure" single-paradigm languages and multi-paradigm languages. If you learn the same type of language multiple times, you're really just learning new syntax and probably a couple of extra idiosyncrasies, so it's important that you pick languages with fundamental differences.
Counting proper languages I actually wrote something useful in, my path looks like:
C64 BASIC -> C64 raw machine code -> QBasic -> x86 raw machine code -> Turbo Pascal -> C -> Visual Basic -> Java -> O'Caml -> Delphi7 -> Python -> C++ -> Erlang -> C# -> Haskell -> F# -> JavaScript
To keep learning very different languages is also what guarantees you will be able to get a good job when your bread-and-butter language falls out of fashion. Try to imagine being a 60-year old Cobol-only programmer in the job market today. In addition to getting some experience with the actual languages, you will also get a good grip of the underlying patterns and ideas, which will make it a breeze to pick up any new language.
Another mostly overlooked skill that you gain from working in radically different languages, is to be able to work with different priorities. Java and C++ are designed for serious work. In these, you take types, error checking and exceptions seriously, you keep the code clean and robust, and you R the FM thoroughly for every single external function you call. Visual Basic, on the other hand, is designed for slapping together something that gets a small job done. Errors can be ignored, text encoding can be fucked up, functions can run into 500 lines, and that's simply something you should be comfortable with when in VB - it's copy/paste/hack/throw away all the way. C# is again very much like Java, but without the documentation attitude. Critical bits of the standard library are woefully undocumented, and you are expected to just try some code and see if it works. When in C#, just accept that and be comfortable with it.
But, most importantly when learning a new language: Adopt the mindset. Don't try for type-safe Python. Don't write slapdash C++ code. Don't try for time-critical optimized VB. Don't box/unbox everything in F# to get dynamic typing.
Java and C++ are designed for serious work. In these, you take types, error checking and exceptions seriously, you keep the code clean and robust, and you R the FM thoroughly for every single external function you call.
What type is "null" in Java? What type is the stack in C++?
Java and C++ have very little typing. You have to type a lot of types into your source code, but they don't get you anything. For every Java or C++ program, there is some set of input that results in a NullPointerException or a segmentation fault. Guess what: if you had a type system, that wouldn't happen.
Java and C++ are designed for certifications, long-lasting career, and compiling [1].
Completely agree with the types part. I did not try to say that Java or C++ are strictly typed, but that the types (ie. classes) that are used in programs are taken seriously. By this I mean that if you are looked down by serious C++ developers upon if you send your references via void pointers or typecast by guessing.
i always hear about how many jobs there are for cobol programmers to maintain legacy code. i've never actually met any though. maybe they all commit suicide.
My only encounter with the mythical COBOL Legacy Architect was at one job where we indadvertedly shared a desk. Since he was only in the office about 2 hours a months, others had assumed it was an empty cube and put me there. The rest of the time, he was making consulting bank in his mountain cabin. I think other than myself and the CIO, maybe 3 people knew who the guy was.
The flipside is that probably 90% of mainframe programmers were washed out of the industry in the mid-1990s. I remember seeing tons of useless resumes full of RPG and JCL and no C++/Oracle/Java/WinNT or whatever was hot back then.
I've heard about a lot as well, especially in the banking industry, yet not actually met anyone. Does anyone have any data or any numbers on how much someone can get paid doing cobol legacy maintenance? Just for educational purposes of course.
A lot of banks still have mainframes lurking somewhere on which they run (legacy?) accounting and settlement systems. Interestingly, a lot of the mainframe / COBOL programming jobs are outsourced, mainly to Indian companies. Infosys and TCS (the two huge outsourcing shops) actually train some graduates in Cobol / Mainframe programming. When I worked at ${Wall Street Bank}, we had an outsourced team in Chennai looking after a mainframe system. I had a quite a shock when I visited the Chennai office and discovered that most of the guys were straight out of college!
Ah so it isn't like theres all these American companies that are going to be paying top dollar to maintain their legacy, mission critical COBOL systems. They're outsourcing it for minimum wage.
An article [1] showed up on HN a while ago. In it the author gave a list of business which run their entire business on the mainframe. I work as a Java dev in rail transportation. The author is dead-on right - COBOL runs the world.
> Java and C++ are designed for serious work. In these, you take types, error checking and exceptions seriously, you keep the code clean and robust, and you R the FM thoroughly for every single external function you call.
So how do they compare to Haskell, especially when it comes to types and code cleanliness?
For those who don't have Haskell listed in their path, I'll tell you: Haskell takes types a lot more seriously, but they're so different from what a C++ or Java programmer would think of as types that it's difficult to make a direct comparison. Ditto error checking, which, to a large extent, is baked into the type system such that it's a compilation error to not check for a lot of problems. Cleanliness is practically an obsession, to the point you'll wonder how anyone can write useful code in Haskell until a switch flips in your head and you begin to wonder how people can live with Java and C++. ;-)
Frankly, every language you learn should cause a switch to flip in your head like that.
I went like this CPP -> Java -> Haskell -> Python -> Ruby -> Coffeescript and elisp somewhere inbetween.
I learned a lot about languages but there are many of my friends who know just PHP or Java and who are much more productive day to day than me.
My advice to someone would be to pick one language an learn it really well so you can do pretty much anything in it. Do Code Katas, make stuff all the time. When you're bored, dick around with other languages like Haskell or some of the Lisps(try to do SICP exercises).
But be productive in at least one language.
Check out some of Corey Haines's videos on practice to understand better what I mean.
I would rephrase this to learn a new programming paradigm. There are fundamental differences between static typing and dynamic typing, object orientation and functional, manual memory management and garbage collection. There are also "pure" single-paradigm languages and multi-paradigm languages. If you learn the same type of language multiple times, you're really just learning new syntax and probably a couple of extra idiosyncrasies, so it's important that you pick languages with fundamental differences.
Compare going through this learning path:
Perl -> PHP -> JavaScript -> Python -> Ruby -> Node.js
To going through this:
Java -> C -> Scheme -> JavaScript -> Erlang
For example.