Forum: Ruby Status of Cardinal (was Re: Proposal to create a new mailing

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
pat eyler (Guest)
on 2006-12-30 19:06
(Received via mailing list)
On 12/30/06, Gregory S. <removed_email_address@domain.invalid> wrote:
> [deleted] Cardinal (Ruby on Parrot, which may or may not be dead)

It's not dead, it's pining for the fjords.  No, actually, Kevin T., the
maintainer, has been bogged down with school related issues the
last two months, but has told me that he's chomping at the bit to
start chasing Cardinal again.

You can track his progress at:
   http://http://cardinal2.rubyforge.org/

(The original cardinal project appears to be dead, and Kevin's had
no luck raising the maintainer to get the project transferred -- if
anyone's up to helping with with that, Kevin would probably
appreciate it.)
Francis C. (Guest)
on 2006-12-30 19:58
(Received via mailing list)
On 12/30/06, pat eyler <removed_email_address@domain.invalid> wrote:
>
> -pate
> -------------------------
> http://on-ruby.blogspot.com
>
>

I think Ruby/Parrot is pretty interesting. Anyone else interested
enough to put some time into it?
M. Edward (Ed) Borasky (Guest)
on 2006-12-30 22:55
(Received via mailing list)
Francis C. wrote:
>>    http://http://cardinal2.rubyforge.org/
>> thanks,
>> -pate
>> -------------------------
>> http://on-ruby.blogspot.com
>>
>>
>
> I think Ruby/Parrot is pretty interesting. Anyone else interested
> enough to put some time into it?
>
>
Well ... I'm not! Don't you think jRuby, Rubinius, "Microsoft Ruby", and
YARV are enough? jRuby and "Microsoft Ruby" have industrial support,
Rubinius and YARV have vibrant communities and core teams of excellent
hackers. The other two -- Cardinal and the vmgen/Forth version, whose
name I've forgotten -- have languished as half-person projects.

At one point I considered reviving the vmgen one because I'm a Forth
hacker (I know Forth better than I know C, in fact), but once I learned
that YARV had adopted direct threading and a stack machine -- the two
core ideas behind vmgen -- I abandoned that idea in a big hurry. Parrot
is a *register* machine because it caters to assembler programmers who
grew up on things like the Motorola 68000 and System\360, not because
that's the "right way" to build a virtual machine for dynamic languages.
:)

--
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.
Wilson B. (Guest)
on 2006-12-30 23:19
(Received via mailing list)
On 12/30/06, M. Edward (Ed) Borasky <removed_email_address@domain.invalid> 
wrote:
> >> You can track his progress at:
> >> --
> >
> is a *register* machine because it caters to assembler programmers who
> grew up on things like the Motorola 68000 and System\360, not because
> that's the "right way" to build a virtual machine for dynamic languages. :)

Exactly. I wasn't going to chime in until someone broke the ice.. but
the Parrot team basically can't explain the design rationale. It's
even featured in a solid book about virtual machines, along with a
narrative that amounts to: "Uhh.. umm.. this is certainly an
interesting way to go about it."

From Ruby's perspective, it also has the odd feature of having
separate registers for Strings and for Objects. *shudder*

Anyone who wants to hack on a Ruby VM will receive a warm welcome in
the arms of Rubinius. :)

P.S. I have the utmost respect for Parrot's implementation team. It's
just not the VM I want to see for Ruby.
Francis C. (Guest)
on 2006-12-30 23:47
(Received via mailing list)
On 12/30/06, M. Edward (Ed) Borasky <removed_email_address@domain.invalid> 
wrote:
> >> You can track his progress at:
> >> --
> >
> is a *register* machine because it caters to assembler programmers who
>
And another interesting idea bites the dust.
M. Edward (Ed) Borasky (Guest)
on 2006-12-31 00:33
(Received via mailing list)
Francis C. wrote:
>> >> start chasing Cardinal again.
>> >> > --Greg
>> > enough to put some time into it?
>> that YARV had adopted direct threading and a stack machine -- the two
>> If God had meant for carrots to be eaten cooked, He would have given
>> rabbits fire.
>>
>>
>>
>
> And another interesting idea bites the dust.
>
>
Well ... as the old saying goes, "Adding programmers to a late project
makes it later." :) I certainly don't want to discourage Kevin T. from
pursuing his goals with Cardinal, and I don't want to discourage anyone
else who thinks it's "interesting". But I have my own languishing
half-person projects to look after. :) And I have confidence that at
least jRuby, Rubinius and YARV are "good enough" without diluting the
Ruby implementation space with Parrot or vmgen.

I'm less sure about "Microsoft Ruby" for a number of reasons:

1. Microsoft's attitude towards open source and software patents,
2. The fact that I haven't heard much about the .NET/CLR-based
implementations since RubyConf 2006, unlike the others, which are
regularly discussed here,
3. The difficulties Austin Z. and Curt H. are having connecting
with Microsoft over the issues associated with compiled Ruby extensions
on the Windows platform,
4. The general feeling, as noted by Eric Raymond, that MacOS is the
horse to beat in the race to the 64-bit desktop OS. Again, see

http://www.catb.org/~esr/writings/world-domination...



