"Matej Kosik" kosik@fiit.stuba.sk wrote:
Hi Frank,
Frank Shearar wrote:
"Matej Kosik" kosik@fiit.stuba.sk wrote:
gruntfuttuck wrote:
How is squeak going to handle multy-core CPUs, if at all? If we see
cores of
100 plus in the future and squeak stay as it is, I would imagine other languages such as erlang, will look more attractive.
Anyone followed links that Andreas gave?
???
There is a dissertation that addresses two fundamental problems:
from the situation where you
- it introduces synchronization mechanisms that are meant to escape
(Erlang does not solve these problems. The recent book about Erlang does not even mention the word
- either have interference
- or non-deterministic deadlock
"deadlock")
- *security*
It is a point-of-view-changing reading.
It is true that it is far less mature for production quality, but
taking
ideas from something as
primitive as Erlang ... well, good luck.
Why exactly is Erlang primitive? What do you mean? Do you mean that it
can't
solve real-world problems?
It's proven itself in at the very least its original target market, that
of
the highly concurrent environment found in things like telephony
switches.
It certainly seems applicable in other highly concurrent environments.
We're
not talking about some new thought experiment - this is a language that
was
released in its open source form in 1998, and whose initial development started in 1986. There are case studies of _successful_ large systems (Ericsson's AXD301, in particular).
In what ways is Erlang better than E? In what ways E cannot be extended to be as good as Erlang?
Well, Erlang is "better than" E because I know of at least one large system written in Erlang, while I know of none in E. That's not much, I know :)
I certainly don't mean to imply that E has nothing to teach Smalltalk - I think there are LOTS of languages out there that can teach us LOTS of things.
E supports objet-oriented programming. Erlang is not object-oriented.
Well, _that's_ certainly not evidence of being primitive! Haskell's not object oriented either, nor is Lisp (without CLOS).
Non-deterministic deadlocks cannot occur in E. Non-deterministic deadlocks can occur in E.
What is the difference between E's promise architecure, and Erlang's combination of ! and receive? (! sends an asynchronous message to a process, and receive checks the mailbox of a process for messages in a blocking fashion, and can time out.) I mean, is one more powerful than the other? (From my cursor reading of E in a Walnut, I think they're equivalent.)
E can be used for building open systems (where various parties can
cooperate despite the fact that
they do not trust each other ultimately). Erlang does not provide such
mechanisms.
Sure; Erlang focuses on _concurrency_ issues, not security ones.
E can be used for building systems internally composed from multiple
untrusted components without
security risk because E provides mechanisms that enable programmers to
follow with principle of the
least authority. Principle of the least authority cannot be followed in Erlang. Any part of
the Erlang system has the
authority to destroy the whole system and perform irreversible damage.
Yes, much like, say, Smalltalk. That doesn't make Smalltalk primitive. On the other hand, perhaps one could implement an E-on-Erlang.
Then again, while it's usual for distributed Erlang applications to run in a trusted environment, there's nothing stopping one from writing applications that use sockets to communicate, in which case the Erlang applications's as secure or insecure as you make it. (Yes, I know, E addresses exactly this issue.)
I do not say that E is perfect. I only believe that it is more valuable
than Erlang (with respect to
future) and should not be demoted just because it is not popular. Of
course, the more people use a
particular language, the bigger chance that it will ripe (to its full
potential/but no further).
So you feel that E is superior to Erlang because, while both support equivalent ways of writing distributed programs, E focuses on security issues right from the get-go?
Anyway, I just object to (pejoratively) labelling a language as "primitive" when it has delivered on what it set out to do.
frank