Are you sure about that?
http://vividpicture.com/aleks/atari/forth.jpg
On 12/31/06, M. Edward (Ed) Borasky <znmeb@cesmail.net> wrote:
Wilson Bilkovich wrote:
>
>> P.P.S: What exactly *is* the status of Perl 6?
>
> I will let this link stand on its own, with.. no.. further.. commentary:
> http://dev.perl.org/perl6/doc/design/syn/S05.html
Holy Toledo!<ducking>
Forth is looking better every day
Logan Capaldo wrote:
On Mon, Jan 01, 2007 at 11:18:22PM +0900, Martin DeMello wrote:
On 12/31/06, M. Edward (Ed) Borasky <znmeb@cesmail.net> 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.But there *is* something wrong with implementing a *new* Ruby
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.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?
--
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 Nutter 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.
Robert Dober wrote:
<lots of good points snipped>
And I have gladely taken them especially the one about Java being your
friend even if you do not like it!!!
I think Ruby has the potential to be a "friendlier" Smalltalk, friendly
enough that it could be Smalltalk design principals to a much wider
development world.
That was after all also my idea, I still think that albeit some good points
Ed made on the GUI, a Smalltalk GUI system would be a *very* productive
development environement. To be clear I guess so I *do not know*.
Ruby has taken the many of the best features of
Smalltalk (and Lisp, and a few others) and made them usable in a
friendly, fun context. That's no small feat.
<snip>
Here's a quick alioth shootout comparing VisualWorks Smalltalk (they
claim it's comparable to Strongtalk) versus "Java JDK -server", whatever
that is. Java comes out well ahead on almost every benchmark in terms of
both performance AND memory use. I believehttp://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=vw&lang2=java
Also versus GST Smalltalk (I'm not famiiar with it). Again Java comes
out well ahead:http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=gst&lang2=java
It's also very important to remember that the technologies in Strongtalk
and Self live on in HotSpot;
Is HotSpot open source now?
so it's not far off to say that Smalltalk
technology is in play today to make Java run faster.
That is very nice credit you are giving them
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 ll try to get some time looking at it.
And without any ambition because of lack of time, money and (probably 
talent, it might nevertheless by a nice personal project to port some of
jRuby to Smalltalk.
Thanks for your precise and kind answers.
On 1/2/07, Charles Oliver Nutter <charles.nutter@sun.com> wrote:
--
Charles Oliver Nutter, JRuby Core Developer
Blogging on Ruby and Java @ headius.blogspot.com
Help spec out Ruby today! @ Welcome to headius.com
headius@headius.com -- charles.nutter@sun.com
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."
- Alan Kay
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.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.
No numbers, but I have been keeping a vague eye on perl6 and pugs, and
the impression I get is that Haskell has proved to be far more of an
asset (it's a very productive language indeed) than a dealbreaker.
O'Reilly Media - Technology and Business Training is indicative.
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.
I can't argue with that, but I hope it's wrong. There really is a lot
to be gained from powerful, expressive languages, which C is
emphatically not.
martin
On 1/2/07, M. Edward (Ed) Borasky <znmeb@cesmail.net> wrote:
Doesn't this mapping imply generating platform-specific machine code
directly from the code that targets your V-ISA?
To my knowledge, Parrot isn't planning to do this. (Feel free to
correct me with a link I missed on Google, though.)
That is a big, big job requiring more machine-level expertise than has
yet arrived in the #rubinius IRC channel. Heh.
That's the basic thrust of my argument against register-based VMs.
Conceptually, the idea of having 'hard' mappings between virtual
registers and architected registers is cool. Actually implementing it
means basically reinventing gcc inside your project. Also, given that
by far the largest target platform is x86, and it has a tiny number of
gprs, you're going to be doing a lot of shuffling anyway. Why not let
a compiler handle that for you, since they spend all day, every day,
working on making it good at that task?
On 12/31/06, Francis Cianfrocca <garbagecat10@gmail.com> wrote:
On 12/31/06, M. Edward (Ed) Borasky <znmeb@cesmail.net> wrote:
>
> >>> And if it's more efficient to
> manage two or three stacks than dozens of registers, I think you want a
> stack machine and not a register machine.
> <<<You haven't established that it is more efficient. I'm completely
sympathetic to leveraging the strengths of particular hardware platforms as
available, but observe that most mainstream hardware is register-based.
High-quality register-based code is far harder to automatically generate
than stack-based (try it sometime), but you have more potential to squeeze
performance out of the machine by bypassing memory-bus cycles. Again, try it
sometime. It's not easy to do, and I surmise that some of the attractiveness
of the stack-based model comes from its simplicity. And also from the fact
that every register-based piece of hardware is different, so you're leaking
multiple abstractions into VM-level code where it arguably doesn't belong.
Does this make stack-based VMs axiomatically better-suited for dynamic
languages as opposed to languages like Java? I have no idea how to even
approach answering that question.
Francis Cianfrocca wrote:
Concurrency primitives: all of the actual intra-process concurrency features
you mentioned can be implemented straightforwardly, given the availability
of the atomic check-and-set primitive. You mention a lot of things that
don't fall into this realm, and as a former language designer, I think there
is a stylistic tradeoff to be made among them. It may not necessarily make
sense to implement all of them.
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. And yes, a language designer does need to be 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.
--
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.
Gregory Brown wrote:
On 12/31/06, M. Edward (Ed) Borasky <znmeb@cesmail.net> wrote:
Wilson Bilkovich wrote:
>
>> P.P.S: What exactly *is* the status of Perl 6?
>
> I will let this link stand on its own, with.. no.. further.. commentary:
> http://dev.perl.org/perl6/doc/design/syn/S05.html
Holy Toledo!<ducking>
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.
Logan Capaldo 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.
On 1/1/07, M. Edward (Ed) Borasky <znmeb@cesmail.net> wrote:
--
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.
--
thanks,
-pate
-------------------------
Yep:
https://openjdk.dev.java.net/hotspot/
On 1/2/07, Robert Dober <robert.dober@gmail.com> wrote:
On 1/2/07, Charles Oliver Nutter <charles.nutter@sun.com> wrote:
>
> It's also very important to remember that the technologies in Strongtalk
> and Self live on in HotSpot;Is HotSpot open source now?
<snip>
http://www.oreillynet.com/onlamp/blog/2005/10/ofun.html is indicative.
What a great link!!!!!
Thx a lot for sharing.
<snip>
martin
Robert
On 1/3/07, Martin DeMello <martindemello@gmail.com> wrote:
--
"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."
- Alan Kay
Devin Mullins wrote:
Charles Oliver Nutter wrote:
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?
JRuby will be both a floor wax AND a dessert topping.
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.
<dons asbestos-lined suit>
Then I encourage them by all means to make such things happen. Except that they aren't, and they haven't. Actions speak louder than words, and unfortunately smalltalkers seem to talk big (yuk yuk) but produce little.
If a Ruby implementation on a Smalltalk VM is so easy, where is it?
--
Charles Oliver Nutter, JRuby Core Developer
Blogging on Ruby and Java @ headius.blogspot.com
Help spec out Ruby today! @ Welcome to headius.com
headius@headius.com -- charles.nutter@sun.com
Fair enough, but from the small amount of commentary I've seen, I
don't think parrot is going to matter to anyone anyway. From what I
can tell, most people would be happy with a Ruby implementation that
had "better" performance (in most cases that means faster and more
linear with respect to working set size), more modern GC, and native
threads. Very few people are looking for a "better" version of the
language itself, and since that would constitute a fork, it's not
likely to succeed anyway.
Intel chips: why do you say they have a tiny number of gprs's? That
hasn't been true for years, unless your idea of tiny is as big as,
say, the size of the register file on an ultrasparc chip.
On 12/31/06, Wilson Bilkovich <wilsonb@gmail.com> wrote:
> Doesn't this mapping imply generating platform-specific machine code
directly from the code that targets your V-ISA?
To my knowledge, Parrot isn't planning to do this. (Feel free to
correct me with a link I missed on Google, though.)That is a big, big job requiring more machine-level expertise than has
yet arrived in the #rubinius IRC channel. Heh.That's the basic thrust of my argument against register-based VMs.
Conceptually, the idea of having 'hard' mappings between virtual
registers and architected registers is cool. Actually implementing it
means basically reinventing gcc inside your project. Also, given that
by far the largest target platform is x86, and it has a tiny number of
gprs, you're going to be doing a lot of shuffling anyway. Why not let
a compiler handle that for you, since they spend all day, every day,
working on making it good at that task?
Wilson Bilkovich wrote:
Also, given that
by far the largest target platform is x86, and it has a tiny number of
gprs, you're going to be doing a lot of shuffling anyway. Why not let
a compiler handle that for you, since they spend all day, every day,
working on making it good at that task?
Actually, though, if you have a look at Software optimization resources. C++ and assembly. Windows, Linux, BSD, Mac OS X, you'll see that not only is the *compiler* working hard to do that, so are those bazillions of transistors in the chip! Just because an 8088 only had half a dozen registers, none of which was truly general purpose, and needed an 8087 to do floating point computing, doesn't mean a Tulsa can't have hundreds or thousands of threads' worth of copies of the 8087 and 8088.
So why not have a Ruby inner interpreter that exploits the massive parallelism, concurrency and caching that's on the chip? In short, why should Sun, Microsoft and the open source community build the Ruby interpreters? Intel and AMD build their own compilers and math libraries, or contract them out -- why don't they build Ruby (and Perl and Python and PHP) interpreters too?
There's not a heck of a lot I can do about AMD, but I *am* in Intel's back yard.
--
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.
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 ;-).
On 12/31/06, M. Edward (Ed) Borasky <znmeb@cesmail.net> 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.
pat eyler wrote:
On 1/1/07, M. Edward (Ed) Borasky <znmeb@cesmail.net> wrote:
Logan Capaldo 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.--
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.
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.
However would that not make it possible to make it as fast a VM for
Smalltalk as for Java at least?
I still believe that more is better than viewer and that SmallTalk is much
more modern than Java, sorry about that.
Thx for the input!
Robert
On 1/2/07, Wilson Bilkovich <wilsonb@gmail.com> wrote:
On 1/2/07, Robert Dober <robert.dober@gmail.com> wrote:
> On 1/2/07, Charles Oliver Nutter <charles.nutter@sun.com> wrote:
> >
> > It's also very important to remember that the technologies in
Strongtalk
> > and Self live on in HotSpot;
>
> Is HotSpot open source now?
>Yep:
https://openjdk.dev.java.net/hotspot/Now I should really rethink before writing so fast
--
"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."
- Alan Kay
Robert Dober wrote:
On 1/3/07, Martin DeMello <martindemello@gmail.com> wrote:
<snip>
O'Reilly Media - Technology and Business Training is indicative.
What a great link!!!!!
Thx a lot for sharing.
<snip>
Yeah ... fun is definitely a compelling business reason for moving from subversion to Darcs. So -- is there any chance that Perl 6 will become a dialect of Haskell rather than a rewrite of Perl?
And who has more fun -- Ruby programmers or Haskell programmers?
--
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.
I talk much and produce little not the Smalltalkers. This is after all a
Ruby List.
I did not take offence because I know best for myself that I am not up to a
task like yours but I still have the feeling that Smalltalk has its time
ahead.
If a Ruby implementation on a Smalltalk VM is so easy, where is it?
Ok I will do it, alpha is planned for 2042, sigghhhh!
Robert
On 1/4/07, Charles Oliver Nutter <charles.nutter@sun.com> wrote:
Devin Mullins wrote:
> Charles Oliver Nutter wrote:
>> 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?JRuby will be both a floor wax AND a dessert topping.
> 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.<dons asbestos-lined suit>
Then I encourage them by all means to make such things happen. Except
that they aren't, and they haven't. Actions speak louder than words, and
unfortunately smalltalkers seem to talk big (yuk yuk) but produce little.
--
Charles Oliver Nutter, JRuby Core Developer
Blogging on Ruby and Java @ headius.blogspot.com
Help spec out Ruby today! @ Welcome to headius.com
headius@headius.com -- charles.nutter@sun.com
--
"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."
- Alan Kay
Tiny compared to the PowerPC, for example. x86 is characterized by a
small number of registers, assisted by some crazy-fast instructions
for flipping them around. I think that's a fair statement still, yes?
re: concurrency. We're implementing STM in Rubinius, so you'll be able to say:
atomic do
critical section of code here
end
I'm (personally) amused by being able to use the same 'pseudo-code'
syntax as the papers that introduced the idea of transactional memory.
Heh.
On 12/31/06, Francis Cianfrocca <garbagecat10@gmail.com> wrote:
On 12/31/06, Wilson Bilkovich <wilsonb@gmail.com> wrote:
> Doesn't this mapping imply generating platform-specific machine code
> directly from the code that targets your V-ISA?
> To my knowledge, Parrot isn't planning to do this. (Feel free to
> correct me with a link I missed on Google, though.)
>
> That is a big, big job requiring more machine-level expertise than has
> yet arrived in the #rubinius IRC channel. Heh.
>
> That's the basic thrust of my argument against register-based VMs.
> Conceptually, the idea of having 'hard' mappings between virtual
> registers and architected registers is cool. Actually implementing it
> means basically reinventing gcc inside your project. Also, given that
> by far the largest target platform is x86, and it has a tiny number of
> gprs, you're going to be doing a lot of shuffling anyway. Why not let
> a compiler handle that for you, since they spend all day, every day,
> working on making it good at that task?
>Fair enough, but from the small amount of commentary I've seen, I
don't think parrot is going to matter to anyone anyway. From what I
can tell, most people would be happy with a Ruby implementation that
had "better" performance (in most cases that means faster and more
linear with respect to working set size), more modern GC, and native
threads. Very few people are looking for a "better" version of the
language itself, and since that would constitute a fork, it's not
likely to succeed anyway.Intel chips: why do you say they have a tiny number of gprs's? That
hasn't been true for years, unless your idea of tiny is as big as,
say, the size of the register file on an ultrasparc chip.