--
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.
M. Edward (Ed) Borasky (Guest)
on 2006-12-31 00:55
(Received via mailing list)
Wilson B. wrote:
> Exactly. I wasn't going to chime in until someone broke the ice.. but
> the Parrot team basically can't explain the design rationale. It's
> even featured in a solid book about virtual machines, along with a
> narrative that amounts to: "Uhh.. umm.. this is certainly an
> interesting way to go about it."
What's the name of the book? The only book I've seen is the O'Reilly
book on Perl 6 and Parrot. That pretty much ignores Python, PHP and
Ruby, of course. :)
> From Ruby's perspective, it also has the odd feature of having
> separate registers for Strings and for Objects. *shudder*
IIRC they also have separate integer and float registers, just like many
real machines. *That* -- a separate floating point stack vs. a single
"parameter stack" -- was a big debate point in the discussions leading
up to the ANS Forth standard, and in the end, the standard had to be
written so either could be implemented.
> Anyone who wants to hack on a Ruby VM will receive a warm welcome in
> the arms of Rubinius. :)
Well ... to repeat myself:
1. Adding programmers to a late project makes it later.
2. I have my own languishing half-person projects to look after.
3. I really really suck at C programming -- I can just barely read C.
> P.S. I have the utmost respect for Parrot's implementation team. It's
> just not the VM I want to see for Ruby.
P.P.S: What exactly *is* the status of Perl 6? :)

--
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.
Wilson B. (Guest)
on 2006-12-31 01:09
(Received via mailing list)
On 12/30/06, M. Edward (Ed) Borasky <removed_email_address@domain.invalid> 
wrote:
> Wilson B. wrote:
> > Exactly. I wasn't going to chime in until someone broke the ice.. but
> > the Parrot team basically can't explain the design rationale. It's
> > even featured in a solid book about virtual machines, along with a
> > narrative that amounts to: "Uhh.. umm.. this is certainly an
> > interesting way to go about it."
> What's the name of the book? The only book I've seen is the O'Reilly
> book on Perl 6 and Parrot. That pretty much ignores Python, PHP and
> Ruby, of course. :)

http://www.amazon.com/Virtual-Machines-Iain-D-Crai...
Badly needed an additional editor to fix typos and other mistakes, but
is a very interesting book none the less.

> > From Ruby's perspective, it also has the odd feature of having
> > separate registers for Strings and for Objects. *shudder*
> IIRC they also have separate integer and float registers, just like many
> real machines. *That* -- a separate floating point stack vs. a single
> "parameter stack" -- was a big debate point in the discussions leading
> up to the ANS Forth standard, and in the end, the standard had to be
> written so either could be implemented.

> > Anyone who wants to hack on a Ruby VM will receive a warm welcome in
> > the arms of Rubinius. :)
> Well ... to repeat myself:
> 1. Adding programmers to a late project makes it later.
> 2. I have my own languishing half-person projects to look after.
> 3. I really really suck at C programming -- I can just barely read C.

Well, I meant it as a general invite. :)

> 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
M. Edward (Ed) Borasky (Guest)
on 2006-12-31 10:54
(Received via mailing list)
Wilson B. 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 :)

--
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.
Robert D. (Guest)
on 2006-12-31 11:14
(Received via mailing list)
On 12/30/06, M. Edward (Ed) Borasky <removed_email_address@domain.invalid> 
wrote:
> >> start chasing Cardinal again.
> >> > --Greg
> > enough to put some time into it?
> >
> >
> Well ... I'm not! Don't you think jRuby, Rubinius, "Microsoft Ruby", and
> YARV are enough? jRuby and "Microsoft Ruby" have industrial support,
> Rubinius and YARV have vibrant communities and core teams of excellent
> hackers. The other two -- Cardinal and the vmgen/Forth version, whose
> name I've forgotten -- have languished as half-person projects.


