Eleanor McHugh
4/19/2007 3:14:00 PM
On 19 Apr 2007, at 15:23, M. Edward (Ed) Borasky wrote:
> Eleanor McHugh wrote:
>> I think possibly I'm more attracted to the Occam-pi language
>> structures as I can sense ways in which they can be implemented
>> using Ruby's threads or dRb/Rinda and multiple processes.
> I took a cruise by the web site and I must say it was interesting
> but I have a very bad taste in my mouth from Occam. I used to work
> for a company called Floating Point Systems. A bunch of very bright
> folks bet a big chunk of the company on the Transputer and Occam.
> It was a classic case of a beautiful theory being murdered by a
> gang of brutal facts. There were less than a handful of Occam
> programmers in the world. Our marketplace consisted of FORTRAN, C,
> and to a certain extent Pascal programmers.
My experiments were limited by minimal access to hardware. My
supervisor had a Meiko Transputer Surface but that was mainly used
for large-scale skeletal forces simulations so I never got to play,
and anyway Occam in its version 1 form is an ugly dog. The transputer
architecture though fascinated me and I still have an assembly
language manual for it lurking somewhere on my bookshelf.
> To be blunt, Erlang is a production-ready, commercially supported
> industrial strength programming environment -- no, let me make that
> stronger -- *software engineering environment* with a lot of
> momentum and a strong open-source community. Occam, CSP, the Pi-
> Calculus and Pi-Occam aren't. Aside from the obvious entrenched
> position of the Pi-Calculus in business process modeling, I don't
> see much other than another beautiful theory walking alone on a
> dark and stormy night in a very bad neighborhood. :)
I've yet to meet any theory that comfortably withstood the light of
day, so I won't hold that against it ;) I can definitely see the
argument for using Erlang in preference to Occam, but I don't think
that invalidates the value of lifting its core strengths (concurrency
and code mobility) for use in Ruby. If they are good abstractions
then Ruby will make them much easier to use, and if not it will soon
show up their faults lol
Ellie
Eleanor McHugh
Games With Brains
----
raise ArgumentError unless @reality.responds_to? :reason