Article on ARTIMA

[Peter Hickman]

There is the start of a series of articles on ARTIMA with Matz.

www.artima.com

However they interleave (!) their interviews and publish one a week so you
will have to keep comming back. But that is not a bad thing, this is a very
good site even if you are not a Java programmer with many lenghty interviews
top language designers.

 

[Peter C. Verhage]

Yukihiro Matsumoto: "... But in fact we need to focus on humans, on how
humans care about doing programming or operating the application of the
machines. We are the masters. They are the slaves."

Bill Venners: For the time being anyway.

Yukihiro Matsumoto: For the time being anyway, until the age of Terminator.

LOL

 

[Ben Giddings]

Yukihiro Matsumoto: For the time being anyway, until the age of Terminator.

Heh. Isn't it great? Ruby is fun to write, and Matz is fun to read.

I guess one reason I like Ruby is because I agree with him on so many
points. Programming should be flexible and fun. You shouldn't think too
much about what the computer is doing under the hood. Doing something
simple should be simple. I also like that he's very honest that Ruby is
designed by him for him, and if it works well for other people that's
great, but it really is his language and if it doesn't act the way you
expect, want, or hope... well make your own language!

Ben

 

[Bob X]

From the talkback:

"Ruby is over 10 years old, very popular in Japan, gaining popularity in
other parts of the world, have thousands of users and hundreds of hackers.
However, the implementation (Ruby has only 1 currently, written in C) is
pretty weak. It's slow, does not support native threads, does not do JIT
compilation (not even bytecode), needs a better GC, etc. It is especially so
if we compare it with Java and Smalltalk, who have gotten real good
implementations (JIT compilers, fast GC, threads, etc) nowadays."

Comments?

 

[Phil Tomson]

From the talkback:

"Ruby is over 10 years old, very popular in Japan, gaining popularity in
other parts of the world, have thousands of users and hundreds of hackers.
However, the implementation (Ruby has only 1 currently, written in C) is
pretty weak. It's slow, does not support native threads, does not do JIT
compilation (not even bytecode), needs a better GC, etc. It is especially so
if we compare it with Java and Smalltalk, who have gotten real good
implementations (JIT compilers, fast GC, threads, etc) nowadays."

Comments?

I saw this comment as well. I think it's a valid concern. In the area of
performance Ruby is falling behind. Smallscript shows that you can have
high-performance dynamic language implementations.

Let's hope that Rite comes along soon...

Phil

 

[Sean O'Dell]

"Ruby is over 10 years old, very popular in Japan, gaining popularity in
other parts of the world, have thousands of users and hundreds of hackers.
However, the implementation (Ruby has only 1 currently, written in C) is
pretty weak. It's slow, does not support native threads, does not do JIT
compilation (not even bytecode), needs a better GC, etc. It is especially so
if we compare it with Java and Smalltalk, who have gotten real good
implementations (JIT compilers, fast GC, threads, etc) nowadays."

Let me also add that hand-grenades make terrible hammers. Discuss.

Sean O'Dell

 

[Kingsley]

Well I don't know if this comment is factually correct or whether it is just a
re-iteration of an anti-ruby chinese whisper.

But If David Garamond the author is right in what he says, then I would much
prefer people to aknowledge this and work to improve it, than retort with
over-exaggerated claims about how wrong he is.

Positive criticism should be welcomed, embraced and seen as an opportunity for
advancement.

Thats my thoughts anyway

Kingsley

 

[Ben Giddings]

From the talkback:

"Ruby is over 10 years old, very popular in Japan, gaining popularity in
other parts of the world, have thousands of users and hundreds of hackers.
However, the implementation (Ruby has only 1 currently, written in C) is
pretty weak. It's slow, does not support native threads, does not do JIT
compilation (not even bytecode), needs a better GC, etc. It is especially so
if we compare it with Java and Smalltalk, who have gotten real good
implementations (JIT compilers, fast GC, threads, etc) nowadays."

Comments?

Slow: yup, slower than Python, C, Assembly and most other things... not a
big issue for me most of the time, however.

Does not support native threads: not a major issue for me, but maybe for
some people it is.

Does not do JIT compilation or bytecode: nope... not a major issue for me

Needs a better GC: really? Not for me.

All in all, I think the criticisms are valid, but I don't care. The way I
use Ruby these problems haven't come up. It's like someone saying that my
swiss army knife doesn't have a saw. If I ever need a saw that will make
my swiss army knife less useful, but until I need one, it doesn't really
interest me.

I think the 10 years of development is a bit of a red herring though. I
don't know how intense the development has been over those 10 years, but it
is now at version 1.8, wheras Python is at 2.3 and Perl is at 5.8. For an
open-source type project where there is one main developer, no massive
funding, etc. it isn't surprising that certain tweaks (JIT, bytecode,
speed) haven't been added yet. I'd be curious to see how Ruby 1.8 fares
against Python 1.8 (if it existed) though.

