Non sequential programming

Matej Kosik kosik at fiit.stuba.sk
Sat May 28 23:38:15 UTC 2005


Brent Vukmer wrote:
> Matej -
> 
> Have you looked into Erlang at all?
> 

Hi,
Thank you for your reaction,

You are the second one who recommended me to look at it. Sincerely, I did not studied that language in depth. Not because I refuse traditional things just because they are not mine. Sometimes I am lazy and ignorant. But I admit the rational arguments.

I do not want to claim that Erlang is bad. It is probably matured language highly usable for certain domain of problems.

One of my objection against it is that it is not a clean language. I mean, concurrency mechanisms are attached to another (in this case they I think functional) language. This is a similar situation when someone attached object-oriented features to procedural languages. Such a language is hybrid. This is not a case of Smalltalk. You cannot tear apart "object-oriented features" from Smalltalk. Nothing would remain. From certain point of view, it is perfect. This point of view may seem irrational (or hard to explain or argue about) but I insist on using clean programming language(s). Erlang mixes functional programming with concurrent programming. I cannot right now check it 
(http://www.erlang.org is down) but if it is not an object oriented language whose objects can change state over time without changing their identity, then this language is not my cup of tea. I would not be compatible with my way of modeling real world. Everything is an object. I am not content with functional programming, I am not content with programming with objects which cannot change their state. This is unnatural.

V2 differs from Erlang in the point that
- Everything is an object (in Erlang there are no objects, or at least there are also things which are not objects)
- It is fine-grained parallel language. There are no processes. You cannot remove concurrency mechanisms from V2 because nothing would remain. It is from certain point of view, a clean language (Erlang is based on coarse-grained parallelism).

(I admit, that prefering clean languages over unclean languages is only matter of choice. I can now afford it because I am not tight by any constraints).

The second objection is related to the quality of the concurrency mechanisms. If I am not wrong, these are very similar to those ones provided also by the SR programming language
- asynchronous (i.e. non-blocking) send
- blocking receive.
This is very common. Heavily parallel programs written by means of these parallel mechanisms can easily suffer by
- interference
- and deadlocks.
In simple situations we can write a code where these problems are avoided. Similarly as in other (alternative) view of the concurrent computation: shared variables and semaphores. We can deal with trivial problems easily, but it was already recognized that for big problems these mechanisms are nightmare and alternative concurrency mechanisms are sought.

http://www.drjava.de/e-presentation/html-english/img1.html

Well, I did not used Erlang, so I do not know if it is a nightmare tool for constructing large concurrent systems. I do not know, I do not have my own experience. But if there are no mutable objects, it is weak.

By V2 I want to show that, it is possible to do parallel programming
- without the threat of interference
- without the threat of deadlocks.
- conveniently (as in Smalltalk).
- consistently (as in Smalltalk).

Although, I am not 100% sure if the things which I know about Erlang are as bad as I have written above. I will install it and play with it for a while and compare its concurrency mechanisms to SR. Thank you very much for the suggestion.
--
Matej Kosik, icq://300133844, http://altair.dcs.elf.stuba.sk/wiki/Kosik/Main



More information about the Squeak-dev mailing list