Just Another Grumpy Developer says 9 June 2006 @ 10:02

RoR (like any other technology) has it’s place in the grand scheme of things. I think the problems with RoR are not with the technology, but rather the hype generated by passionate and well meaning (yet ill informed or narrow focussed) types who think RoR is the next panacea to all their web development problems.

I’m a cynic (and a c# developer as well), but I have read enough to see that applied to the right problems, RoR is great – just don’t expect it to be everything the hype makes it out to be. It’s time to shoot the tech reporters (actually any reports but thats another discussion entirely) who don’t think beyond the narrow confines of their current piece.

traskjd says 9 June 2006 @ 10:20

Thanks for the comment sitharus.

With regards to following points:

3. Would you still be happy to work without an IDE if doing a half million dollar project? What sized projects would you require before you though that RoR just wouldn’t be up to it?

4. Agile is good, but I don’t agree that it’s good when the foundation is changing constantly. Agile suits developing solutions but products/development languages don’t suit it. They need more structured testing and suit be stable for long periods of time.

5. I meant scaling in terms of both time and requests. I know there are a few very large sites running RoR but reading the effort they went to in order to scale it sounds like a black art. In terms of development time RoR maybe faster initially but when you have a truly large solution I find scripting languages break down.

– JD

traskjd says 9 June 2006 @ 10:57

Just on point five, when is it expected that Ruby will be able to be “compiled” into bytecode?

– JD

/ drew’s Blog » Blog Archive » On JD on Rails says 9 June 2006 @ 11:15

[...] JD has posted about five four problems he sees with RoR. In this post I’ll try to address each of his concerns. [...]

Gabe says 9 June 2006 @ 12:03

1. I agree that people are being misled by scaffolding. But that’s not Rails’ problem. If you actually generate the code instead of just putting the declaration it’s informative about how several different parts of Rails works and provides a decent jumping off point for modifying the code if you are still uncomfortable setting things up from scratch.

2. 10 years ago people said Java can never replace C++ because it’s too slow. Productivity is more important than raw performance 9 times out of 10. Ruby being purely interpretted has a lot of room for improvement with the bytecode compiler. Certainly some features of Ruby certain optimizations impossible, but it remains to be seen how fast Ruby can get. Certainly you wouldn’t want to use Ruby for crunching massive data sets, but Ruby on Rails performance seems quite by my experience.

3. RoR removes a lot of the boilerplate code which make IDEs such an indispensable product for Java and .NET. I think you will see more IDEs emerge overtime, but personally I find the easy programmability of TextMate extremely useful in a Rails environment. Between the command-line tools (breakpointer, etc) and a good set of snippets and commands, there’s very little I miss from an IDE.

4. This is true, but also consider that Rails was only released 18 months ago. Version 1.0 was only release 8 months ago. It was essentially created by one man. You have to expect there to be a lot of areas that need to be fleshed out. Given the massive popularity, my guess is this will be a diminishing problem. Also, because Rails makes testing so easy, it’s similarly easy to automatically discover where breakage has occurred.

5. This one I just don’t get. Performance-wise Rails scales with a share nothing approach. It keeps its classes in memory using FastCGI, and it has a very easy-to-use caching system. You hear this admonition all the time, but there are some pretty large websites running on Rails. You never seem to hear any thorough analysis about why Rails doesn’t scale, it’s always from quick one-off reviews like this.

Development-wise have you looked at the output of the code generators in Rails? It’s all pretty basic readable stuff. In my mind RoR projects scale better than most other languages because of the low signal-to-noise ratio in the Ruby language. Using things like Ruby blocks, mixins and naming conventions to their full extent make RoR code lighter and more readable than their PHP or Java equivalent. In that regard I see RoR as being one of the most scalable solutions out there.

I think more pressing issues with RoR might be lack of support for unicode, many rdbms features aren’t given their due, lack of ruby bindings for some libraries, hosting availability / expertise, and general maturity. However having worked in-depth with Rails it just hits a huge sweet spot for web app development for me personally. Given the quality of the community and how its reached critical mass, I feel very confident developing websites using Rails. Maybe not quite there yet for million-dollar corporate projects, but I think it’s only a matter of time…

traskjd says 9 June 2006 @ 13:21

Cheers for the very well written comment Gabe

Also thanks for your comment too Michael.

It’s good to be getting quite a few different opinions for various points in my post Remember to let me know if any of you blog about this and I’ll hook you up with some Google juice.

One thing I was surprised about is the comment that it doesn’t support unicode.

Cheers guys,

– JD

Michael Koziarski says 9 June 2006 @ 13:45

Because ruby’s from japan, unicode isn’t particularly popular there. Han unification is a bit of a sore spot:

http://en.wikipedia.org/wiki/Han_unification

However it’s utf-8 support is included in the std library:

$KCODE=’u’
require ‘jcode’

Then all your strings will work fine.

You have to be careful with things like String#[] as numeric references into variable byte strintgs won’t behave correctly (under any language).

We support several non-latin languages with my clients app. Farsi, Hebrew and Chinese were just tested this morning. No problems at all.

Keith says 9 June 2006 @ 15:08

there are issues with any platform, but the bigger question to ask is….

Are you more productive with RoR?

thats the argument a lot of people who use RoR have for using Ror, its fast and fun…….

imagine if….

- your more productive using notepad and RoR than using a fancy ide and C#…

- Ruby is slow but is still fast enough for given te purpose…..a car is a much better way to get around a city than a jet is. But the jets faster.

- you need a few more webservers to deliver a soloution but you deliver much sooner than you’d deliver anything else….

The real question about RoR is, are these things true? can you be a lot more productive?

Gabe says 11 June 2006 @ 05:06

My experience with RoR compared to PHP is that I’m about as productive as I imagine myself to be! But then when I go back to PHP I’m amazed at all the hoops I have to jump through and end up always taking longer than I thought. I’ve spend 6 years developing a lot of personal MVC-style conventions for efficiently writing PHP. Yet Rails is already faster for me when I know comparatively little about it and the Ruby language. Now I expect ASP.NET with an IDE is much more productive than raw PHP, but I’m really reluctant to go with a Microsoft platform because open source just seems a lot safer for long-term development purposes (to me). I’m also not interested in anything too enterprisey. I realize that J2EE can do a ton more stuff than Rails, but I don’t feel the need for the mental overhead and complexity (and verbosity). Enterprise developers are fond of calling RoR a toy. But answer me this: Would you rather be in a cubicle working on some arcane component that no human being outside your team will ever be able to understand? Or would you rather play with ‘toys’ all day? I’m not offended by the toy moniker, I’m just glad I can make a living with it!

As for going outside the box, I think that’s just a matter of familiarity. Personally I still have a ways to go to become as familiar with Ruby as I am with PHP, but so far Ruby feels like the most expressive language I’ve ever worked with. Looking at the available plugins is proof of just how outside the box you can go keeping with the spirit of Rails. With PHP and Java I feel like you just write APIs all day. If you need new functionality in a modular form, you write a class. One way to do things. In Rails though you can write a plugin that extends the existing functionality by means of mixins, or general methods that are specialized with blocks. It’s a new way of thinking about things, and takes some mental gymnastics to get up to speed, but the rewards are great. A good example is the file_column plugin for Rails that lets you turn a database field into a filesystem-stored file with a single declaration in your model. It processes uploaded files, stores the filename, and even allows multiple versions of images transformed by imagemagick, all with a single declarative line in your model. Not that APIs can’t do this just as cleanly, but Ruby provides more vectors to approach problems, and its accomplished relatively easily.

I think the perception that going outside the box is difficult with Rails is based on how easy it is to stay inside the box. But the opportunity to expand the box is there, and make more things just as easy. I think it all boils down to Ruby. If you can’t get into Ruby then Rails will never be comfortable. The reason I embraced Rails so readily is because I’d already been looking at Ruby for a while, as a well-designed alternative to languages like PHP and Perl. And Rails is very well-written Ruby.

Gabe says 12 June 2006 @ 09:28

Actually I’ve experienced a corollary of this which is that there’s a ton of content out there about Rails that is not marked with a version (and sometimes not even a date). I guess this is the flipside of “release early, release often”. Documentation for Rails is thin in so many areas that informal resources like blogs and unorganized Wiki pages end up becoming defacto authorities.

On the one hand it’s annoying when things change and break so often, but on the other hand it’s also annoying when legacy decisions prevent technology from reaching its full potential. PHP is a prime example of this though it’s an easy target because of just how bad the decisions really were.

It feels like Rails is stabilizing, but I seriously doubt whether it can ever rival the stability of corporate frameworks. There’s a fundamental value difference in large organizations where stability over time far outweighs productivity gains. If you’re talking about million-dollar systems with lives of 20, 30 or 50 years, initial development time pales in comparison to maintenance. Fortunately that’s not the field I’m in.

traskjd says 17 June 2006 @ 14:29

Marc,

More books on RoR are coming out but the best to start with is the second edition of “Agile Web Development with Rails”. Coupled with “Programming Ruby” which is a useful language reference for Ruby as well if you want to get a little deeper.

– JD