
In 2017, learn every language - adamnemecek
https://blog.bradfieldcs.com/in-2017-learn-every-language-59b11f68eee#.oys0e7tqo
======
ekidd
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/](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/](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.

~~~
mercer
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.

~~~
acchow
Haskell or Ocaml

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

~~~
kiloreux
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 :) .

~~~
marai2
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.

~~~
lgas
I think this really depends on what your background is and what your personal
expansion of "understand" is. Assuming a cold start (which would never
actually be case), with your approach it would take seven years to get through
eg. Assembly, C, Java, Haskell, Prolog, Factor and and J. Obviously you would
have a better understanding of each paradigm and their strengths, weaknesses
and tradeoffs after seven years of study than someone who tries to get through
all seven in 2017. But that person will have a much better understanding of
all seven paradigms in one year, whereas you will have no basis to compare the
single language you've learned in that year to anything else.

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

------
kensai
"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?

~~~
spapas82
Here are my recommendations, each category has a really different programming
paradigm than the others:

* 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!

~~~
david-given
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.)

~~~
dualogy
Luckily I first encountered "OO" after having already learned the concept of
structs/records in Pascal, this way I did not have to seriously entertain the
idea that simple scalars oughta be anything-but..

------
anondon
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".

~~~
jghn
While I'm ultimately not a fan of the books themselves the "Seven Languages in
Seven Weeks" series tries to do exactly this.

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

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

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

------
randcraw
Likewise I've learned to use every carpentry tool. Unfortunately many of 'em
tend to shatter when I hammer a nail with it...

------
ChuckMcM
So funny anecdote, I once asked a candidate which programming languages he
knew and he replied "All of them, BASIC, FORTRAN, and COBOL." :-)

More seriously though the point in the article is solid, all computers have
broadly similar architectures and the number of concepts needed to express
computation on those architectures is finite, so starting with a language in
each "category" of expression and and then adding additional languages in each
category can quickly teach you the essence of computing. At that point a new
language can be quickly picked up and mastered once you've mapped the
essential concepts to the idioms of the new language.

------
mindcrime
Love it. Many years ago I read some advice somewhere to "learn a new language
each year". And while I'm something of a language junkie, I never actually
stuck to that. But lately I've been getting more aggressive again about adding
new languages to my repertoire. In 2016 I spent a lot of time with R and
Octave, and started brushing up on Python again.

Going into 2017, I've started spending a lot of time on Prolog just recently,
and am hoping to spend some serious time on Scala and Figaro soon.

How valuable all this is from a career standpoint can be hard to quantify, but
if nothing else it's just plain fun to learn new approaches and new languages.

------
nickpsecurity
On top of this one, there's another discussion of this article on Lobsters
that the author is participating in:

[https://lobste.rs/s/peldje/2017_learn_every_language](https://lobste.rs/s/peldje/2017_learn_every_language)

Has some recommendations, reviews, & critiques on various books & learning
strategies people here might be interested in. Here's a repost of my comment
on the article:

"Consider a Scheme resource like How to Design Programs for its combination of
easy modification of syntax and DSL’s. Additionally, OMeta, TXL, or the
original paper on Meta II for transformation-based languages. Paul Morrison’s
stuff on flow-based programming. Hit them with Datalog or Mercury on
declarative side on top of whatever foundational logic they learn so they see
its practical power. Formal language like Coq with Chlipala’s Programming with
Proofs might be icing on the cake so they can see programs get engineered from
precise specifications with provable correctness. Should come in handy in
debates on whether programming is engineering or not. ;) Lightweight version
of that would be SPARK Ada that can automatically prove aspects of imperative
programs due to clean design. Or design by contract with that, Ada 2012, or
originator Eiffel. If doing parallelism, show them an inherently parallel
language like X10, Chapel, or ParaSail. Erlang should come up if we’re talking
high concurrency and reliability in same sentence."

------
powera
Being pedantic, what does he mean by "learn"?

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.

------
c8g
similar HN discussion: 27 languages to improve Python[1]

