> Honestly, once you learn 5 or 6 languages, picking up a new one (not as a deep expert, but enough to functionally contribute to an open source project) takes only a day or so.
I think this really depends on some of those 5 or 6 languages being similar to the new one. If I know C, C++, Python, Java, Perl and C#, I'm not going to walk right into Prolog or SML or Scheme. (Your second paragraph is related to this, I just wanted to call it out a little clearer.)
> Once you understand the space of possible programming languages you can often learn a new one in just a week or two,
This is only true if that new one is closely related to the ones you already know.
Learning, say, Haskell, in the period of week for the person with knowledge of “standard set” like C,Python,JS,Go will be somewhat painful exercise include some brain explosions.
> 10 different programming languages... It's a struggle for me to list them all (let alone learn them).
That's still very little. You can take a look at my site (in profile, the "Languages" page) where I listed PLs which I learned. There's 126 entries on that list (to save you a couple of clicks). I'm not boasting - just offering a different perspective.
> all the others were a waste of time because they're so similar to each other.
If they are so similar, then learning them should be very easy and quick, no?
> I can pick up a new one in a single day and my code could fool someone into thinking that I've been doing it for a while (if you ignore development speed)...
In a single day? So it's not that much effort, is it? Assuming, of course, you won't hit the language which is different enough and your intuitions and experience become useless.
> you can only truly master a language or framework after working with it full time for a couple of years.
You're wrong, in part.
It takes a lot of time to master your first language and a few others in the beginning. Later it can take quite a lot of time to learn your first language with a paradigm you're unfamiliar with.
But languages are similar to each other, can be classified into types and studied in bulk. With enough languages (and frameworks) learned you develop an intuition of what happens and how. With enough different languages known, you develop an intuitive feel for what's the best way of solving a problem in a given language. There's also a bit of theory to be learned, but once you have it down there's really nothing that can surprise you.
Personally, I've had the hardest time when learning J. There are exactly two other languages which are similar (APL and K) and they both are even harder to get into. So the reverse is also true: if you don't know enough about a certain kind of languages, you're going to have a hard time.
In the end, I think we disagree on what we consider mastery. I don't believe you have to remember all the finest details of implementation to say you've mastered the language - as long as you can easily drop down to the compiler or interpreter source, read it and understand without effort. It's all pretty easy then, believe me.
A person proficient in multiple programming languages absolutely knows all of the 6 concepts - it's just cases of 'aha, go allows me to do x,y,z and this is how things should be done'.
I basically learned ideomatic go in a week, by skimming over the "effective go" guide and cross referencing concepts to other languages I know -- there is really nothing inherently 'new' in Go that would require years. It's a deliberately simple language.
A language is like an instrument, once you know one, learning the next will be much easier, because you already know about rhythm and harmonics. Each new instrument, even a new guitar, is a ear opener, as it forces one to play different, to learn fresh.
Same with programming languages. Learning a new language becomes trivial after the first dozen. But each new one widens the way one see code.
> THIS. After learning a few languages and paradigms, I find that I often have a 2 week ramp up for any given programming language.
That sounds about right for many programming languages. My personal average from "having heard of the language" to "writing non-trivial programs" (let's say, something that is able to talk to a REST API and do some processing) is a non-stop weekend programming session. [1]
The time-consuming part is learning the libraries and how to write idiomatic code. That can take months or years (C++, I'm looking at you).
Still, knowledge of a specific programming language is usually the wrong thing to optimize for. Perhaps a more useful metric was the number of programming languages one has been exposed to? That is more useful, as once you have learned a bunch, you've seen most of the important concepts, and can focus on whatever subset is implemented by the new language.
[1] Except Haskell. That's a nut I still haven't cracked.
I think that Norvig's point in this article is that to really learn to use a language, along with all of its specific idioms and everything (so that you're not just writing "Java in Python"), one needs to study and use it for far longer than the learn-quick books would suggest.
I think you're misunderstanding what the OP is looking to do.
The more languages you learn, the more you realize they have more in common than not. At some point it’s time to stop learning 20+ languages and start building stuff. I never said to stop learning, but be very careful what you spend your time learning. If you can be world class at Python alone, able to solve just about any problem with it, it’s better than 100% knowing many languages. Knowing a language doesn’t mean you know all of the standard libraries and third party libraries, much less solve challenging problems efficiently.
There's a difference between mastery and whatever it is you think you're doing in a month. Learning syntax is simple enough, but learning to write software in the language's idiomatic style and using common libraries without looking them up every time is a longer task.
It's not like anyone would say the vistor who looks up words in a travel dictionary has mastered the language...
> Learning new languages is pretty simple if they're in a family I know.
Does your list of languages include fairly disparate examples, such as languages that do not have a Latin base or share a portion of their vocabulary with ones you know?
I think the point being made was the type of language learned. Shared concepts reduce learning time. Knowing Perl, Ruby, Assembly, etc may not help too much learning something like Haskell or Clojure. Knowing Lisp might help quite a bit. Prolog would be another thing entirely.
> There seems to be a common thread that languages that are easy to pick up (not necessary "learn") are also harder to make use of to build something once your skill level has gone up a bit.
There's also a line of thinking that some languages (like Python) are both a great beginner language and simultaneously a bedrock language that should be a first choice for many advanced/complex problem spaces as well.
I disagree with the whole notion of "learning" a programming language. It's studying, maybe trying out or learn how to do [something] with it. It's like a real language can't be learned, but only studied. "Last week I learned English?" "Really do you now know all of it?"
I think you missed the point. The author didn't say learn Java, Go, or C, for example.
"I think the reason for this is that in an ML family language, where the types are static but inferred, you are constantly playing a learning game with the compiler as your teacher'
> I would also recommend that beginners/early programmers learn 1 programming language really well
That's a dangerous approach. The first language is very hard to learn, because, well, it's your first. And when you stick to one language, you easily conflate the syntax and the semantics.
So when you learn a second language, you have to unlearn the syntax of the first, in addition to learn the genuinely different concepts. Distinguishing the similar stuff in new clothes from the actual new stuff is hard. Simply put, learning the second languages will be very hard as well.
Now your programmer has two data point, and knows with their gut that learning a new programming language is hard. This sets expectation, an will make it harder to learn additional languages. It will take some time to realise learning a new language, besides a few insane exceptions like C++, is not that hard.
> ignore the din of people on the internet who claim to effortlessly, expertly jump among 10 languages as part of their day-to-day.
Jumping from language to language may not be that easy. But one can certainly be an expert at 20 programming languages. Once you see the commonalities, there isn't much to learn. Really, a good course in programming languages is enough to get you started. The hard part is memorising 20 big programming frameworks, with all their warts, special cases and so on. Still, if you know the concepts, learning the vocabulary takes little time.
Silly idea. One can learn the basic syntax of a language after a days worth of toying with it. Python has such a simple syntax, but you don't really know the language until you know all the awesome modules out there.
I'd rather become more fluent with one or two new languages over the course of a year
> and that can actually be the most effective way for them
A lot of it is just a general lack of learning material for that demographic. For most languages, you get to choose between an introductory text that assumes you've never even heard of a "pointer" or an advanced text that is meant as a reference for an experienced developer of the language.
There's not really a lot of stuff out there to teach someone who already knows another language, who just wants to know the syntax and common idioms in that language. For example, a C programmer can easily pick up Python, learn some syntax, and go nuts -- but they just won't know about stuff like list comprehensions or dataclasses unless someone points it out. They'll write Python code that reads like C, not like Python.
My issue is that there are only so many times you can go thru the process of learning a new language. It's monotonous. You have to learn a new way to create code without really advancing your knowledge. You can learn to create a loop in 10 different languages and still not advance your programming abilities. You just know 10 different ways to do the same thing. Not only that, your time is finite. The time you take to recreate the wheel could have been better used somewhere else. Learning a new language is like spinning your wheels rather than moving forward.
If someone spend many months learning a new language, but still can't be able to build something functional with it, I think he has a bigger problem...
I understand the point you are trying to make in posting this, and it is a good point to make.
However, in the article, Norvig himself points out the worthiness of learning several languages, and doesn't claim that you have to get on a ten year treadmill for any individual one, or even a subset. My impression was that Norvig was really targeting the people for whom whatever-language-in-a-fortnight-and-a-half would be their first exposure to programming at all.
As you gain more languages, provided you are judicious in choosing, so shall your learning of each of those languages be more rapid than the prior.
Does a month per language seem a bit rapid? Yeah, it kind of does, depending on the time spent in study and tooling. The pragmatic programmer guys suggest learning a new language every year; that seems wholly attainable. In reality, the author studied a language to what he considered a sufficient level in a quarter. That also doesn't seem that unreasonable, depending on the level of mastery desired. Could be that both perspectives have more than a grain of truth.
I'm sure I could look at Go code and roughly explain what it does, or take a problem and roughly explain how to do it in Go.
I'm sure it would take 3 months of misery or 3 months of practice for me to be able to write Go from scratch as quickly as Python.
And there's really no reason to learn 500 languages. There's barely reason to learn 10.
reply