Comments on: If Smalltalk can Squeak, why can’t Ruby Rumble?

By: Raf

Raf — Wed, 05 Mar 2008 02:58:34 +0000

I think the difference between Ruby on Rails and Smalltalk is the same as between earning $50/h and being unemployed with joyful Seaside :).

Raf

By: Göran Krampe

Göran Krampe — Fri, 10 Aug 2007 09:48:04 +0000

Being a Squeaker take my words with a grain of salt - I haven’t used Ruby but follow it closely.

IMHO the clearly easiest path here is to actually move over to the Smalltalk world. I have yet to see the really clear advantages of Ruby over Smalltalk but can point out a whole bunch of things the other way around. And a lot of people have made this journey - for example Avi Bryant - the creator of Seaside.

Having said that - another possibility is to actually write a Ruby to Squeak bytecode compiler - in Squeak. Not sure if someone is doing this, I am aware of other interesting efforts in this grayzone - but not that particular one.

I know that the Ruby syntax/grammar is a complicated thing - but you would get TONS of stuff for free this way. Just a freaky idea.

By: Curt Hibbs

Curt Hibbs — Tue, 15 May 2007 18:36:52 +0000

I am one of the founders of the FreeRIDE project (that Ruby IDE “that noone uses”), and I can tell you that the speed of Ruby is not an issue. Performance is, in fact, fast enough to write an IDE — even an that has a completely decoupled internal architecture (http://freeride.rubyforge.org/wiki/wiki.pl?Databus)!

Back when Rich Kilmer and I started FreeRIDE (2001), there were no IDEs for Ruby. Now that are many commercial and open source choices, most of which surpass FreeRIDE in functionality (which never garnered enough developer interest to build an active community).

By: Antonio

Antonio — Tue, 15 May 2007 13:26:25 +0000

I personally heavily disliked the GUI-only nature of coding Smalltalk. While having workspaces and such is occasionally _nice_ — especially for debugging — the fact that I can’t just drop out and edit in vim or what have you was very very annoying to me. That said, I think there’s definitely room for a tool like that in the Ruby community. Definitely worth looking into.

Re: Matz not caring about speed — he’s always said he’s more of a language creator than a good implementor. There are several projects to speed up Ruby right now, including Yarv, Rubinius, JRuby, and IronRuby (though the latter two obviously have other goals, as well). People in the Ruby community hardly hate C (Hpricot, for example, has a C component, and it’s rather widely used), and while Rails abstracts away SQL, it still lets you use it directly when needed, and the developers have said more than once that you should when it becomes necessary. So we’ll label that `fud’.

Re: Ruby written in Ruby — have a look at Rubinius. The goal of the project is to get to exactly that.

By: Alan Lovejoy

Alan Lovejoy — Tue, 15 May 2007 05:47:32 +0000

If you want a Smalltalk workspace, the easiest way to get one is to use Smalltalk. “Do the simplest thing that could possibly work.”

By: Mark Miller

Mark Miller — Mon, 14 May 2007 23:35:22 +0000

I enjoyed your story. I’ve been in the process of relearning Smalltalk after a long absence from it. The temptation to learn Ruby and Rails has been there, but more from a financial perspective (a bit easier to find work with it). I dabbled in Ruby a bit last year. Since I found out about Seaside, I’ve been a bit reticent to learn RoR on technical grounds. I have this sneaking suspicion that I’ll use it for a while, get something out of it, but eventually discover that it’s “VB for the internet”, or something. It sounds like you’ve had that experience already.

A possibility for your “Rumble” environment would be to make the source code for Ruby objects/methods that are implemented as primitives (in C) browsable, but non-active. Meaning that the language in which everything is technically defined is Ruby, but some of the code would be immutable. This way at least everybody could see how everything is implemented in a consistent language. Conceptually, a C-to-Ruby translator would be a reliable way to accomplish this.

Or, if you want to go all the way, you could implement what Squeak has, which is complete source code in Smalltalk, down to the VM level (the kernel build process translates it to C, which is then compiled). Anyone for a version of Ruby written in Ruby?

By: Daniel Lyons

Daniel Lyons — Mon, 14 May 2007 19:18:44 +0000

I agree with you completely. I have basically two questions:

- Should it be graphical in nature, like Squeak, or essentially textual, like Emacs? I could make a strong argument either way.
- Do you have any time to work on such a project?
I would definitely throw my hat in the ring on such a project.

By: John Deere

John Deere — Mon, 14 May 2007 16:19:26 +0000

I think the problem is that Ruby is excruciatingly slow. There is supposed to be an ide written in it, but I think it is just so awful that noone uses it. Ruby has no problem strangling your CPU to the tune of 98% while simple scripts are running. You want to write and IDE which does all the introspection etc on the fly a la SmallTalk?

It would be possible, maybe if the Ruby crowd figures out this speed issue. I know a lot of people are going to get their panties in a bunch on this.. but the truth is, Ruby is just extremely slow. The denial machine only helps aggravate the problem, and the kind of crowd attracted to Ruby just doesn’t have the technical knowhow to put together something better than Matz’ interpreter.

Lua offers everything Ruby offers in terms of dynamic langugages and it is less than 500kb. So all this whining that Ruby is slow because it is just “so special” is just BS excuses from incompetent implementers.

Matz doesn’t give a shit anymore, Ruby community’s been taken over by Retards from PHP and inflammtory figures like DHH and his 12 disciples who think their feces don’t stink. This is a crowd which prides itself in not dealing with the “complexity of SQL”. They are mortal enemies of C and anything low level. They have disillusioned a lot of good developers away from the community and right now it is a bunch of gravy train riders enjoying the ride while it lasts.

How can you expect a decent and fast interpreter/compiler (a prerequisite for this “rumble” you speak of) to come out of this crowd?

not gonna happen.

By: Yoni Rabkin

Yoni Rabkin — Mon, 14 May 2007 07:24:46 +0000

I’ll be mind-numbingly stereotypical and say that the above sounds to
me like you want a Lisp-machine. Try seeing this video http://www.lemonodor.com/archives/misc-gems/lispm.mov.gz and have a look at this screenshot: http://upload.wikimedia.org/wikipedia/en/f/f6/Debugger.gif. I believe that these machines still represent the essence of your post. Take your idea; to have an application environment which is written in and for the language you use, and everything that language represents. Now take that idea to its logical extreme: the entire machine, through the keyboard, OS, environment and the hardware itself have been designed with/for/around the language; this is a Lisp machine. I think that by studying Lisp machines, you can see that your idea is not only correct, but it has been taken to its logical conclusion (no need to re-invent it). One more thing though that you did not mention. One very important point that people miss is that in order to have truely powerful introspection, you need to actually launch the application out of the same environment you develop. For example, you start a Lisp image in SBCL, connect to it with a tool like SLIME, disconnect and launch that very same image as the application. Then you can reconnect and change something in the live image or even stay connected permanently as the application lives. An environment which is designed to let you do that forces upon itself a discipline of transparency and introspection that the edit/make/run loop cannot support.