I am curious though. Regarding Ruby the environment, rather than Ruby the
language, what is it that people would most want? Native threads?
Bytecode compilation? Speed increases? More memory-efficient GC?

Ben

 

[Thomas Sondergaard]

First, let me say that the original posting very clearly represents my
sentiments. Ruby the language rocks, the implementation... not so much.

Slow: yup, slower than Python, C, Assembly and most other things... not a
big issue for me most of the time, however.

Me neither, but without even thinking contientiously about it runtime
performance has influence on when I find ruby suitable for a project. If
ruby could be made a faster performer it would make more projects ruby
projects.

Does not support native threads: not a major issue for me, but maybe for
some people it is.

On Windows threading is *the* issue, if you ask me. It simply doesn't work.
It is incredibly counter-intuitive, as a thread model, that a *blocked*
thread prevents the other threads from running. Bizarre. Perfectly
comprehensible considering the implementation, but it just makes threading
on windows suck.

Does not do JIT compilation or bytecode: nope... not a major issue for me

Well who cares how it is implemented, you already addressed your lack of
concern for the runtime speed.

Needs a better GC: really? Not for me.

I was not aware of this problem either.

... I'd be curious to see how Ruby 1.8 fares
against Python 1.8 (if it existed) though.

You know that different projects assign version numbers differently. It is
way more fair to count the number of years a language has existed. In the
end it only matters to you what is a fair comparison because you (and I)
love ruby. To everyone else only one thing matters: what is best for them
now!

I am curious though. Regarding Ruby the environment, rather than Ruby the
language, what is it that people would most want? Native threads?
Bytecode compilation? Speed increases? More memory-efficient GC?

1) Native threads.
1.1) A thread safe interpreter.
2) Speed (somehow, don't care, bytecode, jit, whatever)

But then again, we can talk all we want, we are getting all this for free
and getting smarter for working with it, and I for one am very grateful for
all of it, even if there are a few blemishes on this particular ruby
(implementation).

Cheers,

Thomas

 

[Lothar Scholz]

Hello Bob,


BX> "Ruby is over 10 years old, very popular in Japan, gaining popularity in
BX> other parts of the world, have thousands of users and hundreds of hackers.
BX> However, the implementation (Ruby has only 1 currently, written in C) is
BX> pretty weak. It's slow, does not support native threads, does not do JIT
BX> compilation (not even bytecode), needs a better GC, etc. It is especially so
BX> if we compare it with Java and Smalltalk, who have gotten real good
BX> implementations (JIT compilers, fast GC, threads, etc) nowadays."

BX> Comments?

100% ACK. The poster described the technical problems of ruby very
well. And they are a reason for not choosing the language in some
projects.

I really don't like native threads programming at the low level that
most languages offer (introduced 30 years ago - mutexes, semaphores
etc). Eiffel and TCL have much better way separating
threads and using message passing as the only way for communication.
I wish someone would take a look at TCL how to implement it, but the
current C implementation of ruby is such a hack that it is impossible to
add something like this.

And another thing is very important and should really be done if ruby
wants to escape the hacker world:

A Formal description of the language (you know the "language lawyer"
section of the python documentation). JRuby and Ruby are not the same
in some details and this is the result of the lack of specification.

 

[Hal Fulton]

And another thing is very important and should really be done if ruby
wants to escape the hacker world:

A Formal description of the language (you know the "language lawyer"
section of the python documentation). JRuby and Ruby are not the same
in some details and this is the result of the lack of specification.

This interests me. David Alan Black and I have discussed it more
than once.

But I'm not sure Matz likes the idea of a formal language spec. Or
perhaps he would say the spec already exists, and it is written
in C.

Matz? What would you think of a formal spec as long as 1) the content
was OK'd by you and 2) you didn't have to write it?

