Schrade.Blog

I'm somewhat taken aback by all of the negative reaction to Gemstone being a closed source product in the wake of the Maglev announcement.

Look at this:

Do you really think that the people that own this ship care about paying for software?

I doubt it, but they probably care about things like development speed. And software reliability. And the ability to get someone on the phone immediately if something goes wrong with the software.

That's the world the Gemstone comes from. I would bet that if the software running the shipping platform for this company falls over, it would lose more money over the course of a few hours then it would cost them to license Gemstone for an entire year.

Here's another example where JP Morgan has a system built on top of Gemstone that they can not afford to shut down or migrate to another language because it would cost them too much money.

How is being exposed to the toolset that powers things like that going to be a bad thing?

Sure, it's closed source, but if enough people use it and benefit from it then the community will just do what we always do:

Some of us will pay for it, some of will find clever ways to subvert the license, and the rest of us will get to work on building an open source clone of it.

That's what always happens, and when it does happen some people will continue buying the closed source supported version (Oracle) and others will move to the free version (MySql).

What makes anyone think that something different is going to happen here?

I'm not at Railsconf this year, but before he left I asked my coworker Krishna to beg for, borrow, or steal a copy of the Maglev alpha code and bring it back to the office. Unfortunately, it looks like that's not going to happen (in an email he says "They don't have anything to share at the moment"), damn it.

Still, as Obie says, this is a huge deal. Even without the stated performance improvements that they're already seeing (I'm hearing 5x to 100x in microbenchmarks vs the MRI), it would still be a huge deal, because this might be our best chance ever to move people to a real object database. And not just any object database, but one of the best object databases out there.

Once you use it, you won't ever want to go back.

As far as I'm concerned though, the bigger news about this is that the Maglev VM "does retain the ability to run Smalltalk code." As long time readers of this blog know, I'm a big fan of Smalltalk and the Seaside framework, and being able to start a project in Rails and then use the same data to build a Seaside app will knock down another huge barrier as far as getting people to try Seaside goes, (see my my post from a year and a half ago about sneaking Smalltalk in through the Ruby backdoor).

In my experience, Seaside makes writing web applications faster and easier than even Rails does.

Paul Graham is well known for saying that their secret weapon while developing Viaweb was Lisp, because it let them develop software faster than any of their competitors.

Ruby + Smalltalk + Gemstone is your secret nuclear weapon.

Not only will it let you develop software faster than any of your competitors, it will also let you scale that software in an easier manner than ever before.

It seems like every time I post something bad about a programming language, or compare one language (A) to another (B), at least one commenter lets me know that they like language B better, and furthermore, some aspect of my post has convinced them that language A is so bad that they won't even try it anymore.

The thing is, I don't care.

I'm not a consultant anymore. I'm not trying to sell you anything (unless you need drug discovery software). I'm no longer actively involved in open source community. If you don't want to ever try Ruby (or Smalltalk, or Python, or whatever) it really doesn't matter to me.

When I point out something about a language, I'm just doing it because I genuinely think that it is better than something else.

So how do I really feel about languages?

Well, over the last couple of months I've written code in Ruby, Smalltalk, Javascript, Python (if you haven't read Programming Collective Intelligence you should), Java, and even PHP (SearchMonkey is seriously cool, if you haven't checked it out).

So what language do I think that you should program in?

All of the above, and as many more as possible.

Learn about functional programming. And iterator methods. And closures And continuations.

Even more importantly (from my selfish point of view), learn about things that other programming languages can do that I don't know about.

Then hopefully someday we'll be able to have a discussion about programming languages without resorting to pointless statements like "I still prefer braces over keywords for blocks" and instead we'll get comments that we can all learn something from.

Whenever I get I get tired of dealing with all of the disconnected layers of Rails, I think about how I should really write a decent component architecture that works well on top of it. Luckily, someone has already done it for me.

From the Cells homepage:

Cells brings the benefits of component-oriented development to the Ruby on Rails web application platform, without the performance problems that had been associated with Rails' own, deprecated, component subsystem.

Each Cell is like a little lightweight controller (with associated views) that you can embed anywhere in your app. I've been playing with it tonight, and while it's not on the level of say, Seaside, it seems like a fairly good baseline for building a more component oriented system for your apps.

I know from a mailing list that I'm on that some people are kicking around taking this and building a stateful component framework with real object binding underneath. That would really take Ruby web frameworks to the next level. (And be a ton of work to get right, I'm sure. :-) )

