
"I couldn't really learn Erlang, 'cos it didn't exist, so I invented it" - chops
http://erlang.org/pipermail/erlang-questions/2013-January/071949.html
======
ghc
Just for a moment, consider who this man is and what he has done. We would all
do well to take a step back and consider his manner of response. Notice that
he continued learning new languages after creating Erlang (instead of just
evangelizing it at the one true language). He did not immediately say "choose
these three languages" as if they were the only ones you could possibly learn.

Does it really help our profession/hobby at all if we engage in language-
elitism and snark? Even on Hacker News I've seen vitriol directed at Ruby,
Python, Javascript, Haskell, to name a few recent targets. All languages have
their place, even if that place is only as a lesson for future language
designers.

Encouraging people to _build stuff_ , whatever the language, whatever the
library, whatever the framework; __that __is what we should be doing. IF
someone wants suggestions, or help deciding what to use, that is fine, but
criticizing someone for the language or framework they use has become all too
common and a stain on the character of our community.

That's not to say honest criticism is unwelcome: All
languages/libraries/frameworks/software can improve. But to belittle people
for the choices they make, or to segregate ourselves into voluntary language-
ghettos we are compelled to stay in by the force of public opinion...that goes
against the spirit of what people like Armstrong worked hard to build. Maybe
it started with "Worse is Better", maybe it started with alt.religion.emacs
being taken a little too seriously, but it has been perpetuated by all of us,
even Paul Graham (in Beating the Averages).

At some point, this has to stop. We, as a community, must grow to support the
betterment of hacking by creating and encouraging creation; not by petty
vitriol and conformism based on fashion.

Now, I've strayed pretty far from the point of the post itself, but Armstrong
closed with such a salient point: If we stopped bickering so much about what
is the "right language", "right framework", "right library" and instead
encouraged particular protocols and documentation standards we'd all be better
off for it.

~~~
JPKab
I found it revealing that he appeared to not only like Javascript, but liked
it better than Python and Ruby. Interesting. I personally have grown to love
coding in Javascript, but I'm a dumbass who doesn't know Lua, Erlang, Haskell,
etc. It would be interesting to hear his perspective on JS.

~~~
SoftwareMaven
I know quite a few languages, and I like Javascript. It has a nice mix of
functional, procedural, and object oriented aspects. Once upon a time, it was
a horrible language to work in (with browser differences making it infinitely
worse); but now, I find I like it.

Now, that said, given the choice, I'd choose coffescript. It gives many of the
same benefits in a more concise format. It has its warts as well, though,
reflecting its desire to stay as close to a concise-javascript as possible.

~~~
zackmorris
I feel like coffeescript largely exists because of early mistakes in
javascript, like no heredoc and places where they weakened the language to
make it more convenient, like this one I just discovered today (with
workarounds) <http://stackoverflow.com/a/14510952/539149> and js has a ton of
problems because it separated Array and Object, but overall I think it's still
probably my favorite language right now. I like lua too but it's less pure, so
aspects of it remind me of older languages like pascal.

------
h2s
For when the moderators inevitably change this post to reflect the page's
actual title, here's the title under which it was originally submitted:

    
    
        I couldn't really learn Erlang, 'cos it didn't exist, so I invented it

~~~
DigitalJack
Surely it's a piece of Arc doing that. I can't imagine time and time again
somebody is wasting their time changing titles.

Perhaps the delay is from the software waiting for a good (low load) time to
fetch the page.

~~~
MiguelHudnandez
The perfect low-load time to do something like that would be upon submission,
before the link is shown to anyone. Also it's a good time to make sure it's
not a 404 or 500.

I think the titles are manually changed, because plenty of times descriptive
titles are left intact.

------
programminggeek
What is most interesting here is the ideas about protocols and communication.
To me, that's what much of software development is getting wrong both on the
small and on the big.

In a single app, objects should talk to each other and databases and queues
and junk via protocols, not by being glued to an ORM or a particular
implementation of a queue or whatever. Most devs don't do this because it's
more work, but you end up with a much cleaner/more testable structure to work
with.

On a higher level, many/most programs aren't made to communicate with each
other at all. Look at web software, it's all about communicating with a
browser and that's it. The API driven movement is helping things along, but
it's still a HTTP Browser driven mindset complete with holy wars about
REST/Hypermedia.

Unix pipes are a great example of what is possible with standard communication
protocols, but it seems like it could be taken further. What if you could pipe
a stream of API's together? Yahoo's YQL and Pipes plays in this realm, but you
still have to kind of glue pieces together yourself.

