Hello all,
These times we were playing with a different model of computation to which we all are used to. We believe that before we will be able to create cooperating distributed software (systems/programs) we have to throw away traditional sequential thinking.
Now we are evaluating the prototype of such a programming platform, which is not only convenient (Smalltalk was also convenient) but also inherently parallel. At least, that is our immediate goal (conveniency & inherent parallelism). We have very strange feeling because doing everything from scratch is very suspicious. But, until know we did not find any other parallel language which would be - as consistent as Smalltalk - as convenient as Smalltalk - and of course parallel The experiments we have hitherto performed exhibit that the prototype based on the ideas we have got one year ago seem to be (until now) promising.
Weird (but highly desirable) properties of the proposed parallel programming platform are: - interference over mutable shared objects is automatically excluded - deadlock as we know does not exist. These properties are ensured by the policy how it is possible to derive new capabilities from the old ones.
We do not know if here are people who, similarly as us, know about Smalltalk (and any other inherently sequential language) constraints in the area of distributed computing.
Currently the best source of information in written form about our system can be found here:
http://altair.dcs.elf.stuba.sk/~kosik/esug2005.pdf (an ESUG 2005 research-track article candidate)
Just in case someone wanted to download it, the whole implementation can be found here:
http://altair.dcs.elf.stuba.sk/~kosik/squeak/V2.sar
It works in Squeak 3.8 & 3.9 (due to one bug in 3.7, V2 does not work there)
Test case classes `TestV2*' exhibit the correct behavior of the system. Particularly interesting might be - TestV215Workspace - TestV216Actor - TestV217Integer - TestV218Number - TestV219Magnitude - TestV220True - TestV221False - TestV222Point - TestV223Context - TestV224Iteration
Perplexed records of interesting experiments can be also found here:
http://altair.dcs.elf.stuba.sk/wiki/Kosik/Experiments http://altair.dcs.elf.stuba.sk/wiki/Kosik/Implementation
Some are already out of date
The syntax of the language is close to Smalltalk http://altair.dcs.elf.stuba.sk/wiki/Kosik/Syntax
The semantics is somewhat analogous but yet very very different.
Nice thing which misses is some functionality which would be able to generate state diagrams such as: http://altair.dcs.elf.stuba.sk/uploads/Kosik/equivalence6.png automatically. These were useful during debugging the virtual machine. They could also be useful during presentation. Drawing them manually is a burden. Excavate that information using Explorer tool from the my virtual machine is horrible task. Program could that do quickly. The problem is how to draw in those diagrams (actually special graphs) in clear way. I guess that to implement such a functionality could take about a month. If I had it, I would be able to flip forward (and perhaps backward) between the adjacent virtual machine states. Then it would be easy to explain the effects of the language. Squeak is perfect platform for such a thing.
If anyone interested could look at the paper I have written http://altair.dcs.elf.stuba.sk/~kosik/esug2005.pdf and perhaps also at the implementation (see the test cases and `System class example*' methods) and give me some feedback, that would be very valuable for me - Do you thing that what I do is worthwhile? - What experiments should I try to do? - What is not clear in the article or what should be explained in more detail (I must admit that I am not a great writer) - Is there someone who has also the same goals as me and is working to realize them? - Any other good ideas?
Thank you in advance
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
(http://www.erlang.org is down)
Try http://www1.erlang.org/ instead (they're having a server upgrade)
Just for the records: The above presentation is about the E language (www.erights.org) and has nothing to do with Erlang.
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).
E is a good place to look at if only for comparison (since your paper quotes Joule I'm assuming you are aware of E).
Cheers, - Andreas
Andreas Raab andreas.raab@gmx.de wrote:
quotes Joule I'm assuming you are aware of E).
And I hope people remeber to pronounce it "jow-el" not "jool" since Mr Joule was a Yorkshireman not a Frenchman...
tim -- Tim Rowledge, tim@rowledge.org, http://www.rowledge.org/tim Strange OpCodes: PSP: Push Stack Pointer
Andreas Raab wrote:
(http://www.erlang.org is down)
Try http://www1.erlang.org/ instead (they're having a server upgrade)
Just for the records: The above presentation is about the E language (www.erights.org) and has nothing to do with Erlang.
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).
E is a good place to look at if only for comparison (since your paper quotes Joule I'm assuming you are aware of E).
E is valuable (also) for its ideas in the area of security.
When I started to implement V2 I was not aware of these problems. In the last autumn I installed E and revealed (thanks to E) what it really means security in distributed systems. V2 is a transient and throw away prototype. The next prototype (V3) shall heed these problems.
V2 is valuable for its capability to find parallelism also there, where noone would normally sought for it. This
http://altair.dcs.elf.stuba.sk/wiki/Kosik/Experiments#day31052005
is one (not very interesting becaouse it is so obvious) example. There are also other (also boring because they are so obvious) examples scattered around.
When I these days tried to show the power of V2 on more complicated examples, I have revealed that the strategy employed to break the cycles which appear in virtual machine state which under normal conditions should form partial order of activations, is not general enogh. I knew that, but I have finally come to those situations which reveal that fact. This is not a lucky situation because right now I cannot show you the power of V2 when operating on matrices or other mutable objects (such as Transcript) shared and used between multiple parallel "activities". The non-perfectness of the strategy prevents me to do so. This is on the other hand a luck because I have to solve the problems mentioned in the esug2005 article sooner than I expected.
The problem is, that right now I cannot view conveniently the state of the virtual machine. When I previously had to draw all the states of the virtual machine through which it transfered from the initial state to the final state. If the total number of steps (and related states) was 12, this took me more than one hour to draw the series of virtual machine state diagrams. That was passable for short computation which did not last more then 12 steps. This approach is however completely useless when a computation lasts, say, 100 steps. I need a functionality which draws those steps automatically. That is another unfortunate requirement because this again hinders me because it has no theoretical worth. But, it will is worthwhile to have it when I need to explain the effects of the V2 language on the V2 virtual machine states. I will not need to create something like this
http://altair.dcs.elf.stuba.sk/wiki/Kosik/TrueTest03not
(follow the links at the bottom of the page) manually. I will be able to generate such a "movie" on the fly. Also for less trivial computations. I expect that implementing such a "movie generator" will take one month. Then I will be able to conveniently reason about the proper strategy for breaking the cycles. Answering that question how * to detect them effectively * to break them without introducing interference are crucial. Finding out the answer will hopefully not take too long.
Cheers
On 28 mai 05, at 20:34, Matej Kosik wrote:
- Do you thing that what I do is worthwhile?
Yes I think that the current model of concurrency that we have in traditional oo language is really low level. I'm inherently bad with these model while I programmed with Esterel, Signal and other "parallel" synchrone languages. So looking at new way of performing concurrent programming is indeed important.
- What experiments should I try to do?
- What is not clear in the article or what should be explained in
more detail (I must admit that I am not a great writer)
You will get feedback from ESUG :)
- Is there someone who has also the same goals as me and is working
to realize them?
- Any other good ideas?
squeak-dev@lists.squeakfoundation.org