Hal

 

[Yukihiro Matsumoto]

Hi,

In message "Re: Article on ARTIMA"

|Matz? What would you think of a formal spec as long as 1) the content
|was OK'd by you and 2) you didn't have to write it?

Definitely it's good to have, unless it slows down the language
evolution.

matz.

 

[Rasputin]

"Ruby is over 10 years old, very popular in Japan, gaining popularity in
other parts of the world, have thousands of users and hundreds of hackers.
However, the implementation (Ruby has only 1 currently, written in C) is
pretty weak. It's slow, does not support native threads, does not do JIT
compilation (not even bytecode), needs a better GC, etc. It is especially so
if we compare it with Java and Smalltalk, who have gotten real good
implementations (JIT compilers, fast GC, threads, etc) nowadays."

Comments?

None of those interest me personally, except perhaps the GC
issue - can't say I've seen that and last month I had 2 AI
tic-tac-toe players going head to head on a 425x425 board, and didn't
have problems. Each Square was an instance of a 'Square' class, and I was
running a testsuite against it so there were plenty of setup/teardown
calls to exercise GC

I wouldn't try to argue about performance because it's good enough
for me. I suspect most people wouldn't have a problem either.
Unfortunately it seems to be one of those pissing contest issues
like a PCs Mhz value....

For me the main concern about a language is how easy it is to write and
maintain programs in it, and Ruby kicks seven shades out of any other
language I've used for that.

(C/Java/Perl/shell/PHP/FORTRAN/V**ual B**ic).

 

[Jim Freeze]

Hi,

In message "Re: Article on ARTIMA"

|Matz? What would you think of a formal spec as long as 1) the content
|was OK'd by you and 2) you didn't have to write it?

Definitely it's good to have, unless it slows down the language
evolution.

matz.

A formal spec is be good for the rest of us, and eventually
it will speed development because more people will have
access to understanding the internals of the language.

But, a formal spec will slow progress down initially (however,
it may also clear up muddy thinking). And it will need
to be under constant revision (albeit hopefully minor).

 

[Kingsley]

One of the reasons I love Ruby is because of how I feel when I code in it. I
feel happy.

I wasn't a programmer and still don't think of myself as a programmer as I
have been a tester for a long time, but in trying to learn various different
languages like C or Java I found it pretty hard going and never managed to
stick it out for long.

I think this is mainly due to the language syntax - I never really could
understand it fully and there seemed to be words I had to type which didn't
seem to make sense to me. Ruby seemed to remove all this mystery with its
intuitive and easy to understand syntax.

Being a Martial Arts student for over 20 years now - I liken it to Bruce Lee's
assessment of classical Martial arts - he focused on stripping away all the
unnecessary and redundant structures and worked on improving the simplest way
to achieve the goal. He believed in evolution and that anything that remains
static and unchanging would soon wither.

I found some things in Life are designed to fit the individual - becoming a
taylor made solution, like Wing Chun - one of the blocks works becuase you
hold your arm in the correct position for your body - some styles make
everyone hold their arm in the same position - no wonder they don't work as
fluidly and effectively considering all the different shapes and sizes of
people out there.

I find Ruby to be one of those things in life that feels like its designed to
fit the individual - I'm not straining to understand all the time, instead it
all feels natural and unrestricted. So there's a lot to be said for Matz
concentration on this side of the language. Intuitive design is extremely
important. I feel Ruby fits my personality and character very well - becoming
an extension of myself almost, rather than an external tool. In fact I might
even go so far as to say I can find self-expression in my Ruby Code. (I don't
know if this is unusual for a programmer to feel?)

As for Ruby's apparent 'issues' mentioned above well I can see how they might
hold back the explosion of Ruby into a commercial / enterprise arena. But
seeing as I'd rather not code in anything else, I'd love Ruby to go in that
direction. So If these issues are being addressed thats more strings to the
bow.

Where I work there are a couple of people who I feel sure also love Ruby -
people such as Martin Fowler and Dan North. Now If I could just give them
something more to justify using Ruby in future projects then maybe our
company would consider it. Which would make me very happy.

Anyway - I seemed to have typed more than I anticipated