Imagine if you could say...

fb search --name 'John Doe' --location 'Chicago, IL' | linkedin --filter 'Ruby
Programmer' | twitter tweet 'Hey check out our ruby meetup next week'

That's a somewhat contrived example, but it would be great if we could do
something that simple and not just via a command line, but from any language
in a similar amount of code. That would be a step forward I think.

------
sambeau
I spat my coffee out at this bit:

    
    
        if you want a quick fix go buy 
        "learn PHP in ten minutes" and spend
        the next twenty years googling for 
        "how do I compute the length of a string"

~~~
Joeri
He's right though, PHP has no reliable way to obtain the length of a string in
characters, unless you keep track of which character set a string is in and
carefully manipulate the mbstring functions.

Doing multibyte string handling properly in PHP is way harder than it should
have been.

~~~
sambeau
I spat my coffee out laughing. Because he is _so_ right.

------
krenoten
Here's an interesting lecture (sorry, I couldn't find a non-split version) he
gave at a university in Sweden (where Erlang has a much greater influence,
ahhh the sanity of Northern Europe ;P) note - the sound is dim for the first
few moments <http://www.youtube.com/watch?v=9uIhawQ1G0I>

He goes into some of the choices that went into Erlang, and some interesting
experiences he had as the project went forward. He gives a different list that
he feels the students in attendance should learn: C, JS, LLVM Assembler, one
of ruby or python, and one of Erlang or Haskell.

------
DigitalJack
I have to say this made me feel better that I'm not a wizard in Clojure. If
one could be said to be "in love" with a programming language, that would be
where I am at with clojure in terms of feelings.

But I've only scratched the surface. I sometimes sit and watch the #clojure
channel on freenode, and I find it inspiring, interesting, entertaining, and
disheartening all at once.

Inspiring because I get to see the people who write the awesome software and
write the terrific books interacting, and I'll be danged, they are kind and
good people!

Interesting because of the problems they are working on and discuss, asking
each other for advice or just plain help.

Entertaining because they aren't just kind and good, they are also
lighthearted sometimes very funny.

Disheartening because sometimes I look at the pastebin code, or the code they
message to the clojurebots, and I am left scratching my head.

However, having read this "oldtimer's" post, I'm inspired to know that it's OK
to not become a master in programming in 24 hours.

------
_nato_
Joe is fearless and an inspiration. For those with 25~ dollars to spare, pick
up Joe's 'Programming Erlang' and never regret it. I _think_ differently after
reading that book. I am mainly a musician, but what he uncovered for me
regarding our brains and how we think blew me away.

~~~
jasonlotito
Just going to second this comment. First, for reference, here is the book
mentioned:

<http://pragprog.com/book/jaerlang/programming-erlang>

But yes, I agree, the book is an excellent, enjoyable read. I wish I had more
opportunities to use erlang in my day job.

