11 ms·

Why Erlang looks like it does

198 points by joeyespo 11y ago

lectrick 11y ago
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 11y ago
  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.
  - Diederich 11y ago
    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.
    - lectrick 11y ago
      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_programming_in_C.php http://gamasutra.com/view/news/169296/Indepth_Functional_pro...
      - Diederich 11y ago
        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.
        lectrick 11y ago
        Don't be jaded! Stay excited! You were way ahead of the curve! ;)
        Diederich 11y ago
        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/ https://flux.io/
  - deleted 11y ago
    [deleted]
  - signa11 11y ago
    > 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.pdf 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.
    - strmpnk 11y ago
      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.
    - alankay 11y ago
      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.
  - rdtsc 11y ago
    > '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-objects-never-well-hardly-ever/ 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".
    - bryanrasmussen 11y ago
      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.
- shockzzz 11y ago
  Agreed, love the post. Kind of wish other programming languages were seen the same way.
jack9 11y ago
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.
- stass 11y ago
  What's wrong with prolog syntax?
  - pessimizer 11y ago
    Different, not same. All computer languages must be Algol.
    - rvirding 11y ago
      I thought they all must be java.
      - im_down_w_otp 11y ago
        We are all JVM now.
- dang 11y ago
  > 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.
- rvirding 11y ago
  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.
lkrubner 11y ago
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.
- walkingolof 11y ago
  Care to elaborate ?
  - xiaq 11y ago
    I have never really used Scala, but by reading its documentation it feels like that the designers are cramming all sorts of features into the language without carefully considering what concrete problems they are going to solve.
    - bad_user 11y ago
      I don't know what I'm talking about, but let me try anyway.
- PeCaN 11y ago
  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.
- kyle4211 11y ago
  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 11y ago
    > 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]
