I definitely agree with the article that once you learn a good set of "archetypal" languages, then most popular new languages become easier to learn. It's a worthwhile exercise.
But at the same time, there are some deeply weird languages out there. These contain some absolutely fascinating ideas. And if you follow the advice in the article to learn "every" language, then these languages will still surprise and perplex you.
- If you go deep enough in Haskell that you stop being confused by monads and start being confused by "free monad interpreters", then Haskell will provide you with a nearly endless source of complex, powerful abstractions—more than enough for any 10 other research languages.
- Mozart (http://mozart.github.io/) is a concurrent logic language with a constraint solver. Even if you're familiar with Prolog and Erlang, this one's going to blow your mind.
- Coq (https://coq.inria.fr/) is a language for formally proving the correctness of the things you compute. (You typically also write your programs in Coq.) There are also other, newer languages in this space. These languages have a steep learning curve, and they're challenging to work in, but they're extremely interesting.
Learning exotic programming languages is fun, and it means that you'll rarely be surprised by any new popular language. But despite this article's suggestion to "learn every language", you won't run out of strange new languages any time soon.
The book "Concepts, Techniques, and Models of Computer Programming" (what this blogpost basically is about) uses Mozart/Oz. When I first studied it at uni I didn't care much for it, but when I sat down later and really tried to understand it, it blew my mind as you said.
The book is cool, basically introduces a simple model of an abstract computer and defines some operations, and then expands upon that throughout.
Spending some time learning Clojure, I feel, has had a measurable positive effect on the code I write. I'm considering something even more exotic for the coming year.
I'd like to disagree with the title of this blog post.
I did something like this in 2016, learnt Clojure, OCaml, Haskell, Go and Racket. Took Dan Grossman's excellent Coursera course on learning language fundamentals and paradigms across Ruby/ML/Racket. Though I can code basic to medium level toy programs in all these languages now I wish I had followed Dave Thomas' (of Pragmatic Programmer fame) advice of concentrating on only one language a year.
My advice would be pick only one language for 2017 and then think and code only in that language for the year (for your learning projects - of course you'll be using other language for your $DAY_JOB).
In 5 years you'll know how to use 5 tools really really well and your brain will be much better aware of which of these tools is the right tool for which kinds of problems.
Its a width vs depth argument. I think If you wanted to start digging deeper in any of the languages you learned in 2016 you could do so faster than having one language to consider. For instance, you've probably noticed that Clojure borrows ideas from other languages (go channels for instance), so learning how Clojure deals with that abstraction will help you compare/contrast it with how Go's abstraction works.
The more languages you know (lots of width), the more you can compare to others as you learn (gaining depth), and the faster you can assimilate new ideas as you go. Analogously, its as if while digging into one language you discover a cave-tunnel that connects you back up to another language you are familiar with. This saves you from having to dig all of the tunnels yourself because you can see how deep concepts in one language can be connected across your broad familiarity (width).
IMHO, I hate approaching tasks with a rigid mindset, whether its "LEARN EVERYTHING" or "LEARN ONE THING". I think its better to just encourage yourself to investigate something because you're interested in it, and then see where it leads you.
For instance, I'm digging into Clojure right now myself, and after watching a Rich Hickey talk about immutability and concurrency, I became curious about how GPU's work, and if they could be used with immutable data structures. Now somehow I've gotten into learning about OpenCL and CUDA and am having my mind blown about the possibilities of using a GPU as a massively parallel processor (concurrency isn't possible on GPU's though). If I were strict, I would've blocked myself from diverging from the Clojure path, and I would not have learned anything about the wonders of the emerging field of Heterogeneous Computing Languages.
You obviously did not read the whole blog post. He is talking about the importance of programming paradigms and the ideas behind programming languages that could lead to a more general understanding of new languages :) .
I did read the blog post and what Im saying is that I think the end goal of being able to understand the different paradigms that different languages bring to your understand/repertoire - would be much better served by - not just sampling a whole bunch of languages in 2017 - but by thinking in just one paradigm a year and then going on to the next one the next year.
oh wait - you're right. For the purposes of being able to get a more general understanding of new languages it is better to have somewhat of a (good) grasp on the main paradigms that exist out there. So my earlier comment and advice (which I still maintain) was orthogonal to the blog post.
Loved this!
To be honest I think the more you learn, the better for you but I would even disagree of learning everything since then you can't specialize as much as other people. I'd say, it depends on what you look for. I've seen successful people who are savvy in lots of fields but I've also came up to meet people who are really good at just a couple of things :)
And I say this because I believe it's not only about the quantity of languages that you know, but also how it's gonna be implemented, a developer that knows about business is in my opinion really valuable and difficult to find.
"It’s about understanding the common paradigms and implementation patterns so as to be confidently language agnostic."
Essentially, which are these few common paradigm languages that teach you more than 90% of what's out there? My guess would be to include something like C and LISP, but is that enough?
Haskell for lazy FP, pattern matching, and monads; ocaml for strict FP and a crazy expressive module system; C# for industry OO; lua for dynamic language and prototype inheritance; ruby for runtime meta programming; lisp for macros; forth for stack language; erlang for actor module, byte pattern matching, and dynamic unification pattern matching; prolog for logic programming; c for low level; c++ for templates and destructors; rust for linear types; idris for dependent types; R for rank polymorphism. After that languages started to seem like variations of things I've seen before.
Apparently Philip Wadler came up with this notion, so your already-mentioned Haskell should suffice ;)
> idris for dependent types
Are we still on "Essentially, which are these few common paradigm languages that teach you more than 90% of what's out there?" or are we by now in the territory of "which languages to cover every single remotely-computation-related notion anyone ever conjured up and managed to somewhat implement"? ;D
C++, Java and C# aren't really object oriented languages --- they're scalar languages with object systems bolted on. The giveaway is that they're full of types which aren't objects; ints, pointers, floats, booleans, etc. These are handled and implemented entirely differently to the object types. e.g.: compare a Java int (a scalar type) with a Java Integer (an object type).
In a proper object-oriented language, everything is an object, including these. That allows you to do some really interesting things which are at the heart of the OO mindset. e.g. Smalltalk avoids having to use conditionals almost completely via dynamic dispatch:
b ifTrue: [ 'b is true!' print ]
b is a Boolean; ifTrue:block is an abstract method called on Boolean. But the values true and false are actually instances of subclasses of Boolean; True's implementation of ifTrue evaluates the block, and False's doesn't, and that's how you get different behaviour depending on whether b is true or false. The core language neither knows nor cares that booleans are special.
(Actually, the bytecode does care, and has special accelerated opcodes to make operations of booleans fast for performance reasons, but that's just an implementation detail.)
OO should be Smalltalk given it's real OO & implementations still exist. Functional should include an ML on it given all the languages influenced by SML and Ocaml. If they'd done functional, then I suggest Mercury for logic language as it's a better Prolog with functional and performance improvements. It's used commercially, too. Query, if logic programming is done, should be SQL followed by Datalog. Assembly should be x86 and one RISC (probably ARM).
Your OO examples all come from the same portion of the OOP family tree. People should also explore the style of OOP which comes from systems like CLOS & Dylan.
My favourite member of the Logic Programming family of languages would be http://picat-lang.org/ . As far as implementations of Prolog go, http://www.swi-prolog.org/ is a good implementation to go with (It's mature, has a good ecosystem, and good documentation).
C is a bit dated and Lisp too wishy-washy, I'd suggest either Rust or Go for the Turing machine paradigm, and for the Lambda Calculus paradigm Haskell (or any truly comparably powerful robust "strictly" pure-and-lazy functional language --- can't think of any).
This way by covering the extreme ends of the spectrum from (A) gratifyingly roll-up-your-sleeves-and-get-your-hands-dirty petal-to-the-medal (heh) systems programming to (Z)abstractions-all-the-way-up-and-down-and-sideways algebraic-typed purely-functional glory.
With current-day concurrency approaches, easy-networked-ness etc thrown in natively in any of the above.
Once proficient in these "spectrum extremes", anything in between should be relatively easier to get up to speed with
Norivg's advice seems better than the entire article. And it's probably best to be skeptical of anything that insists you should start with X - that tends to reflect the author's own experience rather than anything fundamental.
The problem with learning numerous programming languages with the implicit hope of learning about various programming pradigms is that it's not a focussed approach. Instead explicitly set out to learn different programming paradigms and hopefully avoid languages which have an overlap of programming paradigms.
So instead of "In 2017, learn every language" I would say "In 2017, learn every programming paradigm".
I am a person who LOVES to try different, new, exotic languages whenever I can. I usually try around 5-6 new programming languages (sometimes including frameworks) in a year.
My personal strategy is to try to learn enough of a language "to be dangerous". This means you can create working code with it, probably not 100% idiomatic, and probably reinventing the wheel in many ocassions.
The good thing is that it in my opinion the 80/20 rule applies here, as it takes 20% of effort to learn 80% of a (programming) language. The largest benefit is that you are going to be able to try many different languages and decide if you want to keep digging deeper into it. Heck, maybe you love a programming language so much you would even accept a new job just because you want to program in that language.
For the record, in 2016 I tried Go, Rust, Clojure, Elixir, Crystal, Swift. My personal favorites this year are Clojure and Elixir. But all the other languages have their own niches with lots of potential. I'll be keeping an eye on them.
Roughly understanding every language is admirable, but very different than being highly productive in a language. If I have to google syntax and packages to do every little thing like writing a for loop, I wont exactly be productive. He is very correct though - subtle differences in syntax often translate well to other languages and learning the general paradigms are the key point.
So yes, have a general knowledge of programming that applies to different languages with ease, but focus on getting very productive with the language that you use all the time. For me, my focus is dictated by my work: primarily VBA, Matlab.
The missing puzzle piece here is that languages also imply APIs and Frameworks - which are beast in themselves. Rails is mentioned in the article. Understanding Rails, in context of a serious application, is a huge piece of work... And in many ways very different from knowing Ruby as a language.
If you're going to learn a language you probably want to learn a canonical framework for that language... which can be a much bigger (and maybe rewarding) process.
Readit News
But at the same time, there are some deeply weird languages out there. These contain some absolutely fascinating ideas. And if you follow the advice in the article to learn "every" language, then these languages will still surprise and perplex you.
- If you go deep enough in Haskell that you stop being confused by monads and start being confused by "free monad interpreters", then Haskell will provide you with a nearly endless source of complex, powerful abstractions—more than enough for any 10 other research languages.
- Mozart (http://mozart.github.io/) is a concurrent logic language with a constraint solver. Even if you're familiar with Prolog and Erlang, this one's going to blow your mind.
- Coq (https://coq.inria.fr/) is a language for formally proving the correctness of the things you compute. (You typically also write your programs in Coq.) There are also other, newer languages in this space. These languages have a steep learning curve, and they're challenging to work in, but they're extremely interesting.
Learning exotic programming languages is fun, and it means that you'll rarely be surprised by any new popular language. But despite this article's suggestion to "learn every language", you won't run out of strange new languages any time soon.
The book is cool, basically introduces a simple model of an abstract computer and defines some operations, and then expands upon that throughout.
I did something like this in 2016, learnt Clojure, OCaml, Haskell, Go and Racket. Took Dan Grossman's excellent Coursera course on learning language fundamentals and paradigms across Ruby/ML/Racket. Though I can code basic to medium level toy programs in all these languages now I wish I had followed Dave Thomas' (of Pragmatic Programmer fame) advice of concentrating on only one language a year.
My advice would be pick only one language for 2017 and then think and code only in that language for the year (for your learning projects - of course you'll be using other language for your $DAY_JOB).
In 5 years you'll know how to use 5 tools really really well and your brain will be much better aware of which of these tools is the right tool for which kinds of problems.
The more languages you know (lots of width), the more you can compare to others as you learn (gaining depth), and the faster you can assimilate new ideas as you go. Analogously, its as if while digging into one language you discover a cave-tunnel that connects you back up to another language you are familiar with. This saves you from having to dig all of the tunnels yourself because you can see how deep concepts in one language can be connected across your broad familiarity (width).
IMHO, I hate approaching tasks with a rigid mindset, whether its "LEARN EVERYTHING" or "LEARN ONE THING". I think its better to just encourage yourself to investigate something because you're interested in it, and then see where it leads you.
For instance, I'm digging into Clojure right now myself, and after watching a Rich Hickey talk about immutability and concurrency, I became curious about how GPU's work, and if they could be used with immutable data structures. Now somehow I've gotten into learning about OpenCL and CUDA and am having my mind blown about the possibilities of using a GPU as a massively parallel processor (concurrency isn't possible on GPU's though). If I were strict, I would've blocked myself from diverging from the Clojure path, and I would not have learned anything about the wonders of the emerging field of Heterogeneous Computing Languages.
Essentially, which are these few common paradigm languages that teach you more than 90% of what's out there? My guess would be to include something like C and LISP, but is that enough?
Apparently Philip Wadler came up with this notion, so your already-mentioned Haskell should suffice ;)
> idris for dependent types
Are we still on "Essentially, which are these few common paradigm languages that teach you more than 90% of what's out there?" or are we by now in the territory of "which languages to cover every single remotely-computation-related notion anyone ever conjured up and managed to somewhat implement"? ;D
* Procedural: c / pascal / basic / fortran
* OO: c++ / java / c#
* Dynamic: python / ruby / javascript
* Funcional: lisp / scheme / clojure / haskell
* Logic: prolog
* Query: SQL
* Assembly
Learning something of each category should prepare you for almost everything!
In a proper object-oriented language, everything is an object, including these. That allows you to do some really interesting things which are at the heart of the OO mindset. e.g. Smalltalk avoids having to use conditionals almost completely via dynamic dispatch:
b is a Boolean; ifTrue:block is an abstract method called on Boolean. But the values true and false are actually instances of subclasses of Boolean; True's implementation of ifTrue evaluates the block, and False's doesn't, and that's how you get different behaviour depending on whether b is true or false. The core language neither knows nor cares that booleans are special.(Actually, the bytecode does care, and has special accelerated opcodes to make operations of booleans fast for performance reasons, but that's just an implementation detail.)
This way by covering the extreme ends of the spectrum from (A) gratifyingly roll-up-your-sleeves-and-get-your-hands-dirty petal-to-the-medal (heh) systems programming to (Z)abstractions-all-the-way-up-and-down-and-sideways algebraic-typed purely-functional glory.
With current-day concurrency approaches, easy-networked-ness etc thrown in natively in any of the above.
Once proficient in these "spectrum extremes", anything in between should be relatively easier to get up to speed with
So instead of "In 2017, learn every language" I would say "In 2017, learn every programming paradigm".
My personal strategy is to try to learn enough of a language "to be dangerous". This means you can create working code with it, probably not 100% idiomatic, and probably reinventing the wheel in many ocassions.
The good thing is that it in my opinion the 80/20 rule applies here, as it takes 20% of effort to learn 80% of a (programming) language. The largest benefit is that you are going to be able to try many different languages and decide if you want to keep digging deeper into it. Heck, maybe you love a programming language so much you would even accept a new job just because you want to program in that language.
For the record, in 2016 I tried Go, Rust, Clojure, Elixir, Crystal, Swift. My personal favorites this year are Clojure and Elixir. But all the other languages have their own niches with lots of potential. I'll be keeping an eye on them.
So yes, have a general knowledge of programming that applies to different languages with ease, but focus on getting very productive with the language that you use all the time. For me, my focus is dictated by my work: primarily VBA, Matlab.
If you're going to learn a language you probably want to learn a canonical framework for that language... which can be a much bigger (and maybe rewarding) process.