David Pollak's Blog - Ruby

In defense of DHH & the Rails comminity

nospam@example.com (David Pollak) — Wed, 29 Apr 2009 06:16:06 -0700

No, my machine was not hacked. Yes, I do believe that DHH and the Rails community has done far more to advance web development than the Apache Software Foundation. I radically disagree with J Aaron Farr's post comparing the two.

First, I am a fan of DHH. I think he's a wicked smart person and that Rails as a piece of software and as a catalyst for web development is a milestone. DHH built Rails and created the Rails community. He's done a masterful job. He's also become more of a statesman over the years. With that being said, I'm not a huge fan of the Rails community or its culture.

I'm a user of a lot of Apache Software Foundation stuff. It's solid. It's maintained. With the possible exception of Wicket, none of it is groundbreaking. In fact, some of it is poorly designed crap. I'm an Apache commiter (perhaps not for long) on the ESME project. I have seen very little of the meritocracy that Aaron blogs about.

It's not easy being green running a ground-breaking project

I've run my share of groundbreaking software projects in my life. It's really not an easy task. Having vision, managing employees/committers, building community, and satisfying users all takes a bit of attitude that pisses people off. Let's look at what DHH did with Rails:

He blew away most of the other web frameworks by demonstrating that web development could be concise and that web apps could be built to be visually pleasing and easy to use without a ton of developer time. That, IMHO, puts him in diety territory.
He built an ecosystem around Rails that had enough critical mass to spawn a whole industry around Rails development.
And the 37 Signals apps don't suck.

But doing all that requires making choices. DHH made a series of choices about style, community building, etc. Some people think he's a jerk... but the same can be said about Steve Jobs, Bill Gates, Halsey Minor and other folks who fundamentally changed the game (yeah, I'm lumping DHH in league with those guys.) In my opinion, DHH is not a one trick pony (Folks who built the future). He's got direction, attitude, energy, charisma, and the other stuff that it takes to change the game, and he'd done just that.

And in the other corner, weighing 98 pounds...

Now, let's look at the ASF. It's a nice place to house a project. There are lots of reports to write. In fact, I believe more time is spent on the ESME project writing monthly reports than writing code. The ASF has done nothing to help the ESME folks build community or inspire folks to join the project. There's been little in the way of technical guidance. Sure there's brand and visibility in having an ASF project, but there's no meritocracy. There's nothing that I've seen in the ASF that rewards anything other than being nice and writing reports and having statistics get better. Sure, if I'm Yahoo! and I want to open source Hadoop and pay my developers to work on it, Apache is a nice neutral place to house it. CouchDB is high on the doesn't suck scale, but I gotta say, Damien Katz is the personality behind it (no, he's not as acerbic as DHH) and without him, CouchDB would not be (violating the ASF guidelines, but I guess they needed a flashy project).

Further, let's look at the ASF crap pile. Well, there's the HTTP server... so bogged down in commityism that Nginx blows it away. Struts... the ultimate piece of crap web framework. ActiveMQ... junk compared to RabbitMQ. Tomcat, consistently behind Jetty (a personality driven show.) There's no real merit that I can see across the board in Apache's offerings. Put another way, if the ASF were a meritocracy, they'd dump the crap that's in their top-level projects.

Yes, I think that the Rails community could be a nicer place to be. I've tried to build the Lift community so that it's a warmer and more welcoming place to be than the Rails community. But I am sure glad Lift is not part of the ASF. I tip my hat to DHH and what he's built.

Party and (likely) flame on.

Advocacy vs. Attack

nospam@example.com (David Pollak) — Fri, 13 Apr 2007 10:02:54 -0700

I read What's wrong with Ruby yesterday, including many of the "comments." Putting aside the substance of the article, the tone of the responses really bugged me. There were plenty of ad hominem attacks and very little discussion about the substance of the posting.

A while back, I got cranky about some Ruby guy suggesting that Java folk who use static typing as a tool must be stupid. Someone asked me about my view of advocacy... well here goes...

FIrst, I believe that open, sometimes heated, debate about topics is the best way to improve a "thing."

Second, I've been around Internet flame-wars since 1990 (this was before Web 1.0, this was before the Web.) I've done my share of flaming and been flamed a whole bunch of times.

Here's my "formula" for debating (yes, you'll find a bunch of places where I haven't followed my formula, but each time I don't I regret it):