[1]:
[https://news.ycombinator.com/item?id=10380118](https://news.ycombinator.com/item?id=10380118)

------
mpweiher
I noticed that we have

\- class abstraction

\- functional abstraction

\- syntactic abstraction

\- declarative specifications

\- parallelism

Where is _architectural abstraction_?

------
joshbaptiste
nim-lang is my language to concentrate on in 2017

------
Manishearth
I sort of did this a couple of years ago without exactly realizing what I was
doing. I learned a bunch of languages and played around with them for fun.
Many were functional, many were not. I deliberately tried to learn languages I
felt would be different from what I already knew, so I didn't even touch
languages like C# or Ruby. It was a fun few weeks, and I got a better mental
idea of a general framework of thinking about languages. It was effectively
the "go meta" thing (the wording of that section of the post really resonated
with me) -- I stopped thinking of languages as their own special snowflakes to
be learned, and instead each language was a cocktail of features I already
understood, wrapped in their own special-snowflake syntax (which doesn't take
long to pick up). At some point I implicitly understood that it wouldn't be
much effort to be useful a new language if I wanted to. I was an idiot student
back then, so I never consciously realized this I think -- it just affected my
decision making (e.g. "I need to code in perl to add this feature to my irc
client? Doesn't sound too hard.")

This exercise became immensely useful, because while it doesn't give you the
ability to write new codebases from scratch in $randomlanguage without needing
to put effort into learning it, it does give you the ability to make
nontrivial changes to codebases in $randomlanguage by looking at the context.

An explicit realization of exactly what skill I'd gained came a few years
later at one of my internships. My own project was in Java/C++ with some GLSL,
all languages I had used before. The project itself was very interesting, but
my manager was super busy and I was finishing work pretty quickly so I'd often
have nothing to do. A fellow intern had a very large C# project that I found
pretty interesting. Involved a server-side backend, client-side app, phone
app, and a lot of communication between them all. This intern was very smart,
but had never had the chance to learn new languages or the general concepts
used in building such things. He was learning, but would often ask us (me +
another somewhat-bored intern) for help. Now, I didn't actually _know_ C# at
this point (none of us did). Never coded a line of it in my life. But I was
able to pattern-match the code I saw with concepts I already understood and
explain things. At some point I realized that I was _teaching_ my friend a
language that I didn't know in the first place. This blew my mind, and I
gradually had a conscious realization that I could do this with most languages
provided they didn't bring something too radical to the table.

\---------------------

My personal list of languages I tell folks to learn are:

\- C++ because it has so many unique features. This usually covers for C as
well. D may be a decent substitute since it has a lot of overlap with C++s
features, but they're designed to better work together. I suspect that
learning D will not let you automatically hack on C++ code without learning
C++ first, but the reverse would be easier.

\- assembly

\- A GCd OOP language like Java or C#

\- Haskell

\- Lisp

\- Some flavor of ML. Rust or Swift can substitute here, but it's better to
just pick up an ML.

\- Something for the GPU (GLSL)

\- Something with affine/linear types (Rust?)

\- Something with dependent types (Idris -- I have yet to properly dig into
this one myself)

\- Javascript. Also has a lot of interesting bits.

\- Some dynamically typed scripting lang like Python or Ruby.

It's important that you cover programming styles, not just features -- e.g.
Lisp is there not because of its features, but because of the way you program
in it.

------
hacker_9
_" After learning a few more languages myself, I came to realize that they
were all less diverse than I had anticipated. After some more study, I started
appreciating some of the underlying models of computation and programming
language theory that make most languages look like different versions of the
same basic ideas."_

Yep despite all these language wars, they all really are the same ~10 ideas
shuffled around in a different priority queue (type safety over dynamic, camel
case over snake case, AOT over interpreted etc).

I'm surprised the author advocates learning new languages after this insight,
especially Rust and Go which are again just a reshuffle of the status quo
(followed by the need to re-create everything in said language once again).

Instead of just re-learning the same ideas over and over under different
names, how about do something actually productive in 2017...

~~~
goatlover
There's no way you can maintain that when you compare very different languages
to one another, e.g. Scheme, APL, Haskell, Smalltalk, Go, Forth and Prolog.
They're all such different ways of telling the computer to do something, that
it isn't just the same 10 ideas being shuffled around.

~~~
hacker_9
Starting from a C# background:

Scheme - prioritized a 1:1 between syntax and the AST. Reshuffle the syntax,
remove the explicit type system.

APL - prioritized arrays.

Haskell - prioritized FP. Also introduced primitives to make things possible
with FP that you could do with OOP already (Monads etc).

Smalltalk - prioritized OOP.

Go - prioritized Concurrency.

Forth - prioritized Stack based.

Prolog - prioritized Stack based.

Really isn't that much insightful difference between these languages as you'd
think. Not taking away from their history, but you gain nothing from learning
them.

~~~
goatlover
That's a really simplistic way of thinking about language differences. Saying
that Smalltalk prioritized OOP is saying nothing about how Smalltalk is
different in all sorts of ways from Java, or how Self and IO are different
from both by doing away with classes, but closer to Smalltalk than C++. An
important addition with Smalltalk and Self are the environments they live in,
which are very different from most programming environments. Smalltalk was
designed to be part of an image-based GUI, with modification of live objects,
which includes the entire image, instead of text in files and folders, which
are separate from whatever editor is being used. That's a huge difference
(whether one prefers it or not).

And with APL, you leave it the not-so insignificant ability to use any
character one wishes, which is again very different from most programming
languages (whether one prefers it or not). It's not insignificant that an APL
program looks nothing like a program in most mainstream programming languages.

~~~
beagle3
I recommend an APL offspring to someone who wants to expand their horizons,
rather than APL itself: K (or a variant thereof), or J. No special chars
needed.

J used to be the only freely available, and with better documentation --
however, it is also a larger language. It seems that recently the K dialects
(oK, klong, kuc, kerf, xxl) are plentiful, freely available and well
documented.

It is also my experience that K is less frightening to most people - J uses
e.g. curly braces independently as operators, which looks a-priori broken to
most people (rather than just unintelligible like K does).

