techno.blog("Dion")

I am finding that Ruby is “my style” of programming language for many tasks. One that would be very well suited to Ruby, would be driving the browser VM, what we end up using JavaScript for now.

Ruby would be ideal for this task IMO, and I wonder if anyone has created an extension for Firefox at least. It would be hard to practically deploy with Ruby, until there was enough of an uptake of course… but you can still dream.

One of the problems to overcome is the fact that now, we don’t really modularize our web scripting code a lot. The most we do is have seperate .js files which encapsulate logic.

What if we had a mechanism in which the script could contain metadata which would look like dependencies in Maven.

E.g.

“My script needs My::Module version 2.4, and ActiveRecord 1.0, and ….”

Then there could be a local repo which would allow us to share code. Something like this would change the way we think about web scripting on the client, and move from a ‘hacker’ perspective, to something more mature. Of course, we would have to have a sandbox-like system to stop people from doing Bad Things.

There is yet another blog discussion about Ruby on Rails vs. Java web frameworks.

I think you find this type of discussion all over with the generic version being:

Technology X is simpler than Y so it either:

• Is too slow
• Is TOO simple
• It doesn’t scale
• It’s dad got beaten up by my dad

We are getting some of that at the moment. David Geary of JavaServer Faces fame (and fellow NoFluffer), and Matt Raible started on the rants.

Then the Rails creator, David Hannson came back at them.

It is interesting that David isn’t sure that showing the scaffolding piece in his demo was a good thing. Scaffolding lets you do a quick “there is my database, give me active record access to it now please”. You will end up with actions/views for your model at this point, which is nice for getting started / prototyping, or for simple “Naked Object” access for admins. Even David admits thats it probably shouldn’t be used in ‘real projects’.

So, my view on this?

Is Rails too simple?

It is simple in a good way. You can get started very quickly. You can incrementally tweak your architecture and extend Rails where needed BUT NOT BEFORE. I can start with scaffolding and then move to handling the model more myself. Basically everything is there for you to hook in.

Is Rails too slow?

Although I haven’t had the pleasure in deploying a Rails solution to a high end site, I have never had any problems, sites that run it are speedy and consistent, and there is NO REASON why Rails would force a slow application. Of course, a badly developed application that uses Rails could easily be slow (as with everything).

Can Rails Scale?

Web sites can easily scale as long as you have written your application in a way that can handle scalability. Ruby, and/or Rails, has nothing implicit about it which says “this can’t scale”. I know that the Java camp tends to think that it is the only scalable solution for “enterprise” apps, but it isn’t ;)

Rails isn’t the be all and end all of web frameworks. There are always going to be pro’s and con’s between two frameworks. I personally sometimes like rich components (a la tapestry), although there is nothing stopping you from building these components that you could reuse in Rails.

David Hannson, of Rails fame, writes a case against high-level components.

Although we have definitely seen components NOT be successful in areas such as EJB (yeah, we can buy SO many vertical components), the web tier (apart from the displaytag ;), I don’t think we should write off components in general.

There are many places where components make sense. They make sense in GUI development. Tapestry components work out great. In my experience, it depends on the contract and what you are trying to do. There are some items which you really don’t need to tweak much, and if you do, it is there for you. However, it is hard to have ONE reusable component for “new WebCommunity().start()”.

It is an art to choose what should be generized, what shouldn’t, and how to give enough hooks to allow you to tweak the component.

David Hannson, of Rails fame, writes a case against high-level components.

Although we have definitely seen components NOT be successful in areas such as EJB (yeah, we can buy SO many vertical components), the web tier (apart from the displaytag ;), I don’t think we should write off components in general.

There are many places where components make sense. They make sense in GUI development. Tapestry components work out great. In my experience, it depends on the contract and what you are trying to do. There are some items which you really don’t need to tweak much, and if you do, it is there for you. However, it is hard to have ONE reusable component for “new WebCommunity().start()”.

It is an art to choose what should be generized, what shouldn’t, and how to give enough hooks to allow you to tweak the component.

Brian McCallister has started on a path of comparing Rails in a way that Strut’ters would get.

He is spot on that people have made a connection between:

Rails is easy. Look at the short demo video

and:

Rails is easy, which means it must no be flexible, or scalable, or …

However, I think Rails manages to be all of these things. The hooks are there for you to get your fingers dirty, while staying in the rails world. There are also many apps which are running with high load, and no scalability problems.