Hopefully that project will get started soon. I'm extremely interested in watching and helping it develop.

Seaside, my other favorite framework, released version 2.8 today. This release has been optimized and optimized some more, as it doubles the average page rendering speed, and now uses up to 4 times less memory. Plus it supports Gemstone, which is the feature that I'm most excited about playing with.

The official release page is here, and if you still haven't tried Squeak, a great new tutorial can be found here.

Congrats to the entire Squeak team on this one.

(Seriously though, who does a release on a Sunday? You guys are nuts.)

Seaside does not have a marketing problem!

Everyone I know in this business knows about Seaside and its super productive powers. We've all seen the demos and the screencasts and the awesomeness that is DabbleDB. For god's sake, Avi gave a keynote at RailsConf this year.

I think it's safe to say that people know about Seaside.

The problem at this point isn't a marketing one. It's the same problem that Squeak has always had. Namely that when you download Squeak and start it up, you're presented with this:

When most programmers I know see this, they have the same reaction, "What the fuck?"

This is usually followed quickly by the question of, "Can I edit this using Vi or Emacs?"

Let me answer this now. No and No.

If you're the type of person that can't imagine giving up writing code at the command line, then Squeak isn't for you. (Although there are Vi and Emacs keybindings.)

And that's usually the end of it. People play with Squeak for a few minutes and then go back to doing their real work in Ruby or Python or Java or C#. A lot of the power and magic of using Seaside is directly derived from the power and magic of using Smalltalk, which unfortunately (or fortunately, depending on your point of view) means that you're going to have to learn Smalltalk if you want to use it .

And Smalltalk is, at least in the case of Squeak, a whole different world. You have to unlearn a lot of what you know in order to use it. Editing is different, class creation is different, version control is different. Basically everything you know as a programmer gets thrown out the window.

But you know what? At some point, once you do that and really start to immerse yourself in Smalltalk, you'll suddenly realize that it's hard to go back to the old way of doing things.

You'll realize how much easier it is to just ask the system what method you should use to get something done instead of going to a PDF document somewhere to look it up. (Yes, in Squeak you can just type "'class'. 3. 'cla'" into the the method finder and tells you that "contractTo" and "truncateTo" are the two messages in the system that give you that result.)

You'll suddenly come to the realization that this is simply better.

That this is how things are supposed to work.

Unfortunately for most of us at this point, we'll have to go back to our real jobs, (I asked Avi after his keynote how many people in the world are actually making money using Seaside and he said that he figures about 20) but even if you get this far you'll learn enough to to have a whole new outlook on how coding should work.

It's not a marketing problem, it's the the same old problem that people are scared of things that are different then what they're used to. Hopefully someday we will be able to overcome this fear, and then Seaside and Smalltalk will finally take over the world. But for now this new outlook on development will have to be good enough.

Said during an informal discussion with Avi Bryant after his keynote:

When I look at DHH's code, it makes me want to scream.

The guilty party (not Avi or myself, obviously) shall remain nameless.

If Ruby is a step up from Java in productivity and power, and Smalltalk is a step up from Ruby, then we should all feel a little ashamed when we read the following from The Early History of Smalltalk by Alan Kay:

In January 1976, I took the whole group to Pajaro Dunes for a three day offsite to bring up the issues and try to reset the compass. It was called "Let's Burn Our Disk Packs." There were no shouting matches, the group liked (I would go so far to say: loved) each other too much for that. But we were troubled. I used the old aphorism that "no biological organism can live in its own waste products" to please for a really fresh start: a hw-sw system very different from the ALTO and Smalltalk, One thing we all did agree on was that the current Smalltalk's power did not match our various levels of aspiration. I thought we needed something different, as I did not see how OOP by itself was going to solve our end-user problems. Others, particularly some of the grad students, really wanted a better Smalltalk that was faster and could be used for bigger problems. I think Dan felt that a better Smalltalk could be the vehicle for the different system I wanted, but could not describe clearly.

I know that they went on to implement Smalltalk-76 as the follow-up to this, and that what we use today is a closer ancestor to that then the Smalltalk-72 that he is discussing here, but it was really just anther evolution. How is it that we haven't had a revolutionary advance in programming languages in the 30 years since then?

I don't have a solution, but I think that all too often we forget that there's even a problem to be solved.