I guess it is very reasonable what you are saying and yet I`d wish to
have
a SmallRuby, something squeakish you see. First that might really make
the
difference for both languages and secondly it might as well turn out to
be
faster and more agile  than YARV or JRuby (well JRuby for sure as the
used
language is just faster - Smalltalk just fits better to Ruby than Java).
If only I were (a) rich, (b) a genius and (c) three persons the project
would be rolling already :(

Actually it would attack the two most criticised points of Ruby "speed"
and
"IDE":)

At one point I considered reviving the vmgen one because I'm a Forth
> hacker (I know Forth better than I know C, in fact), but once I learned
> that YARV had adopted direct threading and a stack machine -- the two
> core ideas behind vmgen -- I abandoned that idea in a big hurry. Parrot
> is a *register* machine because it caters to assembler programmers who
> grew up on things like the Motorola 68000 and System\360, not because
> that's the "right way" to build a virtual machine for dynamic languages.
> :)


Hmmm be careful about that statement I guess you know you might be wrong
;)

--
> 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.
>
>
>
Cheers
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
M. Edward (Ed) Borasky (Guest)
on 2006-12-31 20:41
(Received via mailing list)
Robert D. wrote:
> would be rolling already :(
Of the Ruby implementations, I'm guessing Rubinius is closest to a
"SmallRuby" as you describe it. At least the way Evan P. described
it at RubyConf makes me think that. However, I'm not at all thrilled
with the Squeak UI. It is so contrary to everything I do on a daily
basis that I find it difficult to do any more than replay the built-in
demos. And it's visually unappealing to me on top of that. Squeak is an
exciting and interesting project -- it's just too far away from my
default modus operandi.

> Actually it would attack the two most criticised points of Ruby
> "speed" and
> "IDE":)
I haven't seen benchmarks from the jRuby people recently and I don't
recall ever seeing any from Rubinius, but I think jRuby is even now
faster than the standard C version on some benchmarks, and YARV is four
times as fast as the standard C version on my "Matrix" benchmark, which
(very indirectly) tests speed of "exact math".

Concerning IDEs, I've already said that I find the Squeak UI unusable,
although I know I could learn it. But what's the motivation for learning
Squeak? Aside from a rather nifty continuation-based web framework
called Seaside, there's nothing written in Squeak that remotely
resembles any of the projects that interest me -- computational finance,
applied mathematics, performance engineering.

The only thing that I find *very* interesting in Squeak is Squeak's
rather extensive built-in MIDI/audio capabilities. Squeak appears to be
a fine platform for algorithmic composition and synthesis. But I'm so
used to the Lisp and CSound (and Lilypond and Rosegarden and Alsa-jack)
way of doing those things that it's a tradeoff between learning another
way of doing something I already know how to do for the joy of learning
or just getting stuff done. Once again, it's the triumph of "good
enough" over "cool beyond words". :)

Let's have a Ruby IDE that works the way Rubyists work -- integrated
with Rspec/Rdoc/Ri/ZenTest/Rake/Hoe/Rubygems (and Rails/Mongrel -- let's
not forget Rails). Again, that's probably a lot more like Rubinius and a
lot less like jRuby or "Microsoft Ruby", which, after all, work the way
Java programmers or .NET programmers work for the most part.

As an aside, perhaps the JVM is more than just a virtual machine -- at
least that's the way it appears to me after seeing what jRuby is all
about. It seems to me to be very much an "operating system" --
concurrency primitives, process, thread and memory management, windowing
toolkit, mixing of languages (at least Ruby, Python, Java and C
extensions), etc.
> Hmmm be careful about that statement I guess you know you might be
> wrong ;)
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. :) C and the JVM and the CLR are "good enough", with the
possible exception of concurrency primitives.

--
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. (Guest)
on 2006-12-31 21:29
(Received via mailing list)
I'm not jumping back into this in a big way, since it's obvious
Ruby-on-Parrot isn't intriguing to enough people to make it worth the
attention.

But on this point of register vs. stack machines. Most of the people
writing to the VM are language implementors, not ordinary users, and
they have a lot of sophisticated things to learn anyway. Most real
hardware supports the register-file model either natively, in
microcode, or with opcodes. I'm not convinced that the stack-based
model necessarily gives advantages over the register-based, and my
intuition says that other factors in the machine architecture are more
important.

Most of the recent work in VM optimization has taken place in the JVM
context, and involves extreme cleverness in regard to what code should
be compiled or recompiled to native opcodes, and when. But look at the
older literature, from before the release of Java, and you'll find a
lot of stuff that is probably more germane to dynamic-language
processing (much of it done in the Smalltalk context, but still
generic): things like detecting and hard-compiling code that is not
likely to be metaprogrammed, and tuning these code paths heuristically
during the run.

My bottom line is this: I don't care about Perl, not even a little
tiny bit. But I'm not convinced that we've asked enough questions
about the ideal VM characteristics for supporting highly-dynamic
languages. I know little about Rubinius and have not conversed with
Evan. I'm quite impressed with Charles' work to date on JRuby, but the
JVM may not be the ideal platform for running Ruby. I don't think
we've heard the last word.

And Ruby is in a distinct class compared to other dynamic languages
because of the unusual degree to which it encourages and benefits from
metaprogramming. No, that's not to say other languages can't do
similar things. It is to say that this is part of "the Ruby way," and
I find Ruby handicapped by the huge performance penalty that
metaprogramming often imposes.

Concurrency primitives: at the end of the day, there is only one
primitive that is really required, and it MUST be supplied by the
hardware, not the VM. That's the atomic check-and-set operation, of
course. Threading packages for C can be and often are supplied as
pure-userland libraries.
M. Edward (Ed) Borasky (Guest)
on 2006-12-31 23:15
(Received via mailing list)
Francis C. wrote:
> But on this point of register vs. stack machines. Most of the people
> writing to the VM are language implementors, not ordinary users, and
> they have a lot of sophisticated things to learn anyway. Most real
> hardware supports the register-file model either natively, in
> microcode, or with opcodes. I'm not convinced that the stack-based
> model necessarily gives advantages over the register-based, and my
> intuition says that other factors in the machine architecture are more
> important.
Well ... most of the interesting problems in this area are either
NP-Complete or flat out unsolvable, so it boils down to questions of
what reasonably good programmers can get done in reasonable amounts of
time. For example, I think there's an awful lot of optimization in GCC
that most of us could live very well without. Back in the "good old
days", people used to compare compilers optimized for compile speed with
compilers that worked hard to generate fast code, and the typical result
was that there was only a factor of two improvement in run time speed
from working hard to generate fast code.

But when the code in question is a language interpreter or run-time,
that's another thing entirely. In that case, I think you *do* want to
work hard to squeeze the most out of the hardware. I think you *do* want
to do what the vmgen/gforth project does -- exploit things in GCC that
aren't part of the C language standard to squeeze every last wasted
cycle out of the "inner interpreter". 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.

And given that you've embraced a GCC dependency, I think you *do* want
to go the extra step and put in assembly language kernels for x86,
x86-64 and probably PPC and SPARC and ARM architectures as well. Why
should a linear algebra library like Atlas, which runs continuously for
hours on a problem, be allowed to do that and not a language
interpreter, which also runs continuously for hours on a problem?

> Most of the recent work in VM optimization has taken place in the JVM
> context, and involves extreme cleverness in regard to what code should
> be compiled or recompiled to native opcodes, and when.
Well, I'm not at all familiar with the Microsoft CLR, but I suspect
they're got some equally bright folks hacking on it as well.
> But look at the
> older literature, from before the release of Java, and you'll find a
> lot of stuff that is probably more germane to dynamic-language
> processing (much of it done in the Smalltalk context, but still
> generic): things like detecting and hard-compiling code that is not
> likely to be metaprogrammed, and tuning these code paths heuristically
> during the run.
I'm not at all familiar with any of that. My background is "VLIW",
vector and parallel supercomputing and FORTRAN compilers for same. As an
aside, it really saddens me that the current crop of pundits bemoans the
ascendancy of multi-core processors with whining about "the applications
aren't ready, the software isn't ready, the languages aren't ready, the
operating systems aren't ready, programmers don't know how to deal with
concurrency," etc., etc. Come on, people -- Gene Amdahl formulated
Amdahl's Law in 1967! There are teraflop computing platforms operating
*today*! The guts of multi-media -- digital signal and image processing
-- have been parallelized and vectorized since the mid-1970s!
> My bottom line is this: I don't care about Perl, not even a little
> tiny bit. But I'm not convinced that we've asked enough questions
> about the ideal VM characteristics for supporting highly-dynamic
> languages. I know little about Rubinius and have not conversed with
> Evan. I'm quite impressed with Charles' work to date on JRuby, but the
> JVM may not be the ideal platform for running Ruby. I don't think
> we've heard the last word.
Well ... maybe we haven't heard the "last" word, but we've certainly
heard the directions of the four major Ruby implementors -- if there are
indeed still four. I think when all the smoke clears, at least jRuby and
YARV will still be standing and will be "for all practical purposes"
equivalent in performance. Rubinius in some form or another will survive
and thrive, though I'm not sure it will be as a virtual machine -- I
think of it more as an IDE/OS in the same sense as Squeak is to
Smalltalk.
> And Ruby is in a distinct class compared to other dynamic languages
> because of the unusual degree to which it encourages and benefits from
> metaprogramming. No, that's not to say other languages can't do
> similar things. It is to say that this is part of "the Ruby way," and
> I find Ruby handicapped by the huge performance penalty that
> metaprogramming often imposes.
This is where I think the edge goes to Rubinius.
> Concurrency primitives: at the end of the day, there is only one
> primitive that is really required, and it MUST be supplied by the
> hardware, not the VM. That's the atomic check-and-set operation, of
> course. Threading packages for C can be and often are supplied as
> pure-userland libraries.
It's not just atomic check-and-set -- it's *all* of the conveniences
people expect. Message passing, monitors, lightweight processes a la
Erlang/Termite, drb, Rinda, starfish, high-speed numeric vector
processing -- it *all* has to be there, either in the language or in a
library and supported *efficiently* by the run time on the major
operating systems and hardware. Otherwise, it violates the dictum that
it's possible to write FORTRAN programs in any language. :)

--
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. (Guest)
on 2006-12-31 23:31
(Received via mailing list)
Robert D. wrote:
> I guess it is very reasonable what you are saying and yet I`d wish to have
> a SmallRuby, something squeakish you see. First that might really make the
> difference for both languages and secondly it might as well turn out to be
> faster and more agile  than YARV or JRuby (well JRuby for sure as the used
> 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? And Squeak is far from being one of the fastest
incarnations.
Francis C. (Guest)
on 2006-12-31 23:37
(Received via mailing list)
On 12/31/06, M. Edward (Ed) Borasky <removed_email_address@domain.invalid> 
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.

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.
Wilson B. (Guest)
on 2006-12-31 23:47
(Received via mailing list)
On 12/31/06, Francis C. <removed_email_address@domain.invalid> wrote:
> available, but observe that most mainstream hardware is register-based.
>
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?
Francis C. (Guest)
on 2006-12-31 23:57
(Received via mailing list)
On 12/31/06, Wilson B. <removed_email_address@domain.invalid> wrote:
 > Doesn't this mapping imply generating platform-specific machine code
> 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.
M. Edward (Ed) Borasky (Guest)
on 2007-01-01 00:05
(Received via mailing list)
Francis C. 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.
Wilson B. (Guest)
on 2007-01-01 00:20
(Received via mailing list)
On 12/31/06, Francis C. <removed_email_address@domain.invalid> wrote:
> > Conceptually, the idea of having 'hard' mappings between virtual
> Fair enough, but from the small amount of commentary I've seen, I
> say, the size of the register file on an ultrasparc chip.
>

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.
M. Edward (Ed) Borasky (Guest)
on 2007-01-01 00:30
(Received via mailing list)
Wilson B. 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 http://agner.org/optimize/,
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.
Francis C. (Guest)
on 2007-01-01 00:34
(Received via mailing list)
On 12/31/06, M. Edward (Ed) Borasky <removed_email_address@domain.invalid> 
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. :) 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.



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 ;-).
M. Edward (Ed) Borasky (Guest)
on 2007-01-01 00:36
(Received via mailing list)
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.
M. Edward (Ed) Borasky (Guest)
on 2007-01-01 00:56
(Received via mailing list)
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.
Chuck R. (Guest)
on 2007-01-01 02:20
(Received via mailing list)
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] http://en.wikipedia.org/wiki/Actor_model
[4] http://iolanguage.com/about/
Francis C. (Guest)
on 2007-01-01 02:40
(Received via mailing list)
On 12/31/06, M. Edward (Ed) Borasky <removed_email_address@domain.invalid> 
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.
M. Edward (Ed) Borasky (Guest)
on 2007-01-01 02:58
(Received via mailing list)
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/bpt...

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.
Brian M. (Guest)
on 2007-01-01 03:00
(Received via mailing list)
On 12/31/06, removed_email_address@domain.invalid 
<removed_email_address@domain.invalid> 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 parallel
>
> It 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.
Francis C. (Guest)
on 2007-01-01 03:24
(Received via mailing list)
On 12/31/06, Brian M. <removed_email_address@domain.invalid> 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.
Robert D. (Guest)
on 2007-01-01 12:59
(Received via mailing list)
On 12/31/06, Charles Oliver N. <removed_email_address@domain.invalid> 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
> removed_email_address@domain.invalid -- removed_email_address@domain.invalid
>
> 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."

