> I would really like to read your opinion on what exactly the skills are to "learn new programming languages in minutes or hours rather than days or weeks.
In this there is no substitute for practice and a little drudgery. It is a lot like sight reading sheet music. At first each new piece is a struggle (more so if you are learning the instrument at the same time). But over time, you naturally develop a set of "meta skills" that make you much better at sight reading. Many of these skills you are not even totally conscious of, but they do develop and before long you can play most new pieces just as you can immediately read most new books (though it still takes a deeper read to appreciate the nuance).
So, here's some advice for developing this skill:
- Learn a lot of programming language and, if possible, learn them simultaneously or in rapid series. You're not shooting for mastery of each, just understanding and casual proficiency.
- Again, having a really cool mini-project helps. If you're a math guy, Project Euler is a good way to start building your personal Rosetta Stone. If not, pick a game or some simple app. It needs to be something that fairly well exercises the 20% of each language that is used 80% of the time, but also has enough complexity to warrant playing with the remaining 80%.
- The "Rosetta Stone" example is, I think, apt. Your goal is not to build yourself a personal decoder ring such that you can just match up the equivalent symbols, but for something deeper. You're aiming for something that aligns the concepts in each language such that the superficially similar things are blindingly obvious, but the deeper differences still abstract out to a higher-level similarity that you can train your mind to see when new languages come along. For example, how are object-orientation and functional decomposition, though dramatically different in form and theory, both just translations of a single higher level concept or two? I can't tell you that, because I would be wrong or, at best, trivial. You have to discover those deep mappings yourself. Only then will they really speak to you.
- Syntax is just, like, the language designer's opinion, man. No, really. Stop caring about the syntax while you're learning. Just accept that you're painting with someone else's idea of a paintbrush and move on. As you get more advanced you'll come to have "aesthetic taste" in syntax and you'll know which languages look, to you, like beautiful paintings and which, to you, look like so much angry scratching. But when you're learning a new language (or 10), it's best to put your aesthetic judgements aside and just let it ride. Haskell is a good example of this. At first I absolutely HATED the kind of "sharp" syntax and bizarre ordering of things. The language felt "pointy and argumentative" in the area of my mind that has developed this weird "code sense synesthesia" that has developed over years of looking at so much different stuff. But I put that aside to really learn the language, and while it's still not my favorite language syntactically (that goes to Clojure or CoffeeScript), it became more beautiful and ordered in my mind and took on a kind of beauty that, like certain forms of architecture, is only visible once you understand a bit of the purpose. But in any event, really, ignore the syntax and just treat it as "the rules of the road" until you become more adept.
- Similarly, just because a language LOOKS difficult doesn't mean it is. Tell yourself that it's "just code" (I use this term a lot) and struggle through. Before long you'll invariably look up from your frustrations and say "oh. This isn't as hard as it looked." coughScalacough
- When learning about a language, read about the history of its development and guiding philosophy first. It helps to understand a language more when you know where the designer was coming from. You may not AGREE with the designer(s), but you'll appreciate that there's a reason behind the apparent madness.
- I'd recommend learning the following types of languages simultaneously or in rapid succession to shake yourself of the "different == scary" prejudice that's only human in all of us:
* Something comfortably high level and "cozy", like Python or Ruby
* Something "enterprisey and conventional", like Java or C#
* Something really functional, like Haskell or F#
* Something really object-oriented, like Smalltalk (just go with Smalltalk here)
* Something "industrial". Go with C here or maybe C++
* Something lispy, like Clojure or Scheme
* Something theoretically foundational and bootstrappable, but not lispy. I'm thinking FORTH
* Something painful and to the metal. Assembly language for your favorite architecture.
* Also, do yourself a favor and write at least ONE thing in pure machine code (as in manually write a hex file that will execute). In the DOS days, I wrote a COM file that printed something to the screen using a BIOS interrupt. Load up DOS in an emulator and do that, or do a system call in your environment. This little exercise will be tedious and suck unless you're a hexadecimal masochist, but you'll be forever better for it, because you will have broken the ultimate barrier and actually done the thing most people think of as "ultimate wizardry"... and it won't be as hard as you think.
Keep in mind that this is an intellectual exercise. It's not job training. It should be treated as a hobby at first, because it can be frustrating but rewarding... like a really hard jigsaw puzzle.
Finally, I'd have to recommend picking up a copy of Petzold's Code. Once you read that, get yourself into an online TECS (The Elements of Computing Systems) course and follow it all the way through. Go to http://www.nand2tetris.org/ for starters.
This is all very time-consuming and difficult, and at times it will be extremely frustrating, but it's more than worth it. Once you REALLY get how the machines work and how the various languages above machine code (even assembly language!) are just the result of various people's opinions on what kinds of abstractions to stack on top of the wires, you'll be a better programmer for the rest of your life. You'll also, with continuing practice and education, run rings around everyone at work :)
I can't stress how much I agree with the last point. Probably the single hardest CS course I took in college was an upper-level seminar on compiler design, in which we built a simple compiler (for Appel's Tiger language) over the course of a semester. I've never poured more hours in to doing harder, more frustrating work in my entire life... and I've found that I haven't looked at code the same way since. I've found that you can get a similar experience by really, really groking C, but it still doesn't hold a candle to really getting to the innards of the machine.
> I would really like to read your opinion on what exactly the skills are to "learn new programming languages in minutes or hours rather than days or weeks.
In this there is no substitute for practice and a little drudgery. It is a lot like sight reading sheet music. At first each new piece is a struggle (more so if you are learning the instrument at the same time). But over time, you naturally develop a set of "meta skills" that make you much better at sight reading. Many of these skills you are not even totally conscious of, but they do develop and before long you can play most new pieces just as you can immediately read most new books (though it still takes a deeper read to appreciate the nuance).
So, here's some advice for developing this skill:
- Learn a lot of programming language and, if possible, learn them simultaneously or in rapid series. You're not shooting for mastery of each, just understanding and casual proficiency.
- Again, having a really cool mini-project helps. If you're a math guy, Project Euler is a good way to start building your personal Rosetta Stone. If not, pick a game or some simple app. It needs to be something that fairly well exercises the 20% of each language that is used 80% of the time, but also has enough complexity to warrant playing with the remaining 80%.
- The "Rosetta Stone" example is, I think, apt. Your goal is not to build yourself a personal decoder ring such that you can just match up the equivalent symbols, but for something deeper. You're aiming for something that aligns the concepts in each language such that the superficially similar things are blindingly obvious, but the deeper differences still abstract out to a higher-level similarity that you can train your mind to see when new languages come along. For example, how are object-orientation and functional decomposition, though dramatically different in form and theory, both just translations of a single higher level concept or two? I can't tell you that, because I would be wrong or, at best, trivial. You have to discover those deep mappings yourself. Only then will they really speak to you.
- Syntax is just, like, the language designer's opinion, man. No, really. Stop caring about the syntax while you're learning. Just accept that you're painting with someone else's idea of a paintbrush and move on. As you get more advanced you'll come to have "aesthetic taste" in syntax and you'll know which languages look, to you, like beautiful paintings and which, to you, look like so much angry scratching. But when you're learning a new language (or 10), it's best to put your aesthetic judgements aside and just let it ride. Haskell is a good example of this. At first I absolutely HATED the kind of "sharp" syntax and bizarre ordering of things. The language felt "pointy and argumentative" in the area of my mind that has developed this weird "code sense synesthesia" that has developed over years of looking at so much different stuff. But I put that aside to really learn the language, and while it's still not my favorite language syntactically (that goes to Clojure or CoffeeScript), it became more beautiful and ordered in my mind and took on a kind of beauty that, like certain forms of architecture, is only visible once you understand a bit of the purpose. But in any event, really, ignore the syntax and just treat it as "the rules of the road" until you become more adept.
- Similarly, just because a language LOOKS difficult doesn't mean it is. Tell yourself that it's "just code" (I use this term a lot) and struggle through. Before long you'll invariably look up from your frustrations and say "oh. This isn't as hard as it looked." coughScalacough
- When learning about a language, read about the history of its development and guiding philosophy first. It helps to understand a language more when you know where the designer was coming from. You may not AGREE with the designer(s), but you'll appreciate that there's a reason behind the apparent madness.
- I'd recommend learning the following types of languages simultaneously or in rapid succession to shake yourself of the "different == scary" prejudice that's only human in all of us:
* Something comfortably high level and "cozy", like Python or Ruby
* Something "enterprisey and conventional", like Java or C#
* Something really functional, like Haskell or F#
* Something really object-oriented, like Smalltalk (just go with Smalltalk here)
* Something "industrial". Go with C here or maybe C++
* Something lispy, like Clojure or Scheme
* Something theoretically foundational and bootstrappable, but not lispy. I'm thinking FORTH
* Something painful and to the metal. Assembly language for your favorite architecture.
* Also, do yourself a favor and write at least ONE thing in pure machine code (as in manually write a hex file that will execute). In the DOS days, I wrote a COM file that printed something to the screen using a BIOS interrupt. Load up DOS in an emulator and do that, or do a system call in your environment. This little exercise will be tedious and suck unless you're a hexadecimal masochist, but you'll be forever better for it, because you will have broken the ultimate barrier and actually done the thing most people think of as "ultimate wizardry"... and it won't be as hard as you think.
Keep in mind that this is an intellectual exercise. It's not job training. It should be treated as a hobby at first, because it can be frustrating but rewarding... like a really hard jigsaw puzzle.
Finally, I'd have to recommend picking up a copy of Petzold's Code. Once you read that, get yourself into an online TECS (The Elements of Computing Systems) course and follow it all the way through. Go to http://www.nand2tetris.org/ for starters.
This is all very time-consuming and difficult, and at times it will be extremely frustrating, but it's more than worth it. Once you REALLY get how the machines work and how the various languages above machine code (even assembly language!) are just the result of various people's opinions on what kinds of abstractions to stack on top of the wires, you'll be a better programmer for the rest of your life. You'll also, with continuing practice and education, run rings around everyone at work :)
Good luck!