n0us 11y ago
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 11y ago
  They got that from Erlang :-)
  - bpicolo 11y ago
    Who got it from elsewhere ;D
    - rvirding 11y ago
      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 11y ago
        Who did it come from? Haskell? ML?
        signa11 11y ago
        according to wikipedia (https://en.wikipedia.org/wiki/Pattern_matching https://en.wikipedia.org/wiki/Pattern_matching) SNOBOL in '62
        fanf2 11y ago
        SNOBOL pattern matching is on strings; SASL is the origin of pattern matching on algebraic data types.
deleted 11y ago
[deleted]
- rvirding 11y ago
  Well, you can filter, map and fold over maps so there is not really much missing. And they are efficient both when they are small and large.
  - deleted 11y ago
    [deleted]
    - simoncion 11y ago
      > ...but the added chapter on maps give you errors whe using erlang 18... Are you talking about the section entitled "What Maps Shall Be", or are you talking about the section entitled "Stubby Legs for Early Releases"? If you're talking about the former, then the prose in the previous section "EEP, EEP!" makes it pretty clear that the maps spec is not fully implemented in Erlang, and that "What Maps Shall..." describes the spec, rather than the implementation. If you're talking about the latter, then I'm not sure what's up on your end... the examples in "Stubby Legs..." work for me: Erlang/OTP 18 [erts-7.2.1] [source] [smp:2:2] [async-threads:10] [hipe] [kernel-poll:false] Eshell V7.2.1 (abort with ^G) 1> SomeMap = #{a => x}. #{a => x} 2> #{a := X} = SomeMap. #{a => x} 3> X. x 4> SomeMap#{a := update, b => new}. #{a => update,b => new} 5> Y=3, #{Y => Y-1}. #{3 => 2} 6> > For a beginners it sound very strange that a basic structure like a maps is not well consolidated in a language as erlang. The maps module is very, very, very new. As mentioned in the "Mexican Standoff" section, dict [0] was more-or-less the go-to module when you wanted a K/V store [1] in Erlang. The maps module [2] (and map type) adds a lot of nice syntax for working with K/V datatypes. [0] http://erlang.org/doc/man/dict.html http://erlang.org/doc/man/dict.html [1] And had no need for ETS, or Mnesia, or similar, naturally. [2] http://erlang.org/doc/man/maps.html http://erlang.org/doc/man/maps.html
  - deleted 11y ago
    [deleted]
  - deleted 11y ago
im_down_w_otp 11y ago
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.
- RickHull 11y ago
  Is your Erlang CV online to view?
  - im_down_w_otp 11y ago
    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.
- rvirding 11y ago
  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.
- deleted 11y ago
  [deleted]
jack9 11y ago
> 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.
- corprew 11y ago
  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.
- rvirding 11y ago
  I was going to make a nasty comment and refer to Schiller, but I won't. The jokes on you. :-)
- felixgallo 11y ago
  (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.
  - cbd1984 11y ago
    > (Mr. Virding is one of the co-inventors of Erlang.) And we know that this username is being used by the real person because... ?
    - felixgallo 11y ago
      because it's his account. Look at his posting history, if you like. Or ask him on twitter, where, like here, he's @rvirding.
    - 11y ago
ninjakeyboard 11y ago
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 11y ago
  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.
- 59nadir 11y ago
  > 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.
BuckRogers 11y ago
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.
dschiptsov 11y ago
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.
perishabledave 11y ago
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
deleted 11y ago
[deleted]
anfroid555 11y ago
Once you learn it.. It's very easy and basic. This is what happens when you choose the path less traveled.

198 points by joeyespo 11y ago

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 11y ago
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.
- Diederich 11y ago
  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.
  - lectrick 11y ago
    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_programming_in_C.php http://gamasutra.com/view/news/169296/Indepth_Functional_pro...
    - Diederich 11y ago
      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.
      - lectrick 11y ago
        Don't be jaded! Stay excited! You were way ahead of the curve! ;)
        Diederich 11y ago
        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/ https://flux.io/
- deleted 11y ago
  [deleted]
- signa11 11y ago
  > 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.pdf 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.
  - strmpnk 11y ago
    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.
  - alankay 11y ago
    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.
- rdtsc 11y ago
  > '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-objects-never-well-hardly-ever/ 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".
  - bryanrasmussen 11y ago
    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.
shockzzz 11y ago
Agreed, love the post. Kind of wish other programming languages were seen the same way.

jack9 11y ago

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.

stass 11y ago
What's wrong with prolog syntax?
- pessimizer 11y ago
  Different, not same. All computer languages must be Algol.
  - rvirding 11y ago
    I thought they all must be java.
    - im_down_w_otp 11y ago
      We are all JVM now.
dang 11y ago
> 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.
rvirding 11y ago
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.

lkrubner 11y ago

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.

walkingolof 11y ago
Care to elaborate ?
- xiaq 11y ago
  I have never really used Scala, but by reading its documentation it feels like that the designers are cramming all sorts of features into the language without carefully considering what concrete problems they are going to solve.
  - bad_user 11y ago
    I don't know what I'm talking about, but let me try anyway.
PeCaN 11y ago
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.
kyle4211 11y ago
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 11y ago
  > 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]

n0us 11y ago

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 11y ago
They got that from Erlang :-)
- bpicolo 11y ago
  Who got it from elsewhere ;D
  - rvirding 11y ago
    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 11y ago
      Who did it come from? Haskell? ML?
      - signa11 11y ago
        according to wikipedia (https://en.wikipedia.org/wiki/Pattern_matching https://en.wikipedia.org/wiki/Pattern_matching) SNOBOL in '62
        fanf2 11y ago
        SNOBOL pattern matching is on strings; SASL is the origin of pattern matching on algebraic data types.

deleted 11y ago

[deleted]

rvirding 11y ago
Well, you can filter, map and fold over maps so there is not really much missing. And they are efficient both when they are small and large.
- deleted 11y ago
  [deleted]
  - simoncion 11y ago
    > ...but the added chapter on maps give you errors whe using erlang 18... Are you talking about the section entitled "What Maps Shall Be", or are you talking about the section entitled "Stubby Legs for Early Releases"? If you're talking about the former, then the prose in the previous section "EEP, EEP!" makes it pretty clear that the maps spec is not fully implemented in Erlang, and that "What Maps Shall..." describes the spec, rather than the implementation. If you're talking about the latter, then I'm not sure what's up on your end... the examples in "Stubby Legs..." work for me: Erlang/OTP 18 [erts-7.2.1] [source] [smp:2:2] [async-threads:10] [hipe] [kernel-poll:false] Eshell V7.2.1 (abort with ^G) 1> SomeMap = #{a => x}. #{a => x} 2> #{a := X} = SomeMap. #{a => x} 3> X. x 4> SomeMap#{a := update, b => new}. #{a => update,b => new} 5> Y=3, #{Y => Y-1}. #{3 => 2} 6> > For a beginners it sound very strange that a basic structure like a maps is not well consolidated in a language as erlang. The maps module is very, very, very new. As mentioned in the "Mexican Standoff" section, dict [0] was more-or-less the go-to module when you wanted a K/V store [1] in Erlang. The maps module [2] (and map type) adds a lot of nice syntax for working with K/V datatypes. [0] http://erlang.org/doc/man/dict.html http://erlang.org/doc/man/dict.html [1] And had no need for ETS, or Mnesia, or similar, naturally. [2] http://erlang.org/doc/man/maps.html http://erlang.org/doc/man/maps.html
- deleted 11y ago
  [deleted]
- deleted 11y ago

im_down_w_otp 11y ago

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.

RickHull 11y ago
Is your Erlang CV online to view?
- im_down_w_otp 11y ago
  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.
rvirding 11y ago
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.
deleted 11y ago
[deleted]

jack9 11y ago

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

corprew 11y ago
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.
rvirding 11y ago
I was going to make a nasty comment and refer to Schiller, but I won't. The jokes on you. :-)
felixgallo 11y ago
(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.
- cbd1984 11y ago
  > (Mr. Virding is one of the co-inventors of Erlang.) And we know that this username is being used by the real person because... ?
  - felixgallo 11y ago
    because it's his account. Look at his posting history, if you like. Or ask him on twitter, where, like here, he's @rvirding.
  - 11y ago

ninjakeyboard 11y ago

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 11y ago
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.
59nadir 11y ago
> 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.

BuckRogers 11y ago

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.

dschiptsov 11y ago

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.

perishabledave 11y ago

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

deleted 11y ago

[deleted]

anfroid555 11y ago

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