M. Edward (Ed) Borasky wrote:
purpose, and needed an 8087 to do floating point computing, doesn’t
There’s not a heck of a lot I can do about AMD, but I am in Intel’s
back yard.
Did I just propose that Ruby keep green threads and not move to using
the OS threads? 
–
M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
http://borasky-research.blogspot.com/
If God had meant for carrots to be eaten cooked, He would have given
rabbits fire.
On Dec 31, 2006, at 4:54 PM, M. Edward (Ed) Borasky wrote:
(That’s why I’ve worked so hard on event-driven programming
so I’m not going to belabor the point. I’ll just fall back on
Arthur C. Clarke’s Law: When a distinguished but elderly scientist
says something is possible, he is usually proven right.
At this year’s C4 conference [1], Steve Dekorte gave a presentation
[2] on programming using the Actor Model [3]. It was fascinating to
me since I had never been exposed to anything like it before. His IO
language [4] is rather pretty too.
It would be wonderful to wrap something like this up in ruby so it
was a first-class citizen in the language.
cr
[1] http://c4.rentzsch.com/0/ AND http://en.wikipedia.org/wiki/C4_%
28conference%29
[2] http://www.iolanguage.com/docs/talks/2006-10-C4/Actors.pdf
[3] Actor model - Wikipedia
[4] http://iolanguage.com/about/
On 12/31/06, M. Edward (Ed) Borasky [email protected] wrote:
Well, given that Ruby already has threads, monitors, drb, Rinda,
starfish and NArray, you’d have to de-implement those if it doesn’t make
sense to implement them.
able to say “No”. But I think what I really want to see is, given the
visibility of concurrency and multi-core processors and energy
efficiency right now, for Ruby to have some compelling “killer language
features” for exploiting this trend.
I’m not going to speak for the folks who are implementing or adapting
VMs
for Ruby. But on first thought, I’d implement threads, mutexes and
condvars
primitively and add monitors (and all the other derivatives like RW
locks)
on top of those. The other stuff you mentioned is cross-process. Are the
new
VMs actually planning to implement stuff like drb and Rinda primitively?
Multicore architectures: many people will probably disagree vehemently
with
this, but I think that taking advantage of the new architectures will
best
be achieved by breaking computations up into multiple processes. I think
the
style that is broadly represented by Erlang will be the most effective
approach, so a new “paradigm shift” (sorry) in programming is coming.
(That’s why I’ve worked so hard on event-driven programming support for
Ruby.) But teaching programmers to be better at multithreading, etc.
will be
fruitless because this approach is really difficult now, and will be far
more difficult on highly parallel or multicore hardware. That’s my two
cents
on the subject, and it’s worth every penny ;-).
Francis C. wrote:
will be
fruitless because this approach is really difficult now, and will be far
more difficult on highly parallel or multicore hardware. That’s my two
cents
on the subject, and it’s worth every penny ;-).
On the contrary – I’ll agree vehemently on some of this and disagree
less strenuously on the rest.
Vehement agreement: Erlang-style lightweight processes are a proven
way to solve large complex problems on large collections of hardware.
However, Erlang does some other things that seem to stick in the craw of
a lot of folks here – like a functional programming style and
compile-time type checking.
Disagreement, but perhaps more a lack of acceptance of reality: I think
today’s programmers are up to the task of highly parallel programming,
because there are many decades of theory and practical experience in it
already. I posted a rant about this already today, so I’m not going to
belabor the point. I’ll just fall back on Arthur C. Clarke’s Law: When a
distinguished but elderly scientist says something is possible, he is
usually proven right.
–
M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
http://borasky-research.blogspot.com/
If God had meant for carrots to be eaten cooked, He would have given
rabbits fire.
Francis C. wrote:
I’m glad you agree, Ed. I’d add a couple of minor clarifications. First,
I’ve been involved with Posix threads since before they were Posix
threads,
and to me “lightweight process” refers to what is sometimes called a
kernel
thread. I assume you’re using the term to mean full-weight (userland)
processes that interact with each other in more advanced ways than are
common today.
Well, actually, I meant “Erlang-style” to include the semantics and
efficient implementation thereof specific to the way Erlang does it,
rather than anything more “generic”.
Second, I was careful not to endorse the Erlang language
itself, but rather the broad approach (processes collaborating through
low-bandwidth but very flexible channels) that characterizes Erlang.
You can be as careful as you wish. I, on the other hand, have no problem
endorsing Erlang for a number of things I think it does right.
Neither, apparently, do the good folks at Amazon.
business problem. I’m not interested in fighting over this, however,
except
to say that if I’m right, I’ll be shipping a lot more valuable
software in
unit time than someone else will. I’m inclined to answer that question
empirically, and then revisit the theoretical issue.
Ah … OK. In terms of business problems, I’m with you – let’s ship
valuable software and let the theoreticians argue over whether Petri
nets or the Pi-Calculus is the correct model.
http://is.tm.tue.nl/research/patterns/download/bptrendsPiHype.pdf
Of course, since I know a lot more about Petri nets than I do about the
Pi-calculus, that’s going to color my approach.
–
M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
http://borasky-research.blogspot.com/
If God had meant for carrots to be eaten cooked, He would have given
rabbits fire.
On 12/31/06, M. Edward (Ed) Borasky [email protected] wrote:
Vehement agreement: Erlang-style lightweight processes are a proven
way to solve large complex problems on large collections of hardware.
However, Erlang does some other things that seem to stick in the craw of
a lot of folks here – like a functional programming style and
compile-time type checking.
I’m glad you agree, Ed. I’d add a couple of minor clarifications. First,
I’ve been involved with Posix threads since before they were Posix
threads,
and to me “lightweight process” refers to what is sometimes called a
kernel
thread. I assume you’re using the term to mean full-weight (userland)
processes that interact with each other in more advanced ways than are
common today. Second, I was careful not to endorse the Erlang language
itself, but rather the broad approach (processes collaborating through
low-bandwidth but very flexible channels) that characterizes Erlang.
Disagreement, but perhaps more a lack of acceptance of reality: I think
today’s programmers are up to the task of highly parallel programming,
because there are many decades of theory and practical experience in it
already. I posted a rant about this already today, so I’m not going to
belabor the point. I’ll just fall back on Arthur C. Clarke’s Law: When a
distinguished but elderly scientist says something is possible, he is
usually proven right.
There are a lot of strands to this argument, but to avoid a lot of
offtopic
controversy, I’ll just call out that my concern is not with highly
parallel
programming. My problem is with multithreaded programming, which I
don’t
believe is the right way to take advantage of machine parallelism
because it
introduces a concurrency into programs that usually isn’t germane to the
business problem. I’m not interested in fighting over this, however,
except
to say that if I’m right, I’ll be shipping a lot more valuable software
in
unit time than someone else will. I’m inclined to answer that question
empirically, and then revisit the theoretical issue.
On 12/31/06, Brian M. [email protected] wrote:
mirrored in Io to experiment with the combination. The project was
dropped after I had difficulties with some of less defined areas,
parsing ruby code, and Io’s general instablility (much better these
days, but still very visible).Brian.
I love transparent futures! They also appear in Alice. Have you looked
at
it? Too heavyweight for real programming (it’s an ML derivative) but
some
really sweet ideas.
On 12/31/06, [email protected] [email protected] wrote:
style that is broadly represented by Erlang will be the most
on the subject, and it’s worth every penny ;-).
think today’s programmers are up to the task of highly parallelIt would be wonderful to wrap something like this up in ruby so it
was a first-class citizen in the language.
The language has some great ideas to steal. Not all of them are
original to Io but some are implemented in really nice ways. One of my
favorites has been transparent futures. These are a little hard to
implement in Ruby w/o Object#become of some form. Proxies work well
but give a large performance hit and rare gotchas (Ruby takes quite a
few shortcuts that makes this break in odd places).
It would be awesome to see some of this implemented as first class
concurrency mechanisms. I had a good portion of Ruby’s object model
mirrored in Io to experiment with the combination. The project was
dropped after I had difficulties with some of less defined areas,
parsing ruby code, and Io’s general instablility (much better these
days, but still very visible).
Brian.
On 12/31/06, Charles Oliver N. [email protected] wrote:
language is just faster - Smalltalk just fits better to Ruby than Java).
You do know that Smalltalk, even in its fastest incarnations, is still
slower than Java, right?
oops I stepped on your feet, did I?
Did the JVM speed up so much or is my reference rotten, I am going to
look
it up when back on work.
Forgive my ignorance I should have put a question mark behind my
statement
but that holds for too many a things we think to know 
If the JVM has become that fast a Smalltalk VM should be able to become
even
faster I guess.
I really dislike Java but even as biased as I am I recon JRuby must be a
hell of a project and very important for the community.
It is also my last trump when discussing Ruby with Java affacinados and
it
is a very high trump.
But the motivation for JRuby holds for SmallRuby and looking at both
languages (J&S) Smalltalk seems to fit better. Now even the greates
Smalltalk fan ( and I am not ) could not immagine that a Smallruby would
ever have the usage of JRuby.
If Smalltalk will survive it will so in a niche I guess, it would be
wounderful if Ruby could exist in that niche, would it not?
And Squeak is far from being one of the fastest
incarnations.
That I have heard too, but I did only intent to use Squeak as a FE (and
BE
too buit one could use any VM).
–
Charles Oliver N., JRuby Core Developer
Blogging on Ruby and Java @ headius.blogspot.com
Help spec out Ruby today! @ www.headius.com/rubyspec
[email protected] – [email protected]Happy New Year
Robert
–
“The real romance is out ahead and yet to come. The computer revolution
hasn’t started yet. Don’t be misled by the enormous flow of money into
bad
defacto standards for unsophisticated buyers using poor adaptations of
incomplete ideas.”
On 12/31/06, M. Edward (Ed) Borasky [email protected] wrote:
Forth is looking better every day
Are you sure about that?
http://vividpicture.com/aleks/atari/forth.jpg
On 12/31/06, M. Edward (Ed) Borasky [email protected] wrote:
Yeah, I know – there’s no such thing as the one best way to do
something. And there’s nothing wrong with designing the Parrot virtual
machine as a register machine because the majority of people who will be
programming at that level are Motorola 68000 assembly programmers
either.
virtual machine in Forth or Pascal or pseudo-M68000 assembler when the
majority of the people who will be programming at that level are C
programmers.
possible exception of concurrency primitives.
On the other hand, a lot of people have flocked to Haskell simply to
hack on Pugs. I’m sure if a really good alt-lang-based ruby vm was
developed, people would learn said lang just to hack on it.
m.
Gregory B. wrote:
Forth is looking better every day
Are you sure about that?
http://vividpicture.com/aleks/atari/forth.jpg
Thanks! I needed that!
–
M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
http://borasky-research.blogspot.com/
If God had meant for carrots to be eaten cooked, He would have given
rabbits fire.
Martin DeMello wrote:
On the other hand, a lot of people have flocked to Haskell simply to
hack on Pugs. I’m sure if a really good alt-lang-based ruby vm was
developed, people would learn said lang just to hack on it.m.
Can you quantify “a lot of people have flocked to Haskell simply to hack
on Pugs”? How does that number compare with the number of people hacking
on Parrot? How do these numbers stack up relative to the size of the
Perl 5.8.x communities? I actually wandered to the Pugs and Parrot sites
last night just to see what they were up to. They’re both in Gentoo’s
Portage tree – I could play with them if I wanted to, but I don’t.
I think I have the GHC binary installed because it’s required by Darcs
and there are a couple of projects I hack on occasionally that are using
Darcs. I think Haskell and Darcs and GHC and Pugs are all dead-ends and
won’t survive a “market shakeout”, no matter how high their “quality” is
on any metric. Haskell, GHC, Darcs and Pugs are deal-breakers for me.
More to the point, how does that compare with the size of the jRuby
community, the YARV community and the Rubinius community relative to the
whole Ruby community? My point here is, to quote Wirth, “Programming is
decision-making.” As a programmer, I made the decision not to pursue the
Forth-based Ruby implementation (which is called Carbone, BTW) precisely
because I already have a number of half-person projects languishing and
I don’t want to start (or take over) another one. I don’t think it’s
realistic to expect a bunch of talented C hackers to run off and learn
Forth to hack on a Forth-based Ruby, especially since vmgen itself is
written in C! The icing on that particular cake is that ideas from
vmgen/Carbone are making their way into YARV. Now if I could just
convince Austin and Curt that gcc is “the one true way” on Windows …
–
M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
http://borasky-research.blogspot.com/
If God had meant for carrots to be eaten cooked, He would have given
rabbits fire.
On Mon, Jan 01, 2007 at 07:54:08AM +0900, M. Edward (Ed) Borasky wrote:
However, Erlang does some other things that seem to stick in the craw of
a lot of folks here – like a functional programming style and
compile-time type checking.
This reply is largely off-topic, but I can’t stand mis-information.
Erlang, just like ruby is dynamically typed. Its type checks happen at
runtime not compile time. Admittedly this is surprising for a functional
language, but there it is.
On Mon, Jan 01, 2007 at 11:18:22PM +0900, Martin DeMello wrote:
On the other hand, a lot of people have flocked to Haskell simply to
hack on Pugs. I’m sure if a really good alt-lang-based ruby vm was
developed, people would learn said lang just to hack on it.
That’s the best part about rubinius. It is an alt-lang ruby vm, where
the alt-lang just happens to be ruby! Brilliant!
Logan C. wrote:
I wasn’t aware of that – since there is a compiler, and some rather
fancy language-based QA analysis tools, I assumed there was some kind of
“compile-time type checking”.
–
M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
http://borasky-research.blogspot.com/
If God had meant for carrots to be eaten cooked, He would have given
rabbits fire.
On 1/1/07, M. Edward (Ed) Borasky [email protected] wrote:
Logan C. wrote:
That’s the best part about rubinius. It is an alt-lang ruby vm, where
the alt-lang just happens to be ruby! Brilliant!Yes indeed! No need to learn Haskell! But how much C does one need to
know to hack on Rubinius?
well, you can do all your rubinius hacking in ruby if you want to. only
a small part of the bits are in C.
Logan C. wrote:
majority of the people who will be programming at that level are C
Yes indeed! No need to learn Haskell! But how much C does one need to
know to hack on Rubinius?
–
M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
http://borasky-research.blogspot.com/
If God had meant for carrots to be eaten cooked, He would have given
rabbits fire.
pat eyler wrote:
The true test will be when either Rubinius or YARV becomes a viable
virtual machine for C#, Perl, PHP, Python or Javascript. After all, JVM,
CLR and Parrot support multiple languages. 
Whoever it was that said, “Don’t reinvent the wheel” obviously wasn’t
watching very closely.
–
M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
http://borasky-research.blogspot.com/
If God had meant for carrots to be eaten cooked, He would have given
rabbits fire.
Charles Oliver N. wrote:
It’s important not to think of JRuby in terms of Java, especially if
you’re a Rubyist or someone who dislikes Java. JRuby is Ruby, just on
another VM and implemented under the covers in a different language.
Don’t equate JRuby and Java.
…
The motivations for JRuby go well beyond those for a SmallRuby, largely
because not only could it potentially be a “better Ruby” in some ways,
but it would be a Ruby that could leverage the entire Java platform, now
GPL and freely available. So there’s two ways to think about JRuby: as
an alternative implementation of Ruby and as an alternative language for
the Java platform.
But you just told him not to think of the second, a paragraph earlier!
Sure, there are valid motivations for JRuby (duh), but does your
motivation inequality apply equally to M. Dober, professed
Java-disliker?
It’s also very important to remember that the technologies in Strongtalk
and Self live on in HotSpot; so it’s not far off to say that Smalltalk
technology is in play today to make Java run faster. If we can find good
ways to leverage that technology from JRuby (and other dynlang impls) we
may achieve what Parrot is still working on: a world-class VM for many
dynamic languages.
I think what the smalltalkers are arguing is that it’d be much easier to
leverage those fun things in a Ruby-Smalltalk implementation, because
the two languages have much more in common than do Ruby and Java. Mind
you, I’m relatively clueless in all things language-implementation, so
consider me a messenger. Well, a curious messenger.
Devin
… who, by the way, isn’t knocking JRuby on any account.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs
