new syntax - a provocation
Wed Sep 24 19:16:11 CEST 2003
On Wed, 24 Sep 2003 10:56:33 +0200 (CEST)
Joe Armstrong <> 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
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
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
> > > 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
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...)
More information about the erlang-questions