[ruby-talk:16516] Re: Smalltalk vs. Ruby

>
> What does Ruby offer that Smalltalk does not?
>
 From what I've seen of Ruby so far, it is lacking in many areas covered 
in several interviews by the top Ruby Developers. BUT.. Ruby has a much 
more modern approach to development and a more modern class model. 
Smalltalk is a fantastic language, but because it's libraries haven't 
progressed over the past 15 odd years, it has become locked in it's own 
little world. It has tremendous power - A Smalltalk project can achieve 
more than any other like project in less time. Proven statistics. The 
reasons for this? .. non-type strictness - Ruby has that. Being able to 
abitrarily pass blocks of code around - Ruby sort of has this. The 
ability to write what you mean, not convert what you mean in your head 
to a language construct that looks vaguely similar - Ruby *can* have 
this, but it appears to me that some people are scared of this. The 
incredible Array/Collection protocols - Ruby has most of this.. select, 
reject, collect, detect and their varients. With being able to pass 
blocks around willinilly, you end up being able to write better 
black-box code. For example.

self connect: someLocation do: [:connection | ....]

The whole process of connecting, disconnecting, interpreting 
someLocation, etc.. that's all stuff that has nothing to do with the 
code you're now writing. In fact, you don't even have to know what kind 
of connection it is if you are given a connection that responds normal 
streaming protocol It could be a net connection, a file, a string.. who 
cares? in Ruby it looks like:

connect(someLocation) {| connection | ...}

Actually I might just take a moment to bring up one of my previous 
points again. Syntax!
Kent Beck showed me a very interesting phenominum in one of his books. 
It's called the rectangle.

self connect: someLocation do:
    [:connection |
    ....
    ...
    ....]

instead of the more C-like structure

self connect: someLocation do: [
    :connection |
    ...
    ...
    ...]

which leaves an onimous [ hanging out in the middle of no where. Ever 
since me and my collegues at work saw this [...] visually, we have 
adopted it. It makes things easier on the eyes. I really wish Ruby would 
let me start my blocks on the next line.

More Ruby things? .. Name spacing. Namespacing in Ruby is virtually 
always behind the scenes. You never have to think about it.. it 
constantly protects individual segments of code running - thus you can 
have many things running in the one Ruby VM without fear of an internal 
melt-down. Many Smalltalk's vaguely do Namespacing. VisualAge Smalltalk 
does it in the most lamest way. This is a key advantage I think.. One of 
the traps of Smalltalk is that everything is in your image. This is a 
blessing in disguise. It means more rapid development, because you can 
instantly query what it is you're about to write and who gets what and 
what's really going to happen in your final product. With interactive 
visual debuggers (like in VisualAge ST) you find yourself running your 
application up to a point, stopping it with a break point (a break point 
doesn't modify your code at all - can be put any where, with a piece of 
code on it to be the condition to stop, with iterations etc) and 
starting to write more code from there. Why do it that way? because at 
the point you want to write more of your code, you can see what objects 
are near you, what classes are near you, and more easily what it is you 
need to write to get the job done. After you've written your bit of 
code, you can simply start stepping through your new code, seeing each 
line as it executes to make sure it's doing the right thing. You can 
rollback to different points in the stack really easily and begin again 
from the middle of your program with no cost. These are the key 
advantages to it. You can get your information faster than greping - You 
really need to have seen VisualAge Smalltalk with VisualAge Assist to 
understand the truthfulness of this. BUT.. having your development image 
and your testing image in the one image is a nightmare. When things 
start to go wrong, you can screw up everything. In many cases we end up 
with scripts to clean up instances of things that should have been 
garbage collected but for some reason or another haven't. Various bits 
of 'state' end up laying around and your 'sequence' or 'loading order' 
for applications/classes is completely lost until it comes time to build 
a stand alone production image.
Ruby on the other hand, at the moment, without the whole single image 
development environment, forces you to make your dependencies right 
first time, as you write your code. If you need something, you require 
it on the spot. This means, your 'loading order' is always correct from 
the get-go. I suppose this would be true in a Ruby development 
environment too. But it's an area that can definately be improved upon 
in Smalltalk. I personally think when testing your code, it should be as 
seperate from your development environment as possible - but still 
interlinked so that you can have live debugging, shared knowledge 
between the runtime and dev images - dRuby will be great for this.

This leads my brain on to ANOTHER point. Source code in files. Now I'm 
getting a bit blasphemous here.. because the Unix/Linux .. heck, most of 
the world revolves around having source code in files. *I* personally 
believe that this is a mistake and has been made out of convenience. If 
you had a truely interactive development environment, it would be 
possible to write code that required no 'parameters' in () or after :'s 
like in Ruby and ST and every other language. You could write some code 
like:
/connect to/ someLocation /then do/ { this code } /then disconnect

connect to _ then do _ then disconnect/  is the method you have just 
sent. someLocation and {} are the parameters. Why can't we do this now? 
because to do something like that requires prompts from a smart 
development environment to make sure you're writing what you really 
mean. Did you mean connect to somelocation _then_ or did you mean 
connect to _someLocation_ then ...  only an environment that can quickly 
and smartly query the system could help you write code that looks like a 
sentence. Only a graphical environment can let you choose which parts of 
the sentence are the parameters without requiring some fudged language 
syntax like (z,x,y) and a: z b: x c: y. The only way to store this 
information is in a format that isn't language writing friendly.. be it 
some binary format (the real format it'll be executed as?) or some xml 
schema doesn't matter.. it's the user interface that makes the 
programming experience fun.. files hold that back simple because 
developers are.. well - scared. It's a chicken and egg thing.. to make 
such a flexible language you need the tools to do it, to make the tools 
do to it you can't have such a flexible language. *shrug*

That's my rant for today.. it's a bit longer than I expected.
Michael Lucas-Smith