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...)
- 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.
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.
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 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.
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.
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.
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].
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.
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.
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
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 :)
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.
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:
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.
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.
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.
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.
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.
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.
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]
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.
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.
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.
> 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.
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.
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.
I think for Scala and Clojure it does not make sense to equalize the languages with a single concurrency model, as they both build on the JVM and provide several libraries and approaches to concurrency. Scala has quite a lot of different actor implementations (std library, scalaz, akka, etc.), clojure has multiple ways (Atoms, Agents, STM, core.async) and you could even use plain java threads with mutexes or lockless data structures or green threads with Quasar/Pulsar on both.
Erlang makes it at least easier to choose a way to solve the problem, because it does not give you that much possibilities :) Erlang concurrency is probably a mix between Scala/Akka actors (unbounded queues, you send things to actors/processes, not to mailboxes) and clojure core.async (you can block inside the actor process).
The 7 concurrency models in 7 weeks book talks about all of those a little bit in case you are more interested in this topic.
> ...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:
> 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.
> 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.
(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.
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. :-)
> 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.
> 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.
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.
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".
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.
>> 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?
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.
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.
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.
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.
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.
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.
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.
I personally hope Elixir helps thrust Erlang into ever more success. (But not so much success that it becomes a victim of it...)