as Hal Fulton so aptly named his book 'The Ruby Way', I am now beginning to
understand the 'Ruby Way'.

Where in programming I once struggled with interdiction, In Ruby I find
accessibility, and where I once stumbled in the jungle of Syntax, In Ruby I
step lightly, frreely and above all happily.

Kingsley

 

[Lothar Scholz]

Hello Joe,


JC> Putting aside the fact that on Windows there are some really pathological
JC> threading issues... does the fact that Ruby doesn't support "native threads"
JC> means Ruby will not take advantage of multiple processors (and
JC> pseudo-multiprocessors, like Intel's HyperThreading)? I don't know much

Yes thats right !
One of the reasons why it is not the best language for larger server
applications where at least dual processors are very common. Of couse
you can use multiple processes, but then you will see much harder IPC
and caching problems if you don't use one fat central database server.

JC> about the microprocessor industry but from what little I know, it seems like
JC> at least some of the big companies are looking to multiple cores and other
JC> parallelism at the thread level for their future chips.

That's right and it's the right way. But i think the NUMA architecture
will win (long term future). With NUMA (Non unified memory
architecture) you don't have a shared memory anymore - so the ruby way
is not so bad.

 

[Simon Kitching]

JC> Putting aside the fact that on Windows there are some really pathological
JC> threading issues... does the fact that Ruby doesn't support "native threads"
JC> means Ruby will not take advantage of multiple processors (and
JC> pseudo-multiprocessors, like Intel's HyperThreading)? I don't know much

Yes thats right !

Yes, it is. If an application implements threading at the "user-space"
level, then the kernel sees the app as one thread, and therefore cannot
distribute processing over multiple physical processors.

One of the reasons why it is not the best language for larger server
applications where at least dual processors are very common. Of couse
you can use multiple processes, but then you will see much harder IPC
and caching problems if you don't use one fat central database server.

JC> about the microprocessor industry but from what little I know, it seems like
JC> at least some of the big companies are looking to multiple cores and other
JC> parallelism at the thread level for their future chips.

Yep, I'd agree with this too. With the proviso, of course, that the vast
majority of programs are not multi-threaded internally, and therefore
don't run any faster on multi-cpu systems no matter what.

That's right and it's the right way. But i think the NUMA architecture
will win (long term future). With NUMA (Non unified memory
architecture) you don't have a shared memory anymore - so the ruby way
is not so bad.

Numa does have shared memory; it's just that memory "local" to the CPU
is faster to access than memory "local" to some other CPU. I do think
NUMA is going to win on very big servers, but is unlikely to come to a
desktop system - though I'm not an expert here.



Have you heard of the "Parrot" project? A team of developers are
building an open-source high-performance virtual machine for
"interpreted" languages. Their initial target is Perl6, but the
expicitly want to support other languages including Python and Ruby.

From the FAQ:

"Ideally, Parrot can be used to support other dynamic, bytecode-compiled
languages such as Python, Ruby and Tcl."

There are some really smart people working on this one, and the project
is coming along nicely it seems.

Re parrot, see:
* http://www.parrotcode.org/
* http://dev.perl.org/perl6/
* http://www.sidhe.org/~dan/blog/archives/000151.html


I presume Parrot supports kernel-level multithreading, though I guess
some of the Ruby libraries would need work on threadsafety to run
correctly in kernel-threading-mode...

There was a project called "Cardinal" to implement Ruby on Parrot.
It appears to be defunct though (so appropriate for us Monty Python fans
. Or maybe just dormant until Parrot is more advanced...

Re Ruby on Parrot, see:
* http://www.rubyxml.com/parrot/parrot_notes.html
* http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/76623
* http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/76552
* http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/29980
* http://www.rubygarden.org/ruby?CardinalProject


Does anyone here know any more on the status of ruby-for-parrot
projects?


Cheers,

Simon

 

[Lothar Scholz]

Hello Simon,

Friday, October 3, 2003, 2:42:54 AM, you wrote:

SK> Have you heard of the "Parrot" project? A team of developers are
SK> building an open-source high-performance virtual machine for
SK> "interpreted" languages. Their initial target is Perl6, but the
SK> expicitly want to support other languages including Python and Ruby.

Yes i heard about it, isn't it the VM machine for the GNU-Hurd shell,
released next year.

SCNR.