As a follow-up on I am getting Ruby-fied, Ruby’s not ready - glyphobet • ???????? • ???????? does a much better job at going over Ruby’s faults. Ruby on Rails is not discussed except to say that it and Pylons are very similar, but i tend to agree that a lot of the different web frameworks out there are quite similar because they all include what is needed of a modern framework.
The author has had more experience in Ruby(and Ruby on Rails) than i did obviously, so i won’t try to go into the things he did. I also can’t validate all his concerns, but i can validate most and agree with most. So i can’t go as deep as he could in the discussion because as expected, the RoR project has been stalled for the past month or so. But let me review my previous assumptions and determine what was and wasn’t true. Note that i will refrain from commenting on the things that i can not yet validate to keep things objective.
Ruby seems like en easy to learn language. A lot of the language syntax and Ruby-way-doing-things(yes, that’s one word) is meant as a productivity boost. > >
That is definitely true. But the many quirks in there make it really difficult to learn the language in any deep manner. I mean to_s ? Come on. Really? to_str i might understand(which does another thing all together) but to_s? And that’s just saying one thing that i find highly annoying, take a look at the linked article and be amazed.
Ruby is not a new language, it is as old as Python and Java. > >
Definitely true. Although, Python and Java being old has worked to their advantage. Both languages have evolved in a generally useful direction. Ruby on the other hand seems to be this toy language that suddenly got immensly popular and is now struggling to become a modern language.
Python and Ruby have similar principles. The most interesting perhaps is that code should be easy to read and some would say beautiful to look at.(should be true of any language, but depends on the programmer i guess) > >
Hmmmm…. I am not sure about this one. Ruby is very lax in its syntax and that makes it terrible to read and definitly not beautiful. In fact, this whole flexibility has turned me off the language completely.
It was meant to solve a general problem and is not meant as an end-all-be-all type of solution. > >
That’s true. If you turn off the noise generated by the fan boys then you would find some wise people telling you not to use Ruby for things it wasn’t designed for.
I come from a c background so i had trouble getting used to languages that don’t follow the C syntax(and its older parents). Earlier on in my career, i decided that i shouldn’t let something like different syntax stop me from learning what might be a truly great technology. I followed this approach with Python and was quite successful and will do the same with Ruby. > >
I did follow that approach on leanring Ruby and well, i think that with proper coding standards, Ruby code can be quite elegant. My only problem is fan boys turning turning Ruby into php.
I think that a lot of the features in Ruby 1.9 should really have been in earlier versions. I don’t know why is that the case though, maybe there’s a good reason. > >
Also true. In fact, my suspicions were quite correct here in that the language doesn’t have a very clear path. But again, this seems to be a subjective issue.
I don’t appreciate the Ruby community believing that the Ruby language is the best thing since sliced bread. It is possible that it is an excellent language but definitely not the answer to everything. Passion is always good, but zealotry is not. I believe that good programmers should choose the best tool for the job. I wouldn’t advocate Python for every kind of problem out there. > >
Well, there’s nothing i can do about that expcept advise my clients(and anybody else who asks) about the proper technology.
A lot of people also complain about some of the conventions used in RoR and how dreadful they are. That is somewhat scary, but then again, all frameworks have some of those. It would be possible to create a framework that doesn’t, but then it would be too complex to learn. A compromise is always needed. I don’t yet know enough to comment on this, I’ll report back. > >
Well, this wasn’t very accurate. I wasn’t intimidated by the convention in RoR, and actually think they’re quite reasonable. The conventions and quirks in Ruby however were a PITA. In an RoR project however, you would be more worried about developing within RoR rather than worrying about Ruby’s idiosyncricities.
People always rave on about the great toolset that RoR has. In particular, capistrano and rake. I think those are definitely good tools but there are several different alternatives for different techs as well. > >
I haven’t worked with capistrano yet, but Rake is cool. I like the way migrations work with some minor comments(should be fixed in RoR 2.1 i think) and i also like the way unit and integration tests are considered to be part of the project development as opposed to “extra development”. I hate the way JS using prototype is dealt with in RoR and prefer Django’s “use whatever you like” atitude and for good reason. Scaffolding is nice at first look, but nobody actually sticks with it except for very small applications. The book i was reading didn’t describe static scaffolding, that seems to be a nice approach to it. And so on….
I went with Django earlier last year because of the excellent way the framework developed. It has very good documentation and a healthy development environment. At the time, i couldn’t see that in RoR. > >
Things have definitely changed with RoR. I still prefer Django immensly because of the general atitude of its developers, but…..
RoR and consequently Ruby got its fame largely from the efforts of one company. 37Signals may be great, but i wouldn’t trust the development of a general purpose framework to one small company. > >
True at first, but RoR is its own beast now. There are still some existing problems, but then again, there always is.
Django seems like field-produced framework. Initially, it constituted the guts of a CMS and was later extracted and made in a general framework. I find that it particularly adept at solving problems that you would encounter when writing a data driven web application which a CMS is an extreme example of. > >
This is definitly also true of RoR. So the comment is valid, but it doesn’t apply correclty to RoR. RoR was extracted from a 37Signals application(backpack was it?) and so is also a field-produced framework.
So in summary, i still wouldn’t use either Ruby or RoR if i had the choice. But depending on its couterpart in comparsion, they might just win.