Why Erlang looks like it does
erlang.org
erlang.org
I personally hope Elixir helps thrust Erlang into ever more success. (But not so much success that it becomes a victim of it...)
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.
This comes across as strongly worded, but I'm going to let it stand, given the understanding that the C++ and Java style of 'Object Oriented' has value in a lot of situations and circumstances. Though I have leaned very heavily on Kay's 'Actor Model' over the years, C++ style OOP has also been useful from time to time.
I've been pointing OO people to these thoughts by John Carmack, who is pretty well-respected in the C++ OO community: http://gamasutra.com/view/news/169296/Indepth_Functional_pro...
Re: "I'm so sorry, man." Thanks, but I'm not sorry at all. The (what I call) Message Oriented Programming first approach has allowed me to have a highly successful career.
Re: Carmack. There's quite a few such highly respected and respectable articles out there, but I gave up advocacy a long, long time ago. I just let what I'm doing, and not doing, do the talking, for better and worse.
I'm actually working at a startup now that I found very interesting, mostly because it's based on flow-based programming paradigms:
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....).
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.
These days it's hard to argue for correcting the features that people label as OO. It's part of history at this point. It is still interesting to note that there was a slightly different intention when Alan Kay coined the term though. Perhaps we need a new label. Kay-OO or something.
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.
Still seems like something worth being proud of. It just got sideswiped by the personal computer industry (a lot of things did).
Yap here it is right from the horse's mouth, so to speak:
https://computinged.wordpress.com/2010/09/11/moti-asks-objec... (see comments history)
---
If you are doing “simulated data structure programming” rather than object oriented programming. One of my original motivations for trying to invent OOP was to eliminate imperative assignment (at least as a global unprotected action). “Real OOP” is much more about “requests”, and the more the requests invoke goals the object knows how to accomplish, the better. “Abstract Data Types” is not OOP!
...
Many of Carl Hewitt’s Actors ideas which got sparked by the original Smalltalk were more in the spirit of OOP than the subsequent Smalltalks. Significant parts of Erlang are more like a real OOP language the the current Smalltalk, and certainly the C based languages that have been painted with “OOP paint”."
---
There you have it folks, Erlang is more OO than C++/Java and C#. It is kind of a funny tidbit, good for sharing during meetups over beers.
One interesting response to that I heard from a developer was "Well, it doesn't matter what Kay thinks anymore. C++/Java/C# got so popular and that is OO now officially".
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.
However, if you ping me on Twitter @n_aschbacher, or something commensurately similar, I'll happily share it with you.
'the answer'() -> 42.
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 :)
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.
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...
Very succinct and (hopefully) puts this misconception to bed.
It's many, many times simpler than the syntax and semantics than any of thos e three that you listed.
The only language that I can think of that's simpler is Lisp.
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.
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.
"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.
Don't forget Scala started out as a research project to unify functional and object-oriented programming.
I took a language design class in collage, and Scala was a great learning language in that application.
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]
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.
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.
In terms of location transparency, what are we referring to here? Because talking to a process in Erlang is location independent. It can be running on another node if you'd like and you don't need to care. I take "location transparency" to mean exactly this.
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.
Why are you so mad? It doesn't really matter if 'other developers' don't understand Erlang. Erlang doesn't have to be the one true perfect language for everything, just a pretty nice sweet spot for a bunch of use cases.
And we know that this username is being used by the real person because... ?
How do we know pg's account is used by a real person, or dang's, maybe they are all aliens, or robots, who knows...
Long history here.
> or dang's
Long history, plus a history of apparently being able to do things normal users can't do.
Plus, of course, dang doesn't claim to be anyone famous, merely a mod of this discussion forum. You can't impersonate someone who's only famous for being able to do maintenance-type things around here: If you can do those things, you're a mod, and if you can't, nobody cares.
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.
Or, at least, people who take on such names on pseudonymous message boards.
Mmm? Ports let you interop with anything that can send data over a pipe. Port drivers let you use a port with programs that don't fit well into the "pass things as a stream of bytes" model. NIF lets you interop with anything that has a C binding.
What are you looking for that's not provided?
We detached this subthread from https://news.ycombinator.com/item?id=10963889 and marked it off-topic.
Also, the link seems strangely mistitled.
Probably because it was the subject of a pre-existing email thread. We've changed the title to a representative phrase from the text.
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.
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?
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.
Of course, Python followed the same strange ideas, so I guess they're well-ingrained now.
Well good, the community is probably better off without that group of people.
The advantages of erlang, over basically every other language, make the "cost" of learning the syntax very low relative to the value of the erlang language.
If you think of yourself as a good engineer, you shouldn't be following the crowd of blubs who use languages simply because they don't tax their brain to learn them.
The idea is that it is easier to grow and scale a business if every role is reduced to something achievable by the lowest common denominator. The book cites McDonalds as an example and how they specify the exact location of pickles on a burger to make sure that a 15 year old can produce burgers indistinguishable from their peers. Sure, plenty of people can cook a better burger than McDonalds, but anyone can cook a McDonalds burger given the equipment and instructions.
In terms of programming, a similar approach may well exist. I've seen it in two forms. First is the enterprise strategy. Standardize on simple, yet inefficient technologies. Anyone with X credential can be as productive as anyone else (this works well because nobody is very productive so its a low bar). This makes hiring and firing much simpler.
The second approach is the "hire smart people and provide them with the tools they need to learn and succeed." I've personally seen great success with "Welcome to the company, let's learn Erlang."
As an engineer who enjoys being challenged I prefer the latter, but I'm not convinced that the first strategy is a bad one from the business's perspective.
In fact, that's the only effective filter I've found for interviewing.
It explains how Erlang was developed through a process of trial and error, initially in Prolog and then inheriting a Prolog-like syntax when it became its own thing. Worth reading, lots of trivia about the thought processes behind his and Virding's back-and-forths at the time; and Armstrong is characteristically modest about how they had to invent their way toward a solution, because none existed at the time.
I believe this is the one: http://cobweb.cs.uga.edu/~maria/classes/4500-Spring-2010/pap...
Edit: It also touches on why Erlang's syntax looks the way it does. They initially for a Prologue syntax, and evolved it from there.