Testing out WebVelocity. There are some quirks and bugs to work through yet, but overall it’s been a pleasant experience. As always the development team is helpful and quick to respond.
I’ve found the #smalltalk at irc.parcplace.net to be the best source of quick help. James Robertson, Michael Lucas-Smith, and others tend to hang out there quite a bit.
So, what does WebVelocity add? Well, it incorporates Glorp for one — Cincom Smalltalk’s answer to Rails’ ActiveRecord. So, you get ‘free’ persistence, Smalltalk-idiomatic customizable queries, etc.
You can develop your entire application, tests and all, right in the web browser. You can even run your tests from there.
More later… maybe even screenshots (I have to check my agreement with Cincom first).
Comments Off
MagLev is a Ruby VM in the works by Gemstone that is targeted for a first release around September of 2008. I am really excited about this development. The VM will hook up to the caches and persistent store that Gemstone provides.
Avi Bryant gave a nice demo of 100 days of work on the VM. It does simple things in the typical Gemstone distributed fashion. Talking with some Gemstone folks afterward, I found out that in 100 days they have implemented about 20% or 30% of the Core library. In the MagLev talk they mentioned that they are effectively (and impressively) running about 38 of the rubyspecs defined by the Rubinius team.
Great stuff.
Comments Off
I am both a Rubyist & a Smalltalker. I enjoy both environments immensely and use them for different purposes. In a recent flurry of posts, James Robertson over at Cincom completely misunderstood the point Neal Ford was making about the meta-programming facilities Ruby offers versus the facilities Smalltalk offers, or better yet the facilities that either tend to use.
Avi Bryant chimed in and cleared the picture up a bit, but I wanted to simplify it even further for those who are still in the dark. Mind you, I do mean simplify.
The issue as I see it is the ability and/or desire to add methods to an instance of an object, rather to its class definition. (I know that you can probably do this in Smalltalk, but I don’t know how.) The beauty of meta-programming this way is that we can add a ton of very useful boiler-plate code to an object without cluttering its definition, and the implementation of the new method isn’t reflective (thus adding performance penalties).
In a language like Ruby this is key, where the tools are less than capable, and we are still dealing with “source code in files, how quaint” (Kent Beck). In Smalltalk it doesn’t matter so much that the code is generated into the class definition, because we don’t browse code in Smalltalk the way we might in Ruby.
Of course there are other arguments about why meta-programming this way is good or bad, but I think this is the main point of the discussion at hand.
Someone feel free to correct me if I have been too simplistic.
Rails vs. Seaside
I have started my first app in Rails at work. Though I find it’s ease of database access really appealing, I am not convinced that I find it a better suit than Seaside. There is something about programming everything in Smalltalk that is so much more appealing than figuring out “OK, what can this view see now? What does this partial know about? What does that controller have its fingers into?”
It’s killing me trying to find out the context in which everything lives. In Smalltalk I know what the context is… I can evaluate things, I can set breakpoints (OK, self halt), I can send messages to known classes — not just some digital ether.
Until next time…
[September 08, 2007]
I have since created a dozen or so Rails apps, and I gotta say I really like it. All but one are essentially quick and dirty views on databases (slicing and dicing in different ways). I prefer to use Seaside for heftier applications, but those don’t come along as frequently and it’s harder to get approval for them. Rails really answers a niche array of needs. It’s great at what it does!
Comments Off
