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.



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!

When the communication between multiple black boxes can be automated without human beings’ intervention, the black boxes should collapse into a single black box. That is the case for database applications. When there was not an effective language, we had to divide a database application into 2 layers (DBMS/SQL and software code/Java). Quite researches had been done a decade ago trying to colliding the 2 layers; Links is trying to have a single language in hiding the 2 layers; and Froglingo is trying to unify both database and programming logically and physically. I do believe that there exist an unified, effective , and practical language for at least database applications.

Kevin Xu
As Links strives to integrate the three tiers into one paradigm or one syntax, I wonder how it will navigate the need to have very different kinds of people (or at least different thinking styles) collaborating on one project.

In every web development effort I've ever seen, there are at least two very distinct roles: those who design and build the UI, and those who choose the algorithms, design the data model, and so on. Those who build the UI are often programmers (working with JavaScript to make an active front end, for example) but these a different background and different needs than those with a more algorithmic expertise. I wonder how (or whether) Links will facillitate this separation of concerns.

Whether or not that separation exists, the goal of a unified framework to reason over both UI and internals is a noble one, and I hope Links will be successful in helping us verify web applications as wholes, rather than just the internals, or just the front end, at any given time.
Post a Comment

<< Home

This page is powered by Blogger. Isn't yours?