
Why Erlang looks like it does - joeyespo
http://erlang.org/pipermail/erlang-questions/2015-December/087223.html
======
lectrick
This is a quite beautiful post about engineering in general, actually. You try
to solve a practical problem as best as you can, and you get sort of an
unintended-beneficial-consequences effect and end up creating principles that
have a more universally-applicable nature.

I personally hope Elixir helps thrust Erlang into ever more success. (But not
so much success that it becomes a victim of it...)

~~~
fizixer
Two sides to every story.

What is not beautiful is that:

\- the people who conceived the original idea of the 'Actor model' were not
appreciated enough, and their work had to languish in obscurity, during the OO
(object-oriented) hype era, before it was rediscovered and later the dots were
connected.

\- 'reinvention of wheels' is bad because it's inefficient.

\- Not to mention original OO idea by Alan Kay, in Smalltalk, was actually the
'Actor model' but it ended up being very misunderstood when implemented in
C++, Java, etc, with the term OO being hijacked.

~~~
signa11
> Not to mention original OO idea by Alan Kay...

i was kind of curious about this statement, so i looked up the history of
programming languages
([http://cdn.oreillystatic.com/news/graphics/prog_lang_poster....](http://cdn.oreillystatic.com/news/graphics/prog_lang_poster.pdf)).

if you take a look, it would seem to _suggest_ that smalltalk borrows from
both simula-67 and lisp. wikipedia page for simula-67 suggest that it
(simula-67) "introduced objects, classes, inheritance and subclasses, virtual
procedures, coroutines and discrete event simulation, and features garbage
collection..."

now it might be _just_ possible that simula-67 was the first language to
incorporate those features in a language, and that alan-kay originally came up
with that idea, waaay before simula-67 came into being.

~~~
alankay1
No, I didn't come up with the idea before Simula -- but it did happen before
Simula-67 (which doesn't matter at all here).

How it happened is well chronicled in the history paper I was asked to write
by the ACM in 1992-3 "The Early History of Smalltalk" (i.e. why speculate when
most high res answers are available online?). Ivan Sutherland's Sketchpad was
the big first hit for me in 1966, and I saw the first Simula a week later.

Some of the confusion here is explained in the above link I wrote explaining
that what is called "O-O" is nothing like I had in mind. The term was
"colonized" because what we had been doing at Parc was powerful and we called
it "object-oriented". But the "low-pass filter of O-O" was that Bjarne
Strousrup decided to "do to C what had been done to Algol to make Simula".
This was a perfectly reasonable idea. We were quite a bit more radical at Parc
because we needed enormous amounts of expressability to invent personal
computing (and we could and did design and build hardware that was matched to
the radical ideas).

An interesting historical note is that the two inventors of Simula had
completely different views of what they were doing and how it should be used
for programming. Dahl was brilliant and conservative, and later wrote papers
about using class definitions to make Abstract Data Types (and that is how a
lot of so-called OOP programming is done today). Nygaard on the other hand was
quite a wonderful wild man and visionary -- beyond brilliant -- and was into
the abstract "simulate the meaningful structures" idea. Dahl was trying to fix
the past and Nygaard was trying to invent the future.

During the 1978 HOPL conference time, we were visited at Parc at two different
times, first by Dahl and Tony Hoare, to whom I showed and tried to explain
Smalltalk: they didn't get it, and this was very frustrating. A few days later
Nygaard showed up, and it was completely different: he got everything, and was
finishing my sentences after 5 minutes!

Back to the origins in '66: besides the biological metaphors I had under my
belt, I was also interested in the "virtual machines" ideas that were being
used to do multi-processes and time-sharing in a safe way via hardware memory
protection schemes (none of which I had had any involvement with inventing).
One of the things that popped into my head while contemplating Sketchpad and
Simula was that it would be just incredibly good -- and a huge improvement in
systems designs -- to be able to use protected processes as the sole building
blocks communicating only by messages that were not commands, but only
"suggestions".

I think I'd call this not an invention, but a "realization" \-- that the
recursive machine idea was already around, and what it lacked was scalability
downwards, so that all entities could be "protected virtual machines". A lot
of what I now have to call "real OOP" turned out to be some years of software
engineering in order to create a practical systems material that could scale
in all directions.

~~~
lobster_johnson
I had no idea that Dahl and Nygaard ever visited you at PARC, that's
fascinating. Growing up in Norway and learning programming in school, Simula
was revered as a proud if distant national accomplishment, in an field where
there weren't much else to be proud of (though this was also around the time
when Norsk Data [1] collapsed, and people weren't really talking about how
innovative they had been). I wish I had learned about Smalltalk back then; I
didn't really look closely at it until I learned Objective-C.

[1]
[https://en.wikipedia.org/wiki/Norsk_Data](https://en.wikipedia.org/wiki/Norsk_Data)

~~~
lectrick
"Throughout its history Norsk Data produced a long string of extremely
innovative systems, with a disproportionately large number of world firsts."

Still seems like something worth being proud of. It just got sideswiped by the
personal computer industry (a lot of things did).

~~~
lobster_johnson
Definitely. For example, not a lot of people know that Tim Berners-Lee
developed his first hypertext system, ENQUIRE, an ND machine (the NORD-16
minicomputer running the operating system SINTRAN) [1].

[1] [http://history-computer.com/Internet/Maturing/Lee.html](http://history-
computer.com/Internet/Maturing/Lee.html)

------
im_down_w_otp
My favorite thing about Erlang is that the syntax is so simple and terse. And
none of it is optional. So its either necessary or it isn't there, and this
saves me from a lot of ambiguity issues.

I also like that it practically reads like bulletpoints. There's no cruft or
decoration around function definition or internal statements. I was even able
to write my CV in Erlang after attemtping 3 other languages first (Elixir,
Rust, C) and Erlang was the only one where it didn't look like a jumble of
weird code and syntax, and was consumable by executives, engineers and
headhunters alike.

My only wish would be that Erlang adopted Elixir's atom syntax, or that Elixir
adopted Erlang's variable syntax, because then I could look at my code and
know immediately at a glance what was a function, what was a Variable, and
what was an :atom.

As it stands in Erlang atoms and functions look superficially the same, and in
Elixir the functions and variables look the same.

~~~
lectrick
I thought Erlang looked weirder than Elixir (to the extent that I was turned
off until Elixir came along), but fortunately, both of our opinions are
compatible as everything compiles down to BEAM and is interoperable :)

From a semantic persopective I've found that I almost automatically understand
Erlang just from working with Elixir. Some things like OTP are pretty much
identical. Plus you get "real" macros :)

~~~
rdtsc
Yeah good point, Elixir is not just Erlang with a different syntax. It has
streams, macros and a few other nice things. I believe Jose Valim likes to
emphasise that point as well.

Now I personally prefer Erlang's syntax. I like that it is different because I
know semantically stuff behaves differently. I would be more confused and
disturbed by it if it looked like Java for example. I also like the immutable
variables aspect..

However at the end of the day I am very happy to see Elixir grow. It really
has one of the friendliest and most welcoming community. It will hopefully
bring more people to the BEAM VM ecosystem.

~~~
lectrick
> I also like the immutable variables aspect.

Elixir has the same immutable variables. I don't know why this is such a
misconception. Erlang conflates rebinding and reassignment, Elixir does not,
and the tradeoffs seem to (overall) be better in Elixir's case. Here, read the
language creators' explanation as to why that is, it's the best:

[http://blog.plataformatec.com.br/2016/01/comparing-elixir-
an...](http://blog.plataformatec.com.br/2016/01/comparing-elixir-and-erlang-
variables/)

Very succinct and (hopefully) puts this misconception to bed.

------
dschiptsov
_Simple in the sense that there should be a small number of basic principles,
if these are right then the language will be powerful but easy to comprehend
and use. Small is good. This we managed to do._ \- this is what packer's
mindset would never understand. Nature doesn't work the way they think Java
should.

This, by the way, is the universal principle. As simple as possible, but
right. People who studied viruses and molecular biology in general would
understand.

The protein expression/DNA repair machinery is where one should look for
insights. That world is everything-is-a-firstclass, pure-functional, strongly
but dynamically typed (everything has its unique structure, which could be
used as a type-tag) and even duck-typed (if something binds to a receptor it
triggers an action), loosely coupled, asynchronous, timeless.

It should be easy to model cells and even organs in Erlang because it has been
based on the right smallest possible set of basic principles, or, at least,
close to it.

MIT Scheme sub-culture also has great insights about putting the right
principles first. So were Smalltalk or Plan9 guys.

------
BuckRogers
I've been playing with Elixir on the side and have picked Elixir as my
singular choice to migrate to after (or alongside) Python. Elixir/Phoenix
looks like a true "upgrade" and I really hope someday I'm in a position at a
company to initiate its adoption.

Unlike so many other newer technologies, even a new language like Elixir
running on BEAM bytecode is technically more mature than Node or Go. I could
make a very strong business case to adopt it within any organization.

And probably even end up making JVM based tech look like some sort of new
upstart project.

------
lkrubner
About this:

"Again our goal was to solve the problem, not design a language with a
predefined set of primitives."

I have the sense that Scala has followed exactly the opposite approach.

~~~
kyle4211
But that's not necessarily a bad thing!

I took a language design class in collage, and Scala was a great learning
language in that application.

~~~
signa11
> But that's not necessarily a bad thing!

hmm, i have a diametrically opposite opinion about it. languages (successful
ones at least) are designed to solve a problem, not prove a point :)

