Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Thinking about Rails? Think Again

CmdrTaco posted more than 7 years ago | from the or-not-at-all dept.

Programming 482

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."

Sorry! There are no comments related to the filter you selected.

Thinking about abortion? think again (-1, Offtopic)

Anonymous Coward | more than 7 years ago | (#20718575)

Day 1

Mommy, I am only 8 inches long, but I have all my organs. I love the sound of your voice. Every time I hear it, I wave my arms and legs. The sound of your heart beat is my favorite lullaby.

Day 2

Mommy, today I learned how to suck my thumb. If you could see me, you could definitely tell that I am a baby. I'm not big enough to survive outside my home though. It is so nice and warm in here.

Day 3

You know what Mommy, I'm a girl!! I hope that makes you happy. I always want you to be happy. I don't like it when you cry. You sound so sad. It makes me sad too, and I cry with you even though you can't hear me.

Day 4

Mommy, my hair is starting to grow. It is very short and fine, but I will have a lot of it. I spend a lot of my time exercising. I can turn my head and curl my fingers and toes, and stretch my arms and legs. I am becoming quite good at it too.

Day 5

You went to the doctor today. Mommy, he lied to you. He said that I'm not a baby. I am a baby Mommy, your baby. I think and feel. Mommy, what's abortion?

Day 6

I can hear that doctor again. I don't like him. He seems cold and heartless. Something is intruding my home. The doctor called it a needle. Mommy what is it? It burns! Please make him stop! I can't get away from it! Mommy!! HELP me!! No . . .

Day 7

Mommy, I am okay. I am in Jesus's arms. he is holding me. He told me about abortion. Why didn't you want me Mommy?

One more heart that was stopped. Two more eyes that will never see. Two more hands that will never touch. Two more legs that will never run. One more mouth that will never speak.


Re:Thinking about abortion? think again (-1, Offtopic)

Anonymous Coward | more than 7 years ago | (#20718663)

if only this were true. sadly, we dont attain sentience until age 4-5 or so. so killing foetuses, babies and kids is no morally different than killing cows until they attain sentience.
mommy! mommy! that big bad man ate me today! jesus, tell me what being eaten is ?

Re:Thinking about abortion? think again (0, Funny)

Anonymous Coward | more than 7 years ago | (#20718723)

I didn't realize Fetuses had such a command of the English language! This is astounding! We'll all have to rethink our positions on abortion now, obviously killing such a life form would be murder!

Why rewrite existing systems? (1, Insightful)

MarkWatson (189759) | more than 7 years ago | (#20718585)

What a waste of time. Evaluate and use new technology on new tasks.

One of my main customers hired a good team in Vietnam who used PHP, CSS, HTML, and Javascript. I introduced them to Rails a year ago, and they were just about instantly productive.

Deploying Rails can be a small hassle, but there are now lots of good options, including running on JRuby/Goldspike/Java app server.

Re:Why rewrite existing systems? (5, Interesting)

Anonymous Coward | more than 7 years ago | (#20718765)

This reminds me of a similar incident I saw on Reddit a few months ago:

Sometimes it's best to leave old software systems alone. []

Last night at the pub, a friend and colleague of mine was telling me of a recent experience he had at a company he was doing some IT work for. I think the lesson learned is a very important one, and thus I wish to share it. But first I'll describe the situation he encountered.

In the mid-1990s, the company in question built their IT operations around systems from Sun. They wrote much of their in-house code using C++, and used Oracle for their database needs. On the front-end, they used PCs running a mix of Windows NT 3.51, FreeBSD 2.x, and even OS/2, depending on the department. While that is not a unique setup by any means, what is somewhat unique is that they essentially continued to use those same systems up until 2006.

One of the main reasons why they didn't switch is because their software systems worked just fine, even if the UIs were somewhat archaic. Their software was mature and well-understood by the company's employees. 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 as the need arose over time.

The hardware proved to be the main instigator of change. After a decade, many of the front-end PCs they were using started to exhibit a variety of physical problems. Some had been replaced earlier, but eventually it was decided to replace them all with newer systems. However, to the best of my friend's knowledge, the back-end Sun systems were working just fine.

However, at the same time they decided to also replace the back-end systems. A variety of consultants were apparently called in to appraise the situation. For whatever reason, it was eventually decided that the new back-end systems would be built around Windows Server 2003 and SQL Server 2005. The new back-end software was to be built upon .NET, while Web-based client-side apps would be developed and used. My friend wasn't sure exactly when this effort started, but he believed it was in early 2006.

By the end of 2006, the consultants and developers deemed the new system ready to go. Over the course of the December 2006 holidays, the new systems were rolled out. It turned out to be a pretty major disaster. The first problem they ran into was a complete lack of performance. As they moved into the first weeks of 2007, their back-end systems just wouldn't scale. As an emergency fix, they ended up throwing more hardware at the problem, which did ease the burden on the existing servers somewhat. But it was in no means a permanent solution.

The front-end software systems proved to be an even bigger disaster. Many of the AJAX-based applications used Internet Explorer-specific functionality. But the IT managers of some of the front-end networks would not allow IE to be used, for security reasons. They only allowed for Firefox to be used. So the Web-based front-end software needed significant modifications right away, as well.

What was perhaps the worst failure involved the in-house users and their productivity. Large portions of the old system were built around a curses-based UI. Although it apparently wasn't very pretty, it did allow for a great deal of user productivity. One of the main complaints about the new Web-based software was that the keyboard support was quite poor, requiring the user to select input fields using the mouse, and at times even having to scroll the page to input or manipulate certain data. With the earlier system, the nagivation could rapidly be performed using just the keyboard. Some of the more experienced users were apparently so efficient with the older system that their productivity was reduced to 25% of what it was before the switch.

My friend and his colleagues were called in to try to remedy the situation as best they could. The company was not willing to invest in a completely new system, but instead insisted that the old system be brought to a usable, if not optimal, state. The work is still on-going, as we speak, five months later.

There are many lessons to be learned here. The one my friend emphasized the most was that it's often a good idea to leave existing systems as they are. What they had worked, for the most part. The problems they experienced with their front-end hardware could have been easily dealt with by buying new PC systems. But the decision to replace their working server hardware, and to rewrite their existing (and well-functioning) back-end software, were obviously terrible ones. The use of AJAX and Web-based software for their front-end systems was also a poor idea.

I think some of the other major lessons are as follows:

        * Use mature, well-tested, effective software (eg. Solaris, Oracle, FreeBSD).
        * Avoid immature fad "technologies" like AJAX.
        * Traditional applications offer more flexibility than Web-based applications.
        * Always give much consideration to back-end scalability.
        * Sometimes a text-based interface is far more efficient than a GUI.
        * Get user feedback on software early and often.
        * Maintain a reasonable level of heterogeneity, when it comes to software, hardware and vendors.

Hopefully we can all learn from these lessons made obvious by this situation. Although given my years of experience, somehow I think that won't be the case.

Re:Why rewrite existing systems? (2, Interesting)

Anonymous Coward | more than 7 years ago | (#20719315)

last year we made a major rollout of an application that was a rewrite of an existing application with microsoft tools, and guess what, it was a success, it outperformed the previous application and now the old system is forgotten. Lessons learned. * Use HTML, CSS, and keyboard support (onfocus, onblur, etc). * Don't understimate old software, we basically rewrote the application from scratch but using the lessons learned in 10+ years of the legacy software, sometimes working with the original developers. * Performance IS a priority, using proper OO techniques, and proper database design, performance is not an issue, even in windows plattform, sometimes the performance problems come from sloppy programming. * Benchmark your software, and test since day 1. Rewrite software is sometimes a need, particulary when the software is not actively mantained, the mentality of "it just works" avoid to look at the real problems... the systems that not change die, even the 20+ year cobol systems will die. Your post is misleading, since the problems were due bad project management, cheap developers and not in the tools.

To me that's poor planning (4, Interesting)

RaigetheFury (1000827) | more than 7 years ago | (#20718587)

Every technology out there has it's benefits. It's the job of the person planning the project to explore all of these technologies before they choose one. If you read his article, he makes no comments as to why he chose Ruby on Rails. Was he following the hype?

I've been involved in the decision making process to choose a technology for writing a site many times. Working for a University common questions we use in comparison to the technology is

1) Development time
2) Ability to integrate with LDAP or other existing technologies
3) Support (server level)
4) Documenation (For development)
5) Budget
6) Number of developers on the project

Depending on those variables it usually winds up being either PHP or Cold Fusion. Ruby on Rails has never once been a consideration. Not because it isn't a good solution, but it's never once been the best for our needs.

7) How far will it scale (4, Insightful)

