Slashdot Mirror
Thinking about Rails? Think Again
wolfeon writes "In 2005, Derek Sivers of CD Baby wanted to scrap his site and perform a rewrite in Rails. He hired Jeremy Kemper, also known as bitsweat on Freenode, to help on the project. Two years later, through blood and sweat, the project was then canceled because of limitations of Rails. Rails just wasn't meant to do everything since it is very much "canned" project. Mr. Sivers has written an entry in the O'Reilly blog: 7 reasons I switched back to PHP."
After twenty five years watching technology try to not suck, one note rings true from The Fine Article. The new girlfriend always seems better... at first. But over time you'll likely discover she too (as one might expect) has foibles, idiosyncrasies that annoy and sometimes downright frustrate.
If you've found a solution to a problem, consider carefully wrapping some other technology around it just because. Unfortunately my experience was that usually new technology/approaches typically were just because, usually driven by management (not always, and I'm not blaming them).
Had I known then what I know now I'd have fought harder for status quo on a lot of big projects.
It is all about choosing the right tool for a job. Sometimes you use a new tool and you wind up feeling like you are trying to put in a screw with a hammer. Sure it will work but not the way you want.
Sometimes you go back to the tool you know how to use best.
Keep the Classic Slashdot.
"All the cool kids were using Rails, so I decided if I wanted to be cool, I had to completely switch to Rails in one big jump!"
There's a complete lack of points against Ruby in that article. And I don't say that as a fan, I don't know the langauge at all. It's just got a complete lack of any useful information to judge the usefulness of Ruby.
Reasons:
#1: Seems a very weak criticism, all languages are interchangeable really. Except some do some things much better than others.
#2: Internal management problem, not really related to Ruby specifically.
#3: Applies to every language
#4: Potential for real criticism here, but without any DATA it's completely useless
#5: Works for whatever language the author likes, again not related to Ruby
#6: Potential for more real criticism here, but again lacks any useful information
#7: Again something unrelated to Ruby specifically
From the whole list, only 2 of the reasons point to Ruby in any manner, and those are so uninformative as to be useless anyway. I think most of the blame for this lies with slashdot, as the article tries to spin it into something against Ruby when the actual article is more about a failed migration than anything else.
I read the article, and I believe the reasons the author switched back to PHP was because he was more comfortable with it than Ruby. If you read deeper, you'll note that he appreciated the experience in dealing with Ruby, and brought some of it back with him to PHP, but he did not think it was right for his application. Seeing this as a "OMG! Ruby replaced with PHP!" is just another fanboy reading into it what he will.
Time to calm down here, people. Just because one person sees value in another set of tools doesn't mean you will too.
So, we have a slow language, with ugly syntax. The ugly syntax is subjective, so we'll overlook it for now. We have a slow Smalltalk, but maybe the framework makes up for it. Looking at Ruby on Rails, it seems like a cheap clone of the old NeXT WebObjects (cloned as GNUstepWeb and SOPE, uses Objective-C, which is typically faster than Smalltalk), and so far behind something like Seaside it's not even funny.
So, why do people use Ruby? Or is it like Java, as Guy Steele said:
And you're right: we were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp. Aren't you happy?I am TheRaven on Soylent News
- the question that scares me most,
- the one that you can never get honest information about from OS or component suppliers,
- and the one that's hardest to test because the most-used features are rarely those you expected.
Who said "prototype the thing, assuming a worst-case scenario"? No can do. With server code, this means you leave out features or spend $$$s more on hardware. And with client code such as AJAX, you know anything could break if used alongside idiot third-party widgets or when another IE patch makes Javascript even slower. You just don't know exactly where it will break in practice. So you add a lot of logging and try to spot when the next bottleneck is approaching. Worst case, it's in obfuscated, third-party modules that you can't change in practice, and you're re-factoring masses of code while angry villagers are breaking down the door. This is IMHO a risk with programming frameworks like Ruby on Rails, or MS dotNet for that matter.Reduce, reuse, cycle
I have one burning question: What is the take of Jeremy Kemper (aka bitsweat) on this situation? Being "one of the best Rails programmers in the world", many of us would like to hear from him. Has he blogged or posted about this too? (need a link) Does he share the same view points on the situation?
My wife and I ditched Windows for Linux 8 years ago at home. I stopped dual-booting and everything -- no more Windows, period. I still have to use it at work, but my wife didn't for years working in retail. One day, she had to use Windows at work and found it dreadful, I chuckled to myself.
;-)
Funny, 10 years ago I ditched Windows (and OS/2) for Linux at home. I stopped dual-booting and everything -- no more Windows, period. I didn't have to use it at work because I was a college student and while I didn't have a wife, I had numerous girlfriends throughout that time period that had to use it when they were in my apartment or dorm. One day, I got a new computer and it came pre-installed with Windows XP and found it far more impressive than the kludge of shit I had been trying to do w/Linux to fit into a Windows world for the last (at the time) 6 years. I chuckled at myself for trying to hard for so many years when Microsoft actually had a product that worked for once.
Yes, some of us are very happy over the long term using both Linux and Windows. Am I a system administrator? No. Do I program? Yes. Am I the average Joe Computer User? No. Does my wife get a husband that understands the best of both worlds and a network that works happily with whatever flavor we require? Yes.
Just my $0.02, take it or leave it
I disagree with the vast majority of those points. The only two that I agree with is giving consideration to scalability and getting user feedback. The rest are illogical conclusions based on a failed project whos real failure was poorly specified requirements.
Certainly, Web UI's are not appropriate for everything. They should really only be used if there is some overpowering need (like the ability to access the data from anywhere without having client apps installed). They also apparently gave zero thought to existing processes and staff skillsets.
Avoiding AJAX or any other technology because you tried to use it for something it wasn't good at is patently stupid. There are good uses for the technologies. This just wasn't one of them.
If you need web hosting, you could do worse than here
Everything you've said is good about Ruby also applies to Smalltalk, which uses blocks (closures) to implement all control structures, has trivial syntax (the entire language can be defined on a single piece of paper, and taught to small children with no programming experience in a few hours). It's obvious that the choice between Ruby and C++ is not necessarily simple; Ruby has higher-level abstractions, C++ has faster execution speed, so the choice depends on which is important. The question is, why would you choose Ruby over any of the following:
- OCaml
- Haskell.
- Common Lisp.
- Smalltalk.
These all have the same high-level abstractions as Ruby (more in some cases). They are all mature languages, and they are all 5-50 times faster in terms of execution speed than Ruby. I understand why you would choose a slow-and-expressive language over a fast-but-less-expressive one, but why would you choose a slow-and-expressive language over a fast-and-expressive one?Even Objective-C can do most of what you claim is great about Ruby, and some other things. For example, I have a category which allows me to send messages to arrays as if they were individual objects and have it perform a map operation in Objective-C, and I've implemented futures in the language, and yet I would still choose Smalltalk over it for anything where speed is not critical.
I would hope, by now, that everyone knows that pretty much any language is better than C++, so 'better than C++' is not much of a recommendation anymore.
I am TheRaven on Soylent News
This is his best point.
My VB coding improved immeasurably after I learned C#. And I'm not just talking VB6, I'm talking VB3 as well.
Learning a new language can teach you to do so much better in your old ones. I am *still* more productive, if you want something fast, in VB6 than I am in Java or C#. I can knock together a small cheap GUI very fast.
Of course, sometimes you do run into the limits of your chosen platform. VB6 strings are all 2-byte unicode internally, which makes dealing with UTF-8 a real pain. Then the ugly kludges start coming out.
The big problem with flavor-itis in large projects is the years of support after. Time tested solutions people!
Once a company gets committed to a design decision made by an trendy-entranced developer, the sysadmins and users can get punished with years of suffering afterwards.
The tools stop being updated, and none of the *good* developers want to care for the ugly, unique application once the shine comes off the tools. It's like being forced to wear a magic top hat made out of steel - because top hats and magic steel were the fads when the project started.
A trustworthy, *experienced* design architect is important. Preferably someone who's been/seen the young-uns make the silly mistakes.
-- Life is good. Tastes like chicken.
My advice is to analyze the needs of the system before designing it. Don't assume a GUI or AJAX front end is the best possible way to do things. My favorite example is the library system in my county: their computers are using a console system for check in/check out, card processing, etc. The beauty of it is that the bar code scanner they use behaves like a keyboard, so that each scan is just a series of a numeric keystrokes following by an end-of-line. It is simple, the 80 year old librarians have no problem using it, and it doesn't require any difficult to coordinate mouse movements (as anyone who has studied this knows, using the mouse requires a lot of brain activity than using the keyboard). The console very accurately maps the workflow; a GUI wouldn't add very much, other than sheer lines of code, and a web interface would actually slow down the people who need to use it.
Sure, there are cases where a GUI or web interface is better than a console interface. But that is why an analysis is needed before any code is written. As your friend's situation demonstrates, a well design system can work for many years without any trouble.
Palm trees and 8
The biggest problem, as I see it, is that the people who make major strategic decisions on IT don't have a clue what they are talking about. It's happening in my company right now - a consultant is being paid vast amounts of money to essentially write an ERP from scratch, for a company that doesn't need anything more complex than a decent accounting package that can handle more than one operating site. The guy is being paid a monthly fee and has no written specification or brief. He has no deadline and no agreed feature set. On a regular basis he turns up and spouts off his latest idea, solving a problem we don't have. The bosses, who know their business but don't know technology, are completely clueless and are pretty much at the whim of this chancer.
[FUCK BETA]
Rails did not invent MVC, nor did they invent scaffolding or any of the other stuff. They didn't even make it popular. Very many people get these facts wrong. The only thing Ruby On Rails did as a first was to apply professional marketing strategies when trying to make an open source web application framework popular. They were the first to build a project website that was appealing to the eye more than anything else and they heavyly pushed the concept of the screencast, right when broadband was becoming commonplace. I'm shure almost everybody has watched that famous 'a blog in 15 minutes' screencast. This screencast alone made Rails (and the editor presented in it, Textmate) extremely popular.
Technology wise there are many frameworks and webkits that are far more mature and far more sophisticated than Rails and have been around for 6 years and more.
We suffer more in our imagination than in reality. - Seneca
I've been interested in learning at least one of those languages for a while. Usually what gets in my way is that I can't find the necessary libraries to complete whatever task I'm working on. Can you point me towards the language from your list that has:
* a rich standard library with a good reference
* a good extended library like CPAN
* easy extension in C
* good documentation
* easily available compiler, etc.
I don't mind buying a book, as long as I can get somewhere just from the online documentation. Out of the languages you mention, I got the furthest with OCaml. However, if I needed to do something simple like connect to a database and then contact a directory server using LDAP, I'd be lost.
Social scientists are inspired by theories; scientists are humbled by facts.
I don't see anything in the article that actually states why he chose Rails in the first place.
Even worse, there's absolutely nothing there about why Rails didn't work. Exactly what was it that was so hard to do in Rails that was easy to do in PHP? The article provides nothing useful to anyone looking to build a web site. How do I know if PHP is superior to Rails for my particular application? There's little there to help. This is nothing but a senseless rant.
"The legitimate powers of government extend only to such acts as are injurious to others." Thomas Jefferson.
The only failed experiment is the one you don't try.
Clearly, someone thought there would be a benefit to using Rails over PHP in this case. If they were wrong, they gained valuable insight into a) the abilities of their tools and b) the nature of their project.
I never liked the old saying "if it's not broke, don't fix it". The quest for innovation is a beautiful thing.
You are welcome on my lawn.
...stupid decisions based on myth over reality. You have front end people making decisions about browser security in utter discord with back end choices made for functionality. You have redesign of existing functional systems without starting back at the design specification. You have scale failures because you didn't test your nonexistent spec. for scale.
I'm glad I don't work there.
The problem with quotes on the internet, is that nobody bothers to check their veracity. -- Abraham Lincoln
You're just trolling.
A PHP tag on a webserver doesn't mean that the site is powered by PHP. It means that whoever compiled apache loaded a PHP module for possible use in one of the virtual hosts. That Apache also has FastCGI installed, which is routinely used for serving rails applications.
I know for a fact that several high-traffic websites use RoR extensively, but none of them are tech sites, so they don't go around advertising what is on the back-end.
I shouldn't have taken time to respond to your obvious troll, but I felt forced to because some gullible moderators gave you points for spewing lies and idiocy. Typical slashdot fare, I know, but give it a break.
MySQL? I know a company that went MySQL4 for a lot of things (and then later MySQL5). Using MySQL is usually a bad idea (and it does bite them every now and then - though most of them don't even realize it - I suppose they think that sort of thing is normal, they switched to having email on Microsoft Exchange too, so go figure).
They have should have gone postgresql as per my recommendation. Oh well.
With MySQL at first sight you seem to have all these features and behaviours/performance. But when you get down to the technical details you find that many of the "great" features, behaviours and performance are mutually exclusive. Want transactions - go innodb. Want fast inserts, go myisam. Want better concurrent write performance go innodb (or deal with buggy myisam insert delayed vs concurrent_insert vs etc stuff). Want fast selects - go myisam. Want foreign keys to work - innodb. Don't want to lock yourself to MySQL tech that's owned by Oracle (who may not have the best interests of MySQL in mind...) go myisam.
Or just use postgresql. The devs tend to do things right (except when the SQL specs are stupid, in which case they usually follow the stupid spec and do things "wrong").
On a practical level rather than a "my code is more beautiful than yours" level, one answer is simple: deployment. If you're writing a program that's intended to be used pretty much just by you (or other people on your dev team, perhaps), it really doesn't matter what you write it in. If you're writing a program that's going to have to be rolled out to production systems that you don't have absolute control over -- like, say, a commercial web-hosting service -- there are new issues.
Ruby is getting a lot of attention because of Rails, and Rails' attention is making it moderately easy to find web hosts that support it. It is easier to deploy a Rails application than it is to deploy a Django application, if you're taking into account "I must find a web host that supports my framework/language." If you are writing, a web app in Smalltalk using Seaside, well, not only are you definitely not shoving that out to your $8/month Dreamhost account, the chances are you're going to have to have complete control of the production side (i.e., colocation or self-hosting). Also, of course, if you're writing for a business, maintainability becomes an issue with any "obscure" language: eventually, the original development team won't be there, and if you can't replace them because the dozen other people in your area who know the language you chose are happy at the research labs they're working at, you find yourself in a very uncomfortable place. I've heard the even a kindergartner can learn Smalltalk so fast they'll be writing complete CRM systems in a week! speech, too, but in practice it seems those kindergartners are few and far between.
Frankly, deployment issues are one of the reasons I'm slinking back to PHP myself; as much as I love Rails in theory, as it turns out, in practice Rails is a sufficient resource pig that many shared hosts that claim to support Rails put serious limitations on it unless you bump up your service level. (I know I'm inviting arguments from Rails fans here, but yes, I've really looked into this.)
I just can't understand how your input data makes you assume your conclussions. Except from the "why change a system already working just OK?" which I'm 100% with you, I extract very different ones from your provided data:
"In the mid-1990s, the company in question built their IT operations [...] They wrote much of their in-house code"
I read here: in the mid 90s the company built a tailor-made IT system engineered by their internal knowledgeable technical staff.
"what is somewhat unique is that they essentially continued to use those same systems up until 200what is somewhat unique is that they essentially continued to use those same systems up until 2006."
We know their staff was knowledgeable and that the system fitted well their needs from the simple fact that it managed to work about 15 years without major complains.
"One of the main reasons why they didn't switch is because their software systems worked just fine"
Exactly what I was saying.
"They even got extremely lucky in the first place, as the developers who initially designed and implemented their software systems did so in a way that allowed for the systems to easily scale"
Do you think that's "luckyness"? That properly scalable systems grow up "per chance"? No: it was properly designed, that's why the system scaled, not because "luck".
An now, for the problems:
"A variety of consultants were apparently called in"
I read here: A variety of *external* resources that surely couldn't know the bussiness better than their old internal counterparts (things cannot be done much better than "OK", and that was the standard to beat), and that surely held their own agendas (like pushing the technologies they are knowledgeable about, instead the ones that best fitted, if only because the old "for a man with only a hammer every problem seems a nail", if not worse, "Certified Microsoft Gold Partner That Gains Money Every Time Microsoft Technologies Are Pushed Into A Client") were in place to design the new system.
And this is the very and only problem: By the 90's they had knowdledgeable internal staff. By 2006 they went to external unfitted consultors. I bet there's an untold story here that includes those "so expensive" Solaris sysadmins and C++ developers that were fired by a "smart" manager looking for profit. All the particular problems you outlined are not problems but consecuencies of this. Of course the new web-based GUI could be Firefox-tested -if knowledgeable people were in charge. Of course the new web-based GUI could make use of proper keyboard-based navigation -if knowledgeable people were in charge. Of course that the proper ammount of iron could have been pushed on the backed (specially after 15-more years of stats and usage-patterns) -if knowledgeable people were in charge.
No one of them are strictily speaking problems with AJAX, or Windows, or dot-net, or whatever the technology (while going from a perfectly working C++/Unix environment to an all-and-only-Microsoft is a very hard hint about management going nuts). All of them can be pointed out to a very common tendency on IT: fire the old knowledgeable technicians that put the means for the company to grow and stay there in first place and contract cheap minions and expensive external consultants as substitutes; then look as a very smart manager that saves the company some pennies; then the obvious "???" and finally the "wreak havoc" instead of "profit".
I've now written two large business applications in Rails. I did the UML modelling first. Then I wrote a fully constrained RDBMS schema, normalised to 3NF, using the Rails naming conventions. Then I wrote the Rails app on top of the rigorously constrained database.
If you want multi-key uniqueness constraints, just define it in your database already! Why do you think Rails prevents you from configuring your database layer?
When I need to do transactions, I use Rails' full support for transactions. There, that wasn't so difficult, was it?
I let Rails save me hours of backbreaking labour writing conventional SQL queries. Then I use the completed application, identify the query bottlenecks (thanks to Rails' built-in profiling) and re-write the slowest of the dumb auto-created SQL using hand-written SQL, which I can get to using find_by_sql, finder_sql, etc. Rails lets you put your own SQL into the application almost anywhere.
Does my bum look big in this?
Referential integrity and unique constraints should always be enforced by the database. Why even have a database if you're not going to use it?
Perhaps I'm missing something in your post, because it sounds to me like you're advocating every application that accesses the database to enforce data integrity rules. This is a recipe for data corruption, as I'm sure you already know.
They don't grade fathers, but if your daughter's a stripper, you fucked up. --Chris Rock