------
Irregardless

      What would I recommend learning? 
          - C
          - Prolog
          - Erlang (I'm biased)
          - Smalltalk
          - Javascript
          - Hakell / ML /OCaml
          - LISP/Scheme/Clojure 
      A couple of years should be enough (PER LANGUAGE).
    

A 'beginner' should start by spending 14 years (minimum) learning 7 languages?
I was starting to agree with him when he mentioned the paradox of choice that
programming beginners face today, but that recommendation is beyond ignorant.

Becoming a veteran polyglot is not the _only_ way to break into the
programming field. This is exactly the type of elitist BS that we don't need
-- scaring beginners away by giving the impression that they face an
insurmountable cliff from the start.

Should we also mention that they need a minimum of 3 master's and 2 doctorate
degrees? I don't think I've heard of a single successful programmer with
anything less. Surely no one has ever dropped out of college and acquired vast
amounts of wealth at an early age by programming.

~~~
stiff
This is a general problem with asking masters in some discipline about the
best way to learn - they almost always tend to recommend simply doing what
they did, but they do not say "I did x, y and z", but "x, y and z are the best
way to learn" and what is worse some people actually take those
recommendations seriously.

The problem with this is twofold: first, the times are always changing and
yesterdays path is seldom adequate today anymore and second, progress is made
by the younger generations not having to repeat the mistakes of the older
ones. So, if you want good recommendations for learning, ask the people who
actually teach others on a daily basis. I think 2-3 good courses in
programming languages can compress a lot of the knowledge you would gain
following this recommendation in a much shorter period - "Structure and
Interpretation of Computer Programs", "Concepts, Techniques and Models of
Computer Programming" and "Programming Language Pragmatics" are three
excellent textbooks that go in this direction.

But then, if you strive for mastery, and I think that's what Dr. Joe Armstrong
is interested in, it is nothing exceptional to spent 15 years learning.

------
peteretep
"Hello, Joe?"

<http://www.youtube.com/watch?v=xrIjfIjssLE>

~~~
laumars
Joe Armstrong did help create Erlang with Bjarne Dacker:

 _Erlang was created at the CSLab by an initial team of Joe Armstrong, Mike
Williams and Robert Virding._

[http://www.erlang-
factory.com/conference/SFBay2010/speakers/...](http://www.erlang-
factory.com/conference/SFBay2010/speakers/BjarneDacker)

~~~
peteretep
Unless I'm mistaken, you can see him in the link posted, too, making phone
calls to the other developers...

~~~
laumars
Ahhh that's what you meant by your post.

Your original comment was a little cryptic (either that, or I've not had
enough coffee today hehe)

------
lucian1900
Proper schemas (based on an algebraic type system) with a simple serialisation
would indeed go a long way.

Sadly, there's still too much choice there as well. Even worse, many would
reject the very idea.

------
politician
Navel-gazing aside, Armstrong suggested that a good language would consist of
closed forms interacting over formal protocols. What languages fit that
description?

~~~
teamonkey
CORBA springs to mind.

~~~
politician
Terrifying.

------
S4M
>> Notice there is no quick fix here - if you want a quick fix go buy "learn
PHP in ten minutes" and spend the next twenty years googling for "how do I
compute the length of a string"

I couldn't agree more on that one.

~~~
rtpg
If he were talking about actually thinking about programming techniques I'd
agree but here he's talking about languages, and while the languages he lists
are sufficiently different, saying it'd take years to master lisp after
working in ML, or learning Javascript after knowing C. After the first couple
of languages learning new abstractions shouldn't really take that long.

In an ideal world easy programming solutions can be easily explained in the
right language. We're not quite there yet but doing quicksort in ML doesn't
require 5 years experience.

------
hellerbarde
This is very well written. A very interesting and verbose (not in a bad way)
way of answering the everpresent question "What language should I learn?"

PS: Yes, I know that not the whole discussion was about this question. Still.

~~~
minikomi
I'm pretty blown away by how well written and _civil_ a lot of posts are on
this thread.

~~~
rdtsc
Erlang mailing is a pleasure to read. Even as mix of different ages and
experience levels (heck, Joe is a regular poster), the conversation is always
civil.

I read it every day along with hn and a few other blogs.

<http://erlang.org/pipermail/erlang-questions/>

~~~
minikomi
Hmm... hn has been doing a very good job at convincing me to get my feet wet
with erlang lately :)

~~~
rdtsc
I certainly love it.

If anything it helps think differently when facing problems. It makes you
think about reliability, fault tolerance and concurrency in a new way. It is
just as much a language as it is a new paradigm.

There some languages and toolkits started to copy some features from Erlang
(Rust, Go, Scala's Akka, ...) they are all still pretty far from it in terms
of providing the whole ecosystem (the full package).

Also Erlang has a great VM behind it (BEAM). It has a completely concurrent
garbage collector and other nice things. That's why I am also excited about
Elixir (I think there was a post here about that as well).

------
sgt
>> Things improved - I went to CERN and used the CRAY1 this could compile 100K
lines of FORTRAN in 1 picosecond (ie about a zillion times slower than my
mobile phone today)

Sarcasm doesn't translate well in a thread like this, so just in case someone
really thought it could compile 100K lines in a picosecond, dream on. :-)

~~~
venus
I don't think it's sarcasm so much as exaggeration; compared to the hours,
days or even weeks he had to wait in the past, it sure seemed like a
picosecond.

Sarcasm would imply he was somehow denigrating or mocking CERN and/or the
CRAY1 and I didn't get that vibe at all.

------
s_husso
>> The crazy think is we still are extremely bad at fitting things together -
still the best way of fitting things together is the unix pipe

Is that sad or pure genius?

~~~
laumars
I struggled with that point of his. From a coding speed perspective, he's
right. But from an efficiency perspective, even some of the slowest
interpreted languages will run circles around a shell script.

However it's still an interesting and thought provoking point. It makes you
wonder about other ways of plugging different objects / modules together.

