new syntax - a provocation

[Chris Pressey]

On Tue, 23 Sep 2003 10:42:46 +0200 (CEST)
Joe Armstrong <joe@REDACTED> wrote:

> On 23 Sep 2003, Mike Williams wrote:
> 
> > The best way to "kill" a language is to make continuous additions.
> > If people believe a language is in the process of change, they 
> > won't use it. The problem is not the additions per se, it is that
> > fact that it is very hard to remove older, often not so well thought
> > out, constructs. For example I would very much like to see
> > "catch/throw" removed, I would like to remove "records" and replace
> > them with some other construct. But this would break a huge amount
> > of existing code. Every addition will make Erlang biger and more
> > cumbersome to learn and use.
> 
> Yes -  but ...
> 
> We got a lot of things wrong in Erlang and a lot of things right -
> changing the language because we got things wrong is IMHO a good idea.

Creating a new language without those wrong things ever in it is IMHO an
even better idea... especially when there are paying customers, and when
you don't have to change the backend much, if at all...

> Now a few comments:
> [...]
> 	   Then I'd like not TWO but an indefinite number of "old
> 	   versions" of the code - let the GC remove code that is 
> 	   not reachable.

I like it, more or less - the mechanism is good, but I'm not sure
whether the fun notation is desirable (why not just write them like
normal functions and have them as lambdas "under the hood" - nested
functions, perhaps?) - and, how easy would it be to work out the details
for retaining state between hot code upgrades?

>   	- Proper structs
> 
> 	<< junk the record stuff. thus has been discussed in previous
> 	   mails >>

Yes.  Either harmonize them with dicts, or disallow untagged tuples :)

> 	- remove the atom table.
> 
> 	<< The *easiest* way to do "Atom table GC" is not to have an
> 	atom
> 	   table in the first place - redesign Erlang so that it does
> 	   not need an atom table - this is "relatively" easy >>

Yes, but can you still ensure constant time operations on atoms?

> 	- Increase the "isolation" properties of processes
> 
> 	<< I want better inter-process protection. One process should
> 	not
> 	   be able to crash another though a side effect, like
> 	   flooding the process with messages.>>

Also, a process should always be able to tell the pid of the process
that *really* sent the message.  (Not just any old pid the sender felt
like sticking in the message.)

As for flooding, you could, in today's Erlang, write a 'safe_send'
function that checks the receiver's buffer before sending, but that
would impact performance negatively, I imagine.  Also - what is the
desired behaviour for when the receiver's buffer is full?  Block, or
discard?  The syntax for sending might outgrow nice simple A ! B.

> 	- Integrate Erlang I/O system with my ideas on UBF - ie
> 	  make strong contractual obligations on the kind of
> 	  session dialogs that one Erlang system can have with another.

Hmmm... I did like the notion of adding state to the type system.  Some
research into how to create a type system that works well with messaging
is probably warranted.

> 	IMHO we need to modify Erlang to increase the isolation
> 	properties.

Erlang already has some of the best isolation properties of any
language, though... the only way I can think to improve them (beyond
what I've already mentioned) is to make locking easier.  But locking is
already easy!  So do you have any other concrete ideas on what would
need to be added/removed/fixed to make processes even better isolated?

> 	The "make it slower" track has been ignored.

For better or worse, speed does rule the industry.
But I grant you that MIPS is not always the best "kind" of speed.
"Speed" of maintenance is probably the critical thing in my mind.
Consider: if you don't put the work into making the language
implementation fast, programmers are going to write their own code in an
optimized manner to compensate - making it much harder to maintain.

> > So please, if we want Erlang to spread, let's keep the language
> > stable and have a moratorium on new constructs, new bif's etc.
> 
> 	No - do the right thing (TM)

...and design a new language :)

-Chris