The goal is optimal outcome, not getting the other people to blindly agree with your original position.
It is very helpful to spend more time listening than speaking.
There is a difference between "facts" (the things that can be objectively measured or the things that nobody is debating), "hypotheses" (something that can be proven true or false by obtaining facts and applying logic), "personal experiences" and "personal opinions." For example, it is my personal opinion that has derived from my personal experiences that statically typed languages are better than dynamically typed languages. For me, this is true, but it is clearly not a "fact" because people are debating it madly and it's not even a hypothesis because the debate has been raging for long enough and enough people have tried to define tests to measure which is "better" and, as far as I know, there's no hypothesis that has been tested that proves things one way or another.
Look for the implicit statements within the explicit statements. For example, "Rails is better than any Java-based framework for building web sites." The "truth" of a statement like this depends on a number of "implicit" parts of the statement. For example, "where security is not a top priority", "where your team size is less than 8", "where it's a green-field project", and "where your data model is closely tied to the presentation layer." When I hear a statement, I try to figure out what the implicit parts of the statement are. In a discussion, it's a powerful tool to say, "okay, I agree with your statement with the following conditions, but let's explore what happens outside these conditions." It helps focus the discussion.
With the above tools, you can talk about the implicit statements, figure out what the hypotheses are and figure out what facts you need to obtain to prove or disprove the hypothesis, and figure out the things that are just personal opinions. For things that are personal opinions, you can share your experiences about why you've formed those opinions.
Respect the classics. Classics are things that have withstood the test of time. That is not to say they are the best that will ever be. That is not to say that they are the best of when they were created (e.g., Windows). But it is to say that there's value in the momentum and investment that have made them classics. Perhaps Shakespeare invented every plot device ever used in any piece of Western fiction, but we still write and view new plays. We still study Shakespeare. Shakespeare gave a platform to grow from (and he stood on a platform built by others.)
Finally, and perhaps most importantly, the ad hominem attack may feel good, but it will change the debate away from the original to a debate about people. Those debates rarely do any good. In fact, learning from other peoples' experiences can make you a richer person. The researchers are the guys thinking about things in a way that computing "could be." But for guys like Alan Kay and John McCarthy, we wouldn't have the foundations of computing that have led to C++, Java, Ruby, Python, etc. We also need "practical guys" like Larry Wall and DHH who make things accessible. We need both.

So, advocate away. Make things better. But please, respect what others have to say. If they disagree with you and you cannot resolve the disagreements, may it's just a personal preference.

Some more Rails to lift code examples

nospam@example.com (David Pollak) — Sat, 07 Apr 2007 15:14:08 -0700

I have been porting a Rails application to the lift web framework.

In this installment, I show an example of a Rails controller method and the converted lift snippet method. Thus I discuss the lift and Scala idioms

Also, for those folks who have claimed I'm a "Java guy" and "don't get Rails." I'd like to differ with you. I've written 7 commercial Rails applications and have been doing Rails work since 2005. While I'm not the best Rails coder on the planet, I'm pretty proficient with Rails and with Ruby. For those folks who are branding lift as a Rails clone, I differ with you as well. I am borrowing the best of Rails, but I view TurboGears and Seaside as the true "thought drivers" for lift. I am using a Rails app that I'm converting to lift because the commercial app that I'm involved in building was written in Rails and we decided to move away from Rails because Rails could not scale to suit our needs (read my prior post where I outline why Rails cannot scale to meet our needs.)

In my ongoing discussion of porting a Rails app to lift, I figured I'd show some Rails code and what it became in lift. These two code snippets perform the same function: a "new account invitation is emailed to a user. The user clicks on a link contained in the email. The user enters their first name, last name, enters a new password (twice). This controller code (or snippet code in lift as controllers are longer lived) performs the validation and updates the model.

The LoC for Rails and lift is nearly identical. The lift code pushes the password validation into the model (where it should and can be reused.) The Rails code does not include the "implicit" lines of code for rendering the view, where the lift code includes the view rendering code (see the "bind" function that binds XML in the view to form fields.) A discussion of the code differences follows the code block:

# allow a new user to accept an invitation from an existing user via

# the email link sent in the invitation email.

def accept_invitation

# the url from the email should have the token to find the user who was invited

if request.get?

@token = params[:token]

user = User.find_by_last_token(@token)

flash[:error] = "Token not found" and redirect_to '/home/error' and return if user.nil? || user.token_expiry == nil || user.token_expiry < Time.now

session[:user_id] = user.id

end

if request.post?

pw1 = params[:new_pw].strip

pw2 = params[:new_pw2].strip

firstname = params[:firstname].strip

lastname = params[:lastname].strip

flash[:error] = "Passwords do not match" and return if pw1 != pw2

flash[:error] = "Password too short" and return if pw1.length < 6

u = User.find(session[:user_id])

u.firstname = firstname

u.lastname = lastname

u.friendly_name = firstname+" "+lastname

u.password= pw1

u.token_expiry = nil

u.default_address.save

u.save

# Send a welcome email

email = NotificationsMailer.create_welcome_email(u)

email.set_content_type('text/html')

NotificationsMailer.deliver(email)

logger.debug("Invitation accepted and welcome email delivered.")

flash[:notice] = "Invitation accepted succesfully, we have sent a welcome email to you."

redirect_to '/user/download'

end

// the "accept invitation" snippet

