24.3.05
Joe Armstrong on Links
I'd also like to comment on your "new language" initiative -
unfortunately I can't make the April meeting (dates clash) - and it's
unlikely that I can participate in any active sense (I'm asking to see
if this would be possible) - I would however like to "sit on the
sidelines" and try to influence your work in a certain direction.
I'll try to explain:
What's the problem - do we need another programming language?
Answer No and Yes.
No we don't need yet another programming language YAPL but we do need
decent system description language(s).
At a high level of abstraction we can consider the world to be made
up of communicating black boxes.
Some of these black boxes represent software, others hardware, others
objects in the real world.
Black boxes communicate by message passing.
There is no shared data between boxes.
Note: This is how the world works - we communicate by modulating
streams of light or sound - this takes place in time and space and
there is no such thing as a simultaneous update (if you believe
special relativity :-) - this is a phycists view of the world.
Programming language are normally "what goes on inside the black box".
But this I find relative uninteresting and a "solved" problem.
Thus I do not want "Yet another language inside the box" - there
are hundreds (thousands) of these already - why make another.
What happens inside the black box is irrelevant when seen from the
perspective of being "outside the box" - indeed if two black boxes are
observationally equivalent then who cares what goes on inside.
There is a severe lack of languages for describing "what goes on
outside the black boxes"
This is what you should do.
No there is a problem - the real world.
Functional boxes (a la function programming, type systems etc) are
predictable, type safe etc (or they should be :-)
But black boxes representing the real world are not.
Errors can occur in real-world black boxes.
How do we (or should we) describe protocols?
Pure functions are at the level of reliable RPCs - these are
(pretty) easy to describe.
Imagine a "factorial machine" - a black box - you send it an integer
N it replies with N!
A first pass at a description language might be:
factorial_machine is:
int => int
ie a machine that if you send it an integer returns an integer.
How do we introduce the real world?
We need to describe timings and failure
factorial_machine is:
x:int => y:int within 100 ms
when x < 1010
| outofservice
Machines in the real world - may suddenly stop - may be
non-deterministic - may lie - may fail intermittently - may produce
incorrect results occassionaly.
How do we describe this?
Worse - the languages INSIDE the black boxes are all different -
how do we describes types in a language neutral way, that is
nevertheless reasonably efficient (ie not XML :-)
As I see things - we need a hierarchy of languages
L3 - evolution languages
L2 - configuration languages
L1 - protocol description languages
L0 - programming languages
L0 are programming languages - like Erlang, Haskell
L1 are protocol languages - like SDL? - my UBF???
L2 are languages that say how the bits of a system fit together -
language abstraction of things like (say) the red-hat package manager
L3 are evolution languages - language that allow me to express how
(say) the protocols of L1 change with time.
All these should fit together in an aesthetically pleasing manner.
UML is much touted as the universal solution to these kinds of problem -
but I'm not sold - we could do better (a lot better)
That's about what I wanted to say - I probably said it badly -
please don't make yet another L0 - make a family L0-L3 - think through
the handling of failure - non-determinism - evolution - security - trust.
Cheers
/Joe
BTW - If I'm not at the April meeting I will be there in spirit -
please raise these questions on my behalf.
----
And here's my response ...
I think there is a role for yet another programming language, if its not just trying to be a general purpose programming language. Links integrates with databases on the back end and browsers on the front end, and few languages around are designed for that.
On the other hand, the problems you raise are very important ones, and I agree with you absolutely that it makes more sense to focus on these than to focus on questions of language design in a space that is well trodden.
I don't feel ready quite yet to give up on design of particular programming languages and focus exclusively on ways to knit languages together, because I still don't have what I want in a particular language. I might feel differently about that if Erlang had types!
unfortunately I can't make the April meeting (dates clash) - and it's
unlikely that I can participate in any active sense (I'm asking to see
if this would be possible) - I would however like to "sit on the
sidelines" and try to influence your work in a certain direction.
I'll try to explain:
What's the problem - do we need another programming language?
Answer No and Yes.
No we don't need yet another programming language YAPL but we do need
decent system description language(s).
+-----------+ +-----------+ +-----------+
| | | | | |
| --->---| --->---| |
| | | | | |
| ---<---| ---<---| |
| | | | | |
+-----------+ +-----------+ +-----------+
At a high level of abstraction we can consider the world to be made
up of communicating black boxes.
Some of these black boxes represent software, others hardware, others
objects in the real world.
Black boxes communicate by message passing.
There is no shared data between boxes.
Note: This is how the world works - we communicate by modulating
streams of light or sound - this takes place in time and space and
there is no such thing as a simultaneous update (if you believe
special relativity :-) - this is a phycists view of the world.
Programming language are normally "what goes on inside the black box".
But this I find relative uninteresting and a "solved" problem.
Thus I do not want "Yet another language inside the box" - there
are hundreds (thousands) of these already - why make another.
What happens inside the black box is irrelevant when seen from the
perspective of being "outside the box" - indeed if two black boxes are
observationally equivalent then who cares what goes on inside.
There is a severe lack of languages for describing "what goes on
outside the black boxes"
This is what you should do.
No there is a problem - the real world.
Functional boxes (a la function programming, type systems etc) are
predictable, type safe etc (or they should be :-)
But black boxes representing the real world are not.
Errors can occur in real-world black boxes.
How do we (or should we) describe protocols?
Pure functions are at the level of reliable RPCs - these are
(pretty) easy to describe.
Imagine a "factorial machine" - a black box - you send it an integer
N it replies with N!
A first pass at a description language might be:
factorial_machine is:
int => int
ie a machine that if you send it an integer returns an integer.
How do we introduce the real world?
We need to describe timings and failure
factorial_machine is:
x:int => y:int within 100 ms
when x < 1010
| outofservice
Machines in the real world - may suddenly stop - may be
non-deterministic - may lie - may fail intermittently - may produce
incorrect results occassionaly.
How do we describe this?
Worse - the languages INSIDE the black boxes are all different -
how do we describes types in a language neutral way, that is
nevertheless reasonably efficient (ie not XML :-)
As I see things - we need a hierarchy of languages
L3 - evolution languages
L2 - configuration languages
L1 - protocol description languages
L0 - programming languages
L0 are programming languages - like Erlang, Haskell
L1 are protocol languages - like SDL? - my UBF???
L2 are languages that say how the bits of a system fit together -
language abstraction of things like (say) the red-hat package manager
L3 are evolution languages - language that allow me to express how
(say) the protocols of L1 change with time.
All these should fit together in an aesthetically pleasing manner.
UML is much touted as the universal solution to these kinds of problem -
but I'm not sold - we could do better (a lot better)
That's about what I wanted to say - I probably said it badly -
please don't make yet another L0 - make a family L0-L3 - think through
the handling of failure - non-determinism - evolution - security - trust.
Cheers
/Joe
BTW - If I'm not at the April meeting I will be there in spirit -
please raise these questions on my behalf.
----
And here's my response ...
I think there is a role for yet another programming language, if its not just trying to be a general purpose programming language. Links integrates with databases on the back end and browsers on the front end, and few languages around are designed for that.
On the other hand, the problems you raise are very important ones, and I agree with you absolutely that it makes more sense to focus on these than to focus on questions of language design in a space that is well trodden.
I don't feel ready quite yet to give up on design of particular programming languages and focus exclusively on ways to knit languages together, because I still don't have what I want in a particular language. I might feel differently about that if Erlang had types!
