Browsing Ruby Code a La Smalltalk

Browsing Ruby code a la Smalltalk?

There really isn't one, at least not with a Smalltalk-like UI including static and dynamic behaviors.

Eclipse and IntelliJ both have some structural insight. Eclipse has a view sort-of similar to a browser. The biggest issue with either is that unless you're working on live objects (e.g., debugging) you won't necessarily know all of an object's behavior since some is defined at runtime. A static view without an image or partial runtime cannot give a complete picture.

IntelliJ does a decent job of figuring things out. For example, a class with an attr_accessor :foo will show the @foo instance variable in the structure pane. I'm not sure you can configure the UI around to be more browser-like, though; Eclipse is better in this regard–each "level" can be added separately.

^{(Since 1994-95ish I've felt we kept taking steps backwards, it's only recently that IDEs have gotten smart enough to give me back some of the productivity I had with Smalltalk/Lisp. Smalltalk's image-based runtime confers a lot of advantages in this regard.)}

Would you start learning Smalltalk?

If you like Ruby you'll probably like Smalltalk. IIRC Seaside has been ported to the Gemstone VM, which is part of their Gemstone/S OODBMS. This has much better thread support than Ruby, so it is a better back-end for a high-volume system. This might be a good reason to take a close look at it.

Reasons to learn Smalltalk:

• It's a really, really nice programming environment. Once you've got your head around it (it tends to be a bit of a culture shock for people used to C++ or Java) you'll find it to be a really good environment to work in. Even a really crappy smalltalk like the Old Digitalk ones I used is a remarkably pleasant system to use. Many of the old XP and O-O guru types like Kent Beck and Martin Fowler cut their teeth on Smalltalk back in the day and can occasionally be heard yearning for the good old days in public (Thanks to Frank Shearer for the citation, +1) - Agile development originated on this platform.

• It's one of the most productive development platforms in history.

• Several mature implementations exist and there's a surprisingly large code base out there. At one point it got quite trendy in financial market circles where developer productivity and time-to-market is quite a big deal. Up until the mid 1990s it was more or less the only game in town (With the possible exception of LISP) if you wanted a commercially supported high-level language that was suitable for application development.

• Deployment is easy - just drop the image file in the appropriate directory.

• Not really a reason, but the Gang of Four Book uses Smalltalk for quite a few of their examples.

Reasons not to learn Smalltalk:

• It's something of a niche market. You may have trouble finding work. However if you are producing some sort of .com application where you own the servers this might not be an issue.

• It's viewed as a legacy system by many. There is relatively little new development on the platform (although Seaside seems to be driving a bit of a renaissance).

• It tends not to play nicely with traditional source control systems (at least as of the early-mid 90's when I used it). This may or may not still be the case.

• It is somewhat insular and likes to play by itself. Python or Ruby are built for integration from the ground up and tend to be more promiscuous and thus easier to integrate with 3rd party software. However, various other more mainstream systems suffer from this type of insularity to a greater or lesser degree and that doesn't seem to impede their usage much.

Multi-Line Comments in Ruby?

#!/usr/bin/env ruby

=begin
Every body mentioned this way
to have multiline comments.

The =begin and =end must be at the beginning of the line or
it will be a syntax error.
=end

puts "Hello world!"

<<-DOC
Also, you could create a docstring.
which...
DOC

puts "Hello world!"

"..is kinda ugly and creates
a String instance, but I know one guy
with a Smalltalk background, who
does this."

puts "Hello world!"

##
# most
# people
# do
# this

__END__

But all forgot there is another option.
Only at the end of a file, of course.

• This is how it looks (via screenshot) - otherwise it's hard to interpret how the above comments will look. Click to Zoom-in:

smalltalk error handling

To raise an exception:

MyException signal.
MyException signal: 'With an error message'.

To handle an exception:

[ 1 / 0 ] on: ZeroDivide do: [ Transcript showln: 'Oops! Zero divide!'].

To handle an exception and use some of the exception's information:

[ 1 / 0 ] on: Error do:
    [:e | Transcript showln: 'Oops! ' , e className , '!'].

To ensure something always happens (a la try finally):

[ 1 / 0 ] ensure: [ Transcript showln: 'This will always run' ]

Sproutcore or Cappuccino for Ruby-on-rails?

When looking at MVC frameworks at work, we considered SproutCore and Cappuccino. They both draw an enormous amount of inspiration from Apple's Cocoa framework and Objective C.

We chose to use SproutCore because:

• It leverages JavaScript in a manner that is aligned with Douglas Crockford's view of JavaScript as described in JavaScript: the Good Parts.
• Good MVC framework that produces fast applications.
• Good community backing the project. Charles Jolley, SproutCore's daddy, worked at Apple until recently, and now is working full time on SproutCore. Apple contributes a lot of code to SproutCore's base, and is making good use out of it, as evidenced by the fact that iWork.com was build using SproutCore.
• SproutCore was designed for very heavy applications that have thousands of elements, using optimized techniques like recycling list items in large lists à la Google Wave or Google Maps.

We didn't choose Cappuccino because:

• It creates a different language in which you run your application in. This is non-intuitive, makes you think in Objective J, which does provide benefits in the fact that you don't bring nasty JavaScript hacky habits, but neglects the fact that JavaScript is beautiful, extensible, and powerful. (I am in no way 'slamming' Objective J, just providing insight to the fact that you run JavaScript in the browser, not Objective J. If you do run another language in your browser, it can get confusing since you're interpreting an interpreted language using an interpreted language.)
• However, Objective J and Cappuccino make beautiful applications and leverage Objective C's language architecture, which is a good model to look at in the world of MVC.

(Keep in mind, I don't have a great deal of experience in Cappuccino and Objective J, so if I make broad and naïve claims, tell me!)

You need to look more at what you want as a frontend framework rather than what "works best" with Rails. Both frameworks are good. We chose SproutCore because it fit our needs that we had for our application more, and fit our ideology.

From experience from wading through SproutCore's source, I can say that it's fairly independent of the server implementation that you're using. We use Prosody, a BOSH server written in Lua. You want to use Rails. SproutCore offers this out of the box:

• DataSources for Rails deploys. FYI- DataStores are SproutCore's low-end model layer for hooking into web services. This is most likely the meeting point between your SproutCore app and your Rails app. SproutCore is not really meant to run in Rails, but you certainly could do it!
• DataStore for RESTful Rails services. Or any REST API for that matter. It also allows for server-side push, if you have a need for that.

As for your DRY requirement- that's all up to you! You can leverage the framework to make your code independent and DRY, or have tight dependencies and repeat. Either framework is good, it just depends on your needs. Don't be nervous- dive in and get to know the communities and what's going on in each of them! We don't bite... too much.

---

Related Topics