After writing this post on the possibilities to add some features from
other languages to Ruby: A++ [Eric Torreborre's Blog]: Pattern matching with Ruby,
I am wondering what it would take for Ruby to implement Erlang-like
features:
-spawn, send and receive primitives
-massive processes creation
-… (all the stuff I unfortunately don’t know yet, until I will lay my
hands on the upcoming Joe Armstrong’s Erlang book )
I am certainly not saying that Erlang should be fully brought to Ruby,
but I would really like to hear the opinion of somebody who is
knowledgeable in both about this idea. This would help me better
understand the fundamental differences between the 2 languages.
This could also result in a mini-framework that could help in
programming some concurrent systems. For instance, it looks like
Kamaelia (Introduction) is trying to
bring some kind of messaging model to Python. Would that be interesting
to do the same for Ruby?
Découvrez une nouvelle façon d’obtenir des réponses à toutes vos questions !
Profitez des connaissances, des opinions et des expériences des
internautes sur Yahoo! Questions/Réponses
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.
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.
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 (occam-pi and KRoC: blending CSP and the pi-calculus) make
it into the Ruby world.
That’s Termite, right? The Gambit Scheme add-on? Quite frankly, I think
they did a better job than Erlang. Sockets aren’t going away. System
V IPC isn’t going away. Threads aren’t going away. dRB and Rinda aren’t
going away. Monitors aren’t going away. And I don’t see the need to
re-invent the OS in every language – just the parts Windows got wrong.
On 19 Apr 2007, at 04:51, M. Edward (Ed) Borasky wrote:
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.
programming language.
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.
to say I’ve been studying Petri nets for something like 20 years now
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.
On 19 Apr 2007, at 15:23, M. Edward (Ed) Borasky wrote:
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
dang near impossible to read as a result.
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.
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.
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.
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.
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.
)
I can definitely see the