for example, lisp, c etc. all came into being because the designers found
nothing which would help them do whatever they were doing e.g. for lisp,
describe an abstract notion of computation, and for 'c' write fairly low level
code without dropping down to assembly etc.

if teaching 'language theory' etc. is the end goal of a language, and it's not
an unworthy goal at all, probably more 'syntax free' languages e.g. oberon,
scheme, lisp etc. might be better ?

[successful languages: imho, are the ones that have just stood the canonical
'test of time' and i would include only 3 here: fortran (blaspheme!), lisp and
C]

~~~
kungtotte
You really would limit your definition of successful languages to only those
three?

------
ninjakeyboard
Interesting. I've worked with Akka heavily over the last 3 years and that was
built borrowing many of Erlang's designs. I'm sort of suprised to see that the
language was not built with the intent of implementing the actor model. Fault
tolerance through supervision was introduced into the actor model here but the
way that state can exist and is isolated for high concurrency systems makes
the actor model very easy to build into and reason about in concurrent
scenarios.

Akka's addition to the actor model - location transparency - takes the actor
model a little further and coupled with Scala makes a really nice language and
concurrency pairing. Akka has the actor model as a library added where Erlang
has all of the qualities built into the language. I'd like to learn erlang
still but the contribution of the Erlang/OTP team in building fault tolerance
into the Actor model has been an incredibly important contribution. As highly
concurrent applications are becoming the norm with multicore CPUs being
everywhere, I can't see the actor model going away any time soon.