- Alan Kay
Martin DeMello (Guest)
on 2007-01-01 16:19
(Received via mailing list)
On 12/31/06, M. Edward (Ed) Borasky <removed_email_address@domain.invalid> 
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. :) C and the JVM and the CLR are "good enough", with the
> 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. (Guest)
on 2007-01-01 23:48
(Received via mailing list)
On 12/31/06, M. Edward (Ed) Borasky <removed_email_address@domain.invalid> 
wrote:
>
> Forth is looking better every day :)

Are you sure about that?
http://vividpicture.com/aleks/atari/forth.jpg
M. Edward (Ed) Borasky (Guest)
on 2007-01-02 00:16
(Received via mailing list)
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.
M. Edward (Ed) Borasky (Guest)
on 2007-01-02 00:20
(Received via mailing list)
Gregory B. wrote:
>>
>> <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 C. (Guest)
on 2007-01-02 02:36
(Received via mailing list)
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. (Guest)
on 2007-01-02 02:44
(Received via mailing list)
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.
M. Edward (Ed) Borasky (Guest)
on 2007-01-02 03:50
(Received via mailing list)
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.
M. Edward (Ed) Borasky (Guest)
on 2007-01-02 03:54
(Received via mailing list)
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.
pat eyler (Guest)
on 2007-01-02 04:12
(Received via mailing list)
On 1/1/07, M. Edward (Ed) Borasky <removed_email_address@domain.invalid> 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.
M. Edward (Ed) Borasky (Guest)
on 2007-01-02 04:24
(Received via mailing list)
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. (Guest)
on 2007-01-02 05:32
(Received via mailing list)
Robert D. wrote:
> 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.

