Frank Shearar wrote:
> "Matej Kosik" <kosik at fiit.stuba.sk> wrote:
> 
>> Hi Frank,
>>
>> Frank Shearar wrote:
>>> "Matej Kosik" <kosik at 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?
>>>>
>>>> http://www.erights.org
>>>>
>>>> ???
>>>>
>>>> There is a dissertation that addresses two fundamental problems:
>>>> - - it introduces synchronization mechanisms that are meant to escape
>>>>   from the situation where you
>>>>   - either have interference
>>>>   - or non-deterministic deadlock
>>>>   (Erlang does not solve these problems.
>>>>    The recent book about Erlang does not even mention the word
> "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