Could Ruby be a good Erlang-like?

[Eric Torreborre]

Hi,=0A=0AAfter writing this post on the possibilities to add some features =
from other languages to Ruby: http://etorreborre.blogspot.com/2007/04/patte=
rn-matching-with-ruby.html, I am wondering what it would take for Ruby to i=
mplement Erlang-like features:=0A=0A-spawn, send and receive primitives=0A-=
massive processes creation=0A-... (all the stuff I unfortunately don't know=
yet, until I will lay my hands on the upcoming Joe Armstrong's Erlang book=
;-) )=0A=0AI am certainly not saying that Erlang should be fully brought t=
o Ruby, but I would really like to hear the opinion of somebody who is know=
ledgeable in both about this idea. This would help me better understand the=
fundamental differences between the 2 languages.=0A=0AThis could also resu=
lt in a mini-framework that could help in programming some concurrent syste=
ms. For instance, it looks like Kamaelia (http://kamaelia.sourceforge.net/I=
ntroduction) is trying to bring some kind of messaging model to Python. Wou=
ld that be interesting to do the same for Ruby?=0A=0AEric.=0A=0A-----------=
---------------------------------------------------------------------------=
-=0AEric TORREBORRE=0Atel: +81 (0)90 5580 3280=0Ae-mail: etorreborre@yahoo.=
com / (e-mail address removed)=0Ablog: http://etorreborre.blogspot.com=0A--=
---------------------------------------------------------------------------=
----------=0A=0A=0A=0A=0A=0A=0A =0A___________________________________=
________________________________________ =0AD=E9couvrez une nouvelle fa=E7o=
n d'obtenir des r=E9ponses =E0 toutes vos questions ! =0AProfitez des conna=
issances, des opinions et des exp=E9riences des internautes sur Yahoo! Ques=
tions/R=E9ponses =0Ahttp://fr.answers.yahoo.com

 

[M. Edward (Ed) Borasky]

I have yet to actually mess with Erlang (I definitely plan to), but doing
what you're asking seems like an almost monumental waste of time. The
reason
Erlang works the way it does is because it was built from the ground
up to
support massively parallel processing. Ruby was built from the ground
up as
your normal single-threaded (with support for green-threads) dynamic
programming language.

So it seems that what you're asking is to rewrite Erlang to work with
Ruby
syntax; this is not something that can be patched into the Ruby VM.

Jason

Well ... maybe. I think the original poster is asking for the Ruby
VM/inner interpreter to be extended with some core semantics taken from
Erlang. I think it *can* be done, but the question is *should* it be
done? My own personal belief is that it should. At the very least, the
Ruby VM should make available all of the OS concurrency primitives
supported by Linux, MacOS, Solaris and Windows as efficiently as
possible. dRB and threads aren't going away, but there are many other
ways to do concurrent programming sensibly.

That said, one of the other things that adding concurrency does to a
language, any language, is to force its community to think harder about
correctness issues. The Erlang community has put a lot of thought into
this, given that their target market is communications systems that must
work when entire cities lose electrical power, etc. They have
correctness-checking tools, and syntactic and semantic constructs in the
language to support these tools. The attitude I see expressed in the
Ruby community is "testing conquers all". That's clearly insufficient,
since testing can only show the presence of bugs and not the absence of
them.

So yes, it's a good idea. But if you need Erlang now, use Erlang now.

 

[Eleanor McHugh]

I have yet to actually mess with Erlang (I definitely plan to), but
doing
what you're asking seems like an almost monumental waste of time.
The reason
Erlang works the way it does is because it was built from the
ground up to
support massively parallel processing. Ruby was built from the
ground up as
your normal single-threaded (with support for green-threads) dynamic
programming language.

So it seems that what you're asking is to rewrite Erlang to work
with Ruby
syntax; this is not something that can be patched into the Ruby VM.