See my comments and links on performance further down...

>
> 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.

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.

>
> 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.

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. Last I checked, there were still quite a few Java
shops around :)

>
> 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?

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. 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.

> 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).

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 believe

http://shootout.alioth.debian.org/gp4/benchmark.ph...

Also versus GST Smalltalk (I'm not famiiar with it). Again Java comes
out well ahead:

http://shootout.alioth.debian.org/gp4/benchmark.ph...

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.
Devin M. (Guest)
on 2007-01-02 05:48
(Received via mailing list)
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.
Robert D. (Guest)
on 2007-01-02 21:11
(Received via mailing list)
On 1/2/07, Charles Oliver N. <removed_email_address@domain.invalid> wrote:
>
> Robert D. 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>

> out well ahead:
>
>
> http://shootout.alioth.debian.org/gp4/benchmark.ph...
>
> 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.

--
> Charles Oliver N., JRuby Core Developer
> Blogging on Ruby and Java @ headius.blogspot.com
> Help spec out Ruby today! @ www.headius.com/rubyspec
> removed_email_address@domain.invalid -- removed_email_address@domain.invalid
>
>

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
Wilson B. (Guest)
on 2007-01-02 21:17
(Received via mailing list)
On 1/2/07, Robert D. <removed_email_address@domain.invalid> wrote:
> On 1/2/07, Charles Oliver N. <removed_email_address@domain.invalid> 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/
Robert D. (Guest)
on 2007-01-02 21:41
(Received via mailing list)
On 1/2/07, Wilson B. <removed_email_address@domain.invalid> wrote:
> >
>
> Yep:
> https://openjdk.dev.java.net/hotspot/
>
> Now I should really rethink before writing so fast :(
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
--
"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 (Guest)
on 2007-01-03 01:34
(Received via mailing list)
On 1/2/07, M. Edward (Ed) Borasky <removed_email_address@domain.invalid> wrote:
> 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.

http://www.oreillynet.com/onlamp/blog/2005/10/ofun.html 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
Isaac G. (Guest)
on 2007-01-03 03:06
(Received via mailing list)
M. Edward (Ed) Borasky wrote:
> > Ruby.) But teaching programmers to be better at multithreading, etc.
> 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. :)

Why do you say Erlang does compile-time type checking?
Robert D. (Guest)
on 2007-01-03 16:20
(Received via mailing list)
On 1/3/07, Martin DeMello <removed_email_address@domain.invalid> wrote:
>
> <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

--
"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
M. Edward (Ed) Borasky (Guest)
on 2007-01-03 17:22
(Received via mailing list)
Robert D. wrote:
> On 1/3/07, Martin DeMello <removed_email_address@domain.invalid> wrote:
>>
>> <snip>
>>
>> http://www.oreillynet.com/onlamp/blog/2005/10/ofun.html 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.
Robert D. (Guest)
on 2007-01-03 17:26
(Received via mailing list)
On 1/3/07, M. Edward (Ed) Borasky <removed_email_address@domain.invalid> wrote:
> > 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?


Well it might be  a challange  to be more -Ofun than them  and I believe
Smalltalkers have a lot of fun too.
Robert

--
> 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 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 (Guest)
on 2007-01-03 17:44
(Received via mailing list)
On 1/3/07, M. Edward (Ed) Borasky <removed_email_address@domain.invalid> wrote:
> Yeah ... fun is definitely a compelling business reason for moving from
> subversion to Darcs.

No, but it's a compelling reason to spend your limited free time
hacking on Pugs rather than any project that might be competing for
your attention. Toss in the productivity boost Haskell gives you and
the future looks pretty bright for Pugs in terms of not drying up and
withering away.

> So -- is there any chance that Perl 6 will become a
> dialect of Haskell rather than a rewrite of Perl?

It's passing Perl 6 tests, so I'd say no :) On the other hand, Haskell
might just about be flexible enough to let it be both (not sure).

> And who has more fun -- Ruby programmers or Haskell programmers?