def accept(xhtml: Group): NodeSeq = {

// find the user associated with the foken

val user = (for (val token <- param("token");

val user <- User.find(By(User.lastToken, token));

!logged_in_? && (user.tokenExpiry.get ne null) &&

user.tokenExpiry.getTime > millis) yield user) getOrElse

{error("Token not found") ; redirectTo("/") }

val invokedAs = S.invokedAs

// this function tests acceptance of the invitation

def innerAccept(xhtml: NodeSeq): NodeSeq = {

// check the password and if all is well, save the user

def checkPassword(i: List[String]) = {

// set the password

user.password ::= i

val issues = user.validate

// if there are no issues, set the friendly name, destroy the token, log the user in and send them to the home page

if (issues.isEmpty) {

user.friendlyName := user.firstname+" "+user.lastname

user.tokenExpiry := null

user.save

user.sendWelcomeEmail

logUserIn(user)

notice("Invitation accepted succesfully, we have sent a welcome email to you.")

redirectTo("/user/download")

}

mapSnippet(invokedAs, innerAccept)

// whoops... we have issues, display them to the user and continue loading this page

error(issues)

true

}

// bind the parameters to the xhtml that was passed to us

bind("cs", xhtml,'email -> user.email.get, 'fn_input -> text(user.firstname := _, Val(user.firstname)),

'ln_input -> text(user.lastname := _, Val(user.lastname)),

'pw_input -> passwordL(checkPassword))

}

// call the innerAccept method with the XHTML that was passed to us

innerAccept(xhtml)

}

The first thing I will call attention to is the "bind" call. lift takes the approach that the "view" should contain only valid XHTML code. It should not contain program code. lift loads the requested view in response to an HTTP request (rather than invoking a controller.) The view contains a list of the controllers and snippets necessary to render the view. These are designated by <lift:snippet> and <lift:controller> tags. The tags may contain XML/XHTML elements that are passed to the snippet/controller as rendering instructions. Snippets and Controllers take the XML and return a rendering of new XHTML.

What is the difference between a "snippet" and a "controller"? lift implements controllers in the Smalltalk "real" MVC "controller" way. Controllers are long-lived. They exist as long as any page that references them lives. Controllers can push changes to a page and if a browser is currently viewing the page, the change will be pushed out to the browser. This allows "chat" controllers, clock controllers, shopping cart controllers (so the shopping cart is updated, even if an item was placed in the cart by another browser tab, or, conceivably, if two people are on different computers, they can share a shopping cart.) Controllers are based on Scala Actors. Each controller consumes about 200 bytes plus whatever state the controller keeps around (let's say 2K of state per Controller for a shopping cart.) This means that 10,000 active controllers would consume about 20MB of RAM, or about 1/2 of the RAM used by a single Rails instance. Put another way, keeping state in memory scales.

Scala Actors do not have to be in the same address space in order to share messages. The "shared shopping cart" controller could be hosted on one machine while the web servers servicing the sessions of the folks who are sharing the shopping carts could be on different machines. There's no difference for the controller.

Snippets are a lot more like Rails controllers. They are low-state (not quite state-free as we'll see in a minute) objects that are instantiated to service a single request and after that, they are discarded.

The view invokes the snippet in the following way:
<lift:snippet type="user_mgt:accept" form="POST">

Dear <cs:email /> choose a password to create an account and be able to use CircleShare.

<table>

    <tr><td>First Name:</td><td><cs:fn_input/></td></tr>

    <tr><td>Last Name:</td><td><cs:ln_input /></td></tr>

    <tr><td>Email Address:</td><td><cs:email /></td></tr>

    <tr><td>Password:</td><td><cs:pw_input /></td></tr>

    <tr><td>Re-type Password:</td><td><cs:pw_input /></td></tr>

    <tr><td>&nbsp;</td><td><input type="submit" value="Accept Invitation" /></td></tr>

</table>

</lift:snippet>

lift instantiates a "UserMgt" object and calls the "accept" method. The accept method locates and validates the user and then "binds" the appropriate values and actions to the XHTML:
bind("cs", xhtml,'email -> user.email.get, 'fn_input -> text(user.firstname := _, Val(user.firstname)),

'ln_input -> text(user.lastname := _, Val(user.lastname)),

'pw_input -> passwordL(checkPassword))

The first parameter in "bind" is the XML tag prefix that we are binding to. By convention, I'm binding to "cs" because this is the CircleShare application. The second parameter is the XHTML passed from the view. The <cs:xxx/> tags are the ones that lift will bind to. The balance of the parameters are the names and values. The names are the tags to bind to (e.g., "email" will bind to <cs:email />). If you pass in a string, it will be XML escaped. You can pass in an XML element, including UnparsedData. The ‘fn_input -> text(user.firstname := \_, Val(user.firstname)) is very interesting. It binds <cs:fn_input /> to a text input field with a value set the the current first name value for the user. The "user.firstname := \_" bit of code is actually a closure that is called when the form is submitted. When the form is submitted, user.firstname is set to the value that was input in this form element.

I'll repeat that because it's a very important concept. When the form is submitted, a function (it's an anonymous function) is called and that function sets the first name of the user. "What user?" you may ask. Because it's a closure, the user is the instance of user that was created by the "User.find" method when the link was first processed. There's no separation between the creation of the form and the action that is executed when the form is submitted. It gets cooler, though... because you could write ‘fn_input -> user.firstname.toForm and the field would automatically generate an appropriate form input with appropriate callback. No worries about keeping the setters in the controller in sync with the fields in the view.

But wait, there's more... you can even say "user.toForm" and a whole form with all the modifiable fields will be generated. And it's all secure. No concerns about "mass assignment" or tampering with fields that are not explicitly listed in the form.

So, "bind" binds the XHTML to form fields, etc. If there's a <cs:xxx /> that does not have a matching bind, lift inserts an error message with a "FIXME" in it. Your tests can search for FIXME in the returned page and that indicates a failure.

We've got our fields bound. What happens when the user presses "submit"? lift processes the form fields in the order that they appear in the bind statement. The last field processed is "password". There are two copies of this field on the page. This will result in a List of 2 responses. The code assigns the list to the password field. The code within the password field validates that the two passwords are the same and are of a minimum length. The code asks the user object to validate itself. If it's valid, the code saves the user, logs the user in, and redirects the browser to the download page.

However, if validation fails (the passwords are incorrect, the first or last names are too short, etc.), the messages are displayed to the user and view is allowed to be processed. There's on bit of "magic": mapSnippet(invokedAs, innerAccept). This code says, "when the view asks for whatever this snippet was called when it was first invoked, don't create a new instance, but instead call the ‘innerAccept' function because it's a closure that's already bound the the user that was found when the link was first clicked." This means that we don't have to temporarily log the user in (as we did in the Rails code.) We don't have to put a marker in the session that says, "the user we're currently validating is xxx", and we don't have to put a hidden field in the form with the user ID or the token. Put another way, we're using the built in facilities of Scala to deal with managing state rather than an "HTTP/HTML" "Web Programing" way of dealing with state. This leads to more secure code and it leads to fewer defects.

I hope this gives you a sense of where I'm taking lift. If you've done Seaside work, a lot of this will be "Well, Duh!"

I look forward to feedback, comments, and questions.

Thanks,

David

Ruby, how you've changed in a year

nospam@example.com (David Pollak) — Thu, 25 Jan 2007 08:45:06 -0800

It was a year ago that I went to the SD Forum Silicon Valley Ruby Conference. I listened with awe to Chad Fowler talking about language patterns, Ruby's evolution, both as a language and as a series of idioms. The energy in the room was warm, welcoming, and felt like a bunch of people who had found a good path and were looking to improve the language, the environment, and make Ruby the best language and the best environment for folks to hang out in. Chad talked a lot about the Ruby way. It wasn't a religion with zealots. It was a bunch of folks taking a journey to make things better for themselves and others. Cool! Sign Me Up!!

Things have changed a lot in a year.

A few days ago, a Rubyista made a blog post (intentionally not linked to) calling Java programmers stupid. The post seems to argue that anyone who needs (or likes) static typing is stupid.

Back in the day, when programmers had to free memory and then this Java thing burst onto the scene there were flames across net news about how stupid and lazy users of managed memory were and that managing your own memory was the one true way. These folks had not seen the beauty of Lisp and Smalltalk. There were benchmarks, etc. Turns out that, for kernel development and some very, very close to the metal high performance tasks, developer managed memory is better. For all other tasks, let the machine do the work.

Ruby is not the end-all. It's got a lot of very nice features, paradigms and idioms. There are also warts (green threads, instability, on average for my projects, 100x slower than Java, and lack of a security model.) Folks can view these warts as "areas for improvement" or as "bashing from someone who doesn't understand the one true way."

For the record, I've been doing Rails development for 18 months. I have 8 Rails projects deployed (6 of them commercial.) 70% of my coding is in Ruby and Rails and it's split between Ruby command-line apps and Rails web apps. I have given a dozen presentations on Ruby and Rails, mainly to help educate Java developers about a different approach that was (past tense intentional), IMHO, a better way to do web development. I have been doing Java for 11 years. I was one of the first users of WebLogic and saw J2EE evolve. I have written popular commercial applications in weakly typed, statically typed, and dynamically typed languages over my 29 year professional career. I was (and no longer am after Matz said that he is not going to listen to enterprise users @ RubyConf) a proponent of adding type checking to Ruby. I have seen the benefits of both language level type checking and totally dynamic typing.

I prefer static typing and languages like Scala and Haskell get it much more right than Java and C++ do. This is my personal preference and I understand why other people have other preferences. Of the languages I've spent time in, I think Smalltalk does dynamic typing best. Because methods and variables can't be mistaken, the common mistake of mis-typing a variable or method name can be caught at method save time (if there is no method with a given name implemented by any object in the Smalltalk system, you get a confirmation dialog.) I'm pretty sure that my preferences don't make me stupid. I don't think folks who prefer Ruby's brand of typing are stupid. I think they've found a groove that works for them.

So, where is all this leading? Dunno. What I do know is that Ruby has changed from being a 'way' into being a dogma in 12 short months. That's really sad. Sigh.

PS -- There was an original post based on the assumption that Pat was a member of the core Rails team. I was dead, absolutely, massively wrong about this. I have pulled anything from this post that reflects negatively on Rails or the Rails team because of the post. I wanted to preserve a paragraph, however... here it is:

Rails is amazing in that it took a very good approach to simplifying the common things that web developers do. There are other systems out there that do a similarly good job (e.g., TurboGears), but Rails popularized the concept of "programmer first" web development. Rails is kind of like the iPod of web development tools: what it does, it does well and in a very approachable manner.

The longest journey starts with the first step

nospam@example.com (David Pollak) — Fri, 24 Nov 2006 13:38:03 -0800

I am wicked impressed with Charles Nutter and the JRuby team. They take things step by step and improve performance and compatibility incrementally. A few days ago, they broke the native Ruby performance barrier.

These guys rock!

The Tail & The Dog

nospam@example.com (David Pollak) — Wed, 25 Oct 2006 12:10:26 -0700

I apologize for the other factual errors and spelling errors in the blog post. I stand corrected on the green vs. giant lock issue in YARV. However, (and correct me if I'm wrong about this as well) the performance improvements and degree of parallelization that YARV brings is marginal (< 40%) compared to the existing 1.8 implementation. If I am mistaken about this please correct me.

What I stand by is that Rails defines Ruby. Let me expound on this statement. First, I'd like to say, the people I met at RubyConf and in the Ruby community as a whole are wicked smart and wicked passionate folks. They care and believe and make things happen. Being at RubyConf and putting faces to posts was a very excellent experience for me.

Second, folks have done some amazing things with Ruby sans Rails. About 50% of my coding is Ruby on its own. Ruby is amazing in that it doesn't require much overhead if you're just writing a 10 line script. On the other hand, it has most of the object "something" of C++ and Java and Smalltalk. Ruby also has nice pieces like Mixins.

Third, Ruby is excellent for gluing disparate system pieces together, like Perl. Except that unlike Perl, Ruby code is maintainable by the original author *and* other folks.

So far, I've described a "better Perl." A language that does all the stuff that people do with Perl, except that the code is easier, more fun, and more satisfying to write and maintain.

Something happened to Ruby to change its trajectory from taking a percent or two of mind and programmer share from Perl and Python each year to being one of the hottest, most recognizable names in technology. That something is Rails.

The number of attendees at RubyConf has grown from 30ish to > 300 since 2001. How much of that growth has happened in the last 2 years since Rails came onto the scene? How many of the people at RubyConf are doing > 50% of their coding on Rails projects?

Rails has changed web development in a very positive way. Rails makes it much easier and faster (and more fun) to develop web sites. Rails is a very exciting tool because it allows small to medium sized teams to develop a class of web app very quickly.

It is the benefits that Rails bring to the party that is raising people's awareness of Ruby. Rails is raising corporate/enterprise awareness of Ruby.

A marketing guy I work with from time to time (he did the PR that launched Yahoo!, the iMac, VeriSign, etc.) has a basic tenet: "In order to get the majority of people to change the way they do something, there has to be a 10x benefit." Rails delivers that 10x.

By all measures that I can find, the increased visibility of Ruby and the increased interest in Ruby is primarily driven by the benefits that Rails brings to the party. If there is someone out there that has statistics that indicates that something else is primarily responsible for the exponential growth in Ruby's popularity, please let me know.

Rails is bringing people to the Ruby party. And (okay, I don't have any statistics for this) most of the newer Ruby folks are doing Rails primarily. They are coming and staying for Rails. Yes, they learn the benefits of Ruby and that helps with deployment, log analysis, etc., but the primary driver is Rails.

These people are consultants who can do fixed price bidding on web sites, underprice the competition, and still have fat margins.

These people are in companies who need to find a way to do more with their budgets.

These are companies like VeriSign that fund stuff like Mongrel in order to learn about new technologies that could improve their bottom line.

These are the drivers of Rails and, because Rails runs on Ruby, the drivers of Ruby adoption.

As a percentage of all deployed Ruby apps, I would bet a lot of money that Rails apps are > 50% and growing.

Rails brings people to Ruby. Rails apps are a substantial percentage of Ruby apps. Managers and clients and people who are writing ever increasingly large checks for Rails-savvy consultants care about Rails. Yeah, it sucks. Yeah, it's not fair. Yeah, those darn suits ruin all the good things. But, it's what's happening. People are coming to Ruby & Rails increasingly for money rather than aesthetics. They're coming because of what Rails delivers (cost savings, more web site for less money.)

As much as I believe that Ruby and Rails are different things... as much as I believe that Ruby is a thing of beauty... I understand that cash drives things. Rails is the cash-cow. Rails is the dominant force bringing people to Ruby and keeping people in Ruby.

That's why I believe Rails is the dog that wags the Ruby tail.

Rails and Seaside -- Two new, great web frameworks

nospam@example.com (David Pollak) — Sun, 20 Aug 2006 12:00:00 -0700

I've been casting about recently, looking for a good set of tools for building applications... mainly applications with a web interface.

I've looked at a lot of environments. Ruby/Rails and Smalltalk/Seaside offer a lot of cool, compelling features.

Java has been my language of choice for 9+ years (since early 1996.) With the help of Dani Pletter, I wrote a framework of domain specific languages that sat on top of the JVM for building web applications (SmartMode.) The syntax for SmartMode was XML with embedded Java. SmartMode compiled the domain specific languages to byte-code at run-time and shoveled them into the JVM so that one could make a change to a SmartMode managed file and the change would be reflected on the next browser refresh. The only time the web container needs to be reloaded or restarted is when changes were made to the Database Schema (this is due to Java's strong typing.) Dani and I were able to write applications about 10 times faster with SmartMode than with other Java tools (we built SmartMode in 2000-2001, at the time Struts was in its infancy and there were very few good OR mapping tools.)

SmartMode included DSLs for Object-Relational-XML Mapping (it generated Java classes that knew how to persist themselves, call stored procedures, and update the database schema and stored procedures automatically [kind of like migrations.]), Web site navigation including access control, multi-page, multi-object Object-HTML-Object mapping (it included state management, support for multiple forms in multiple browser windows, field level validation, etc. much like ActiveRecord validation mixed with a sub-set of Seaside's state management) and a Collection->HTML Table generator (this tool was much maligned, but the more times I have to iterate over objects to create HTML tables, the more I miss it.)

After 5 years, it was clear that SmartMode was long in the tooth. We never managed to open source it, although we've been trying for almost 2 years. That kind of made me start looking for a new environment to program in. It would have taken a lot of effort to retool SmartMode for AJAX and quite frankly, the world doesn't need another Java framework.

I looked at Spring for about 5 minutes. It's a bloated pig. I know it's slimmed down versus other Java frameworks, but if I have to write an XML file and 3 Java files just to get "Hello World!" it's a bloated pig. And while Spring is all about Inversion of Control, it doesn't feel like any well done IoC app I've ever seen.

A side-note... the all-around best development environment I ever used was NextStep. NextStep (now Mac OS X) is built on Objective-C. ObjC is a series of SmallTalk style object extensions to the C language. It's dynamically typed like SmallTalk. There is much message passing. The GUI and application framework that sits on top of ObjC is a beautiful message based framework that allows for the creation of GUI and other applications in very short order. To give an example, I wrote the GUI for Mesa (http://www.plsys.co.uk/mesa.htm) in about 4 or 5 weeks. When I went to write Mesa 2 (http://sundialsystems.com/mesa/index.html) it took me over 4 months to replicate a subset of Mesa's functionality using C++ and OS/2's Presentation Manager. ObjC/OS X and SmallTalk are all about Inversion of Control and most responses to UI messages are 6 or 7 lines of code rather than the bloat that's required for a statically typed system that is requires that the developer handle the plumbing of a UI or Web request.

In November, I started looking at Ruby/Rails. My first impression was that it was very SmartMode-like. The first thing Rails did was create the framework of an application for you. You started filling in blanks. Rails has a built-in web server, so with very little configuration, you can see the results of your application in your browser. The flash-to-bang time for Rails is amazingly short. ActiveRecord (Rails' Object-Relational mapping layer) does most of the basic CRUD (Create, Read, Update, Delete) stuff that you need to do with a database very easily. ActiveRecord has marginal, but allegedly improving, support for complex OR mapping tasks. Between Rails and Open Source Web Design (oswd.org) one can build a simple web site very very quickly.

Ruby as a language is an amalgam of Perl, SmallTalk, Lisp, and a few other languages. As a Java developer, I was able to pick up Ruby in 30 seconds (okay, my propensity for picking up new languages is quite good, but still, compared to OCaml, Ruby was a walk in the park.) It figure the average Java developer should be writing reasonable Ruby code in a week. If the developer had Visual Basic experience, it'll take less time.

As a dynamically typed language, Ruby gets almost everything right at the syntactic level. It's really beautiful to read and write. It's very expressive and, with the exception of some of the meta-programming constructs, most of Ruby makes sense to any Java, C, C++, etc. programmer.

So... I was totally loving Ruby. Until I started to push the language and the runtime.

The Ruby interpreter (there is no Virtual Machine although there are many alleged to be in development) is dog slow. The best performance I've seen, Ruby is 7 times slower than Java (this is for a short process, including JVM start-up time that spent most other the Ruby time doing RegEx.) Most hard-core Ruby tasks take 50-100 times more time than Java and in the case of some hard-core outliers, Java is 1,000 times faster than Ruby.

The Ruby runtime is not stable. I've crashed it repeatedly doing floating point math.

Ruby strings are based on 8 bit characters. While there are a variety of UTF-8 libraries for Ruby, basic methods like 'length' return the number of bytes, not characters, in a string. This is especially surprising given that Ruby was developed in Japan.

The current version of Ruby is 1.8.4. Ruby has been at 1.8 since 2000. Version 2.0 will not be available for at least 18 months. This is a very long cycle, but is due to the fact that Matz seems to be the only one writing most of Ruby's core interpreter and libraries.

There's no viable Ruby debugger. In order to debug a Ruby app, you've gotta use printfs. I kid you not.

Finally, the Ruby interpreter runs on Green Threads, so it can't make use of more than 1 CPU on the new wave of SMP machines. This is due in large part to the underlying IO structure and the way Ruby talks to C programs. It would break many of the existing C libraries if Ruby moved to a native threads model.

For the standard fast_cgi deployment of Rails applications, very few of the above issues have a material impact and the programmer productivity gain of Rails versus Spring/J2EE (about 10x) justifies buying marginally more hardware to run more Rails processes (note that most of the time servicing web requests is spent in the database so the Ruby slowness issue translates to a 1.5-2x increase in the amount of CPU needed to service the Ruby process vs. a similar Java application.)

Rails is amazing, but has its issues as well. It is almost entirely defined around the concept that a web page request translates into a database query/update and the resultant display. This is true in the simple case. However, Rails doesn't have much of a security model, either at the page access level or at the database level. Thus, each page must be protected either with code in the controller or with some third party "engine." The existing user management engines are binary in the way the protect pages: users that are logged in can see everything and all other users can only see the "public" pages. Objects pulled from the database must each be checked to see if they belong to the user that is accessing them. There are scant mechanisms to filter objects in a way that users can only see what they own. Further, the Rails methodology of including database primary keys as part of the URL perpetuates the issue because it's very easy to change the ID in the URL and see data that belongs to others.

Rails has the notion that all state with the exception of the ID of the user for the current session should be kept in the database or passed as part of a web request. This means that making multi-step processes (e.g., checking out of a store, managing a shopping cart) is very difficult and prone to failure. It also means that there is a lot of database traffic for each page load. It also also means that COMET style (http://en.wikipedia.org/wiki/Comet_%28programming%29) web app development is very, very difficult. On the other hand, scaling Rails deployments is brain-dead simple and if one of the fast_cgi processes dies, no state is lost... the user just needs to hit reload.

Rails also has a bunch of security vulnerabilities. The recent 1.1.4-1.1.5-1.1.6 3 day upgrade-o-rama fixed the ability for an attacker to execute arbitrary code on your server if they knew where the code was relative to the Ruby code. This is because files are included by creating paths to the files in the file system and sometimes URIs are merely appended to the paths... well you get the idea. Every Rails form submission can change any attribute on an ActiveRecord object unless the programmer has taken the affirmative step to filter out the fields returned from a POST based on the fields put in the form originally. This means that an attacker can change the primary key of an object by appending ?foo_id=44 to a web post and voila, the object has a new primary key and can over-write another object. There are other lurking vulnerabilities as well. But at this point in time, Rails is as insecure as PHP was 5 years ago.

For building a simple CRUD app, there's still nothing better than Rails. For any application requiring complex user interaction or multiple user interaction, Rails is not the best solution.

I have spent the last 4 days playing with Seaside (http://seaside.st) Seaside is a Smalltalk web application framework. It takes a 180 degree different approach to building web apps than does Rails. First... some background.

Smalltalk is the superclass of all object oriented programming systems. It's a dynamically typed, everything is an object, language that runs on top of its own virtual machine. It was originally developed at Xerox PARC (now known as PARC) in the 70's. It was created in an era of limited computing resources, networks, mice, graphical displays, etc. It's syntactically nice (not as beautiful as Ruby, but a whole like prettier than Java.) Its performance seems to be very good. It seems to be very stable (I'm using Squeak http://www.squeak.org/ )

Squeak is maintained by folks like Allan Kay. As opposed to being "language hobbyists" (as some folks refer to Matz) these guys are the fathers of Object Oriented programming and were around for the creation of TCP/IP and most of the other things we consider advances in computing.

Everything in Smalltalk is an object. Smalltalk originated as a systems programming language (as did C) and has built in process control, etc. However, Smalltalk objects are all live and can be modified on the fly in the running Smalltalk system. This means you can get an exception in a running process, debug the exception by changing code, hit "go" and the process will resume where things broke. Yes... it's that good. It's that flexible.

With the caveat that I haven't tried to beat Squeak into a bloody pulp with 90M record text files, etc., I believe that it's a very stable runtime.

Smalltalk has code blocks you can pass around (in fact, almost everything is a code block that's passed around.) Smalltalk easily allows you to build "continuations." You can say "take a snapshot of the current thread context, save it (in a hash table, array, local variable, instance variable), and start executing it later." This has very important implications for creating non-linear programs using a linear syntax (and we all think linearly.)

Seaside takes advantage of Smalltalk's continuations by allowing the developer to put different components on a page at the same time and each of the actions of the components (expressed as HTML <a hrefs> or form field) executes some code when it happens. Okay, this can be done with Java (think about a program littered with anonymous inner classes) or Ruby (lots of closures.) For example:
html link: 'add one' do: [self count: self count + 1 ] .
html link: 'reset' do: [self count: 0 ] .

However, Seaside also allows a "call:" construct which is done in the flow of the Smalltalk program. You "call:" another Seaside component which is substituted in the HTML display for the calling component and the results of the called component are returned in the normal flow of the caller. So, it would look something like:
address := self call: AddressForm new .
(address inState: 'NY' ) ifTrue: [self alert: 'We don't like New Yorkers' ] .

The AddressForm would be substituted in the DIV where the other HTML content was (that div could be the whole HTML page or just the part of the user checkout) and the user could fill in the right values, the AddressForm could span an arbitrary number of HTTP request/response cycles, validate stuff and when it was successfully complete, the flow of control would return to the caller which tests to see if the address was in New York.

We did stuff like this in SmartMode, but SmartMode could only handle a single multi-page form at once. Seaside can handle the state of an arbitrary number of objects on a page at the same time. So, you could have your address form, your chat with the sales person form, etc. all on the same page and Seaside takes care of managing the state among all the objects, etc.

Seaside correctly manages multiple browser windows open to the same form on the same site. Seaside correctly treats each browser window as a separate logical session.

Seaside also deals correctly with state changes resulting from the back button (it does this by saving continuation snapshots of all the components that are rendered for each page load.) And Seaside has transactional isolation so that the back button won't let you go back to a page after your credit card has been cleared.

If all of this isn't cool enough, you can write your entire Seaside application in the browser. Seaside will display the entire Smalltalk object hierarchy for you, let you add, edit, and remove methods and classes, change CSS, etc. all in the browser and you see that changes in your application. If your app throws an exception, you can fix the code that caused the exception in the browser, hit "try again" and see how things change.

Seaside is very secure in terms of how the responses are handled. Each link and each form element has a unique ID and if that ID doesn't exist in the runtime, it's thrown away. This means doing replay attacks is not possible. It means that hidden links are useless outside of the current browser's state. It means that you can't add a parameter to an HTTP request and change the ID of a database object. It also means that QAing a Seaside app is more difficult because automated tools won't work.

Finally, Seaside has amazing AJAX integration. Because Seaside manages what needs to be served as part of an HTTP request, it determines if all the components on a page need to be re-rendered (e.g., a Web 1.0 page load) or if only a particular component needs to be re-rendered (a component or two or three that were made dirty by an AJAX request.)

DabbleDB was done in Seaside and the main Dabble developers are the guys who maintain Seaside. Everyone I know who has played with Dabble thinks it's the best web app ever.

So... what's wrong with Seaside. Well:
- There's no stable, well maintained Object-Relational mapping layer.
- There's no documentation (it's worse than the lack of documentation for Ruby/Rails)
- There's no HTML layer. All the HTML is rendered programmatically. This is not like CGIs from days of yore. This is html div: [ html text: 'foo' . html text: 'bar' .] It makes sense because all the formatting is done with CSS, but still, without a graphical HTML editor, it's a challenge.
- All the state is managed in the Smalltalk image. If the Smalltalk engine crashes, so does the state. It also means that all requests for a particular user be sent to the same Smalltalk instance (this is doable for load balancers, but requires more work.)
- There's a smaller community around Seaside and it may not reach critical mass.
- It requires a totally new way of thinking. It's not just IoC, it's much much more. While Rails has a shallow learning curve for Java, JSP, PHP, Python guys, Seaside is much, much different.

So... why this rant? Well... even though haven't gotten to my "hate" point with Seaside (I've gotten to that point with most technologies, although with NextStep and Java, I came back to loving them... with Ruby, the jury's still out) I think it's got the right pieces parts to make it a quantum shift in web development. I think the kind of apps that could be commonplace with Seaside are totally not doable with any other web technology. But... I needed to get a lot of this stuff off my chest.

If any of you have a chance to check out Seaside, it's worth 4 hours of time. I'm interested in what you think.