Why Erlang looks like it does(erlang.org)
erlang.org
Why Erlang looks like it does
http://erlang.org/pipermail/erlang-questions/2015-December/087223.html
99 comments
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.
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.
> 'Actor model' but it ended up being very misunderstood when implemented in C++, Java, etc,
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".
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 guess I would have to agree with the unnamed developer, common usage means that OO is C++/Java and C#, hacker is a negative thing, and decimate just means to reduce by a significant portion not reduce by a tenth exactly. Perhaps to the detriment of all these terms.
All of this reflects my thoughts on the matters, and I've been waiting more than 15 years for the co-called Actor model to 'come around', grieving the use of the term 'Object Oriented' in the meantime.
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.
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.
As someone who has only recently (finally) become disillusioned by OO (especially in larger codebases and/or on programming teams, which both seem to rapidly escalate tech debt and complexity thanks to things like mutability, class reopening and stowing-state-everywhere)... I'm so sorry, man. The difference (which is significant) unfortunately seems to require years of real-world experience with both to see it.
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...
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...
I learned to program well before OO became The Thing, so when it came around, I had a foundation to consider it with a broader perspective.
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.
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.
Don't be jaded! Stay excited! You were way ahead of the curve! ;)
Thanks for that! I'm not jaded, just realistic.
I'm actually working at a startup now that I found very interesting, mostly because it's based on flow-based programming paradigms:
https://flux.io/
I'm actually working at a startup now that I found very interesting, mostly because it's based on flow-based programming paradigms:
https://flux.io/
> 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....).
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.
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.
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.
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.
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
[1] https://en.wikipedia.org/wiki/Norsk_Data
"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).
Still seems like something worth being proud of. It just got sideswiped by the personal computer industry (a lot of things did).
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
[1] http://history-computer.com/Internet/Maturing/Lee.html
I think it relates to the idea that "Object Oriented" meant message passing (methods) between entities (objects). Not the meaning that was derived over time as programming languages borrowed select ideas from Smalltalk and then considered themselves OO because of feature similarity.
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.
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.
[deleted]
Agreed, love the post. Kind of wish other programming languages were seen the same way.
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.
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.
Just want to point out that atoms and function names ARE the same in that function names are atoms, they must be in fact as that what the system demands. So are module names for that matter. That is why if you want a function with a "funny" name you quote it as you do an atom
'the answer'() -> 42.
'the answer'() -> 42.
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 :)
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 :)
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.
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.
> 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...
Very succinct and (hopefully) puts this misconception to bed.
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.
The OTP are identical because both use the same OTP, the original Erlang OTP. Elixir just puts a wrapper around it to give a more elixir feel. And add default callbacks which I personally don't like.
Is your Erlang CV online to view?
For the sake of my own sanity, and due to a lack of necessity, I haven't gone through the trouble of CSS'ing things to make it layout the way I'd want on the web. I wouldn't allow myself to half-ass it, and so toiling over OCD-fueled "pixel perfect" HTML & CSS for that task would wind up closely resembling what I'm sure hell is like.
However, if you ping me on Twitter @n_aschbacher, or something commensurately similar, I'll happily share it with you.
However, if you ping me on Twitter @n_aschbacher, or something commensurately similar, I'll happily share it with you.
[deleted]
Erlang's syntax isn't simple at all. No if statements, no for loops, only recursion and guards. Else is ; and there are proper and improper lists e.g. [1|2] is improper but [1|[2]] is proper. Weird.
So it's not simple because it has less stuff and it's not an imperative language?
It's not simple = it is hard to learn for people coming from C/Java/JS-like environment.
That makes it different. Not complicated.
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.
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.
CV as in curriculum vitae? Do a lot of people do that?
Some people like to do cutesy things like this: http://macournoyer.com/blog/2010/02/23/how-to-apply-to-a-job...
I've seen a few around. Here's one HN post that I can quickly recall - https://news.ycombinator.com/item?id=9216299
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.
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.
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.
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.
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.
"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.
I get the opposite feeling from Scala, more that it was "let's make a cool language with a bunch of interesting features" instead of "we've got a problem to solve".
Don't forget Scala started out as a research project to unify functional and object-oriented programming.
Don't forget Scala started out as a research project to unify functional and object-oriented programming.
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.
I took a language design class in collage, and Scala was a great learning language in that application.
> 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]
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]
You really would limit your definition of successful languages to only those three?
Care to elaborate ?
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.
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.
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.
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.
> 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.
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.
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.
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.
They got that from Erlang :-)
Who got it from elsewhere ;D
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.
Who did it come from? Haskell? ML?
according to wikipedia (https://en.wikipedia.org/wiki/Pattern_matching) SNOBOL in '62
SNOBOL pattern matching is on strings; SASL is the origin of pattern matching on algebraic data types.
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
Once you learn it.. It's very easy and basic. This is what happens when you choose the path less traveled.
[deleted](1)
> 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.
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.
Please don't post uncivil comments to anybody here, including inventors of programming languages you don't like.
We detached this subthread from https://news.ycombinator.com/item?id=10963889 and marked it off-topic.
We detached this subthread from https://news.ycombinator.com/item?id=10963889 and marked it off-topic.
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.
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.
> 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.
Or, at least, people who take on such names on pseudonymous message boards.
(Mr. Virding is one of the co-inventors of Erlang.)
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.
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.
> (Mr. Virding is one of the co-inventors of Erlang.)
And we know that this username is being used by the real person because... ?
And we know that this username is being used by the real person because... ?
because it's his account. Look at his posting history, if you like. Or ask him on twitter, where, like here, he's @rvirding.
Because it is! :-) For better or worse I am the Robert Virding. Actually there is only one Robert V in the world at the moment, me, there aren't many Virdings. :-)
Because it is ... ?
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...
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...
> How do we know pg's account is used by a real person
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.
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.
> After that you learn the sad state of ... expected language interoperability.
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?
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?
jack9: you might want to think about how your tone is coming off to people reading your text -- "You're serious and I'm not..." -- if you're surprised by how people react to it.
I was going to make a nasty comment and refer to Schiller, but I won't. The jokes on you. :-)
[deleted]
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.
Also, the link seems strangely mistitled.
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.
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.
>> 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 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?
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.
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.
Because logic programming wasn't the goal of erlang?
[deleted]
The downfall of Prolog's syntax is its weird rules surrounding whitespace and indentation. A few braces and a little more Algol or Lisp wouldn't have killed you, you know.
Of course, Python followed the same strange ideas, so I guess they're well-ingrained now.
Of course, Python followed the same strange ideas, so I guess they're well-ingrained now.
I don't know of any rules in Prolog surrounding indentation and the only whitespace rule I know of is that you cannot have whitespace between a functor and the left paren of its arguments. What have I missed?
Armstrong's paper about the history of Erlang is fantastic.
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.
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.
This comment reinforces my perception that erlang is less popular than it should be because engineers are not as strong as they should be.
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 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.
I have long been fascinated by the principles of business management, specifically those in the well known book "The E-Myth".
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.
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.
Ostensibly, this is what has propped up PHP. Of course calling those who you can convince to absorb a different syntax as "smart" is just a psychological lock-in strategy, rather than an effective sieve.
Not in my experience. I once helped build a team of Elixir developers. There were few people who knew elixir at the time. That simple filter ended up getting us a really great team-- much better than interviewing a bunch of applicants from with other language backgrounds-- the people who wanted to learn elixir, knew it, or were interested in it, were much better than average.
In fact, that's the only effective filter I've found for interviewing.
In fact, that's the only effective filter I've found for interviewing.
Our evaluation of "smart" is independent of syntax absorption. It's less that we convince them to absorb a different syntax, more like we select for people who wouldn't get hung up on it.
> They look at the horrible mess of the prolog structures and say "it's not worth it to learn"
Well good, the community is probably better off without that group of people.
Well good, the community is probably better off without that group of people.
What's wrong with prolog syntax?
Different, not same. All computer languages must be Algol.
> 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.
Probably because it was the subject of a pre-existing email thread. We've changed the title to a representative phrase from the text.
I personally hope Elixir helps thrust Erlang into ever more success. (But not so much success that it becomes a victim of it...)