I enjoyed both, but the last time I looked at Haskell, Ruby was
definitely more in tune with the posixverse, and I didn't have any
real itch that Haskell scratched. Were I a perler I'd be very tempted
by pugs.

martin
M. Edward (Ed) Borasky (Guest)
on 2007-01-03 17:46
(Received via mailing list)
Robert D. wrote:
>> And who has more fun -- Ruby programmers or Haskell programmers?
>
>
> Well it might be  a challange  to be more -Ofun than them  and I believe
> Smalltalkers have a lot of fun too.
Someone (Dave T.? Andy H.? DHH?) said that Ruby made programming
fun *again*. So the obvious question is, "What languages were fun before
there was Ruby?"

I've never written any Smalltalk, so I can't comment there, but I have
to admit, as much as I enjoy programming in general, the two languages
that have been the most fun over the years have been Lisp (1.5 actually
-- I don't really enjoy Common Lisp all that much) and Forth.

The key to fun in that article, or at least one of them, seems to be the
rapid feedback that one can get with some languages. Certainly a Lisp or
Scheme REPL environment or Forth's equivalent, the "outer interpreter"
and "colon compiler", give that kind of rapid feedback. And Ruby has
irb, although there isn't really an "IDE" with irb at the core, at least
none that I'm aware of. In Forth, we used to call this process DATK --
Design At The Keyboard.

--
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.
Wilson B. (Guest)
on 2007-01-03 17:54
(Received via mailing list)
On 1/3/07, M. Edward (Ed) Borasky <removed_email_address@domain.invalid> wrote:
> > <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?
>

In Rubinius, fun is an object, just like stack frames and CPUs.
M. Edward (Ed) Borasky (Guest)
on 2007-01-03 18:09
(Received via mailing list)
Wilson B. wrote:
> In Rubinius, fun is an object, just like stack frames and CPUs.
CPUs are objects in Rubinius? Do you have your own scheduler?

--
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.
Wilson B. (Guest)
on 2007-01-03 20:19
(Received via mailing list)
On 1/3/07, M. Edward (Ed) Borasky <removed_email_address@domain.invalid> wrote:
> Wilson B. wrote:
> > In Rubinius, fun is an object, just like stack frames and CPUs.
> CPUs are objects in Rubinius? Do you have your own scheduler?
>

Yeah. We are planning to have M:N green->native thread mapping, so we
need to do some scheduling.
Martin DeMello (Guest)
on 2007-01-04 00:40
(Received via mailing list)
On 1/3/07, M. Edward (Ed) Borasky <removed_email_address@domain.invalid> wrote:
>
> The key to fun in that article, or at least one of them, seems to be the
> rapid feedback that one can get with some languages. Certainly a Lisp or
> Scheme REPL environment or Forth's equivalent, the "outer interpreter"
> and "colon compiler", give that kind of rapid feedback. And Ruby has
> irb, although there isn't really an "IDE" with irb at the core, at least
> none that I'm aware of. In Forth, we used to call this process DATK --
> Design At The Keyboard.

To me, one major component of 'fun' is how well the 'grain' of the
language supports clean, abstract programming and problem solving in
the domain at hand. Ruby is a lot of fun, for example, because its
blocks make control structure abstraction not only easy, but the
*natural* way to solve a problem, because it speaks unix very well
indeed, and because it is sufficiently multiparadigm that you almost
never need to fight the language to do what you want to do.

Lisp and Haskell are both almost as much fun as ruby, but  a major win
for the latter is that it is the first (sufficiently powerful)
language where I've never had to wonder whether I'm using the language
wrong or simply approaching the problem wrong (I've had experiences in
both CL and Haskell where I was actually making a mistake in my
formulation of the problem, but my first instinct was nevertheless to
blame my grasp of the language. Doubtless that will go away as I get
more comfortable in said languages, but with ruby I was comfortable
from day one).

martin
Yukihiro M. (Guest)
on 2007-01-04 03:49
(Received via mailing list)
Hi,

In message "Re: Fun languages (was Re: Status of Cardinal (was Re:
Proposal to create a new mailing list))"
    on Thu, 4 Jan 2007 00:46:11 +0900, "M. Edward (Ed) Borasky"
<removed_email_address@domain.invalid> writes:

|Someone (Dave T.? Andy H.? DHH?) said that Ruby made programming
|fun *again*. So the obvious question is, "What languages were fun before
|there was Ruby?"

BASIC was fun for me, when I was in junior high.  The point is that as
I grow up, the problem domain I am in charge become far more complex
than BASIC can handle.  That's why I need Ruby.

							matz.
M. Edward (Ed) Borasky (Guest)
on 2007-01-04 05:39
(Received via mailing list)
Yukihiro M. wrote:
> I grow up, the problem domain I am in charge become far more complex
> than BASIC can handle.  That's why I need Ruby.
>
> 							matz.
>
>
>
BASIC was *never* fun for me. I was in grad school when it came out, and
by then I had extensive FORTRAN and macro assembler experience and was
fooling around with Lisp 1.5. I simply can't imagine the people who
bought Altairs and spent *hours* reading Microsoft BASIC into the 8K of
RAM from an ASR 33. :)