~~~
rvirding
One difference is that Erlang's concurrency and error handling in the language
is more basic than Akka's and does not directly provide fault-tolerance
through supervision but does provide the primitives to implement. All of OTP
is implemented in Erlang with these basic primitives. These primitives are
actually very simple, the difficulty was getting the right set of simple
primitives on which to build the rest.

Also I think you will find that a lot of features which are very similar of
Akka's location transparency were built-in to the distribution mechanisms
which are part of Erlang. We were at least thinking of distribution from a
very early stage.

------
n0us
I don't have any experience with Erlang but on a side note Elixir is really an
awesome language. Pattern matching is one of the neatest features I have ever
used and I recommend anyone to try it out.

~~~
rvirding
They got that from Erlang :-)

~~~
bpicolo
Who got it from elsewhere ;D

~~~
rvirding
Who got it from elsewhere. ;-) The sequential part of Erlang is basically a
simple functional language with nothing really unique, except maybe for
binaries. It is the concurrency and error handling where the really good bits
are.

~~~
crimsonalucard
Who did it come from? Haskell? ML?

~~~
signa11
according to wikipedia
([https://en.wikipedia.org/wiki/Pattern_matching](https://en.wikipedia.org/wiki/Pattern_matching))
SNOBOL in '62

~~~
fanf2
SNOBOL pattern matching is on strings; SASL is the origin of pattern matching
on algebraic data types.

------
perishabledave
For anyone interested in Erlang or Elixir, Virding has a great talk on the
Erlang VM. It's a good look on how BEAM implements its concurrency.
[https://www.youtube.com/watch?v=_Pwlvy3zz9M&feature=youtu.be](https://www.youtube.com/watch?v=_Pwlvy3zz9M&feature=youtu.be)

------
anfroid555
Once you learn it.. It's very easy and basic. This is what happens when you
choose the path less traveled.

------
jack9
> If you seriously look at the Erlang syntax you will find it is very simple,
> concise and consistent

You're serious and I'm not, gotcha. This adversarial attitude you assume,
isn't helping. Work on that first.

> I know and have used about 9-10 so far so what is really the problem?

The problem is that you think it's trivial and other developers overwhelmingly
don't. To be fair, it's only the first barrier to entry. After that you learn
the sad state of Erlang data structures and expected language
interoperability.

~~~
gjkood
jack9, isn't it a privilege to be able to interact with folks such as Robert
Virding (one of the co-developers of the Erlang language)?

I know of few other forums where such interaction opportunities are offered.

The fruits of their labour impact our lives and the lives of millions of
others implicitly every day.

Let us atleast be civil in our discourse.

I think they have done enough to earn some respect from us all regardless of
our personal opinions on their work.

~~~
cbd1984
> jack9, isn't it a privilege to be able to interact with folks such as Robert
> Virding (one of the co-developers of the Erlang language)?

Or, at least, people who take on such names on pseudonymous message boards.

------
jack9
The "look" of Erlang (and Elixir didn't really address this) isn't about the
primitives, but about the surrounding syntax and structures (records!). Nobody
looks at Erlang and asks, wtf is an atom. They look at the horrible mess of
the prolog structures and say "it's not worth it to learn" or worse, "let's
just rewrite it".

Also, the link seems strangely mistitled.

~~~
rvirding
If you seriously look at the Erlang syntax you will find it is very simple,
concise and consistent. We wanted to keep it simple. Yes, it different from
most OO languages, most functional languages look different, but that is not
surprising as the semantics of Erlang and other functional languages are very
different from the semantics of your typical OO and imperative languages like
Jave, Ruby and C. If it is doing different things why should it look the same?
That would just be confusing.

Also, if you again look seriously at the syntax you will see there is actually
very little Prolog in it, most of that disappeared along the way when it
became functional. What is left are variables, atoms and lists. Records are a
bit messy although they are very logical and consistent (again) but no one has
come up with an alternative that works. They also fit the language semantics.

Also I personally don't see the problem with learning another syntax. I know
and have used about 9-10 so far so what is really the problem?

And I rather like Prolog syntax, it simple, concise, consistent and truly
homoiconic though with operators.

~~~
YeGoblynQueenne
>> And I rather like Prolog syntax, it simple, concise, consistent and truly
homoiconic though with operators.

I first got interested in Erlang because of its Prolog-like syntax. I was a
little bit disappointed when I realised it doesn't actually use unification.
That would have been a great feature- why was it left out of the language, I
wonder?

~~~
rvirding
It was originally in the original Erlang interpreter written in Prolog but you
could use it for back-doors in the communication so we removed them. If you
sent an unbound variable in a message then the receiving process could reply
by binding the variable. We wanted all communication to be explicit.

I agree though that unification is cool. And I still like Prolog and other
logic languages, and have implemented Prolog in Erlang, of course.

We also gave some thought to laziness but felt it just didn't fit as for the
type problems in which we were interested. For those problems _when_ things
are done is critical, not just that they are eventually done. That would have
meant a lot explicit evaluation which defeated the point of laziness.