~~~
anon1385
Is efficiency the biggest problem? It seems to me the bigger problem is that
streams of raw bytes over pipes is the wrong level of abstraction for most
tasks; at least we seem to have decided that is the case when we are writing
code within a program, so I don't see why it shouldn't extend to interprocess
programming. I don't see people recommending only defining functions that
accept single dimensional arrays of bytes (rather than strings and trees and
hashmaps and multidimensional arrays and so on), even when programming in C.

You end up with every tool containing code to parse a stream of bytes into the
appropriate data structures, and then probably also write them out to a stream
of bytes too. The user has responsibility for a lot of data munging too. It is
error prone and repetitive, at least when dealing with anything other than
very simple text files containing lines of strings where you know which
encoding has been used. (Re)using libraries that read and write more
structured data is likely to get you flamed[1]. The history of Unix contains
plenty of security problems due to people not correctly accounting for nulls
or control characters or spaces etc when chaining together commands (although
this is more of a problem with shells than pipes themselves). The output is
often not friendly to human eyes by default (I'm thinking of things like
localised date and time formats, number formats and so on) since it has to be
suitable for passing to another program, unless you use more options or
another tool to reformat it.

I would compare it to working with raw memory in C. It's the lowest common
denominator, you can do anything, but it's also trivial to screw up and there
is a high cognitive overhead. Perhaps it's just too hard to introduce anything
higher level at this point.

Perhaps my opinion would change if I spent years (deeply) learning unix tools,
but maybe that would just be because I had invested so much time learning a
complicated system.

~~~
laumars
Unix pipes are effectively the same thing as using text streams in C.

Granted not quite the same thing, but raw bits are often used in lower level
languages. Take Windows Win32 APIs, there's a lot of instances where styles
are defined by adding constants with values being exponentials of 2. Thus
creating a binary array of boolean states.

Another example I used to run into was Windows' controller (joystick et al)
API (again Win32). Each bit would represent a different controller button and
the 'on' state was if the button was depressed. But as the value was returned
as an unsigned long int (if memory serves), it was up to the developer to
write their own parser to convert what would otherwise been a random number
into a meaningful array of bits. (or at least I did - there is a chance I
overlooked another function as this was before I made the switch to DirectX6 -
so many years ago!)

------
ricardobeat

        if you want a quick fix go buy "learn PHP in ten
        minutes" and spend the next twenty years googling for 
        "how do I compute the length of a string"
    

pretty much summed up the PHP experience :)

    
    
        If ALL applications in the world were interfaced by 
        (say) sockets + lisp S expressions and had the 
        semantics of the protocol written down in a formal 
        notation - then we could reuse things (more) easily.
    

nodejs apps are usually very close to that: small modular services interacting
via sockets + events using json, protocol buffers, etc. Much like the unix
pipe philosophy applied to servers.

If you didn't study CS and want to improve your knowledge of algorithms, I
found Coursera classes to be very good.

------
jeffdavis
In many ways, SQL is the protocol by which we combine programs together.

~~~
dragonwriter
SQL is not a protocol in the sense that Armstrong is using, which is
(approximately, at least) a specification for the acceptable messages
(including state transitions that change the acceptable messages) over a
communications channel between two processes.

~~~
jeffdavis
Well, it's not thought of as a "channel between two processes". Maybe more
like a hub, except it actually stores data (which is similar to an async
protocol that buffers/queues messages).

But that's all kind of irrelevant. The purpose that a database serves is a
good replacement for other kinds of IPC. It imparts meaning to data and allows
applications to communicate in a common way.

Think about it this way: every language has a different way of representing
some missing value -- null, nil, undef, Nothing, None -- and all are slightly
different. But the application is probably influenced by SQL NULL semantics
more than any of those. (EDIT: reworded this paragraph)

Databases pretty much own everything, which is something I think that language
people should spend more time focusing on. Maybe the reason that cool new
language isn't 2X as productive as python is because you are still using the
same database. Language designers need to focus on _informed_ innovation in
the database space if they really want to make an impact.

"including state transitions that change the acceptable messages"

That sounds an awful lot like DDL to me.

------
dysoco
I'm interested in Erlang, have read a lot of good things about it lately.

However I've not tried it yet because I don't see how it is going to help
me... I already know some functional programming (Scala, Haskell) and I don't
work with large, distributed software or databases.

I'm afraid I'm going to learn it, not finding something useful to do with it,
and then "forget" it.

