Frank Shearar wrote:
"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).
I am sorry. This wasn't the proper word.
Certainly, I believe that there are things that cannot be modelled in the pure functional language (whose constructs can be without exceptions mapped to the lambda-calculus). This is not only the case of input/output. This is also the case of modelling stateful systems that interact with their environment over time (not only at the beginning and at the end). So pretending that functional programming can cover all the important aspects of systems we need to model is unfaithful. Those impurities are useful.
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.)
Well, their semantics is different. I am used to objects and I want to describe systems as mutualy interacting objects. My bank acount is an object, it has some state and some methods. I find it natural.
Erlang's processes are somewhat similar to objects, they create illusion of polymorphism (this is useful) and encapsulation. However, internally, Erlang processes are expressed procedurally. In E, behavior of processes (vats) is expressed as mutually interacting set of objects. So objects are polymorphic, not only the whole process.
E and Erlang are similar that internal behavior of a process is sequential and the whole process acts as a "monitor" (although in E ensures also partial ordering of messages. This is also useful.)
If the statement "(non-deterministic) deadlocks cannot occur in E" is correct (and this is fantastic) then E's communication mechanisms are less expressive than Erlang's. In Erlang you can write systems with non-deterministic deadlock. In E you cannot. So less expressive language need not to be a disadvantage.
E ensures partial ordering of messages passed around (also transitively). Erlang does not. This has implications.
Erlang does not provide you directly with promise pipelining (it had to be added) whereas it is directly available in E.
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.
I agree. Neither Erlang nor Smalltalk were designed with security in mind. Funny thing about security is, that if you do not get it right in the beginning, you cannot "add it later".
That doesn't make Smalltalk primitive. On the other hand, perhaps one could implement an E-on-Erlang.
It is possible, but it would be E, not Erlang. (although it might be more efficient than E-on-Java)
Then again, while it's usual for distributed Erlang applications to run in a trusted environment
Suppose WatchMorph in Squeak. It can delete you home directory. Watch morph is simple so you can read the code and check it. In case of non-trivial system it would not be realistic.
In E, you can put the untrusted code into a powerbox---thus, giving it as much authority as it needs and you are willing to grant it. Then, despite the fact that it is an untrusted piece of code, you can use it and it can be useful. Not using these techniques is a missed chance. Security cannot be "added later".
Erlang cannot be used for writing software this way.
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.)
This would mean emulating E.
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.
Again. Sorry.
frank
- -- Matej Kosik ICQ: 300133844 skype: matej_kosik