Posts Tagged ‘smalltalk’

Delphi and JBuilder as role models for Rails development?

Thursday, September 20th, 2007

Chatting over a beer with Ola Bini last year, we discussed the possibilities for JRuby. My dream was to run a Ruby IDE on top of JRuby to get a Smalltalk like environment, because Smalltalk is still the best programming environment I have ever used.

Now that 3rdRail, running on JRuby, is released, should I get my hopes up? Some people are actually very excited about it, but when Delphi and JBuilder are referred to as some sort of pinnacle of development it seriously makes me wonder.

Where is IBM in Rails?

Thursday, September 20th, 2007

I have absolutely no clue as to why David Heinemeier Hanson would hold any suspicious thoughts toward Sun. To me, given the big boys in the playground, they are the good guys. But reading it made me realize that I have not heard of IBM in a very, very long time.

Big Blue was quite quick to join the Java bandwagon, remember VisualAge for Java? But in the new world of dynamic languages IBM, apart from a few developerWorks articles, is not to be heard from.

And this from a company who once was a strong proponent of Smalltalk? In my mind, if there is a mystery man, he and his cat is sitting in an IBM campus somewhere.

Kent Beck on Ruby

Wednesday, August 9th, 2006
Kent Beck on Ruby: “
I always knew one day Smalltalk would replace Java. I just didn’t know it would be called Ruby.
– Kent Beck

Blaine Buxton links to this quote at ozmmdotorg.”

(Via Mike Bowler’s thoughts.)

Data, encapsulation etc.

Thursday, November 28th, 2002

We're right now trying out Prevayler as a persistence layer for our products. It is basically the coolest think I've seen since I became an OO-afficionado. I did start out with Smalltalk, and it sort of set the tone for what I believe in.

I need to check out if Jon has mentioned this on his blog. Nope, he hasn't so I'll be first then.

Here we go: What Prevayler basically does is store your object graph in memory, recording every transaction as a serialized Command. Every 24 hrs a snapshot of the full object graph is written to disk and the log is cleared. Crash recovery is performed by taking the latest snapshot and redo all the commands that is deserialized from the log.

This basically means complete transparency, wow-whiz-bang performance, database independance and a call to your local RAM-dealer for more memory. It is also very reliable, the full package is something like ten classes, meaning very few dark corners for bugs to hide. We've tried it in development and yes, it rocks. I could dance the funky AOP-chicken here and tell you how fast it was done since we only removed the OJB interceptor and added a Prevayler interceptor, but I won't. Seriously, sure, that rocks too, but haven't we sort of agreed on that by now?

So what's the backside? Schema evolution. I'll save that for a separate post.