~~~
danieldk
> I'm afraid I'm going to learn it, not finding something useful to do with
> it, and then "forget" it.

I am more or less in the same boat. I picked up 'Learn You Some Erlang for
Great Good'. Fun book, fun language, what other motivation does one need? ;)

------
AlexDanger
_The crazy think is we still are extremely bad at fitting things together -
still the best way of fitting things together is the unix pipe_

This is something that resonates with me. I'm never been a 'nix person but
this is a very attractive pitch for getting stuff done. It is, after all, how
we build things with LEGO.

I went to a Java school so my OO indoctrination was strong by the time I
graduated. Now I'm really starting to crave a development paradigm by
composition rather than inheritance. My job title is no longer that of a
programmer but I write utilities and library daily to help me with my 'real'
job. It helps me get stuff done.

So my question - since I primarily work in the MS world, does PowerShell offer
the same flexibility and utility of the Unix pipe? I'd never thought of taking
the time to learn it until reading this post.

------
melvinmt
I'm curious to see what Joe thinks about Go.

~~~
codexon
I was evaluating both languages recently, and the biggest distinction is that
Erlang does context switching per "reduction" or function call while Go does
context switches only when a go-routine explicitly yields or a message is
sent/received.

This means that Erlang can get finer time shared concurrency at the expense of
speed.

Anything other differences such as syntax is relatively trivial.

------
JBiserkov
> A couple of years should be enough (PER LANGUAGE).

Reminded me of <http://norvig.com/21-days.html>

------
gobengo
What a great writeup by an experience programmer.

------
nanoscopic
This person may be "important", but a lot of the comments about languages seem
to be borderline flamebait. Also, the mention of -many- languages, but the
deliberate lack of any mention of Perl seems odd to me. I really dislike PHP
myself, but there is no need to bash it.

------
blumentopf
"In the beginning I looked around and couldn't find the car I dreamed of. So I
decided to build it myself."

("Am Anfang schaute ich mich um, konnte den Wagen von dem ich träumte, nicht
finden. Also beschloss ich ihn mir selbst zu bauen.")

\-- Ferdinand "Ferry" Porsche on inventing the 356

------
dexcs
I wish i had the time to learn that much languages and spend couple of years
per language... I think the problem today is that we try to learn 3 or more at
the same time what often results in bad code....

------
ericbb
I'm not big on IDEs either but how can you dislike revision control?

------
guard-of-terra
"Things improved - I went to CERN and used the CRAY1 this could compile 100K
lines of FORTRAN in 1 picosecond (ie about a zillion times slower than my
mobile phone today)"

I don't like how he mixes together some precise numbers (, RAM size) with
completely unrealistic (you can't do anyting in a picosecond, you can't
compile 100k likes of code without noticing the time it takes the even today
on any hardware.

~~~
huherto
yeah, yeah, I was also confused. But see the comment of sgt below(or above).
It is sarcasm.

------
3pt14159
To me, this list is great except for one small thing.

    
    
        - C
        - Prolog
        - Erlang
        - Smalltalk
        - Javascript
        - Hakell / ML /OCaml
        - LISP/Scheme/Clojure
    

Javascript?! Over Ruby or Python or Lua? What is it with people liking
Javascript. I really don't get it. What can I do that is so beautiful or
mindbending that I can't do in python?

From my experience there is only two reasons to learn Javascript: to be able
to build web applications, or to write document store queries (MongoDB or
Riak, although in Riak you can also use Erlang). Otherwise I just don't see
what the big deal is.

~~~
klibertp
Argh. How could you read this post and _still_ miss the point so badly?

It is _not_ about languages, it is about _ideas_. And the fact that you need
_years_ to master _each_ of these languages because of ideas they are built
upon, not because of such trivial things as syntax.

I strongly suspect that Joe would be equally comfortable with this list was C
substituted with Go, Smalltalk substituted with Io or JavaScript substituted
with Lua.

To paraphrase: "what is it with people _liking or not liking_ JavaScript"? I
know what is it with these people: they are noobs (sorry in advance, this is
not intended as offensive). I have been programming for _just_ twenty years
now and I just recently, a few years ago, understood all this, so I'm not
exactly surprised by your post, but still, I thought that email so well
written as Joe's here would repel this kind of "Javascript is bad, use
WhatEver(tm)" talk.

It seems I was overly optimistic with this one.

~~~
davidw
> trivial things as syntax.

Syntax is not trivial. You stare at something 10 ours a day, you want it to be
a good user interface.