I'm not sure that Erlang is the right place to be looking for good
Ruby concurrency models, given the fundamental differences between
the two languages. What I think would be interesting though is if
some of the CSP and Pi-Calculus inspired stuff that's being worked on
by the KRoC team (http://www.cs.kent.ac.uk/projects/ofa/kroc/) make
it into the Ruby world.


Ellie

Eleanor McHugh
Games With Brains

 

[M. Edward (Ed) Borasky]

I'm not sure that Erlang is the right place to be looking for good
Ruby concurrency models, given the fundamental differences between the
two languages. What I think would be interesting though is if some of
the CSP and Pi-Calculus inspired stuff that's being worked on by the
KRoC team (http://www.cs.kent.ac.uk/projects/ofa/kroc/) make it into
the Ruby world.

Uh ... I'll go check it out, but don't get me started on Pi-Calculus vs.
Petri Nets in the Business Process Modeling arena. Suffice it to say
I've been studying Petri nets for something like 20 years now and I find
Pi-Calculus and CSP (and related process algebra notations) dang near
impossible to read as a result.

 

[Eleanor McHugh]

Uh ... I'll go check it out, but don't get me started on Pi-
Calculus vs. Petri Nets in the Business Process Modeling arena.
Suffice it to say I've been studying Petri nets for something like
20 years now and I find Pi-Calculus and CSP (and related process
algebra notations) dang near impossible to read as a result.

Well I can't say I like the maths notations much - reminds me too
much of studying control theory back in the 80s and wondering why my
lecturer was so excited about what amounts to little more than
plumbing diagrams. It's so ironic that I ended up working in embedded
control systems...

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.


Ellie

Eleanor McHugh
Games With Brains

 

[M. Edward (Ed) Borasky]

Well I can't say I like the maths notations much - reminds me too much
of studying control theory back in the 80s and wondering why my
lecturer was so excited about what amounts to little more than
plumbing diagrams. It's so ironic that I ended up working in embedded
control systems...

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.

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.

For a more positive spin on the subject, for those interested in the
"obvious entrenched position" I mentioned above, see _Essential Business
Process Modeling_ by Michael Harvey. Anybody who implements business
applications, in Ruby or otherwise, should have a firm grasp of the
contents thereof.

 

[Eleanor McHugh]

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

 

[Clifford Heath]

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.

Ed, have you seem the YAWL workflow engine from Queensland
University of Technology and the DSTC? It's formally based
on Petri nets. I had a play with it a while back, but didn't
see it as mature (read, overburdened with pre-canned features)
to easily make use of in a commercial environment (which was
my interest). Granted that you might be using Petri nets
mainly for things other than business workflow automation,
but I'd like your opinion on the chance YAWL might have to
change things in the BPML space.

For a more positive spin on the subject, for those interested in the
"obvious entrenched position" I mentioned above, see _Essential Business
Process Modeling_ by Michael Harvey. Anybody who implements business
applications, in Ruby or otherwise, should have a firm grasp of the
contents thereof.

Thanks for the recommendation. I was needing a good pointer like
that.

My interest in business process is where I see it tying in with
fact-based information modeling. It would seem a shame to mix a
revolutionary yet well-founded technique like Object Role Modeling
with the abortion that is BPML, when it could instead be mixed
with a similarly foundational technology based on Petri nets.

Clifford Heath.

 

[M. Edward (Ed) Borasky]

Ed, have you seem the YAWL workflow engine from Queensland
University of Technology and the DSTC? It's formally based
on Petri nets. I had a play with it a while back, but didn't
see it as mature (read, overburdened with pre-canned features)
to easily make use of in a commercial environment (which was
my interest). Granted that you might be using Petri nets
mainly for things other than business workflow automation,
but I'd like your opinion on the chance YAWL might have to
change things in the BPML space.

As Deep Throat said in "All The President's Men," follow the money.
There are two entrenched 800-pound gorillas. I've forgotten the names,
but one is based on Petri nets and the other on Pi-Calculus, and some
kind of "both sides win" integration of the two is emerging. I think
there's virtually zero chance of something else making headway. So I
suppose I'll need to learn the subset of Pi-calculus that ends up in the
final mix.

My interest in business process is where I see it tying in with
fact-based information modeling. It would seem a shame to mix a
revolutionary yet well-founded technique like Object Role Modeling
with the abortion that is BPML, when it could instead be mixed
with a similarly foundational technology based on Petri nets.

Well ... to my knowledge, Pi-calculus can *directly* model "mobility",
and Petri nets can't. It's been a while since I read the book, and I've
lent my copy out to a co-worker who's more directly involved with
business process modeling. My interest is pretty much only in computer
systems performance modeling, and there (generalized) stochastic Petri
nets are about the most complicated tool I need, and perhaps 99 percent
of what I need to do can be handled by even simpler tools based on
product form queuing networks. That's the source of my bias towards
Petri nets -- they've been around a long time and predate most of the
other analysis tools for dealing with concurrency. In fact, I think they
predate the fundamental theorem of product form queuing networks.

 

[M. Edward (Ed) Borasky]

What about the Join calculus? It always seemed to me to be relatively
easy to program and implement, while still being powerful enough for
serious use, but then I never wrote real code in it.

I'm not familiar with it. My "introduction" to concurrent programming was via Per Brinch Hansen's "Concurrent Pascal" and "Edison" programming languages, which were built on the concept of "monitors". Monitors exist in Ruby, so that's a no-brainer. I also did some small concurrent programming projects in a dialect of Linda called "Circl" in the early 1990s. Ruby has Rinda; again a no-brainer.

I haven't done much with threads or other low-level techniques -- I much prefer having "industrial strength tools" available for the difficult tasks of concurrent programming. I like to be able to prove, for example, that my code cannot deadlock. And I like to be able to estimate how long it's going to take me to get an answer.