If Smalltalk can Squeak, why can’t Ruby Rumble?
Amongst all my dabbling with Ruby, I have taken some time to compare the Ruby on Rails MVC stuff with the original Smalltalk implementation found in the Squeak VM. Now, I’m really not familiar enough with the Squeak MVC stuff to comment, but I did stumble across this well-though-out blog post entitled, “My Full-Circle Journey Back to Smalltalk“. In this post, the author (Ken Treis) tells the story of his experimentation with the many languages of web development and (as the title implies) his eventual return to the world of Smalltalk. He goes on to identify eights places where he feels that Ruby missed the boat. While all of these are really interesting points for consideration and discussion, the sixth point talks about how, in terms of live interaction, nothing beats Smalltalk workspaces.
Beyond the shadow of a doubt, I agree with that. I learned early-on with Python that it’s nice to have an interactive interpreter, but irb doesn’t provide anything near the features of workspaces. With a workspace, you can highlight any code fragment, snippet or statement and have it evaluated. Also, because the entire environment is Smalltalk-powered the code can meaningfully interact with anything and everything. Want details on a given object? Pop up a menu and the “inspect” option pulls up an object inspection window that lets you take a direct peek at the object’s internals. Need a different perspective? A browser offers an ideal way to take a more structured look at the environment and it’s contents (notice the similarity to RDoc generated documentation). Workspaces even integrate with the Refactoring Browser to help clean up your code!
In fact, I can’t think of any editing environment that offers the same level of flexibility as workspaces save for one editor: Emacs. Now, before I get flamed, I am a pretty big Emacs fan. Except for when I’m hacking with KDevelop, it’s really my default editor. That being said, I want to make a point by drawing a parallel: While the base of Emacs is written in C, eveything about the editing environment is written in Emacs Lisp. As a result Emacs is the best editor for Lisp and Lisp-like languages. The similarity I’m trying to point out is that the best development environments are those which are expressly aware of the language being developed within them. The easiest and best way to achieve such integration is to implement the environment in the language itself (i.e. Squeak in Smalltalk and Emacs in Lisp).
I imagine a new development environment, which I will refer to as “Rumble”. Rumble should be written entirely in Ruby and it should borrow the best elements in both design and features from Smalltalk workspaces. I imagine that the Rumble environment provide both the educational and exploratory opportunities that exist within the Squeak world. This way, just like extensions to Emacs are written in elisp, extensions and improvements to Rumble could be written in Ruby. If we had such a development environment, I feel that it would add tremendously to the appeal of Ruby as it makes it an even more compelling platform. Who’s with me?
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.
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.
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.
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?
If you want a Smalltalk workspace, the easiest way to get one is to use Smalltalk. “Do the simplest thing that could possibly work.”
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.
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).
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.
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