--
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.
M. Edward (Ed) Borasky (Guest)
on 2007-01-04 06:09
(Received via mailing list)
Martin DeMello wrote:
> To me, one major component of 'fun' is how well the 'grain' of the
> language supports clean, abstract programming and problem solving in
> the domain at hand. Ruby is a lot of fun, for example, because its
> blocks make control structure abstraction not only easy, but the
> *natural* way to solve a problem, because it speaks unix very well
> indeed, and because it is sufficiently multiparadigm that you almost
> never need to fight the language to do what you want to do.
Yes, as long as your problem can be naturally expressed as a mapping
from real-world entities to objects and classes, Ruby is the natural way
to do it. I have a problem, however, that's most naturally coded as
vector and matrix operations. Moreover, the algorithm is already
defined, and although there are real world "classes" of "objects" --
workload classes and service centers in a queuing network, as a matter
of fact -- there's no "obvious" way to say the methods "belong" to a
workload class or a service center, because most of them are a double
loop over both workload classes and service centers. As a result, the
whole idea of doing it in Ruby is losing its appeal, and I'm probably
going to give up and write the whole thing in R. :(
>
> Lisp and Haskell are both almost as much fun as ruby, but  a major win
> for the latter is that it is the first (sufficiently powerful)
> language where I've never had to wonder whether I'm using the language
> wrong or simply approaching the problem wrong (I've had experiences in
> both CL and Haskell where I was actually making a mistake in my
> formulation of the problem, but my first instinct was nevertheless to
> blame my grasp of the language. Doubtless that will go away as I get
> more comfortable in said languages, but with ruby I was comfortable
> from day one).
Lisp, at least the dialect I learned many years ago and still think in,
is a very low-level language compared to Ruby. It is elegant and simple
and clean and powerful and all that, but there really are only two data
structures -- the dotted pair and the list. The impressions I've gotten
of Haskell -- pretty sparse, except that I've read the works on
Combinatory Logic by the man the language was named after, Haskell Curry
-- is that if you think in combinators, it's great.

But I don't ... and I don't really think in lambda calculus or objects
and classes either. I think in applied math, both numeric and symbolic,
and in macro assembler and Boolean logic design. That's one reason I
like Petri nets so much -- you can reduce them mechanically to matrix
operations. :)

--
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.
M. Edward (Ed) Borasky (Guest)
on 2007-01-04 06:25
(Received via mailing list)
Wilson B. wrote:
> On 1/3/07, M. Edward (Ed) Borasky <removed_email_address@domain.invalid> wrote:
>> Wilson B. wrote:
>> > In Rubinius, fun is an object, just like stack frames and CPUs.
>> CPUs are objects in Rubinius? Do you have your own scheduler?
>>
>
> Yeah. We are planning to have M:N green->native thread mapping, so we
> need to do some scheduling.
>
>
Very cool :)

--
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.
Jon H. (Guest)
on 2007-01-04 06:51
(Received via mailing list)
Yukihiro M. wrote:
> I grow up, the problem domain I am in charge become far more complex
> than BASIC can handle.  That's why I need Ruby.

Here's my list:

1. OCaml
2. Mathematica

F# is also fun but it is newer than Ruby.
M. Edward (Ed) Borasky (Guest)
on 2007-01-04 07:33
(Received via mailing list)
Jon H. wrote:
>>
> F# is also fun but it is newer than Ruby.
>
Mathematica is definitely fun, but expensive fun. Axiom is as much fun
and is open source. :)

--
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.
Giles B. (Guest)
on 2007-01-04 09:58
(Received via mailing list)
> > BASIC was fun for me, when I was in junior high.  The point is that as
> > I grow up, the problem domain I am in charge become far more complex
> > than BASIC can handle.  That's why I need Ruby.
> >
> BASIC was *never* fun for me. I was in grad school when it came out, and
> by then I had extensive FORTRAN and macro assembler experience and was
> fooling around with Lisp 1.5. I simply can't imagine the people who
> bought Altairs and spent *hours* reading Microsoft BASIC into the 8K of
> RAM from an ASR 33. :)

Basic was loads of fun for me, I learnt it when I was 10 or 11 on a
TRS-80. I thought it was the coolest thing in the world.

I'm playing with Smalltalk, it's fun.
Michael W. Ryder (Guest)
on 2007-01-04 10:42
(Received via mailing list)
M. Edward (Ed) Borasky wrote:
>> were fun before |there was Ruby?"
> by then I had extensive FORTRAN and macro assembler experience and was
> fooling around with Lisp 1.5. I simply can't imagine the people who
> bought Altairs and spent *hours* reading Microsoft BASIC into the 8K of
> RAM from an ASR 33. :)
>

I have used Business Basic (a superset of Basic) professionally for over
20 years and like a lot of things about it.  I love having screen and
file handling built into the language.  It makes it very easy to write
programs, no having to worry about requiring files or linking.  And
debugging is even easier as I can stop a program at any point see what
is going on, fix it, and continue.  I started with Fortran on IBM and
CDC mainframes but the language needed a lot of help to be user friendly
or debugging.  I spent over a week debugging a Fortran program that
baffled even the heads of the computer department before finding out my
problem was that I requested too much memory!
Robert D. (Guest)
on 2007-01-04 11:30
(Received via mailing list)
On 1/3/07, M. Edward (Ed) Borasky <removed_email_address@domain.invalid> wrote:
>
> I've never written any Smalltalk, so I can't comment there, but I have
> to admit, as much as I enjoy programming in general, the two languages
> that have been the most fun over the years have been Lisp (1.5 actually
> -- I don't really enjoy Common Lisp all that much) and Forth.
>
> The key to fun in that article, or at least one of them, seems to be the
> rapid feedback that one can get with some languages.


You got that right, again ;)
Imagine where we have come from, feeding Pascal Programs into a card
reader
and searching a printout the next day.
To changing a method in our Smalltalk GUI while the application is
running
(and the concept was born *before* I fed punch cards into a Cyber
mainframe
on university).

That is basically (pun intended) why I had lots of fun with Basic on the
Sharp1500 in the early 80s.
I could experiment with an iterative Quicksort implementing the stack of
local variables and return addresses myself. I thought in Pascal and
implemented in Basic that was about one of the most revealing
programming
experiences I ever had. BTW after the Quicksort program was finished
there
were 10 data cells left to be sorted LOL.

