new syntax - a provocation

[Chris Pressey]

On Wed, 24 Sep 2003 10:56:33 +0200 (CEST)
Joe Armstrong <joe@REDACTED> wrote:

> On Tue, 23 Sep 2003, Chris Pressey wrote:
> 
> > > 	<< 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?
> 
> There are two ways of doing this:

I see.  That's good news.

> > 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?
> > 
> 
> Interesting - I'd *much* prefer a solution based on implicit contracts
> and no locking - locking distributed objects makes me shudder in
> horror ..

Let me clarify - I don't mean "client asks server for a lock, and server
gives client a locking ticket which it hopes the client will return."  I
mean "client asks server for a resource and the server locks it
*internally* for the duration of the transaction."  I fully admit the
former is Way Bad Design.  Perhaps the word "serialization" would have
been a better choice than "locking."

> At the outer level of abstraction processes are black boxes. Their
> communication is regulated by contracts. Contracts can specify
> functional behaviour (types) and non-functional behaviour
> (example, I will reply within 10ms, I will send max 100
> messages/hour).

I see the value in establishing contracts, however, it is a bit like
strong typing: it can only really be done at design/compile time. 
(There's no way to check contracts at runtime, AFAICS: you just have to
be trusting.)

And we've all seen the threads about how Erlang programmers would rather
use an ad-hoc approach that doesn't slow them down (hmmm) than spend all
their time getting the design prim and proper before writing a single
line of code.

Although I would love to have a contract checking system available - I'd
rather just start off writing untrusting code.

> This is why I'd like to tightly integrate the UBF stuff into Erlang,
> and provide wrappers so that components can be written in any
> language.
> 
> > > 	The "make it slower" track has been ignored.
> > 
> > For better or worse, speed does rule the industry.
> 
>   I  disagree -  return on  investment and  time to  market  rules the
> industry.

That's a very good point.  Hmm...

I do think it's related.  If your customers use your product to get
_their_ product to market (or otherwise achieve some sort of goal)
quickly, then, your product has to be fast :)  It could all go under a
general umbrella of 'expedience'...

But it is of course not that simple.  You're right - it's more
psychological than industrial.  Speed is *sexy*.  No one is concerned
with making the source code to Yaws less efficient just so it can be
more easily understood.  (Well, you and I are, kind of (looking at
pico & OpenFlax :) but I think we're in the minority...)

> But but ... at home I have my good 'od work horse a 300 MHz Celeron -
> is is "fast enough" for everything *except* video rendering.
> 
> I have *never* rewritten an Erlang program because it was too slow.

I personally agree 100%.  I'd much rather have something reliable and
even more importantly *maintainable* (return on investment extends into
the future further than most people would like to think about - look at
all the COBOL code that's still out there...)

-Chris