Joe Armstrong
Father of Erlang
Ericsson AB
Joe Armstrong is a co-inventor of Erlang. When at the Ericsson computer science lab in 1986, he was part of the team who designed and implemented the first version of Erlang. He has written several Erlang books including Programming Erlang Software for a Concurrent World. Joe held the first ever Erlang course and has taught Erlang to hundreds of programmers and held many lectures and keynotes describing the technology.
Joe has a PhD in computer science from the Royal Institute of Technology in Stockholm, Sweden and is an expert in the construction of fault tolerant systems. Joe was the chief software architect of the project which produced the Erlang OTP system. He has worked as an entrepreneur in one of the first Erlang startups (Bluetail) and has worked for 30 years in industry and research.
Favourite quote: "... or music heard so deeply That it is not heard at all, but you are the music While the music lasts."
Joe's book
Joe has a PhD in computer science from the Royal Institute of Technology in Stockholm, Sweden and is an expert in the construction of fault tolerant systems. Joe was the chief software architect of the project which produced the Erlang OTP system. He has worked as an entrepreneur in one of the first Erlang startups (Bluetail) and has worked for 30 years in industry and research.
Favourite quote: "... or music heard so deeply That it is not heard at all, but you are the music While the music lasts."
Joe's book
twitter: @joeerl
Joe Armstrong is Giving the Following Talks
A Few Improvements to Erlang
There are two types of thing in Erlang. Forms and Expressions and the two don't mix. The shell is an expression evaluator. The shell reads an expression evaluates it and prints the result. A module is a sequence of forms. The compiler takes a sequence of forms and compiles this into an object file. You can't put forms in shell because they are not expressions. And you can't put expressions in a module because they are not forms.
This is a mess - in many other languages the input to the shell is the same as the input to the compiler - but not in Erlang. There is a fix to this. "All" you have to to is define a form to be an expression. This needs a small syntactic change to the language. Suppose we add a new syntactic form:
def fac = fun(0) -> 1; fun(N) -> N*fac(N-1) end.
But we define this to be an expression with a side effect. It's value can be anything we like (say true). But it has a side effect. The side effect is to define the factorial function. With this change we could write (in the shell):
def fac = fun(0) -> 1; fun(N) -> N*fac(N-1) end. true. fac(5). 120
With this and a few other changes the shell, modules, and escript become more or less identical. I call it erl2.
This is a mess - in many other languages the input to the shell is the same as the input to the compiler - but not in Erlang. There is a fix to this. "All" you have to to is define a form to be an expression. This needs a small syntactic change to the language. Suppose we add a new syntactic form:
def fac = fun(0) -> 1; fun(N) -> N*fac(N-1) end.
But we define this to be an expression with a side effect. It's value can be anything we like (say true). But it has a side effect. The side effect is to define the factorial function. With this change we could write (in the shell):
def fac = fun(0) -> 1; fun(N) -> N*fac(N-1) end. true. fac(5). 120
With this and a few other changes the shell, modules, and escript become more or less identical. I call it erl2.
Talk objectives: Some insights into some inconsistencies in Erlang and how these can be fixed.
Target audience: People interested in future developments in Erlang.