Ruby matches these feelings and I hope Smalltalk will too.

Certainly a Lisp or
> Scheme REPL environment or Forth's equivalent, the "outer interpreter"
> and "colon compiler", give that kind of rapid feedback. And Ruby has
> irb, although there isn't really an "IDE" with irb at the core, at least
> none that I'm aware of. In Forth, we used to call this process DATK --
> Design At The Keyboard.


Exactly what I meant above.

--
> 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.
>
>
> Cheers
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
Charles Oliver N. (Guest)
on 2007-01-04 13:48
(Received via mailing list)
Devin M. wrote:
> Charles Oliver N. 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? :)
Gregory B. (Guest)
on 2007-01-06 20:18
(Received via mailing list)
On 1/4/07, M. Edward (Ed) Borasky <removed_email_address@domain.invalid> wrote:

> Mathematica is definitely fun, but expensive fun. Axiom is as much fun
> and is open source. :)

Octave is fun and free too :)

My other vote would be for Brainf*ck... good masochistic fun.
Robert D. (Guest)
on 2007-01-06 20:30
(Received via mailing list)
On 1/4/07, Charles Oliver N. <removed_email_address@domain.invalid> wrote:
> > Sure, there are valid motivations for JRuby (duh), but does your
>
> <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.


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

--
> Charles Oliver N., JRuby Core Developer
> Blogging on Ruby and Java @ headius.blogspot.com
> Help spec out Ruby today! @ www.headius.com/rubyspec
> removed_email_address@domain.invalid -- removed_email_address@domain.invalid
>
>


--
"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
Jeremy T. (Guest)
on 2007-01-06 20:30
(Received via mailing list)
On 3-Jan-07, at 8:49 PM, Yukihiro M. wrote:

> before
> |there was Ruby?"
>
> BASIC was fun for me, when I was in junior high.  The point is that as
> I grow up, the problem domain I am in charge become far more complex
> than BASIC can handle.  That's why I need Ruby.

Smalltalk has always been fun for me (first environment I actually
played with extensively); but in the last couple of years, Io has
been a little more fun.
M. Edward (Ed) Borasky (Guest)
on 2007-01-06 20:30
(Received via mailing list)
Giles B. wrote:
> Basic was loads of fun for me, I learnt it when I was 10 or 11 on a
> TRS-80. I thought it was the coolest thing in the world.
>
> I'm playing with Smalltalk, it's fun.
>
Ah, but the TRS-80 had a built in cassette I/O and video interface --
you didn't need a clunky old (and large and expensive) ASR 33 to use it!
And wasn't BASIC in the ROM on a TRS-80? The first Altairs didn't have
any of that. And it wasn't much longer before there were floppy disks
and "operating systems".

Yeah, Smalltalk would be fun if I had learned it a couple of decades
ago. But I went down the Forth path then and the Ruby path now.
Smalltalk seems like a distraction now. I'm actually looking at Ada
again -- I just saw some info about Ada 2005 go by on another mailing
list. Can Ada be fun? *Should* Ada be fun? :)

--
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.
Wilson B. (Guest)
on 2007-01-06 20:30
(Received via mailing list)
On 1/4/07, Gregory B. <removed_email_address@domain.invalid> wrote:
> On 1/4/07, M. Edward (Ed) Borasky <removed_email_address@domain.invalid> wrote:
>
> > Mathematica is definitely fun, but expensive fun. Axiom is as much fun
> > and is open source. :)
>
> Octave is fun and free too :)
>
> My other vote would be for Brainf*ck... good masochistic fun.
>

Zed introduced me to this the other day, and it looks like a good time:
http://factorcode.org/
M. Edward (Ed) Borasky (Guest)
on 2007-01-06 20:30
(Received via mailing list)
Gregory B. wrote:
> On 1/4/07, M. Edward (Ed) Borasky <removed_email_address@domain.invalid> wrote:
>
>> Mathematica is definitely fun, but expensive fun. Axiom is as much fun
>> and is open source. :)
>
> Octave is fun and free too :)
Octave is sorta kinda a free Matlab clone. And R is sorta kinda a free
S-Plus clone.
>
> My other vote would be for Brainf*ck... good masochistic fun.
I wo*ldn't to*ch that with a 10 foot pole!

--
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 B. (Guest)
on 2007-01-19 17:30
(Received via mailing list)
On 1/4/07, M. Edward (Ed) Borasky <removed_email_address@domain.invalid> wrote:
> Gregory B. wrote:
> > On 1/4/07, M. Edward (Ed) Borasky <removed_email_address@domain.invalid> wrote:
> >
> >> Mathematica is definitely fun, but expensive fun. Axiom is as much fun
> >> and is open source. :)
> >
> > Octave is fun and free too :)
> Octave is sorta kinda a free Matlab clone. And R is sorta kinda a free
> S-Plus clone.

Octave is a pretty good clone of Matlab, too.  For at least my needs.
I had no trouble getting through a linear algebra course which
required matlab using it.
M. Edward (Ed) Borasky (Guest)
on 2007-01-19 17:31
(Received via mailing list)
Wilson B. wrote:
>
> Zed introduced me to this the other day, and it looks like a good time:
> http://factorcode.org/
>
>
Yeah ,,, I just ran into that the other day too, following some trail of
breadcrumbs on http://del.icio.us/znmeb concerning Forth. Zed has pretty
good taste in languages -- I hope that Factor doesn't distract him from
the wonderful Ruby work he's up to. :)

--
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.
This topic is locked and can not be replied to.