From: Michael Lucas-Smith Date: 2001-06-16T09:23:23+09:00 Subject: [ruby-talk:16516] Re: Smalltalk vs. Ruby --------------080703000008020808050907 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit > > 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 --------------080703000008020808050907 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
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


--------------080703000008020808050907--