giafly (926567) | more than 7 years ago | (#20718821)

After 30 years development, "How far will it scale" is
  • 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.

Linus is right (-1, Offtopic)

Anonymous Coward | more than 7 years ago | (#20718589)

I am with Linus on this one. For the life of me I can't understand what this sucking up to RMS is about. Linus himself does not think GPLv3 is a good thing. So why do people keep adopting it.
Without Linus FOSS is tossed. Not following Linus is dangerous for the survival of FOSS.

Re:Linus is right (0)

Anonymous Coward | more than 7 years ago | (#20718613)

Without Linus FOSS is tossed

FOSS won't go away if Teh Lunis does, but Lunix certainly will.

Now given how Lunix is the flagship FOSSie product, it may turn out that Teh Lunis leaving would be a huge blow to teh FOSSies, but it won't go away entirely.

But either way... I don't see how this has anything to do with the topic.

on rails (1, Funny)

ch0ad (1127549) | more than 7 years ago | (#20718591)

7 reasons I switched back to PHP after 2 years on Rails
wtf is php? is it new or something?

2 years on cocaine!? jesus fuck he can't have much of a nose left...

Re:on rails (0)

Anonymous Coward | more than 7 years ago | (#20718785)

dude, i think php has been around since like the 60s, even before coke. it's more hardcore than coke too, trip you out and fry your brain type shit.

but yeah, this guy has serious problems. php to blow and now back to php... man, hard.core. (wtf is this doing on orielly though??? should be on erowid)

thinking about something new? think again (3, Insightful)

yagu (721525) | more than 7 years ago | (#20718595)

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.

  • Thinking about ditching assembler for PL/I? Think again.
  • Thinking about ditching C for Java? Think again.
  • Thinking about ditching Windows for Linux? Think again.
  • Thinking about ditching Cascade methodology for JAD? Think again.

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.

Re:thinking about something new? think again (2, Insightful)

deftcoder (1090261) | more than 7 years ago | (#20718709)

I denno, I ditched Windows for Debian Linux over a year ago and haven't looked back since. (I'm a programmer though, so my needs are a bit different than your typical Windows user)

Then again, if this article is any indication, maybe I had better wait another year before I speak. :-)

Re:thinking about something new? think again (2, Interesting)

MikeBabcock (65886) | more than 7 years ago | (#20718809)

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.

Yes, some of us are very happy over the long term using Linux. Am I a system administrator? Yes. Do I program? Yes. Am I the average Joe Computer User? No. Does my wife get a free sysadmin with the ability to recode around bugs? Yes.

Just my $0.02, take it or leave it :-)

Re:thinking about something new? think again (3, Insightful)

garcia (6573) | more than 7 years ago | (#20719193)

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 ;-)

Re:thinking about something new? think again (2, Interesting)

ducomputergeek (595742) | more than 7 years ago | (#20718727)

I do the technical coding for a couple web designers (they make it look pretty and I make it work). Typically their clients have done enough research to have heard some buzz words so a typical conversation goes like this:

Client: "We'd like our site/new site to be Web 2.0 with AJAX and Rails and....

Web Designer: "This is the layout I've created with new logo, etc."

Client: "Ohhh, that's pretty, but I don't like that shade of >, could you make it >, maybe a couple shades darker, but know what I mean?"

Web Desiger: "Sure"

Me: "Okay now what are you looking for the site to do?"

Client: "We want our site to be Search Engine Optimized, with built in Web 2.0 features."

Me: "Okay, SEO is not a problem, we have a professional copy writer on staff that handles the ad copy for the pages. What keywords you you like to target in search engines?"

Client: "Um...I want my page to be on the top of Google when they search for it..."

Me: "Okay, is your site E-commerce: meaning your actually going to be selling goods from it?"

Client: "No, just about our XYZ business. But it needs a Web 2.0 contact form so clients can email us from the web page and we can send them back a quote."

Me: Okay, so you need a contact form (standard feature on just about every site we do). What else?"

Client: "Well I need to be able to update upcoming events on a calender and news items."

Web Designer: "We can use Joomla for that."

Me: "Or we can find a news page script in Perl or PHP for that page with a nice easy to use backend. Same with an events calender. Then you can design your nice tabled based pages in Photoshop/Dreamweaver and I won't have to spend a week converting them to a CSS based Joomla template."

Client: "PERL? PHP? That's not Web 2.0. It's suppose to be Ajax and something called Ruby on Rails! That is what > says about having your web site designed!"

Me: *hands client copy of Cult Of Amateurs* And then i WANT TO SAY "Here read this and then get back to me about web 2.0. The short version: there is no such thing, it's a fancy buzzword no different than Dotcom ten years ago. Now we could everything you wanted on your site back then with CGI/PERL and now PHP and it will work.

Instead I say, with a smile: "We can make it work."

Re:thinking about something new? think again (1)

kryten_nl (863119) | more than 7 years ago | (#20719085)

You don't charge your clients based on the number of hours it takes to fulfill their requests?

Re:thinking about something new? think again (1)

foniksonik (573572) | more than 7 years ago | (#20719303)

What you should have said is "What's your budget?" "$XX00.00"

"Oh, well in that case we're going to have to skip straight to Web 3.0, the leaner meaner more efficient web! More ROI ya know!" "Really? What about 2.0?" "Oh that's what the expensive Agencies want to sell you on so they can charge millions for a website. They get the marketing magazines to interview them and hype it all up. BUT we are already ahead of the curve.... we do AJAX and MVC without all the overhead of RAILS or those other big packages... it's like buying an RV when you really just want to go to the Beach ;-p way to much crap to bring along."

Re:thinking about something new? think again (3, Insightful)

TheRaven64 (641858) | more than 7 years ago | (#20718767)

I really don't understand the point or Ruby. It seems like it's semantically similar to Smalltalk, but with uglier syntax. Is it faster? Apparently not. [] On average, Ruby is 1/5 the speed of Smalltalk, and in some cases much worse. In only one test was it faster; startup (not important for long-running processes, such as stateful web apps).

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?

Re:thinking about something new? think again (4, Interesting)

19thNervousBreakdown (768619) | more than 7 years ago | (#20719011)

Try Ruby, code up a project in it after you actually understand the language, and you'll see the draw. For instance, just an hour ago I was writing a quick script to recurse through directories and apply ReplayGain. I had a loop like this:

Dir.foreach(target) do |entry|
    recurse(target + '/' + entry)

Later on, just on a whim, I decided I wanted it to sort the dir listing so I could judge how far it was through the process. I only had to change the first line:

Dir.entries(target).sort().each() do |entry|

A teensy tiny sript to be fair, but that's just an example that I was able to pull out of the last couple hours, I've done much larger things but it'd be hard to think of a good example. There's nine different ways to do everything, and they all work exactly like you'd expect. There's a million things that allow beautiful constructs, like lambda functions and yield statements, implict reference but easy to do deep copies, it goes on and on. The langugage is just an absolute joy to work with, and I'm saying this as a hard-line strict ANSI C++ programmer--so much so that I still find it hard to make myself use long long.

The problem is, it's so easy that it attracts people who hardly understand programming. It also makes you want to try out weird new ideas. I've never looked very hard into it, but from everything I've heard about Rails and its almost code-generation level programming I get the impression that it's a great idea that got over-engineered to Frankenstein proportions, like the first home project of any size a fledgling programmer makes. Not saying these guys are that ... just that's what it reminds me of.

One good measure I try to follow is, if you have to basically learn an entire new language to use your product, be it a framework or a word processor, unless you've purposefully designed it as a language, with all the deep thought that goes into that, you're probably doing something wrong. Really, the yardstick I try to go by is, you should only have to learn one thing to progress further, never two things at once, and it should always be apparent what directions are available. I looked over the Rails documentation and example source, and it doesn't meet that criteria.

Ruby Isn't Rails. Check out the language, it's a thing of beauty, and it allows you to do things really quickly, really easily, and most importantly, the Right Way without a lot of extra effort (an area C++ fails miserably at, unfortunately). No, it's not the fastest language by a long shot, but haven't we always said that premature optimization is the root of all evil? They can (and in all likelihood will) fix that later. Plus, given how easy it is to add inline C, which can easily interact in both directions, make calls, construct objects, etc... well, when I discovered that it was like I was banging a smoking hot woman, who to be fair is a little slow, and I found the keys to a Porche at the bottom of her vagina.

Re:thinking about something new? think again (1)

sg_oneill (159032) | more than 7 years ago | (#20719033)

Seaside would change the world, if only it had better support for templating.

Continuation-passing style web coding. *drool*

Yeah, the One True Way (2, Insightful)

Colin Smith (2679) | more than 7 years ago | (#20718769)


sad (2, Interesting)

m2943 (1140797) | more than 7 years ago | (#20718779)

You know, the sad thing about all the comparisons you make is that they are all choices between bad technologies. Assembler vs. PL/I, C vs. Java, Windows vs. Linux--they're all questions like whether you want to be drawn or quartered, drowned or burned, poisoned or starved. At each of those choice points, there were better technologies available.

As for PHP vs. Ruby, both technologies suck: except for minor differences in syntax and object model, they are naively designed and implemented. After decades of research in dynamic languages and OOP, it is a testament to widespread ignorance that people would produce and use something like that.

But if I have to work with bad technologies, the one that's more popular, more mature, and more widely supported one is, relatively speaking, better. That's why I prefer to be poisoned with PHP rather than starved by Ruby: poison is quicker and less painful.

Re:sad (1)

iBod (534920) | more than 7 years ago | (#20718917)

>>I prefer to be poisoned with PHP rather than starved by Ruby: poison is quicker and less painful.

Ha ha! My thinking exactly.

I feel you are correct in your assessment of these (and other) technologies that abound now.

They were designed by skilfull amateurs and enthusiastic students, who knew problem they needed to address, and addressed it pretty well, but without the benefit of deep technical knowledge and experience.

If everyone had waited for heavyweight pros to address the problem, we'd still be waiting, or be working with some horrible kludge (a camel is a horse designed by a committee etc.).

So viva PHP! and viva Ruby!

They aren't perfect, and nothing ever is, but they power a great deal of the web, very effectively and usefully.

Re:sad (1)

sg_oneill (159032) | more than 7 years ago | (#20719131)

Part of the problem is, if we are really objective about it, the lisp/scheme family of languages are probably about as close to 'well designed' perfect as we will get. Conceptually.

The problem with them is you pretty much have to unlearn so much of the ideas we take for granted in imperative languages, so much so, its been sugested your better off promoting scheme by teaching it to children then causing experienced programmers mind haemorages.

Even Haskell might be a candidate, but holy fucking shit will I never get used to some of its ideas. Algebraic values that don't change, totally non imperative, monads, and .... aaahhh my brains on fire again.

Because of this, I'll stick with my beloved python and hope one day, just one day, it catches on that I'll regularly get employment doing it.

Re:sad (1)

iBod (534920) | more than 7 years ago | (#20719327)

>>Because of this, I'll stick with my beloved python and hope one day, just one day, it catches on that I'll regularly get employment doing it.

Good philosophical viewpoint there.

Agree about lisp etc in terms of purity and elegance but a successful language must not place purist impediments in the way of the majority of potential users.

PHP succeeds like it does because it is a readily-understandable, practical tool, and it's easy to apply PHP to the problem in hand. Python is great in certain problem domains but doesn't have the sheer 'applicability' of PHP.

Fond memories of PL/1 (1)

istartedi (132515) | more than 7 years ago | (#20719019)

Late in high school, some geek friends asked if I wanted to attend a course in PL/1 with them. I thought about it for a day or so, and came to the conclusion that by the time I got to the end of college and was out in the working world, PL/1 might be history. Then, when I got out into the working world I could learn whatever specific language I had to learn. I didn't take the course.

I'm not saying I call it right all the time. I was really skeptical about Java when it first came out, and it seems to have had a lot more staying power than I ever thought it would. OTOH, not only have I not had to code in PL/1, I've never even been at a company that was maintaining it.

Planning is key. (2, Insightful)

djsmiley (752149) | more than 7 years ago | (#20718599)

You dont choose a project for a language, but a language for a project.

Heyho I didn't read the artical but if i've learnt anything (hahah like hell i have), then its planning is key. Plan your project and find a language that works, not the other way around.

Re:Planning is key. (1, Insightful)

Anonymous Coward | more than 7 years ago | (#20718829)

I often hear other managers go on and on about planning. I think they're full of shit.

It makes little sense to sit down and think through an entire non-trivial project, especially when it involves a new technology that you and the developers know relatively little about. You'll surely run into technological roadblocks that there really isn't an effective way around, unless you throw out a lot of the code you've already written. So now you're not only rewriting your code, but you also wasted a long time planning that which you now cannot do.

So the only solution is to be able to manage change effectively, and swiftly. Do a minimum amount of planning, and then get to work solving the problems that you will not have anticipated during your planning sessions.

Languages are just tools (3, Insightful)

Monoman (8745) | more than 7 years ago | (#20718603)

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.

Re:Languages are just tools (2, Funny)

CRCulver (715279) | more than 7 years ago | (#20718621)

But if all my l337 friends are using a screwdriver to pound in a nail, doesn't that mean I'm obliged to follow them?

Only one way to learn... (1)

Gazzonyx (982402) | more than 7 years ago | (#20719307)

But if all my l337 friends are using a screwdriver to pound in a nail, doesn't that mean I'm obliged to follow them?
"Yes, yes, please, by all means..."
*stands around whistling, tapping foot and checking watch every few minutes*

"Ah, back already? That's a mighty nice cast you're sporting there! Now, what did you learn? And, what are you going to do next time your 1337 friends have a bright idea?"

Re:Languages are just tools (4, Insightful)

Jeff DeMaagd (2015) | more than 7 years ago | (#20718641)

The problem I have with the "languages are just tools" adage is that they are about the most complex tools one can use, I mean hammers and screwdrivers have nothing on them. What might undo a project might be because of an obscure limitation of the language that wasn't known at the time of designing the project.

That said, I don't know much about Ruby or Rails, but I've heard that you have to follow the conventions or you're just making things hard. You can just not follow conventions, but it's just adding another pile of problems that defeat the point of using Rails.

What an idiot (4, Insightful)

Anonymous Coward | more than 7 years ago | (#20718617)

"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!"

7 Reasons? (0)

Anonymous Coward | more than 7 years ago | (#20718629)

why 7 reasons? seems like there was 1 -- I like PHP. after looking at the two languages, the guy learned a bit about OOP and applied it to PHP because he had previous experience with PHP and was productive with it.

how is this news?

Very uninformative article (4, Insightful)

DaleGlass (1068434) | more than 7 years ago | (#20718631)

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.

#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.

Re:Very uninformative article (1)

originalnih (709470) | more than 7 years ago | (#20718659)

I think Ruby and RoR are both arse. That won't stop me from pointing out that his 'beautiful' website with its MVC and templating lookse like arse too.

This is why I got out of web development. It's arse all around.

Re:Very uninformative article (0)

Anonymous Coward | more than 7 years ago | (#20718999)

I think you miss the point. It's not a critique of Ruby as a language but of Ruby On Rails as a platform. I agree that Ruby-the-language is not worse than PHP-the-language (probably even better in many respects) but Ruby On Rails as a web development platform is way different from PHP (especially since PHP doesn't really provide much of a platform out of the box; you have to build it yourself). And as the author noted, the rigid structure that Ruby On Rails tries to enforce gets in your way when trying to accomplish your goals, which is much more important than the imperfections that PHP had.

I think Ruby On Rails is a lot like Visual Basic: great for rapid development of some standard applications and to hide the complexity of the internal workings of a web application, but if you have special needs it just doesn't cut it and you need a more low-level tool.

Re:Very uninformative article (3, Insightful)

discord5 (798235) | more than 7 years ago | (#20719013)

I have to agree with you. I've been through a few webprojects in perl, php, rails and struts. Perl is my favorite, but that has largely to do with the jobs I had to do in the past, and it's certainly not the only language to get to a solution.

The only thing that I'd have to agree with is that Rails does take up a bit more resources than the average PHP application (#4), but rails like any other framework does allow you access to your database. It's very well documented in Agile Web Development on Rails [] (not being paid, just giving an example I know of) where they introduce Active Record, and there's an small section on the subject itself. I'm pretty sure it's somwhere in the API reference as well.

Some languages are more suited than others for a certain project, so it's perhaps more important to do a proper analysis of what you want to achieve and what languages will help you most to achieve those goals. The author offers very little detail into what exactly went wrong with his project, except that it didn't go as smooth as planned (welcome to the 90% of all projects, pull up a chair and have a drink).

Finally, even though the article mentions he hired a programmer, it's often wise when learning a new language/API/tool to start with a small application so you'll get a firmer grasp on it. That way you'll get a better feel for possible trouble ahead. Sure, we don't all have the time to do that, but in that case it's often better to stick to what you know and what works for you instead of blindly charging forth and trying to ride the latest wave of technology buzzwords. Not that I'm saying that RoR is just a buzzword (it's pretty neat actually), but don't use it because it's hip. Use it because it solves a problem more easily than another language/framework.

Sensationalist without a clue (1, Insightful)

James Kilton (714163) | more than 7 years ago | (#20718633)

His only valid complaint was integration.

Why the hell would you take a system written entirely in PHP and add to it / rewrite some of it in a different technology?

I love Rails, and if I have my way I will never touch PHP again. But if I join a company who's intranet is all PHP, then by golly I'm going to use PHP!

This guy is a sensationalist and not worth the attention.

article: -1, troll (4, Interesting)

Verte (1053342) | more than 7 years ago | (#20718635)

New article summary:
  1. I still have to program it
  2. We already knew PHP
  3. Rails has features I didn't use
  4. Rails has too many features
  5. I didn't really want to change my thought process
  6. I like my way of doing things
  7. How I justified trying something new.
I'm not saying that these aren't valid- save 1 and 3, maybe. But they aren't new, and aren't interesting.

Re:article: -1, troll (1)

Goaway (82658) | more than 7 years ago | (#20718671)

4 is spot on. Ruby is slow. It has nothing to do with features, and everything to do with having a weak language implementation.

whoops (1)

Verte (1053342) | more than 7 years ago | (#20718745)

clearly, I am also slow.

Re:article: -1, troll (2, Informative)

z_gringo (452163) | more than 7 years ago | (#20718717)

He actually says the exact opposite of most of your points.

He had one of the best rails programmers there was. It wasn't a problem with not knowing rails. He still wasn't finished after 2 years. He could accomplish the same thing faster in PHP.

He specifically said that using and learning Rails helped him change his thought process for the better.

Re:article: -1, troll (1)

Verte (1053342) | more than 7 years ago | (#20718839)

Have you ever seen a C programmers' Python code? Or a LISP application ported to Java?

Re:article: -1, troll (1)

Cl1mh4224rd (265427) | more than 7 years ago | (#20718955)

Have you ever seen a C programmers' Python code? Or a LISP application ported to Java?

Are you even paying attention? Once again, the guy hired one of the best Ruby programmers out there to do the rewrite. He didn't try to do it himself. Your point is irrelevant.

Re:article: -1, troll (1)

Verte (1053342) | more than 7 years ago | (#20719119)

You're missing the point. It's not about programming, not even about language. It's about thinking. It doesn't matter how good at Ruby you are when you're making, essentially, a PHP+MySQL application in Rails. What matters is that you have engineered your site holistically as a Rails site. Maybe I oversimplified. The thing is, all that structure only works when you work with the paradigm. I don't doubt that the author of the article tried somewhat, having made a decision to move to Ruby. But the feeling from the article is that he didn't reorganise the site as a Ruby site- the designer, not the programmer, didn't think in terms of Rails.

He was incompetent...! (3, Interesting)

bogaboga (793279) | more than 7 years ago | (#20718643)

Two years later, through blood and sweat, the project was then canceled because of limitations of Rails.

While I do not doubt the hired programmers coding skills, I am afraid he was incompetent at planning.

It's like choosing ISAM as the DB engine in MySQL instead if InnoDB then expecting to implement [referential] integrity using your own code.

The fact that it took two years to realize imminent failure disturbs my mind. The worst thing is that this coder might have been an Open Source enthusiast that I'd expect to know better.

I am afraid no home work was done or whatever home work was done, it not good enough. The results speak for themselves.

Re:He was incompetent...! (1)

Blackknight (25168) | more than 7 years ago | (#20718819)

Speaking of SQL, just use PostgreSQL and you don't have to worry about stuff like that.

Re:He was incompetent...! (1)

bogaboga (793279) | more than 7 years ago | (#20718873)

For PostgreSQL, I am still searching for a decent programmable GUI. Never found one! The Web based ones found in products like Webmin et al just do basic stuff. Think of Microsoft's Access which is a GUI to its JET database engine. Know of any?

Navicat (1)

Tteddo (543485) | more than 7 years ago | (#20719123)

I use Navicat for MySQL and I really like it. They make a PostgreSQL version too []

Re:He was incompetent...! (1)

Blackknight (25168) | more than 7 years ago | (#20719161)

PHPPgAdmin, it's similar to phpMyAdmin. I believe ODBC is also supported so you could even use Access (yuck) as a frontend. []

Re:He was incompetent...! (1)

cpaalman (696554) | more than 7 years ago | (#20718995)

An Open Source enthusiast does not imply the person is an experienced coder.

To that end I suspect that non-open source coders can suffer from the same dilemma, or that they could be well versed in picking the most appropriate language for developing a non-open source project.

I agree with your other points, failure to match project expectations with language capabilities is a sure way to a projects eventual demise.

Sigh (0)

Anonymous Coward | more than 7 years ago | (#20718647)

The good old "Hmm, what do we need for this?" "Alright, let's take a look at our demands here." blah blah instead of some old fashioned Just do it(tm). What a waste.

The guy also mentions in his blog that his project/creation comprises 100,000 lines of source code, which I find infinitely hilarious. Perhaps someone with his "talent" should leave the programming in the hands of people who know how to get things done properly. (His American style of getting things done vs the European's way of programming)

Also dumping python for PHP (1)

z_gringo (452163) | more than 7 years ago | (#20718681)

I can totally relate to this guy. I am going through something very similar, ableit on a slightly smaller scale.

We put a key system in Python a while back. After dealing with it for over a year, we are also going back to PHP. Everything else in the company is PHP. It just doesn't make sense to have this one Python. We can customize and improve the PHP a lot faster than the python.

Misleading summary (4, Insightful)

Craig Maloney (1104) | more than 7 years ago | (#20718701)

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.

Re:Misleading summary (2, Informative)

chdig (1050302) | more than 7 years ago | (#20719137)

He appreciated Ruby, brought back some programming concepts to PHP, and used them. The concepts and clear flow of programming in Ruby are great, emphasizing MVC and separation of code, and can be used in PHP too (which is something most people for some reason think isn't possible).

This article is interesting (and more than just fanboi talk) because it dispels some key myths about both Ruby and PHP -- all 7 points fall into two categories:
a) PHP can do it just as well or better.
b) PHP doesn't force the programmer into one way of programming -- rather, he can do things his own way (use SQL statements, program the way he likes).

I find his point 5 is the key here, and why many of us love our PHP:

I don't need to adapt my ways to Rails. I tell PHP exactly what I want to do, the way I want to do it, and it doesn't complain.
PHP exposes more of the guts of the language to the programmer. It's easier to make messy code, to leave security vulnerabilities, to have duplication, and to be inefficient in coding. But while this is true, it's also the kind of FUD that this article tackles. The author even wrote that he believed PHP was a bad language for years before returning to it, employing good programming concepts and realizing that it was the most powerful option available.

With the amount of PHP FUD we see on /., it's nice to see a counterpoint

He makes good points, but (1)

FooBarWidget (556006) | more than 7 years ago | (#20718707)

...some of his reasons are just nonsense.

I might as well ask the opposite: is there anything PHP can do that Rails can't? Nope. PHP doesn't give me any reason to switch back from Rails. This entire argument doesn't mean anything.

It's the "not invented here" syndrome. "I didn't write it, so I don't want it, I want to use everything I wrote myself." A pretty weak argument.
I don't know the entire Rails core either. Nor do I have to. I use what I need, and that's it. Everything in Rails that I don't need, doesn't get in my way.

This statement is pretty meaningless without providing website statistics. How many visitors does he have per day?

"#6 - I LOVE SQL"
This is purely a personal thing. I like SQL for complex queries, but for simple CRUD operations on records, why should I have to type the same boilerplate code over and over and over and over again? It's much simpler to type

user = = params[:name]
than to type

$db->execute(sprintf("INSERT INTO users VALUES(NULL, %s)", $db->quote($_GET['user'])))
The former is easier to read and easier to write.

I really don't understand what he's trying to argue here.

#2 is actually a valid point, but this isn't really Rail's fault. I can't argue to #5 as that's purely subjective.

Re:He makes good points, but (1)

modmans2ndcoming (929661) | more than 7 years ago | (#20718851)

why are you typing boiler plate code over and over again? have you ever heard of a functions and classes?

Re:He makes good points, but (1)

FooBarWidget (556006) | more than 7 years ago | (#20718915)

Yes I have. But those functions and classes *are* the boilerplate code. Why should I have to write them manually?

Re:He makes good points, but (2, Insightful)

bryanthompson (627923) | more than 7 years ago | (#20718853)

About your point #6, not only is it easier, but it is easier to add onto later. When you use SQL to create objects, you have to go back to whatever line of code you used to do your insert command and adjust the fields. In Rails, you just run a migration to add a field to the table, then modify your form to add that extra field.

And, I think you're pretty much right on about his other "points." The slashdot summary of his post is entirely misleading and total flamebait--and not written by him. I think the guy is just inexperienced and crawled back to PHP out of a lack of wanting to change his mindset. He does in the end give Rails some credit for introducing him to a logical MVC structure, and I doubt he meant to flame Rails. He just happened to make mostly subjective and uninformed points to justify going back to what he already knew... I'm guessing he named his post "7 reasons..." before actually counting the reasons. Blogging is teh hard :p

Re:He makes good points, but (1)

hattig (47930) | more than 7 years ago | (#20718901)

I think that using Rails taught him about OO programming, and then he went back to PHP and used OO programming there. I wouldn't be surprised to hear that there were huge blocks of duplicate code to do stuff that could have been in an object.

#6 is interesting, because it's more that he doesn't trust Rails to get the SQL right. However it sounds like he would have had a User object in PHP (I don't "do" PHP, thank fuck, so excuse any incorrect structure) and indeed can write in the main part of the code:

$u = new User();
$u->setLastName("Marley"); ...

and he's probably moved all the SQL code into the objects (e.g., persist(), getByUsername(), etc), indeed he mentions using a simplistic pattern to do that (thus not separating the model from the controller, but I digress). I bet the 100,000 line website has SQL splattered all over it, duplicated everywhere, I remember my first Perl website and it was ass in this respect, although reasonably structured otherwise. Now he has a 12,000 line website that probably just duplicated the previous one. No advancement in the website itself, and look at it, it's rather basic. I can't see why it couldn't be implemented in RoR quite quickly myself. I estimate a month or two for a mod_perl version once back up to speed.

I will admit I've had similar issues with heavyweight frameworks in Java, such as JPOX/JDO which clearly has a lot of good technology in it, but lost the vision of what it was meant to be, and thus you'd end up with the same amount of less legible code to do stuff as writing the prepared statements and supporting code yourself. Add to that unexpected behaviour when extracting nested objects via JDO, and you had a stress-fest. Never again! No more setMaxFetchDepth() then getting exceptions trying to access those nested objects past the JDO stage *blubber*.

Re:He makes good points, but (0)

Anonymous Coward | more than 7 years ago | (#20718935)

"#1 - "IS THERE ANYTHING RAILS/RUBY CAN DO THAT PHP CAN'T DO? ... (thinking)... NO."" I might as well ask the opposite: is there anything PHP can do that Rails can't? Nope. PHP doesn't give me any reason to switch back from Rails. This entire argument doesn't mean anything.

Well, it might be a reference to the people who treat Ruby like it was the second coming of Christ. It is a (very good) web framework, not the one true way to web salvation. You need a positive reason to use the technology, not "I need a Rails website because it's Web 2.0-tastic".

"#3 - DON'T WANT WHAT I DON'T NEED" It's the "not invented here" syndrome. "I didn't write it, so I don't want it, I want to use everything I wrote myself." A pretty weak argument. I don't know the entire Rails core either. Nor do I have to. I use what I need, and that's it. Everything in Rails that I don't need, doesn't get in my way.

Well, the larger the system the harder it is going to be to understand. This is pretty inevitable. I find with large complex systems there is often a gap between the (often very good) tutorials that do "Hello, World" style stuff and the full documentation which consists of 1000+ method, function and class descriptions which refer to each other in the descriptions.

"#6 - I LOVE SQL" This is purely a personal thing. I like SQL for complex queries, but for simple CRUD operations on records, why should I have to type the same boilerplate code over and over and over and over again? It's much simpler to type

user = = params[:name]
than to type

$db->execute(sprintf("INSERT INTO users VALUES(NULL, %s)", $db->quote($_GET['user'])))
The former is easier to read and easier to write.

This may be because you are doing store-and-retrieve only, for which I agree SQL is overkill. However many people with databases need to do complex relational algebra which becomes very clunky when you are using a programming language and not a dedicated relational algebra declarative language such as SQL. Expressing transactions is also difficult - the abstraction becomes 'leaky'.

"#7 - PROGRAMMING LANGUAGES ARE LIKE GIRLFRIENDS: THE NEW ONE IS BETTER BECAUSE *YOU* ARE BETTER" I really don't understand what he's trying to argue here.

He is suggesting that the experience of understanding what Ruby and Rails were trying to do helped him become a better programmer in general, even though he ended up going back to PHP.

Re:He makes good points, but (1)

FooBarWidget (556006) | more than 7 years ago | (#20719045)

"This may be because you are doing store-and-retrieve only, for which I agree SQL is overkill. However many people with databases need to do complex relational algebra which becomes very clunky when you are using a programming language and not a dedicated relational algebra declarative language such as SQL."

That is true, but in most web applications most database actions are of the "store and retrieve records" type. For everything else, Rails doesn't prevent you from writing SQL. Indeed, most of my websites have some SQL-based finder methods in the models, usually for querying aggregate information. I've never had to write SQL manually when saving stuff though.

"Expressing transactions is also difficult - the abstraction becomes 'leaky'."
Not with Rails though:

BankAccount.transaction do
    account1 = BankAccount.find_by_name('Joe')
    account2 = BankAccount.find_by_name('Jane')
    account1.amount -= 100
    account2.amount += 100!!
    BankAccount.transaction do
...more database actions here, for nested transactions...
If an exception is thrown within the toplevel 'do' block, then the entire transaction is aborted with a 'ROLLBACK'.

Re:He makes good points, but (0)

Anonymous Coward | more than 7 years ago | (#20719353)

Oh I agree, I'm not trying to spread FUD about Rails not being able to do things - it is very comprehensive and a great deal of careful thought has been put into it.

The code you have written is certainly very clear - it is a good example of how great Rails can be. However it is not really Object-Oriented, is it? You've lost the abstraction of persistent objects floating in the ether and are basically writing imperative-style code. That's what I meant by "leaky abstraction".

This is not a bad thing necessarily - I can't think of an obvious OO way to deal with the issue, and I prefer the appearance of the Ruby code to the equivalent SQL. However where you are writing an application that is data and query driven the object-relational mapper provides you with little benefit. A more direct approach in those circumstances might be a clearer map to the problem domain, even though it might look uglier.

That's not to say that the great majority of web development wouldn't be better off to focus on RoR's rapid development and wide feature set, just that there are times when a direct approach is not necessarily an indication of "NIH syndrome" or incompetence.

Re:He makes good points, but (0)

Anonymous Coward | more than 7 years ago | (#20719317)

...nevermind that you can write raw SQL into rails if you really want to...

Re:He makes good points, but (1)

The Living Fractal (162153) | more than 7 years ago | (#20719325)

Uhm. yea.

There's no reason you couldn't write a very quick PHP function to do basically what you showed with the three Rails lines. In fact, you you could do it all in one line...

But, whatever.

Initiation ... (1)

ValiSystem (845610) | more than 7 years ago | (#20718747)

Think again ? no ! rush into rails learn how a good framework is built, and apply it to whatever technology you use. This is how i work, and it goes very well.

Derek admits it at the end of TFA, too bashfully. But i don't see any shame in having to go through rails to know how to write good php code.

Why do people keep comparing languages with API's? (1)

Jugalator (259273) | more than 7 years ago | (#20718751)

Maybe he will like Ruby better than Rails? I heard that Ruby has less cruft that he disliked than Rails.

This is getting ridiculous.

Re:Why do people keep comparing languages with API (1)

Shados (741919) | more than 7 years ago | (#20719217)

Because we're not in 1985 anymore. In this day and age, languages are often (almost) exclusively selected depending on the APIs they offer. Not completly, but... Even if you're thinking about performance, that often even depends almost completly on the API you'll be using...

Languages are becoming more and more cosmetics, its all in the API.

Article doesn't make sense (1)

Blackknight (25168) | more than 7 years ago | (#20718797)

So rails sucks because you don't know how to use it? This article could apply to any language. Thinking about PHP? Think again, perl doesn't everything PHP can do and then some.

When you're writing a project you need to look at what your existing code base uses and choose something that integrates with it, or just stick with what you know. Every application our company uses is written in perl and they run great, HTML::Mason makes it a lot like PHP any way.

% print "Hello world!" isn't much different from

<?php echo "Hello world!"; ?>

framework != language (2, Insightful)

BestNicksRTaken (582194) | more than 7 years ago | (#20718825)

thats because rails is a web FRAMEWORK not a programming language - you know RUBY is underneath it all, right?

people get too tied up with cms's that they think will do everything. code a plugin yourself (assuming a decent api is available).

Beautiful code (1)

August Lilleaas (1111117) | more than 7 years ago | (#20718835)

To me, Rails is about beautiful code. At my level of app-making, I don't need huge performance and blah and blerg. All i care about is nice looking and agile code, really.

But, of course, we all need to be told that apples is better than bananas.

Re:Beautiful code (1)

betterunixthanunix (980855) | more than 7 years ago | (#20719093)

Well, it really depends on what you are trying to do. Personally speaking, if I were designing some sort of publicly accessible website, I would be looking at what will perform best under very heavy loads (and CGI programs running on a system with highly optimized forking win on this, in my opinion. And apparently in the Slashdot maintainers' opinions, since this website is coded in PERL). If you are coding something for an internal intranet in a medium sized corporation, you might have a bit more flexibility, and can get away with a heavier framework to make your life easier.

Then again, I advocate writing web apps in C++ or Ada, so you might be inclined to accuse me of being 20 years behind the times. I'll say this: if you can handle the formal design process, a C++ web app is no problem at all.

Why did he do it in the first place? (1)

roman_mir (125474) | more than 7 years ago | (#20718867)

The guy says he's got a company with many people already using PHP and all the systems being coded that way. It is only logical to continue with PHP and gradually improve the systems. Whether it makes sense to use Rails for any new projects remains a question. Why Rails anyway? But the reality is that if there is a team and they are familiar and proficient with a technology, then switching this technology to another one is tricky and risky. Are there any reasons for it in the first place?

There is no silver bullet. Many people believe that any new tech IS the silver bullet, in this case it's the Rails. But the reality is that at the end of it there will be the same mess in the code and the team will have to learn everything from scratch and then, once lots of code is done in Rails there will be yet another 'newest/greatest/shiny' thing that will come alone and will move Rails to the second shiny place.

The only thing that makes sense in any kind of situation is to find a suitable technology that works and stick to it, making sure that the team become familiar with it and once everyone is familiar and there are standards that are followed, the solutions will be created that will work. Then the real question will remain, just like it always remains: What are the business requirements?


Basically (0)

Anonymous Coward | more than 7 years ago | (#20718869)

The guy rewrote his code properly. It scares me when people make claims like "all business logic and HTML is separate". Of course it's separate, unless the author(s) of the code are hopelessly incompetent.

The guy says he 'loves SQL' but actually mixing SQL and PHP in your business logic is a necessary evil. I hate SQL and consider it bad form to mix it with application code. Active record and friends are attempts to closer map databases to the application language. A noble goal that ends up adding significant overhead and being less expressive than SQL. I've also experimented with automated query generation and concluded that anything above basic SELECT generation is impractical.

As for RAILS (which I don't like), the same criticisms could be equally applied to countless PHP frameworks. My custom framework now consists of a class loader and 3 - 4 supporting libs. There's nothing to enforce MVC or dictate how the framework is used because that itself ends up being limiting.

(I'm the author of the article) - Please read: (5, Informative)

linuxbaby (124641) | more than 7 years ago | (#20718897)

Hey gang -

Longtime Slashdot reader, surprised to find my little personal blog post on Slashdot today, especially since the lead-in description framed it with the completely wrong point.

I never said "the project was cancelled because of limitations of Rails" - more like I spent two years trying to make Rails do something it wasn't meant to do, then realized my old abandoned language (PHP, in my case) would do just fine if approached with my new Rails-gained wisdom.

That's all.

Re:(I'm the author of the article) - Please read: (1)

Bodhidharma (22913) | more than 7 years ago | (#20718951)

I understand the temptation to try something new. I've wanted to do something in Rails but haven't had the time. Also, I've grown suspicious of frameworks in general. A lot of people swear by Struts, Spring, Rails, Grails, etc. I think frameworks can make easy things dead simple but hard things almost impossible. I do all my web apps as hand rolled MVC using servlets and JSPs. I've never coded myself into a corner with that.

Re:(I'm the author of the article) - Please read: (0)

Anonymous Coward | more than 7 years ago | (#20718969)

You're serving XHTML 1.1 as text/html to IE, IIRC the specs say you "MUST NOT" serve xhtml 1.1 as text/html. If you want to do this you should switch the doctype to XHTML 1.0 strict. You should also be sending a Vary header to indicate you're serving different content based on the clients accept string.

Love the basic HTML layout though, a brave choice for a music site ;-)

Re:(I'm the author of the article) - Please read: (1)

meekers (1105157) | more than 7 years ago | (#20719225)

I presume that they are serving XHTML as text/html to Internet Explorer since application/xhtml+xml does not work correctly in it. Your recommendations seem reasonable otherwise unless there is something that forces them to use XHTML 1.1 rather than XHTML 1.0. I should note that according to [] , serving XHTML 1.1 as text/html is a "SHOULD NOT" rather than a "MUST NOT", so they can continue to serve the document as text/html without breaking standards outright.

Re:(I'm the author of the article) - Please read: (1)

z_gringo (452163) | more than 7 years ago | (#20719001)

We with with python for some things a while back, and I am now putting those back into PHP, which is what everything else in the company is in. I think some of these were kind of trendy and were adopted sooner than they needed to be. I don't hate python either, but I think we are better off in PHP. I had recently heard a few people saying that PHP is obsolete or whatever, but I don't think it is going anywhere anytime soon.

Re:(I'm the author of the article) - Please read: (2, Funny)

Gnavpot (708731) | more than 7 years ago | (#20719037)

surprised to find my little personal blog post on Slashdot today, especially since the lead-in description framed it with the completely wrong point

I am very tempted to use the "You must be new here" /. joke.

Slashdot summaries are always written like this. I don't know if the editors/submitters do not understand the point of the article they are linking to, or if said editors/submitters are so biased that they want to prove another point, using that article.

Re:(I'm the author of the article) - Please read: (3, Insightful)

icepick72 (834363) | more than 7 years ago | (#20719099)

This whole debacle on Slashdot isn't a result of the lead-in description. Anybody who has commented on the 7 points has read the original article in its entirety (well, hopefully!). There are many good discussions occurring around your points, some favorable, some not, but it's all good in the end.

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?

Re:(I'm the author of the article) - Please read: (2, Insightful)

icepick72 (834363) | more than 7 years ago | (#20719331)

Hey, if Jeremy Kemper is one of the best, did he raise any warning flags along the way? Do you think he could have curbed the end effect given his high level of expertise?

Given that your O'Reilly Biography describes you as "Still a relative newbie among programmers, he'd appreciate any tips and advice you could give him", why is it you could pull off CDBaby in 2 months in PHP while an expert Rails programmers, including yourself as a second person on the project, could not pull it off on 2 years?

The project doesn't seem that large after all. Had Jeremy worked on comparably large Rails projects before? If so, had he experienced the same problems before. Did he flag them to you?
I'm not trying to lay blame. I have managed projects and seen the good, the bad and ugly and am always interested in getting the full story, from all the people involved, all opinions. Goodness knows I've pulled some doozies in my day that I'm embarrassed about.

Re:(I'm the author of the article) - Please read: (1, Insightful)

Anonymous Coward | more than 7 years ago | (#20719349)

I'd also like to hear more details about what exactly was so hard in rails. I reckon that's the most useful information.

If someone else is starting a project and considering rails this information might help them make their decision. San we heard more about what exactly was really hard to do in rails?

Re:(I'm the author of the article) - Please read: (1)

seriousthought (832712) | more than 7 years ago | (#20719345)

The problem with your article is that you claim that you spent 2 years trying to make Rails do something it wasn't meant to do... and then you don't actually explain what it was that it wasn't meant to do. It sounds like from clues later in the article that perhaps you tried to shoehorn Rails ontop of your preexisting database which meant that all your table names, were not the correct format/naming scheme.

Lame (1)

Synn (6288) | more than 7 years ago | (#20718911)

His reasons are pretty lame.

The biggest issue I'm having with rails is its lack of scaling due to a horrid threading model. We run mongrel, which can accept multiple requests per mongrel but only process one at a time due to Rails not being thread safe. So you end up having to run many many instances of mongrel on seperate ports to accept incoming requests. This wouldn't bo so bad, but the preferred methods of sending traffic to these mongrels(apache mod_proxy_balancer is what we use) have NO idea what the back end mongrels are doing. It'll happily send requests to busy mongrels when you have free ones doing absolutely nothing.

hmmm (1)

Vexorian (959249) | more than 7 years ago | (#20718939)

I prefer PHP, but this sounds too FUDish to support... (0, Interesting)

Anonymous Coward | more than 7 years ago | (#20718945)

Am I the only one that's noticed that the site in question is pretty damn ugly and seems kinda primitive?

Programmer vs language (1)

icepick72 (834363) | more than 7 years ago | (#20718957)

I think his #6 point about Rails is most telling:

#6 - I LOVE SQL Speaking of tastes: tiny but important thing : I love SQL. I dream in queries. I think in tables. I was always fighting against Rails and its migrations hiding my beloved SQL from me.

Sounds like this guy dropped back to his default mode of putting a lot of his eggs in the database layer, which is good for speed. Some programmers handle levels of abstraction better than others. If he were to reapply Ruby/Rails again in a few years he may find his point #7 works against himself because he will have grown as a programmer.

It would have been interesting had he listed technical more points of frustration. The high level of the article makes me think it's his own problem rather than any particular language -- he might not yet have the ability to conceptualize at a high enough level to understand the abstractions that Rails sits on. The source of frustration could be as simple as that.

Although he sounds convincing and said he hired one of the best Ruby programmers in the world the article is lacking substance/evidence/proof. If the hiree is one of the best, I wonder -- given his investment in Ruby/Rails -- what his take on the entire situation is right now? Where is he blogging about this? I'm sure he's not discarding Rails and his outlook on that situation might not be bleak. For all we know he might be frustrated because the the author could never get the damn concepts, kept complaining about his beloved PHP, etc. (Now somebody will link to an article where the hiree is proving me wrong -- which is great -- because I've been run once before and know what it feels like...)

The author argues that through Rail's faults he has learned which is a backhanded complement, decisively made, although he thinks it's true.

Article Does Not Make Much Sense (2, Insightful)

aldheorte (162967) | more than 7 years ago | (#20718989)

The article reads as a "I tried to use Rails without learning Rails or Ruby and gave up" story and then admits to using many of the Rails patterns in a home grown PHP solution. Well, obviously, if you are much more familiar with another language and refuse to learn the language underneath a framework, it will be hard to use that framework. Point by point:

1. There is nothing that PHP cannot do that Rails cannot do - Well of course, and there's nothing that any language can do that Common Lisp cannot do. Almost all languages implement a Turing machine and can be used to solve any computational problem. The question is code readability, syntactical sugar, and adaptability, all important concepts. Also, the community that has grown around it that builds a knowledge base and plugins and libraries.

2. Their entire company worked on PHP and integration was difficult - Sounds like they didn't understand RPC and services models. Sharing between different languages and platforms is an unfortunate fact of life. Also, it sounds like PHP was the problem here, not Rails, if interoperation was such a problem. "Interoperation" in the article is used oddly - it's actually more about transition to a new site, which has nothing to with the platform used and, if is such a heinous problem, is a problem with design of the new app.

3. Didn't need 90% of Rails - Then why use it? Also, using a tenth of something is not an argument against it if it still the best tool for the job you are doing.

4. The custom solution they jury rigged is "small and fast" - Many Rails apps are small and fast - there's no statistics or analysis here for comparison.

5. The PHP custom app was built for to their tastes - Obviously. If you write a custom app it will miraculously suit your preferences and will probably be a very good solution to your problem. Custom apps if you can do them are often a good idea, keeping in mind the downside is that you don't have a community of knowledge, don't get patches for free, etc..

6. He loves SQL - Fine, don't use ActiveRecord then. Or use ActiveRecord and make direct SQL calls. This goes against common wisdom, of course, regardless of platform, but if you really want to do it, it's there.

7. Programming languages are like girlfriends? - No idea.

The bottom line is that there are criticisms you can level at Rails or any language or framework. However, you actually have to bring facts and analysis to an argument, and this article offers neither.

Re:Article Does Not Make Much Sense (1)

perbu (624267) | more than 7 years ago | (#20719295)

I tried to use Rails without learning Rails or Ruby and gave up

He did hire bitsweat - which is a rails core committer. You are trolling, aren't you?

Yeah, well. (1)

stonecypher (118140) | more than 7 years ago | (#20719055)

Don't get me wrong - I'm no fan of Ruby. That said, Derek Sivers doesn't really say anything about Ruby here, except to complain that he doesn't understand it, doesn't know the standard library very well, didn't want to retrain his existing PHP staff, and has finally discovered how little of a difference the underlying language makes. He also makes the point that learning something teaches him things elsewhere, which makes it sound like Ruby is maybe his third language or so; he seems genuinely surprised that lessons learned in Language 1 carry on to Language 2. Next, he exposes his naïveté by calling PHP fast, and finally he cites his love of SQL as if it somehow has bearing in PHP vs Ruby.

Way to go, Derek, you're becoming less of a noob today. How it is that you got onto Slashdot with that little diary note is beyond me.

Re:Yeah, well. (0)

Anonymous Coward | more than 7 years ago | (#20719171)

Next, he exposes his naïveté by calling PHP fast,

Compared to ruby it is [] and with an opcode cache PHP performs much better. The bottleneck for a web app is always going to be database queries.

not just PHP/Rails (1)

kisrael (134664) | more than 7 years ago | (#20719167)

I see some similar things when I look at a variety of Java toolkits, some offering very OO "you can pretend you're a swing app and ignore the HTTPRequest cycle"

I worry that a decade of homebrew Perl CGI has warped my brain, but frankly, HashMaps wrapping HTTP Request parameters seems really natural to me, and if you use a Model2+ approach w/ servlet and JSP pairs, you're writing your business logic in Java, your HTML in HTML (well, JSP... and honestly, I don't think I've ever been on a team that manage to leverage real benefit from tricks to let you edit HTML in HTML editors, and make that round trip) your CSS in CSS, your Javascript in Javascript, etc etc.

I see the flow control stuff as glue language... directing a user from page to page just ISNT THAT HARD... and its the stuff that's tightly coupled to EVERYTHING, and so I long for that to be as simple and not-get-in-your-way as possible, so that you can spend your mental cycles thinking about the stuff that's actually doing the heavy lifting.

Lots of toolkits offer lots of neat bells and whistles, but most really imply you need to learn the whole language and often new paradigm of thinking about flow control. And unlike APIs and things, your flow control tends not to be isolatable, so if you get something wrong, it's going to be harder to work your way out of. (And the more-OO-ish you get for flow control, the harder it'll be to make sense of your stacktrace, since the danger is that you screwed up something when establishing in your objects, not when the actual interaction was performed...)

On the other hand, I know I tend to be resistant to new core server technologies, unless they make a SUPER clear value proposition. So I'm worried I'm going to be some crazy old curmudgeon. Still, like in TFA, the guy took some good design lessons from the new language, and then stuck with what people really know, and that makes a lot of sense to me.

My next framework is Stripes (0)

Anonymous Coward | more than 7 years ago | (#20719239)

It's like Webwork/Struts 2, but without configuration files. []

reminds me of winston churchill quote (1)

bl8n8r (649187) | more than 7 years ago | (#20719251)

"I was nearly killing my company in the name of blindly insisting Rails was the answer to all questions, timeframes be damned."

      No folly is more costly than the folly of intolerant idealism -- winston churchill

Try CakePHP! (1)

mararual (1160663) | more than 7 years ago | (#20719259)

CakePHP ( [] ) is a framework with all the advantages of ruby on rails, but using PHP as it's language. So is a very good option for every PHP programmer who wants order, flexibility and ease of use, avoiding repetitive tasks such as CRUD and the use of helpers (i.e Html forms, Ajax) to increment productivity and maintenance. As stated on their website:
"Cake is a rapid development framework for PHP which uses commonly known design patterns like ActiveRecord, Association Data Mapping, Front Controller and MVC. Our primary goal is to provide a structured framework that enables PHP users at all levels to rapidly develop robust web applications, without any loss to flexibility."
For a nice introduction read the manual ( [] ) and try the 15 minute blog tutorial, and for scripts, plugins, and a lot of community code try the bakery ( [] ).
Any programmer that wants Rails' advantages combined with PHP's flexibility, documentation, server support should try this. Greetings

PHP!? Oh the humanity!... (1)

Cultural Sublimation (884893) | more than 7 years ago | (#20719319)

Ah, the title seemed promising: someone had come to the conclusion that there is a world outside of the Rails hype-machine. Perhaps they were telling us to look into the truly innovative frameworks, such as Lift [] (for the Scala [] language), or even Ocsigen [] (for the OCaml [] language). But no. They decided to go back to PHP!? I am confused: is this story about S&M fetishes?

I have been using Ocsigen myself for a few months now. It is based on OCaml, so it's very high-level while still being extremely fast (it can be compiled into native code, comparable in speed to C++). Moreover, OCaml has very strong types, and Ocsigen leverages that type-safety to ensure the produced markup will always be Xhtml compliant and that there are no inconsistencies or broken links within a website. Heck, you can even extend that type-safety into the database access, so there is no chance that you'll be processing data the wrong way. And best of all, all mistakes are detected at compile-time! It really is a pleasure to use...

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?