I am really looking forward to talking to Mr. Trails at TSSS, to see what his experience has been shoehorning a Ruby view on a Java platform.

Brian McCallister has started on a path of comparing Rails in a way that Strut’ters would get.

He is spot on that people have made a connection between:

Rails is easy. Look at the short demo video

and:

Rails is easy, which means it must no be flexible, or scalable, or …

However, I think Rails manages to be all of these things. The hooks are there for you to get your fingers dirty, while staying in the rails world. There are also many apps which are running with high load, and no scalability problems.

I am really looking forward to talking to Mr. Trails at TSSS, to see what his experience has been shoehorning a Ruby view on a Java platform.

As you look at the various languages, and platforms out there, you often see people discussing how much intelligence should go into the parser and runtime.

Java, for example, has a very simple syntax. The parsing stage doesn’t have to do and know too much (although Java 5 did add more).

Compare this to the other extremes. Lisp is incredibly simple. The MOP also makes it very powerful, and the user doesn’t ever really know if the ’standard’ operator they are using isn’t really a tweaked out version. The MOP analagy has been:

It is like juggling with chain saws

Perl on the other hand has to have a parser which is a lot smarter. Larry comes at it from a linguistic standpoint, and wants the language to do the right thing (even if it means having a tougher parser).

I think I follow that pattern. As always, there is a tradeoff, but I would much rather have a couple of guys work on a parser that does what I want, and have the many developers work on a level above of that. I want more expresiveness in my languages. I would hate to write a book with a stripped vocabulary, and a lack of context.

However, there is obviously a tradeoff. The parser will have more bugs. It will take longer to implement, it must be proven that it CAN be implemented, and the resulting code will have more ’style’ and can hence be harder to read.

On a selfish note, I don’t mind spending the time to be a ‘power user’. I spent the time to learn the keystrokes for vi and emacs, and I can do many tasks a lot faster there than anywhere else. As a power user you want the tools that allow you to express your ideas in as simple a way as possible.

So, it isn’t for everyone, but give me the smartest parser in the world, let me write as little as possible, and I will be happy ;)

I was a big fan of the Rails video which showed how simple it is to get up and running with the technology.

Now there is an 11 minute Trails video, which walks through a ‘Recipe’ sample application:

Well, I got the video done. I created the Recipe application from the onLamp.com article in 10:53 seconds, and that

Jim Weirich has got a public list on Things a Java Programmer Should Know About Ruby.

This list does tell you a lot, although there are a few politically charged ones:

• Fixed what’s wrong with Perl
• Fixes what’s wrong with Python
• It’s super productive (like Perl, Python and Smalltalk)- maybe 5-10x Java.
• Is a lot like Smalltalk, but doesn’t look as funny
• Is a lot like JavaScript, but more OO and more for full app development

Try to ignore those a little (no matter how you feel about any of them) and stick to the technical side.

Personally, I find myself smiling more when I write Ruby code. It just fits me well.

And I love items such as:

while line = gets do
puts "Found: #{line}" if line =~ /start/ .. line =~ /end/
end

The core items that help me out are:

• Duck Typing: Thinking in terms of behaviour, versus strict typing via Class heirachies really helps me
• Closures: I go on and on about this one I know. I just love the clean code that comes out of it.
• Dynamic Typing: I just don’t by in to the static typing way. Although I see some benefits, it gets in the way too much. And, as Dave Thomas puts it… Java isn’t fully baked in this area as if it was, there would be nice need for ClassCastExceptions :)

Now, there are items in other languages that are also gems. I definitely miss IntelliJ when writing Ruby code :)

Rolling with Ruby on Rails is a new tutorial that goes through building a sample application from start (installing all software [rails, db, etc]) to finish (a running application).

Rails is really getting a lot of attention, and could be the tipping point for Ruby itself this year.

Parting Thoughts

Ruby on Rails has taken web application development to a whole new level. You no longer need to do the parts that used to be tedious work, because Rails does them for you. Even if you have to use a legacy database that does not use the Rails naming conventions, you don’t have to give up the productivity advantages of using Rails–there is still a way to tell Rails explicitly what table and column names to use.

Now that you’ve seen firsthand how easy it can be to create a web application, why would you want to do it any other way?

Perhaps your employer has mandated a particular framework or language. You can still take a few days to prototype it in Rails, then go to your boss and say, “I’ve already finished writing our entire application in Ruby on Rails! If you prefer, we can still take the next few months to write it as we originally planned.”