Restructured Ruby on Rails 3.0 Hits Beta

Curlsman informs us that the first beta of Ruby on Rails 3.0 has been released (release notes here). Rails founder David Heinemeier Hansson blogged that RoR 3.0 "feels lighter, more agile, and easier to understand." This release is the first the Merb team has participated in. Merb is a model-view-controller framework written in Ruby, and they joined the RoR development effort over a year ago. Reader Curlsman asks, "So, is version 3 of RoR going to be a big deal, more of the same (good or bad), or just churning technology?"

Comments

I think everyone would agree here...

[Anonymous Coward]

So, is version 3 of RoR going to be a big deal, more of the same (good or bad), or just churning technology?

How about, we don't care? Back in the day, Ruby on Rails promised that it will "kill developers" and CEO-s will be coding the sites themselves in Rails, the hype was THIS big. "Programmers obsolete??".

Soon after it turned out "real programmers" can't scale a Rails app to save their job (Twitter).

Your moment of marketing glory is over. Have the decency to go in a corner and die.

Re:I think everyone would agree here...

[k33l0r]

I've never heard that Rails would make "programmers obsolete", in fact it seems to be the opposite; if you look at the official Rails site you'll notice that the biggest tag-line is "optimized for developer happiness".

Rails makes developers happier, not unemployed. What's more, anyone can write bad code in any language, so pointing to Twitter is hardly a conclusive argument. There are lots of big Rails sites out there, including Basecamp, the original Rails application.

For a better (and longer) write up on scaling Rails, I refer you to this article.

Re:I think everyone would agree here...

[Anonymous Coward]

AC probably thinks the ruby part in "Ruby on Rails" is a gemstone.

Re:I think everyone would agree here...

[Anonymous Coward]

So, is version 3 of RoR going to be a big deal, more of the same (good or bad), or just churning technology?

How about, we don't care? Back in the day, Ruby on Rails promised that it will "kill developers" and CEO-s will be coding the sites themselves in Rails, the hype was THIS big. "Programmers obsolete??".

Soon after it turned out "real programmers" can't scale a Rails app to save their job (Twitter).

Your moment of marketing glory is over. Have the decency to go in a corner and die.

Just like Google, anybody saying one bad word against the slashbot groupthink that RoR is the second coming gets modded into oblivion. AC was just saying what many of us think, just like PHP RoR is a great language to write not-so-serious apps on. It's praises are sung by the same group that think MySQL is the ultimate enterprise database.

Re:I think everyone would agree here...

[HeronBlademaster]

It's praises are sung by the same group that think MySQL is the ultimate enterprise database.

Everyone knows the real ultimate enterprise database is Access.

Re:I think everyone would agree here...

[Anonymous Coward]

I've used Rails on five projects now. To be honest, I think it has made me more and more miserable with each project.

First, I truly dislike "convention over configuration". The main problem there is that they "convention" they use is far too limited for any sizable application. It may be sufficient for a blog web app, or a bug tracker, or small-scale applications like that. But we now have one web app with over 900 controllers, and "convention" falls apart at this size. Sure, we probably should refactor our app, but we're not in a position to do so at the moment.

The same goes for ActiveRecord. It's great in simple cases, but falls apart rapidly when you're developing larger web apps, especially when you're performing complex data retrieval. It gets even worse if you need to optimize that data retrieval. At this point, ActiveRecord becomes a huge pain in the ass, rather than a useful tool.

And like it or not, the performance of Ruby is quite poor. We actually had to purchase some additional hardware to handle the extra load after converting an old Java-based web app to Ruby on Rails. We tried to optimize it, but were spending far too much time fighting with Ruby on Rails and its abstractions. It was cheaper just to buy more hardware.

Re:I think everyone would agree here...

[Pengo]

It's a double-edged sword.

I've been involved with rails pretty extensively now for a few years, and i've enjoyed the platform for the most part. A few projects we've launched have grown pretty complex, and we too have had some problems with the code management, but discipline seems to help and a steady peer review.

Ive been working with Java pretty much exclusively since the late 90's, with exception of the last few years which have been focused on Rails projects. I've recently been working with Grails (Grails.org) which is a Java based stack taking the great concepts from RoR platform.

As someone who has never worked with Java, I believe that Grails might not be as easy to pickup and learn, but as someone who has an extensive Java background, it's a serious breath of fresh air. For a large scale project, I MUCH prefer grails code management to rails approach. Obviously with my Java background, i'm partial to Grails.

On the note of deployed code, a few of our rails projects have grown to be pretty large. I've had to implement a LOT of hardware to handle the scaling of usage. We've been able to do a lot of improvements to the code, but compared to the speed and efficiency of Java (Yeah, I never thought i'd say that) I'm a little bit 'burnt' on rails.

Comparing something like Passenger on Apache to Glassfish or Tomcat is like getting out of a 2009 BMW 5 series and jumping into a 1991 Kia.

The first time in YEARS i have had run-away processes take down an entire server, I've migrated all of our servers to Xen servers because i got tired of driving to the datacenter 1-2x a week or making a remote hands call to reboot a server because a zealous process took things down. (Did I mention i bought a load balancer to manage the traffic, i'm doing on 10 machines what i used to do on 3 machines w/my java apps)..

I'm sure that there are folks that know Rails better than I do, we're a do-everything group (4 guys managing a LOT of code and servers), not a large IT shop by any stretch, but on one hand we've hit epic levels of productivity. We've gotten projects out fast, and some of them have done well. We've had other projects we assumed would do great, but ended up failing due to marketing miscalculations. The lesson I'd say i've learned with Rails, is it's better to get a 'good enough' product out the door and then figure out how to tighten it down later than not even make it to the race.

I'm hoping that i can bypass that compromise with Grails, but time will tell. :)

Either way , Rails absolutely has it's place in the Open Source server software stack world. In the end it's just a matter of remembering that if you are doing rails programming, you better be doing it with a Test-Driven development style, as large projects can get out of control.

I've not looked at RoR 3.0, but i'm hoping that they have implemented a Service-style implementation for business logic, rather than encouraging to have it thrown into the Models.

Re:I think everyone would agree here...

[selven]

Nah, the real ultimate enterprise database is Google Spreadsheets.

Re:I think everyone would agree here...

[mgkimsal2]

I think the parent possibly could have used JRuby for Rails, getting to stay on the JVM platform they were already comfortable with. But perhaps when they considered it JRuby wasn't as mature as they needed it to be.

Even for someone without a lot of Java experience, Grails can be very productive. I prefer the 'domain first' approach Grails allows, rather than the 'database first' which Rails promotes. There's no 'right' answer, but I prefer the Grails way. I've had my fair share of headaches with Grails over the last couple of years, but I'm typically more productive with it than other platforms on many/most types of projects.

I've got some high hopes for Rails 3, from what I've heard from my Ruby-lovin' friends. There's apparently been a lot of refactoring at various levels, so speed and resource handling should be much improved. I'm expecting some backwards compatibility breakage, but I've nothing to base that on other than speculation - major version numbers are the best time to do those sorts of changes, if any are required.

Re:I think everyone would agree here...

[Big_Mamma]

The same goes for ActiveRecord. It's great in simple cases, but falls apart rapidly when you're developing larger web apps, especially when you're performing complex data retrieval. It gets even worse if you need to optimize that data retrieval. At this point, ActiveRecord becomes a huge pain in the ass, rather than a useful tool.

Hmm, can you explain why? I haven't worked with Rails much, but in Django, if things are too slow like in a really complex query spanning so many tables that the PostgreSQL optimizer chokes, you can hand optimize it easily by either rewriting how you specify it in python, breaking it up into multiple statements. You can also choose to retrieve the data as plain tuples or map/dicts if you need to fetch thousands of rows (100k+, I've no problem with 20k/query the normal way at all). If all fails, plain sql is just 2 statements away, with an easy way to turn the results back into objects.

A good ORM recognizes that there are situations that falls outside of the common/simple use cases and should assist you in the harder things, not work against you.

Re:I think everyone would agree here...

[SanityInAnarchy]

First, I truly dislike "convention over configuration". The main problem there is that they "convention" they use is far too limited for any sizable application. It may be sufficient for a blog web app, or a bug tracker, or small-scale applications like that. But we now have one web app with over 900 controllers, and "convention" falls apart at this size.

First, yes,

we probably should refactor our app, but we're not in a position to do so at the moment.

you should, and this would be biting you in the ass just as much with other technologies.

But keep in mind, "convention over configuration" is not "convention instead of configuration". The idea is that if you follow the conventions, things work better. If you need to go beyond them, you can still configure things.

The same goes for ActiveRecord. It's great in simple cases, but falls apart rapidly when you're developing larger web apps, especially when you're performing complex data retrieval.

For what it's worth, I prefer Datamapper. I don't have especially bad memories of ActiveRecord, though -- but I probably wasn't doing especially complex queries.

But note, again, it's about convention over configuration. Nothing's stopping you from hand-coding raw SQL, or even going entirely around ActiveRecord in the few cases where you actually need that. The other lesson is, of course, that if your queries are your bottleneck, there are probably other tricks you could be doing, like memcached.

And like it or not, the performance of Ruby is quite poor. We actually had to purchase some additional hardware to handle the extra load after converting an old Java-based web app to Ruby on Rails.... It was cheaper just to buy more hardware.

That's part of the point of Rails, though. It usually is cheaper to buy more hardware than to optimize, Ruby just forces you to face that up front.

Sure, sometimes you can change your algorithm from O(n^2) to O(logn) and get a massive speedup, and it's worth it when you can do that. But an extra 5-10% likely isn't worth it until you're of sufficient size that 5-10% of your hardware is costing more than hiring an extra person to do those optimizations.

Re:I think everyone would agree here...

[ZorbaTHut]

That's part of the point of Rails, though. It usually is cheaper to buy more hardware than to optimize, Ruby just forces you to face that up front.

I haven't actually used RoR, but you have to admit that this sounds like you're taking "ruby is really slow" and trying to spin it into an advantage.

"Most people end up having to optimize eventually. But that's hard. Ruby on Rails can't be optimized! You just have to buy more hardware! Isn't it great!"

Re:I think everyone would agree here...

[Pengo]

We tried JRuby.

We had various deployment problems, i'm sure that many people have managed to make it work, but we got about 2 days of trying to port in a medium-sized, high concurrent project, and we finally came to the conclusion that it's better to stay closer to the mainline c-based Ruby than diverge our project to JRuby and deal with the dangers of working on the bastard-project (when we talked to some of the guys at sun, back when we made the choice to give JRuby a try, there was only 3-4 paid employees working on it... it just felt too edgy for us, and we were looking to stabalize our project, not go down a lonely road of untested/unknown.... )

As they say, sometimes it's better the demon you know , than the ones you don't.

Disclaimer:

1. We have had a LOT more success with rails, than failure. And we're getting a LOT more done now than before when doing struts/JSP/JDBC style dev.

2. My lead developer wrote a book on Rails development for Oreilly, (rails handbook), he is leading our charge into Grails even having a substantial background in Ruby/Rails.

I'd never say I regret doing our projects in Ruby, nor do I feel like JRuby would of solved my problems. I'm happy with Grails, and it has well complimented our teams capabilities and experience. We write code to solve problems and generate revenue, we don't have the luxory of coding at a well funded public company, we pay our mortgages and car payments from code we write every week. Ruby has met the challenge for us, but it's silly not to explore our options to try and make our new projects even more robust and improve our development, and our current dilemma of ongoing maintenance.

Re:I think everyone would agree here...

[mgkimsal2]

In my previous post, I'd meant to say "grandparent", rather than parent (your post). Still, given my position, I'm always happy to hear about Grails adoption successes. :)

Rails popularized a lot of ideas that have since been adopted/adapted by many other frameworks, including Grails. I'm not sure many people could argue that "convention over configuration" has overall been a *bad* thing for web development, especially in the Java world.

Re:I think everyone would agree here...

[Anonymous Coward]

You have a good point, and IMO the "buy more hardware" meme is a terrible message to be sent to less experienced programmers.

One one hand, "Scaling through purchasing hardware is easier than deep optimization and refactoring" is generally true. But in the Rails world that often translates into "Scaling through purchasing hardware is easier than learning the RDBMS and not abusing ActiveRecord."

Furthermore the scalability issues in Rails are multifaceted, there's really no single-bullet answer to the issue.

Re:I think everyone would agree here...

[Anonymous Coward]

I really enjoyed this reply. Using third person "I think the parent...." is an excellent way to keep the reader (me) interested in the topic of discussion.

Re:I think everyone would agree here...

[Anonymous Coward]

I think the point of Rails 3 is to step back a bit from convention over configuration. They still ship with defaults, but they've made it trivial to swap out bits of the framework. If you don't like Active Record, for example, you can bring in sequel or datamapper or roll your own and still integrate seamlessly with the rest of the framework.

Re:I think everyone would agree here...

[rsax]

Thus they have made no allowance for dropping back to raw SQL queries.

Ignoring your inaccurate remarks about the core Rails developers, do you care to expand on the above mentioned claim?

count_by_sql: http://api.rubyonrails.org/classes/ActiveRecord/Base.html#M002276

find_by_sql: http://api.rubyonrails.org/classes/ActiveRecord/Base.html#M002267

Re:I think everyone would agree here...

[arthur.gunn]

Not true.

Model.find_by_sql sqlstring

or even more primitively:
ActiveRecord::Base.connection.execute( sqlstring )

Easy. Although you really shouldn't have to use it if you understand relations properly.

Also note that rails 3 is going to have Arel, an Object-Oriented interpretation of the Relational Algebra. It is a mathematical model for representing “queries” on data. It understanding relations this fundamentally means it can optimise easily.

Have a look at:
http://magicscalingsprinkles.wordpress.com/2010/01/28/why-i-wrote-arel/

Re:I think everyone would agree here...

[SanityInAnarchy]

you're taking "ruby is really slow" and trying to spin it into an advantage.

Nope, I'm saying Ruby is optimizing something else -- developer time. That isn't to say it will never be fast, and last I checked, the full Merb stack (and Rails 3.0 is also Merb 2.0) was on par with PHP.

It's also not that it's hard, it's that it's expensive, and a needless expense. Let me put it another way: Do you watch YouTube, ever? (Replace YouTube with Vimeo or any other Flash video website.) Do you ever bother to download a video just to watch it? I mean, you do realize that VLC takes a fraction of the CPU cycles that Flash does, for the same video, right?

But no, I bet you're just like 99% of the population -- it may burn more CPU, it may burn more battery, but you're going to just watch it in the Flash player until you have a good reason not to.

If it was really an issue, if your computer was so old and so slow that the Flash wouldn't play properly... Weigh the amount of time you'd spend in a video downloader against the cost of a low-end PC, and it's a no-brainer.

Ruby on Rails can't be optimized!

Nope, it certainly can, it's just hard, and may (in an absolute worst case) involve replacing parts of it with another language, like C extensions -- not an entirely alien idea to any game developer who's replaced bits of C++ with assembly. (No one would sanely claim that the next blockbuster game should be written in assembly for speed -- you optimize the tight loops that way, but the game logic should be higher level.)

And it's just an observation, I'm not sure if it's cultural or if it's the slowness, but it seems like Ruby people, especially Rails people, focus on horizontal scalability and optimizing their algorithms in the broad sense -- again, O(logn) vs O(n^2). Java vs Ruby is the difference between two servers and four, or a request taking 50 ms vs 100 ms. Your application logic is the difference between four servers and twenty (or not being able to scale at all), or between 100 ms and 2000 ms (or two days, or crash the server because you ran out of RAM).

These are good lessons for any system, but Ruby people seem to be especially conscious of it. Still, I think it illustrates something -- the language is going to be the least of your problems when it comes to optimizing any app, until you're at a much larger scale than 2-4 machines -- think hundreds. Eventually, it may be worth rewriting large chunks of your app, or doing a ground-up rewrite, in a more efficient language -- or it may be worth improving the interpreter of the language you've got (as Facebook has).

But you have to get there first. If you're busy doing Java because you want it to be efficient, and I steal all your marketshare because I write one line of Ruby for every five lines of Java, and I get to market while you've got a prototype with 20% of the functionality... I win. Even if I have to rewrite it all in Java later, I have the money to do that, because I've got the traffic.

Re:I think everyone would agree here...

[Jane Q. Public]

Just another example of someone putting down Rails for reasons that they only imagine because they have no idea what they are talking about.

Hey, I can make stuff up out of the air too!

(1) PHP still has a serious floating-point bug. Try multiplying 3.000001 and any number ending in .000300020001. The result is "Python".

(2) Oracle is going to roll back the last 47 bug-fix commits to the Java repository, but only for the OSS version. Then it will sell the up-do-date version commercially.

(3) Microsoft has announced that it is just too much work to make all those separate compilers that turn its Visual Studio languages into intermediate Common Language Runtime code. It will henceforth be marketing C++, C#, J#, F#, and FU With A # Object, all as separate languages with their own compilers and IDEs. It will be selling the rights to its Visual Basic language to Delphi, who say they will turn it into what it was always supposed to be.

Give me a few minutes; I am sure I can imagine some more.

Re:I think everyone would agree here...

[pmontra]

If most of your 900 controllers are just replicas of the standard restful controller (but... 900 different resources!?) you might be interested in the approach discussed at http://www.ruby-forum.com/topic/202398#881349 Basically you move all the restful code in one "global restful controller" and derive all the restful controllers from it, much like we derive models from ActiveRecord. Most controllers are reduced to a def/end two-liner and the application is much more maintainable because you don't have to create all the index/show/edit/update/new/create methods in every single controller. You add methods or replace the default ones only where you need to implement special logic . The code is at http://gist.github.com/280611

Re:I think everyone would agree here...

[dkf]

Everyone knows the real ultimate enterprise database is Access.

If by "ultimate" you mean "last because it killed the enterprise stone dead through sheer crap-ness" then yes, everyone does indeed know that.

Re:I think everyone would agree here...

[bar-agent]

Everyone knows the real ultimate enterprise database is Access.

If by "ultimate" you mean "last because it killed the enterprise stone dead through sheer crap-ness" then yes, everyone does indeed know that.

Access is totally sweet, because its entire purpose is to flip out and kill the enterprise.

Re:I think everyone would agree here...

[Anonymous Coward]

it's funny because its true

Re:I think everyone would agree here...

[ubersoldat2k7]

the "buy more hardware" meme is a terrible message to be sent to less experienced programmers.

If Jeff Atwoods says so, then it must be true... Damn! I better move to a Microsoft stack right now!

Re:I think everyone would agree here...

[Anonymous Coward]

No. The only true enterprise database is excel. Linked spreadsheets can, and in fact have run everything from bank trading desks to oil rigs.

Re:I think everyone would agree here...

[wisty]

Mod parent tragically informative.

Re:I think everyone would agree here...

[Jane Q. Public]

Um, excuse me, malicious modder, but how was that "offtopic"? Please get some clue before trying to give it to others.

Re:I think everyone would agree here...

[uberjack]

I completely agree. Not only do I find features such as pluralization and singularization annoying and capricious, at worst they are an obnoxious waste of cpu cycles. For almost every Rails project I attempt, I find myself turning my head in disgust - all but simplest projects are up Rails' alley. There are virtually no ways to deal with sophisticated database relationships without resorting to cheap hacks. Not that I find this surprising, seeing as Rails' team's original approach to database development was "don't set up foreign keys/constraints, let the framework handle it" (they have since changed this to "we don't use relationships, but knock yourself out"). "Polymorphic relationships"? Seriously, why not just chuck all the data into a text file and avoid databases altogether? There are a lot of good things in Rails, but the framework is simply too weak for anything with even a slightly sophisticated database backend. This in addition to Ruby, a language that I find exceptionally "pretty", but lamentably slow, will keep me on languages like PHP, and off of constantly-updating-with-no-regard-for-backwards-compatibility behemoths like Rails.

Re:I think everyone would agree here...

[DragonWriter]

First, I truly dislike "convention over configuration". The main problem there is that they "convention" they use is far too limited for any sizable application. It may be sufficient for a blog web app, or a bug tracker, or small-scale applications like that. But we now have one web app with over 900 controllers, and "convention" falls apart at this size. Sure, we probably should refactor our app, but we're not in a position to do so at the moment.

"Convention over configuration" in Rails generally doesn't mean that there aren't elegant methods to do configuration for the cases where convention isn't sufficient, it means for the (very large parts of most apps) parts where sensible defaults are sufficient, you don't need to have boilerplate configuration.

The same goes for ActiveRecord. It's great in simple cases, but falls apart rapidly when you're developing larger web apps, especially when you're performing complex data retrieval.

This is true, but there are plenty of open source Ruby ORMs that can be dropped into Rails in place of ActiveRecord that are better in the places AR is weak (Sequel is, I think, the best.)

And like it or not, the performance of Ruby is quite poor. We actually had to purchase some additional hardware to handle the extra load after converting an old Java-based web app to Ruby on Rails.

Although, in many cases where the performance of Ruby on Rails is at issue, the problem is either configuration or Rails issues, not Ruby, this is still a real issue. There are a couple of things to be aware of:
1) With dynamic languages like Ruby vs. static languages like Java, there is usually a trade-off of performance (and thus hardware and hardware support cost) with ease of maintenance and new development (and, thus, development/maintenance staff costs).
2) Still, as Ruby features have mostly stabilized, more and more of the focus of Ruby implementations is on improving performance. That's also true of Rails to an extent (though Rails is less feature-stable, recent version have done a lot of work focussed on performance, and a big part of Rails 3.0 was merging with Merb on of whose main advantages over Rails was performance.)

Re:I think everyone would agree here...

[jadavis]

Everyone knows the real ultimate enterprise database is Access.

Access is really not bad for what it is. I think it's actually underrated among tech people. I'd take it over MySQL in many situations.

The only problem with it is that it's slow. It's REALLY slow.

Re:I think everyone would agree here...

[tendrousbeastie]

On a site with over a million subscribed users, and countless millions of lurkers, it does seem unlikely that you're the one and only reader of the post. I think using the third person was just the chap's way of being polite to everyone else.

Re:I think everyone would agree here...

[mini me]

In fact, the Rails team always promoted the fact that you can drop down to pure SQL when necessary as a feature of ActiveRecord. It is like there is some kind of distortion field between Rails developers and the rest of the world.

What was said: We developed this handy framework to make web development more enjoyable for developers. We hope you enjoy it.

What was heard: We developed this handy framework to allow everyone and their brother to build a web application. Fire those expensive programmers! They aren't needed anymore.

What was said: We created a database abstraction library that simplifies common database operations. You can still drop down to the database level for the more complex operations, if necessary.

What was heard: We created a database library that makes accessing a database easy enough that your grandma can do it. If you have to do anything more complex than select a few rows from a table, forget about it. P.S. And don't even think about adding a second web server to the mix as your app grows, it just ain't gonna work.

Re:I think everyone would agree here...

[DragonWriter]

Just like Google, anybody saying one bad word against the slashbot groupthink that RoR is the second coming gets modded into oblivion.

As with Google, the people posting negative comments about RoR are at least as negative as those posting positive comments, although for some reason its only those posting negative comments that portray the other side as "the Slashbot groupthink" and pretend to be a small oppressed group fighting the Man.

Re:I think everyone would agree here...

[nullchar]

We have had a LOT more success with rails, than failure. And we're getting a LOT more done now than before when doing struts/JSP/JDBC style dev.

I'm curious if you have ever tried Apache Wicket. Wicket is yet another framework for Java, and it requires your team to have a solid level of OO programming knowledge because every web page is a hierarchy of components, and to customize behavior, you need to @Override various methods.

I just finished my first iteration of a decent-sized project using Wicket that used many of wicket's components like repeating list/grid views, a custom session with different user types/roles, and some custom components to deal with "edit vs view" modes.

We integrated this project into an existing Spring MVC + regular servlet/jsp web app. Instead of custom JDBC as we did previously, we used hibernate annotations which means no XML nor direct SQL.

Writing wicket was fun; I've had more fun in 3 months of wicket than 2 years of "regular" java. The learning curve was steep, as I spent days solving what later seemed simple problems, but I learned a lot. Future iterations of this project will be quick. Overall, I say medium to large projects will take much less total time from concept to stable delivery using wicket versus other java web methods.

I've not tried Ruby, ROR, JRuby, nor Grails, so unfortunately I can't compare wicket to any of them. But it sure beats Struts, Spring MVC, and JSTL/JSP. Wicket does not allow any logic in the view -- you use plain xhtml+css (with a wicket DTD while designing for validation), and use java code to do everything else, including ajax. So a web+css+javascript master can bust out a prototype/mock-up, and a few wicket programmers can tie in the back end logic. When maintaining, the web designer can open the plain html+css (in their favorite editor) and modify it as needed, without any code in the way.

Wicket is a neat technology, with great security (url encrypting, server-side validation with ajax) and good performance.

who said that?

[Pirulo]

...a CEO?

Standard Slashdot Ruby comment form

[metalhed77]

Please pick form the list below

Ruby and/or Rails sucks because:
    1. It doesn't scale (Twitter)
    2. It's slow
    3. I read somewhere that Python was a better language
    4. I write PHP, I can do everything Ruby/Rails can do better
    5. My obnoxious younger coworker uses it
    6. It's not lightweight enough
    7. The ruby community is full of over-hyping zelous twits
Ruby and/or Rails is awesome because:
    1. It scales within reason (Twitter, Lighthouse, Shopify)
    2. It's as fast as Python and PHP
    3. I read somewhere it was better than Python
    4. I used to write PHP, Ruby's been a godsend
    5. There are so many motivated and innovative people in the community
    6. It's featureful
    7. Pythonistas are over-hyping jealous twits

Re:Standard Slashdot Ruby comment form

[Anonymous Coward]

7. The ruby community is full of over-hyping zelous twits

Re:Standard Slashdot Ruby comment form

[Foofoobar]

You forgot Groovy and Grails does it better :)

Re:Standard Slashdot Ruby comment form

[Hurricane78]

What about F#lukie and FAILs?

Or Gravel and Nails? (Chuck Norris’ favorite morning cereal.)

Or Gravy and Meats? (Favorite British breakfast, I guess... especially in pie form. ;)

Re:Standard Slashdot Ruby comment form

[Neon Aardvark]

Pearl on Paths

Diamond on Driveways

Topaz on Tracks

Sapphire on Streets

Aquamarine on Avenues

Re:Standard Slashdot Ruby comment form

[Yvan256]

Ruby and/or Rails sucks because:
8. None of the local web hosting services offer it except in their most expensive packages, all we get for the low-cost packages is XSSI, PHP and Perl.

Re:Standard Slashdot Ruby comment form

[Foofoobar]

Actually Groovy and Grails are Java native. No need to interpret via JRuby. Groovy is native Java code as is Grails.

But being the ignorant troll that you are, your kneejerk response shows how little you know about these technologies and that you must have confused Slashdot with another one of your Facebook pages.

Re:Standard Slashdot Ruby comment form

[Anonymous Coward]

This is exactly true. Rails was in full-scale OMG hype mode before they even found an application server that worked properly or had a decent XML library. (Many of the fundamental building blocks only appeared because people bought into the hype and found that Rails, as promoted, was simply unusable for anything more than a low-traffic blog.)

And I say this as a developer who really likes Rails, but the toy-developer nature of the community is it's biggest weakness IMO.

Re:Standard Slashdot Ruby comment form

[Anonymous Coward]

Who the fuck is using "web hosting" these days? Get a $15-20/month VPS and stop whining.

Re:Standard Slashdot Ruby comment form

[Anonymous Coward]

What about clients who don't want to/don't care to/can't host their website?

Re:Standard Slashdot Ruby comment form

[Anonymous Coward]

Ruby doesn't suck, I first checked it out around 2003 and impressions were good. Wrote a couple of small programs for fun and moved on. Never used it seriously because I'd use perl, python, PHP, javascript, lua or shell scripting where they're strongest and there's zero advantage to using ruby in any real world situation I can think off.

Rails let 'developers' with no fucking clue whatsoever churn out cookie-cutter apps that performed about as well as you'd expect. The bullshit being spewed forth a couple of years back was offensive because it put us in an unfavorable positions with potential clients.

No, we can't write a high load web site in two days using a slow scripting language and ORM. What you're asking for is two months work and it'll be written in perl or PHP with anything heavyweight being done in C; alternatively we can write the entire thing in Java. Yes, we're more expensive than the Rails shop. Yes, the Rails shop are offering [biting tongue] a faster turnaround.

Long story, short story. We're still in business, several of the Rails shops we bid against are not.

Re:Standard Slashdot Ruby comment form

[JAlexoi]

The magic of math, my response is a sum of two of my answers: 10.
Now guess what my answers were...

Re:Standard Slashdot Ruby comment form

[Anonymous Coward]

Lets not confuse the technology issues with the business issues.

I'll speculate those Rails shops folded because they were 24 year old noobsters who bought into the Agile bullshit, which simply does not work for fixed budget/fixed time development projects where clients expect a finished product. All those "two-week" projects probably turned into three-month over-budget development hells with dissatisfied customers.

Technology-wise, its not as if Java/etc devs don't load up the ORMs and other frameworks and spew out massive amounts of poor-performing cookie-cutter code. The difference is that the architects and PMs are smart enough to estimate the projects properly.

Re:Standard Slashdot Ruby comment form

[16K Ram Pack]

If you ever want to attract lots of blog comments, there are 2 subjects to cover:-

1. Apple.
2. Ruby on Rails.

Seriously, what put me off Rails was the utter zealotry of some of the people involved in it. Django is full of more sane folks.

Re:Standard Slashdot Ruby comment form

[Anonymous Coward]

You're absolutely right. After seeing widely-publicized incidents like the trademark shenanigans involving DHH, and then the blatant sexism at GoGaRuCo, I refused to become associated with that community.

As a professional, I don't want my name linked to such childish behavior. So I took Ruby and Ruby on Rails off of my resume in May of 2009, and have taken contracts dealing with Django and Python instead.

Unlike the RoR community, the Python community somehow seems to be able to avoid petty arguments and blatantly unprofessional behavior. Then again, the Python community is generally made of more experienced professionals interested in developing high-quality software applications, rather than 18-year-old college students "rebelling" against PHP to develop Web-2.0-buzzword-compliant web sites.

Re:Standard Slashdot Ruby comment form

[Anonymous Coward]

Shut the fuck up.

Say, do you happen to do any Ruby on Rails consulting? You're more polite and better-spoken than most Rails consultants I've had the "pleasure" of working with so far. I might have some work for you.

Re:Standard Slashdot Ruby comment form

[maxume]

Somebody out there is just itching to write C on Crack.

Re:Standard Slashdot Ruby comment form

[metalhed77]

Well, if you want good, cheap rails hosting you could easily do Dreamhost or Heroku. I'd go with Heroku, they'll scale up pretty well.

Re:Standard Slashdot Ruby comment form

[metalhed77]

7. The ruby community is full of over-hyping zelous twits

You know, I wrote my post as a joke, to hopefully prevent stupid comments like yours. That yours was modded (twice) up is proof of the juvenile partisanship present here on slashdot.

Re:Standard Slashdot Ruby comment form

[s_p_oneil]

Good post, but IMO it's a shame you left this one out:

Ruby and/or Rails sucks because:
8) It doesn't use spacing to delineate code blocks

Ruby and/or Rails is awesome because:
8) It doesn't use spacing to delineate code blocks

Re:Standard Slashdot Ruby comment form

[PCM2]

Hostgator offers Rails on all their plans, too, which start at $4.95/month. I think someone's not looking hard enough.

Re:Standard Slashdot Ruby comment form

[Lord Ender]

ASmallOrange.com has Ruby web app hosting for $5 per year.

Google App Engine offers JRuby hosting for free, though you have to deal with App Engine's miserable Java performance problems.

Re:Standard Slashdot Ruby comment form

[Anonymous Coward]

Wow - you think RoR is even in the same ballpark as Java or .Net? Methinks your idea of a large application and the rest of worlds idea of a large application are orders of magnitude different in size...

Re:Standard Slashdot Ruby comment form

[SanityInAnarchy]

And the biggest "problem" there is the lag while they spin up an instance of your app. The most promising thing I've seen about that is a proposal to cache a JRuby image as Java bytecode -- that should drop us back closer to Java spin-up times, which really aren't that bad now.

Re:Standard Slashdot Ruby comment form

[metalhed77]

Hey, I agree, I wrote that post as a joke, almost all the negatives are easily dis-proven falsehoods. The knee-jerk zealots on Slashdot are too arrogant to educate themselves about this language unfortunately.

Re:Standard Slashdot Ruby comment form

[Draek]

Shouldn't that be the other way around? local web hosting services suck because none of them offers Ruby and/or Rails in their low-cost packages.

Yeah, yeah, grandma won't care whose fault it is when she can't run her knitting patterns e-store, but put the blame where its due. It's not Rails' fault that web hosting services won't offer a language worth shit unless you pay for the priviledge.

Re:Standard Slashdot Ruby comment form

[Hurricane78]

What the...
My friend, the fact that you misinterpreted my little funny and random word-play as having a “knee-jerk reaction” of an “ignorant troll” really shows, that you should go out more often, and have a little fun.
Because you are starting to see assholes everywhere.

See, the problem with text-only communication is, that we read it in the (inner) tone of voice of what we expect to read. Which is controlled by our own mood.
So if we expect ignorant trolling everywhere, that’s what we will always see. Which makes them that, in our reality.

And because I just recently realized that I did the same... man... it’s not good for you. You are getting angry where you could have a little laugh etc. Basically making your own life bad. :/

Look at the moderators. They got it right, and even modded you funny, because of the good mood. :)
Chill, relax, kiss a girl. :)

P.S.: This is a dual-purpose comment. In case parent comment was really meant funny, it’s meant funny too. In case it’s not, this one also isn’t. :D

Re:Standard Slashdot Ruby comment form

[bill_mcgonigle]

Ruby's a great language with a mediocre runtime (but getting better) and Rails is a great idea with massive breakage and version dependency problems among minor versions. Maybe that just means it's not done yet, but, man, stuff should work on 1.8.6 and 1.8.7 the same way and Rails 2.2.1 and 2.2.2 should cause huge breakage (I'm only recalling those versions from memory, apply fuzz).

Re:Standard Slashdot Ruby comment form

[Anonymous Coward]

Stop being such a zealous twit.

Re:Standard Slashdot Ruby comment form

[Dhalka226]

Then again, the Python community is generally made of more experienced professionals interested in developing high-quality software applications, rather than 18-year-old college students "rebelling" against PHP to develop Web-2.0-buzzword-compliant web sites.

You clearly gave Rails a fair chance there, didn't you?

Perhaps your really silly reasoning for "taking Ruby on Rails off [your] resume" was really nothing more than self-selecting against a platform you had already decided was worse than one you clearly think more of?

Rails isn't for everybody, and it isn't for every project. But "ZOMG SOME RANDOM RAILS CONFERENCE HAD A BAD SPEAKER MAKE A BAD ANALOGY ABOUT TEH PRONZ!!!" is about the stupidest possible rationale for not using it.

Work with whatever you want, but don't pretend you gave it a fair evaluation.

Re:Standard Slashdot Ruby comment form

[Jane Q. Public]

The Ruby and Rails core groups have both been excellent about documenting any issues, and also offering plenty of warning and deprecation time before features are changed or dropped. If minor version changes in Ruby or Rails are not getting along with some of your Gems or Plugins, I would start looking at the suppliers of those Gems and Plugins, not Ruby or Rails.

Re:Standard Slashdot Ruby comment form

[Jane Q. Public]

Haha that's actually funny because that was the point I made in my own post. In my experience, most people who make these objections simply haven't bothered to learn about it.

I even lost a job because of that once. The senior programmer at the company wanted to do everything in PHP, and was constantly putting a bug in the boss's ear about how he "didn't trust this new Ruby on Rails stuff... it's funky and unreliable." But he NEVER bothered to actually learn anything at all about it, despite our frequent prompting and offering to help.

Eventually, all the RoR work was shut down... despite the fact that they never found another technology that would do the particular niche work we were doing, and despite the fact that we had been quite successful at doing it. We had finished 3 major projects and by then we had done enough meta-programming that the next one would have taken a fraction of the time. They just closed down that part of the operation, even though it was profitable. Because 1 guy preferred PHP. Talk about shooting yourself in the foot!

Re:Standard Slashdot Ruby comment form

[metalhed77]

Eeesh, what a tragedy. I got the same BS at my job, luckily my higher up was fired and I replaced him, letting me turn our crapload of PHP into Rails.

I took a good long look at the PHP MVC world when it was clear my company wasn't going to drink the Rails kool aid, and I have to say, none of the PHP frameworks were (at the time, 2 years ago) up to snuff compared to Rails. They were just flat out missing a lot of the features that made Rails great.

Plus, it takes me way less time to code in Ruby than PHP, PHP just takes more LoC, especially as your app's complexity increases.

Re:Standard Slashdot Ruby comment form

[Lord Ender]

Java loads on App Engine are so slow, even a Java "hello world" app will occasionally time out. Java spin-up times are typically OK (1-4 seconds usually) but are occasionally and unpredictably unacceptable.

Re:Standard Slashdot Ruby comment form

[MadCat]

I gave RoR a chance and evaluated it for a while, and while RoR isn't bad, it's community is absolutely terrible. Help is hard to get, and more often than not a simple question leads to 5 people falling over eachother to call you stupid in various degrees, yet they are unable to actually offer any help. A large majority (from what I've seen) of the community can only follow the "hype" and treats the RoR dev team like deities, yet has no idea how to do certain things, how to properly structure and architect software, and responds with vitriol when asked about this.

So instead I stuck to what I know, and have been using Catalyst for my projects. That community is awesome, helpful, knowledgeable and not afraid to help out even for dumb questions.

In short:
RoR: loud, obnoxious, hype followers
Catalyst: quiet, friendly, no hype anywhere (which unfortunately means Catalyst is a bit in the shadows)

Just my 2 cents.

Re:Standard Slashdot Ruby comment form

[pushing-robot]

C++ was written a long time ago.

Re:Standard Slashdot Ruby comment form

[timmarhy]

let me get this straight - replaced your boss and your still doing the bulk of the coding? fail.

Re:Standard Slashdot Ruby comment form

[Jane Q. Public]

And I admit that it is rare that you simply MUST do something in a particular language, but without going into details, nothing else would do it. There was a Perl library that would do half the job, and a PHP library that did half the job, but there were overlaps in some areas and gaps in others. We cold have written our own libraries for either, of course, given a lot of time and trouble. But it so happened that there was (and still is) a Ruby gem that did it all, of all the languages we looked at.

And thanks to the dynamic nature of Ruby, it was ridiculously easy for us to modify methods and add custom methods to code libraries as necessary, to make the job easier... without having to actually patch or overwrite the originals. That is really sweet. Regular inheritance wouldn't do it, single OR multiple... but Ruby mixins made it easy.

Re:Standard Slashdot Ruby comment form

[Per Wigren]

Somebody out there is just itching to write C on Crack.

...or COBOL ON COGS.

Re:Standard Slashdot Ruby comment form

[Anonymous Coward]

So, some people in a community have problems and this is representative of most of the community? You really think those communities are that different? They hardly ever are. It's more likely that you have a selective bias. The both just tools. They each have advantages and disadvantages. To make anything more of it than that is what's childish.

Re:Standard Slashdot Ruby comment form

[Anonymous Coward]

Ruby on Rails is a religion, not a serious programming language.

Re:Standard Slashdot Ruby comment form

[Anonymous Coward]

No ISP is stupid enought to offer support to a resource-hogging and performance-killer language like RoR...

Re:Standard Slashdot Ruby comment form

[Anonymous Coward]

> "ZOMG SOME RANDOM RAILS CONFERENCE HAD A BAD SPEAKER MAKE A BAD
> ANALOGY ABOUT TEH PRONZ!!!" is about the stupidest possible rationale for not using it.

You are 100% wrong on this point.

I know from first hand experience that more than one large enterprises dialed down their level of interest/activity in Ruby after David Heinemeier conducted himself like a sex-obsessed 15 year old last year.

People want to respect and identify with other people in the communities that spring up around technology. If the Rails community appears to be full of masturbation-obsessed teenagers then serious corporate types (and their big $$$) are going to stay far the hell away. So it's completely reasonable for a job hunter to likewise take Ruby off his resume.

Right or wrong, that's how the world works.

Re:Standard Slashdot Ruby comment form

[Anonymous Coward]

I can see you're just one big joke.

Re:Standard Slashdot Ruby comment form

[Anonymous Coward]

7. The ruby community is full of over-hyping zelous twits

Re:Standard Slashdot Ruby comment form

[Anonymous Coward]

Lets not confuse the technology issues with the business issues.

The hype about rails was not based on realistic appraisal of the technology. I wasn't confusing the two issues, that was entirely the work of the RoR community.

All those "two-week" projects probably turned into three-month over-budget development hells with dissatisfied customers.

Of course they did. That doesn't help when you're dealing with potential clients, it's not professional to call bullshit on would be competitors.

Technology-wise, its not as if Java/etc devs don't load up the ORMs and other frameworks and spew out massive amounts of poor-performing cookie-cutter code.

True but doing so doesn't impact java performance in the same way, nor did I see it enshrined as the default in anything until I tried RoR.

The RoR community needs to grow up and stop over-stating the capabilities and relevance of their pet language / framework combo. If they stopped the self-promotion and instead concentrated on improving rubys runtime performance until it matches the likes of V8, tracemonkey and luaJIT... perhaps people like me wouldn't feel the need to call bullshit every time I see YARS (Yet Another Rails Story).

Re:Standard Slashdot Ruby comment form

[Foofoobar]

Gotcha... thanks for the bit of perspective. I needed that.

Re:Standard Slashdot Ruby comment form

[Anonymous Coward]

> As a professional, I don't want my name linked to such childish behavior. So I took Ruby and Ruby on Rails off of my resume in May of 2009...

yep i did stuff like that too, since i don't want to use anything linked to childish behaviour i ditched linux (ever read those kernel list flames? i did) openbsd (hello theo), windows (only a toddler would think a FAT patent has any innovation worth defending) and i got to an abacus- i am typing by making the beads resonate at the right frequencies for my acoustic coupler

Re:Standard Slashdot Ruby comment form

[Yvan256]

You forgot the "local" part. In my case it needs to be in Quebec, Canada.

Re:Standard Slashdot Ruby comment form

[Anonymous Coward]

7. The ruby community is full of over-hyping zelous twits

You know, I wrote my post as a joke, to hopefully prevent stupid comments like yours. That yours was modded (twice) up is proof of the juvenile partisanship present here on slashdot.

Or perhaps many, many, many would-be users have experienced your "joke". Sometimes the truth is funny - but its still painfully true.

Re:Standard Slashdot Ruby comment form

[DragonWriter]

Actually Groovy and Grails are Java native. No need to interpret via JRuby.

There is no reason to "interpret" via JRuby in any case. JRuby provides an AOT compiler (jrubyc) that compiles Ruby code to Java bytecode; in addition, the normal mode of operation for JRuby is to do JIT compilation on method bodies when first encountered and then execute the compiled method from then on.

Re:Standard Slashdot Ruby comment form

[Unequivocal]

I agree with your comments - but the merb community has been awesome. Now that the merb dudes are core contributors to Rails 3.0 there is some hope that they will "unsuck" the elitist/cult-of-personality mania in the core Rails community. In the end the guy running the community makes a big impact - get cool people like Brian Behelendorf evangelizing Apache, Linus Torvalds for Linux and you get open, interesting communities. DHH has turned RoR into a Steve Jobs look-a-like. Ezra Z (original author of merb) is a much better community leader, and I have some hope that his crew will create some big improvements in what it's like hanging around Rails. Time will tell.

Re:Standard Slashdot Ruby comment form

[Unequivocal]

Bullshit. I remember very clearly the 1.8.x AND the 2.2.x upgrade issues. Both these updates broke my app - not the gems, the core application. I was using features they removed or changed without deprecation warnings. It took me only about 2 hours to figure out the issues and repair them in both cases, but core libs were broken silently by the Rails core in both those version releases.

Re:Standard Slashdot Ruby comment form

[RAMMS EIN]

My pick:

Ruby sucks because:

        2. It's slow
        7. The ruby community is full of over-hyping zelous twits

Rails sucks because:

        6. It's not lightweight enough

Ruby is awesome because:

        4. I used to write PHP, Ruby's been a godsend
        5. There are so many motivated and innovative people in the community
        6. It's featureful

Full disclosure:

Ruby sure isn't perfect, but, of all the languages I've tried (and there are many), it seems to me Ruby sucks the least. I use it whenever I can, which is when another language isn't a better choice (e.g. speed is required) or mandated (e.g. required to do the project in Java). Current implementations are dog slow, and, as always, there are people who will hype it up to ridiculous levels. But hey, that's how Java got big. ;-)

I don't really use Rails much, and I probably wouldn't have built it as it is, but I enjoyed working with it in the past. At the time, it did certainly rock the world. Still, I think Ruby's main strength is in quickly building _simple_ things and its power to make lots of things simple. Grab the modules you need and/or (have someone) tailor the language to your needs, then write your program in a few lines of code. That's where Ruby shines.

Re:Standard Slashdot Ruby comment form

[PCM2]

May I ask why? When I'm talking about cheap Web hosting, I usually think in terms of their network connectivity, not their geographic location. Hostgator, I believe, is in Texas.

Re:Standard Slashdot Ruby comment form

[Yvan256]

It's more about giving work to local businesses. And Montreal has more than enough bandwidth and ends up having a lower latency for the visitors who are mostly from Quebec and Canada (targets of our clients).

If you're American, would you buy Canadian potatoes or Idaho potatoes? Supporting your local* economy is important.

* local takes on a new meaning once you take the whole planet into account.

Re:Standard Slashdot Ruby comment form

[MadCat]

True, the merb folks are a lot better in that regard, and if they succeed in "un-sucking" the greater RoR community that would be awesome. RoR is a nice piece of work, and it does deserve a better "image". One thing that it also needs is for DHH to back away a little because he comes across as some religious sect leader who's trying to convince people that his kool-aid is the best ever because it's fizzy

Re:Standard Slashdot Ruby comment form

[Foofoobar]

There is no reason to "interpret" via JRuby in any case. JRuby provides an AOT compiler (jrubyc) that compiles Ruby code to Java bytecode... Yes. Thats commonly referred to as interpretting since Ruby doesn't run native on the JVM like Groovy. And unlike Groovy, Ruby can't import Java libraries or use java methods natively.

Re:Standard Slashdot Ruby comment form

[PCM2]

If you're American, would you buy Canadian potatoes or Idaho potatoes?

For the record, I'm both.

Unfortunately, I have no idea where my produce comes from. I live in California, one of the biggest agricultural markets in the U.S., but I can all but guarantee you that my tomatoes don't come from the San Joaquin Valley -- not all the varieties, anyway, and not all year round. Welcome to the new global economy.

Things got like that, of course, because as a practical matter you can't source everything from one location. If I actually can't buy something from a source in my local area -- something like decent Web hosting, for example -- then it seems justifiable to seek it elsewhere, especially if the location of the resource isn't particularly important.

If you can put aside the whole patriotism thing (since Canadian companies don't seem to be willing to offer you what you want), the physical distance shouldn't be that much of a factor. Montreal is 1,516 miles (2,439 km) from Dallas. But San Francisco is 1,485 miles (2,389 km) from Dallas -- so I'm not dealing with much more geographic distance than you. The really funny thing is, I swear my latency to my current hosting provider is way better than it was to my last one, even though I think they have their servers in the same datacenter in Dallas. Go figure. What I'm saying, I guess, is that when looking for a hosting provider, I've learned it pays to shop around.

Re:Standard Slashdot Ruby comment form

[bill_mcgonigle]

This was exactly my experience as well. I'm back to using Catalyst for now.

Re:Standard Slashdot Ruby comment form

[Anonymous Coward]

I gave RoR a chance and evaluated it for a while

I applaud you for your 'I actually evaluated it' viewpoint.

Like you, I also had a looksie at both Ruby and RoR.

Loved ruby. Found RoR interesting but didn't like it much.... read on for why.

In short, I really like Ruby, the 'why the lucky stuff' tutorial was absolutely the most fun I've had learning a language in years. I was so enthused I evaluated rewriting significant parts of my business systems in ruby/RoR. So I looked at RoR.

RoR was OK ... some nice ideas I hadn't really been sat in front of and forced to stare at before ... but I'm sure they weren't new. After a few test projects, some things put me off using it.

First, I tend to shy away from code generation (vs. smarter code) as an affront to maintanability, except in very specific types of situations and I felt that RoR overuses this technique without obviously providing any other options.

Secondly, the whole 'define your data model in a text file' thing is pretty broken in my view. How many web based systems need to be moved from one database to another? How many times will the text file EXACTLY match the specification that is database-native? (Hint: This is NEVER a safe assumption, particularly across database versions, if your data model is nontrivial) It's OK if 90% of your projects are going to be 'the client has no idea of scalability required or target environment, yet somehow knows ruby is OK to use' ... but in other cases (almost all that I ever see), I would posit that the overhead and distance-from-the-grindstone you are building in to your codebase is actually counter-productive.

The final nail in the coffin for me was that language-native Unicode support was lacking in ruby at the time. I understand this is being or has been resolved with a later release, but I have not had time to go back to it.

the community can only follow the "hype" and treats the RoR dev team like deities, yet has no idea how to do certain things, how to properly structure and architect software, and responds with vitriol when asked about this.

RoR is a framework that provides quick results with certain types of qualities in a certain problem space. The qualities are relative (though rarely significant) machine-level inefficiency and in my view limited maintainability (too much code generation), The way it is marked, RoR appeals to the 'I'm a fairly inexperienced coder, probably in the west, using a Mac, and doing build, deploy, forget-style web agency type jobs for bread and butter' types. It's not a bad fit for such people.

So instead I stuck to what I know, and have been using Catalyst for my projects.

These days I would NEVER consider programming a web-based (I would almost say -- any complex transactional) system in perl. Whilst it is of course possible, and there are many successful perl-based websites, implementation language is not a design decision to be taken lightly, and perl is a tool less-suited to the web based system problem space than PHP. This shows in both usage stats and the job market. Learn something else.

Full disclosure on my background: perl (pretty damn fluent, CPAN author, have done a lot with the language - but not a fan of OO perl at all, and NEVER use it as a primary language for web systems), PHP (fluent, frequent since PHP3 - but not a fan of OO PHP at all), web (80% my focus since ... 2000 or so), interest in security, TCP/IP RFCs were my high school reading, also do Linux systems stuff, including embedded/diskless/virtualisation, used *BSD a bit, OK javascript, some Java/C/whatever, own my own international business operational in six languages (only one of these being latin-based) including custom integration of voice/fax/telephony/sms/email/web and multicurrency billing/accounting so I believe I can claim to understand a little about the business side of software - maintainability, reliability, security.

Mod submitter -1 Troll

[Anonymous Coward]

WTF kind of troll-ass summary is this? It's be like seeing a Microsoft announcement like this:

Office 2010 is almost out; is it gayer than nine guys blowing eight guys, or just a total piece of crap?

BTW: a preemptive STFU to the scaling trolls. Take your whinge back to 2005, where somebody might give a crap.

Cynicism = good sign

[dino213b]

I'm glad first responses are so negative; now I don't have to bother trying ROR out.

Re:Cynicism = good sign

[Jane Q. Public]

"First responses" were years ago. The people who are still bitching about it are people who have not gotten to know it well.

I have many years experience in programming, but I have spent the last 4+ doing Ruby, and Ruby on Rails. And I love it. I have yet to find something another languages and frameworks do that RoR will not, and usually RoR does it simpler and more easily.

It does in fact scale quite well, and while it is relatively slow, all interpreted dynamic languages are.

There is a learning curve, probably a bit more than most languages, but once you get past the hump it's a pretty nice ride. Most of the objections are coming from people who haven't gotten there.

Re:Cynicism = good sign

[Tacvek]

Besides speed should hopefully become less of an issue once people migrate to Ruby 1.9 with YARV and eventually 2.0 which will hopefully have a decent JIT over top of the YARV bytecode (or something else perhaps) that should help significantly with the speed issues.

(Especially if said JIT offers an unsafe optimization mode that makes certain documented assumptions about the code, like not changing the integer arithmetic methods, and other similar cases, the detecting of which can add significant overhead which many programs don't need, since they don't do that.)

Re:Cynicism = good sign

[Jane Q. Public]

Somebody has it out for me today. No less than 3 of my comments in this topic were modded down for completely bogus reasons, that one above included.

And that's the way it has tended to work... somebody who occasionally gets mod points spends them all (or a lot of them anyway) modding me down in particular. At least, I tend to get lots of negative mods for no apparent reason, all at about the same time.

I wonder if the Powers That Be have a way of telling if a modder is doing it maliciously... i.e., marking down a particular person rather than posts: the messenger rather than the message. Because I have good reason to believe that it has been done.

A ton of Rails 3 Beta links

[Peter Cooper]

Over at Ruby Inside we did (and are maintaining) a roundup of ~36 Rails 3.0 beta links/articles (it's up to about 40 now, I think). If you've got Rails 3.0 installed and want to know how to use X or Y or want to learn some of the back story/motivation, the links should come in useful. They're only things that are actually worth reading. Well, mostly.. :-)

It's a great day to be a rails developer!

[Anonymous Coward]

I just love the rails development community...they've really shown that they welcome any new ideas, frameworks etc and incorporate the best of everything into a fully fledged release.

Well done and Thank you.

Buzzword Alert!

[Anonymous Coward]

...agile...

That's where I stopped reading. I'm on a no-buzzword diet.

Re:Buzzword Alert!

[Anonymous Coward]

You probably missed the announcement of Emeralds on Asphalt 3.0 beta too. It's heavier, more waterfall-like and harder to understand.

Re:Buzzword Alert!

[John Whitley]

That's where I stopped reading. I'm on a no-buzzword diet.

Excellent! More enjoyable and better paying work (and better co-workers) for the rest of us clued enough to realize when there's real substance behind those buzzwords. Have fun with that self ghettoizing!

7 seven 7 seven 7 seven 7 seven 7

[Anonymous Coward]

7 seven 7

Testing

[rgravina]

Slightly off-topic, but since a lot of comments are about how Ruby and Rails has nothing other popular dynamic languages and frameworks have to offer, I'd like to say there's one thing which drew me to Rails which I couldn't find in any popular Python or PHP web frameworks.

Testing. Craftmanship. Quality. This is more cutural than technical. While it's technically possible to write tests in PHP and Python, it just seems like people rarely do (especially so with PHP). And even if they do write tests, it's an afterthought. Things may have changed since I've done any serious development in PHP or Python, but I've done a little with Django and the testing that's done in the community didn't come close to Rails at the time. I'd be lucky to find a plugin authour whom had a test suite for their work and there was nothing of the function or quality of RSpec or Cucumber around.

This kind of lax "I tried it in my browser so it works" attitude to web software development in PHP and Python almost made me want to give up on web development and get into some other type of programming with some real professionalism - but thankfully I found Rails and glad that in general Rails programmers take their work seriously.

Having said all of that, I don't want to paint too negative a picture of Python. There are some awesome frameworks and communities in the Python world - Twisted/Divmod, for example, where the community really are bright and dedicated to test driven development. Zope 3/Grok is another. But I couldn't find anything in the mainstream web development world which were. Being mainstream is unfortunately important in getting anyone to support your descision - be they management, or a client.

Re:Testing

[Bogtha]

I can't say my experience matches yours. There are two testing modules shipped by default with Python. Django has integrated support for them out-of-the-box. Django itself has plenty of tests. There are plenty of good third-party testing modules and people are pretty vocal about using them.

On the other hand, I do very strongly get the impression that the lax attitude of "I tried it in my browser so it works" is omnipresent in the Rails community, coming right from the top. Witness the uproar over the Google web accelerator. Rails was just plain wrong to use GET for unsafe operations. But "it worked in a browser", so they didn't see anything wrong with it, even though it was out of spec. GWA came along and triggered data-loss bugs in Rails applications that used unsafe behaviour for GET requests, including 37signals' applications. Rails developers, rather than simply saying "whoops, our bad, we'll fix this ASAP", called GWA evil and wrote code to block GWA. Roll forward a year, GWA changes its behaviour and the blocks don't work any more, the same things happen all over again, and the Rails developers call GWA "scary" and "malicious". These are not the actions of people who care about writing the best code possible, these are the actions of people with egos chasing features and attention.

As for the word "professional" in particular, that's a dirty word in the Rails community.

Re:Testing

[metamatic]

Testing. Craftmanship. Quality. This is more cutural than technical.

Funny, my experience of the Rails community is that it attracts a lot of crackpots who don't believe in documentation--not even API documentation.

Re:Testing

[Anonymous Coward]

DHH != Rails

Re:Testing

[jemmyw]

Well Rails itself wasn't responsible for developers putting unsafe operations behind GET requests, you can shoot yourself in the foot with any language. Rails convention (now) is for a RESTful service where each operation does what it says (GET gets, POST posts, PUT puts, DELETE deletes). I think that perhaps the Rails community will have to accept "professionals", like it or not, if larger companies start using the framework. Also I think that a few very vocal developers who consider themselves central to the Rails community are quite unprofessional in a bad way.

Re:Testing

[Anonymous Coward]

I have to agree somewhat about the lack of both solid tests and solid documentation. There seems to be a lot of TALK about testing in the RoR community, but a lot of the test tools (and the debuggers, for that matter) are underdeveloped and immature. I've run into undocumented or counter-documented behavior more than once when writing Cucumber tests, for example. I've also seen a lot of code where the rcov coverage reports are okay, but looking at the actual cases tested, you see that only the bare minimum was done (e.g., build from the scaffolding and don't think through the tests too much). The only significant documentation to back any of these tools: forum posts. The biggest things reining in my excitement about RoR are the underdeveloped development and testing tools and the total disregard for documentation, really.

Now, to play devil's advocate against myself, I'm not a web application developer by trade - I do high-reliability embedded software (avionics), so I'm used to a pretty stringent level of required testing that isn't really appropriate for most web apps. I'm also really only at a hobbyist level for RoR - I've only used it off and on for about the past year, spending maybe 2 or 3 months of real time working with it, so I'm sure I'm still running into seriously rookie problems. Still, the talk about RoR doesn't really jibe with the reality of the situation, at least from what I've seen so far.

Re:Testing

[mini me]

While it may not be your preference, applications written in Ruby are supposed to be written in such a way that they are self documenting. Contrary to other languages, the expressiveness of Ruby allows the developer to write code that means as much, if not more, than formal documentation.

If you need the documentation you are looking for in a Rails app, it was written poorly, or, dare I say incorrectly. So yes, you are right, you're not going to find the documentation you might find in other languages and frameworks. But it just isn't necessary most of the time if the app is written well.

Re:Testing

[Anonymous Coward]

I hope I don't work in the same company as you.

That's a very dangerous thought process. Each language has it's own way of doing things and not everyone thinks in a way that fits every language. I know some people who swear by Lisp. I personally swear at it because it doesn't fit my brain.

You should never rely on code alone to document how to use something.

Re:Testing

[beguyld]

While it may not be your preference, applications written in Ruby are supposed to be written in such a way that they are self documenting. Contrary to other languages, the expressiveness of Ruby allows the developer to write code that means as much, if not more, than formal documentation.

Yeah, sure... I've inherited plenty of code by people who were religious about the "no comments" idea. Utter nonsense.

Yes, my own code is as self documented as possible. It shows HOW, but it can't show WHY. Code alone can 't describe the overall context of why that code, and now some other code, or how it fits into the whole. That's what comment blocks are for.

Otherwise, you're just doing like the current US government, and burdening future generations with the true cost of today's "short cuts." It's self-centered and short-sighted.

If it is truly "throw away" code, fine. Don't comment it. But that is about 0.001 % of all the code I've seen in the last 25 years.. Good rule of thumb is that all code lives forever, and will be read 100 times for every time it is read. Thus the ROI on comments is enormous and always worth doing.

Re:Testing

[Anonymous Coward]

Rails today is based largely on REST concepts. They learned from those early mistakes and are better for it.

Re:Testing

[Anonymous Coward]

hahahahahahahahahahahahahhaha

wtf d00d

Re:Testing

[Anonymous Coward]

Maybe its just me, but a language that encourages monkey patching and anonymous methods is not very "self-documenting". Any trips I've made into the Rails source code have resulted in a lot of WTFing trying to figure out what's really going on.

Plus that entirely misses the point of an "API" being a documented interface rather than a random heap of methods sitting on your disk.

Re:Testing

[Jane Q. Public]

In fact this is supposed to be a central idea behind comments in Ruby. It is usually much more important to indicate WHY your are doing something than HOW. Ideally, the how should be self-evident.

Re:Testing

[rgravina]

Yes, Django does have testing support, and Django itself is quite well tested - so I agree with you. The point I was trying to make is just that testing wasn't really a priority amoungst developers in the way it is in the Rails world. Things may have changed now.

As for talking about professionalism, it's more just a case of being fustrated by developers not testing their code - and it happens in all languages (and I do it sometimes too). It's just less common a problem in Ruby/Rails in my experience.

Re:Testing

[TheDarkMaster]

So true... You wrote exactly I liked to say about this.

Re:Testing

[The Abused Developer]

100% I agree; however, this is the cultural part of programming; I live in the Toronto area and in more than 6 years I haven't seen even one project where the principle of HOW vs WHY has been practiced. It has become the norm in the profession here to write non-commented code - besides poorly designing it; being self-centered and short-sighted under the criteria of the *short cuts* is the standard you are expected to submit 100% otherwise you'll be punished by the team who wrote it in the first place or the manager who desired it that way. So, from this perspective I think Rails style and habits represents more of a culture becoming dominant these days in the programming field than something Ruby/Rails specific.

Re:Testing

[mini me]

Okay, here is a common idiom in virtually every Rails project. Please show me how comments can improve the understandability of the following code:

class Foo < ActiveRecord::Base
  has_many :bars
end

Another common pattern is:

class FoosController < ApplicationController
  def index
    @foos = Foo.all
  end
end

Again, I would love to see how comments can improve the code. I'm not saying that comments are never necessary. I am saying that if you need them in your average Rails app, you are doing it wrong.

Re:Testing

[The Abused Developer]

Agree; however, the complexity and the magnitude of the code and logic inter-dependency of the snippet you posted is not relevant at all for the sake of this topic. Post a snippet of some hundreds of lines where multiple logic flow paths have to be managed and split between various modules and then we have a starting point for the smacking :-). The code as posted lives only in samples, the one I mentioned is the real deal you face every moment of doing real, business programming.

Re:Testing

[beguyld]

Oh come on, you can't possibly be implying that DHH is self-centered... :)

Re:Testing

[beguyld]

Agree; however, the complexity and the magnitude of the code and logic inter-dependency of the snippet you posted is not relevant at all for the sake of this topic.
Post a snippet of some hundreds of lines where multiple logic flow paths have to be managed and split between various modules and then we have a starting point for the smacking :-).
The code as posted lives only in samples, the one I mentioned is the real deal you face every moment of doing real, business programming.

Thanks for responding for me. That was perfect, and probably better than I would have done.

The point is not to comment already clear code. The point is be explicit about the context in which that code lives.

Information that is in my head at the moment, but will be gone 3 months later; and someone else new to the code never had at all.

Re:Testing

[beguyld]

Perhaps some of this is an outgrowth of a misunderstanding of Agile Development, or at least a miscalculation of the relative costs of investing a little something for the future.

While I'm completely on-board with the Agile Development concepts in general, many developers do seem to use it as an excuse to put zero investment into making the code base understandable to future developers. (including themselves months or years from later)

The large percentage of development being web-based, and moving very fast, probably has something to do with it as well. If the code, and the company, doesn't stay around very long, then perhaps the comments don't matter. But if the company is successful and that code sticks around for a few years and turns into a million lines of code, then that missing contextual information will become a huge problem.

And the problem is there whether management or the original developers recognize it or not.

All that said, really good TDD probably helps quite a bit, where the tests become the documentation. (though I don't think it can entirely replace well-placed comment blocks, by people who can step outside their own headspace once in a while)

Re:Testing

[The Abused Developer]

Agree 100%. Unfortunately, this symptom was quite common before Agile but has grown as the sustainable norm and got industry *de facto* acceptance following the practice of the so called *SCRUM but*. Also, I agree with the factors related with the business context - it is a dog-eat-dog, jungle surviving game where only the immediate benefit counts as long term expectancy doesn't exist. As crazy as it sounds TDD is seen - as far as in my experience - as a burden, an unacceptable cost adding component. As long as the bottom line can be achieved by abusing your developers to work inhumane hours everything goes as planned and expected. So, going back to our starting point - I don't think DHH is self-centered :-) -but the way we see our practices evolve is the result of the industry customs.

Re:Testing

[DragonWriter]

While it may not be your preference, applications written in Ruby are supposed to be written in such a way that they are self documenting.

Code in any language should be self-documenting to the extent the language allows, that doesn't excuse not doing additional documentation when the language (or your use of it) isn't sufficiently self-documenting. Rdoc -- which is included with Ruby -- generates documentation by reading the code and comments for a reason -- because it is assumed that code will not always be sufficient documentation on its own.

Contrary to other languages, the expressiveness of Ruby allows the developer to write code that means as much, if not more, than formal documentation.

Compared to static languages live Java, its very hard to explicitly express things like expectations about arguments clearly in code in Ruby, and the kind of tests that would express these expectations more clearly are often considered bad style, except in very particular circumstnaces. Documenting these expectations in comments which turn into API docs via Rdoc would seem to generally be the right thing to do.

Re:Testing

[Anonymous Coward]

For whatever reason, some programmers think that programming should be done this way. They don't want to document tricky constructs for less experienced programmers, or to document some of the legacy-system data model that lives in their head, or do anything that makes programming somewhat enjoyable. They want all programmers to struggle and then marvel at the technical genius of the hack-upon-hack they had to perform to do something the framework didn't want them to. And if you can't figure that out on your own, you're clearly an inferior programmer.

Of course, they'll be lauded as the hero because they are the only person who understands legacy system X since they put so little effort into making it understandable by anyone other than themselves. And they don't write any tests, so although the system is buggy they'll pull an all nighter to fix a critical bug and get even more praise for their outstanding efforts.

Do those mythical and magical pair-programming, knowledge-sharing, agile-developing teams actually exist or only in theory?

Re:Testing

[metamatic]

Being involved somewhat in Ruby's development, I've seen the "There's no need to document" myth bite people many times.

The single biggest reason why it's a myth: without documentation, you don't know what behavior is intended and supported, versus what behavior is an accident of implementation.

So then when the developer changes the (apparently accidental) API and hundreds of people's apps break, the blamestorming begins.

Re:Testing

[mini me]

A Rails app, or any Ruby app for that matter, should never grow to be significantly more complex than the code I posted. Sure, you will have much more code, but that code will be just as understandable as the code I have posted. If not, you are doing it wrong.

Mutually exclusive??

[syousef]

Rails makes developers happier, not unemployed.

When you've had a lousy job, the two aren't mutually exclusive. I want assurances that they don't intend to make me happier BY making me unemployed ;-)

Apple and Rails

[200_success]

Apple makes opinionated hardware. Rails is opinionated software. It's not surprising that the two fan bases act similarly. In fact, I would bet that there is a lot of overlap between the two groups.

Re:Apple and Rails

[edw]

Yes, but while there may not be right and wrong opinions, opinions can definitely be either thoughtful or stupid. A case in point: Rails likes to give your database tables plural names. This is a stupid opinion. I explained this on #rubyonrails years ago, but it seems that the developers, DHH included, were so enamored with their pluralize method that they didn't want to rip it out and do the sane thing.

It's convention over configuration, not instead of configuration, I read in another comment. Well, I tried to configure Rails to not pluralize table names...and Rails broke. If the pull of tradition and convention is so strong that very few people stray out of the ruts worn into the beaten path, deciding to break with convention means fixing all the latent bugs in the system.

One of the reasons to prefer singular table names is that it improves Rails's interoperability with the applications that either want to supply data to or consume data created by Rails. Web apps do not exist in a vacuum. I was told by DHH that such things were outside the scope of Rails, and therefore those pluralize calls would stay for the rest of eternity. And thus everyone who has their first involvement with relational databases using Rails becomes brain damaged. Hooray for opinionated software?

I soured on Rails early, though I have tried to go back to it on occasion, only to find that the hype still exceeds the reality by a significant factor. I'm very much a right-tool-for-the-job kind of person, but I haven't come across a project where a feature in Rails makes it uniquely suited to the situation over something like Django.

Don't get me wrong, I think Rails gave web development frameworks a much-needed wake-up call. The Java way of doing things circa 2004 was horrible. But Rails has no monopoly on smart developers -- an understatement? -- and smart developers are quick to adopt good ideas.

Re:Apple and Rails

[arthur.gunn]

ActiveRecord::Base.pluralize_table_names = false

simple.

Re:Apple and Rails

[Anonymous Coward]

In fact, I would bet that there is a lot of overlap between the two groups.

There is. I'm writing this on my Mac, before going back to writing Rails apps professionally.

Both are indeed opinionated. If the tool makers' opinions match your own, enjoy the ride, it's going to be a good one. If not, get back to your
own stuff and let your work make a statement for you instead of bashing other people's choices.

Not meant to be an attack on the parent, just stating my own view on all this fuss.

Re:Apple and Rails

[ubersoldat2k7]

Actually, I've seen some RoR screencasts and most of them are made with the Aqua L&F. Doesn't matter the OS, but always the same L&F, coincidence?

Re:Apple and Rails

[jeremyp]

Imagine a discussion forum about developing with Rails on OS X (I just checked, rails is part of the standard OS X install). You'd probably need asbestos trousers for that discussion group.

Re:Apple and Rails

[Unequivocal]

I run a production rails app with pluralization turned off. I turned this feature off in 2006 and it worked fine then - it works fine now. I agree with you that this is a dumb feature.

Re:Apple and Rails

[edw]

Maybe it works today, but it didn't work six years ago. Did you read the part of my post that mentioned Rails broke when I did what some know-it-all like you suggested I do? Hello?!

Re:Apple and Rails

[arthur.gunn]

Hello.

Seeing as rails was not released publicly till July 2004 this is does not surprise me.

Seriously though, 5 years is a very long time for an open source project which has grown to have over a thousand people contribute code to it.

Perhaps with the release of rails 3, with its particular emphasis on modularity and configurability, it would be a good time to re-evaluate?

Also, I read you post and found no know-it-all reference.

HTTP methods

[200_success]

That wouldn't be the only time that Rails has been sloppy in choosing the right HTTP method to use. When they implemented REST, they got PUT and POST backwards. Compare with CouchDB, which gets it right: PUT to create and POST to update a record.

Re:HTTP methods

[mini me]

Not true. From the CouchDB docs:

To create new document you can either use a POST operation or a PUT operation. To create/update a named document using the PUT operation, the URL must point to the document's location.

In other words, because CouchDB allows you to define the document ID before it is created, you can use PUT to pass that information upon creation. But if you want CouchDB to define its own document ID, you must use POST. This is consistent with the HTTP spec.

Rails apps, on the other hand, typically do not allow you to define the ID of the record you are manipulating. It is assumed that the database, or at very least the application, knows how to handle this operation best. That is why creates are almost always POST for Rails apps. Again, this is consistent with the HTTP spec.

Re:HTTP methods

[Jane Q. Public]

Actually this is not true. While a newly instanced object (or record as you are using it) may not have an ID using the Object.new() syntax, Rails has always allowed you to create a record with an ID. The fact that you did not know this does not say much for your experience with it.

Nevertheless, while you can both create a new record with an ID, or specify your own ID for an object, the former can cause issues if you are not careful, and the latter was determined by the Rails folks (correctly) to be generally BAD PRACTICE, because any logic errors on your part could hopelessly (and very easily) screw up your DB's table index. They were correct in deciding to make it not easy to do that accidentally.

Re:HTTP methods

[DragonWriter]

That wouldn't be the only time that Rails has been sloppy in choosing the right HTTP method to use. When they implemented REST, they got PUT and POST backwards. Compare with CouchDB, which gets it right: PUT to create and POST to update a record.

PUT and POST don't map perfectly to Create and Update.

PUT should be used (per the HTTP spec) where the URI to which the PUT is conducted will be the URI of the resource provided. Clearly, this can make sense for either creates or updates in certain cases (creates where the requester has control of the URI or has "reserved" it somehow in advance, updates where you are doing a replace of an existing resource.)

POST should be used where the content is added to the resource at the URI provided, which can makes sense for updates that add information or creating a sub-element of a collection identified by the URI to which the POST is applied.

As long as you follow the semantics of the HTTP spec -- which Rails REST implementation does -- I don't see how you can say that it is "wrong". I'm not familiar with CouchDB, but it seems harder to have a good way to do Create with PUT, since PUT requires knowing the URI at which the resource "lives", which is easy for updates, but harder when you are asking some application to create the resource initially.

Re:HTTP methods

[DragonWriter]

Nevertheless, while you can both create a new record with an ID, or specify your own ID for an object, the former can cause issues if you are not careful, and the latter was determined by the Rails folks (correctly) to be generally BAD PRACTICE, because any logic errors on your part could hopelessly (and very easily) screw up your DB's table index.

It could cause the insert to fail, but unless you have a database that can't properly enforce uniqueness constraints (which would be a phenomenally bad database) you can't actually screw up the index. You might (with certain systems of automatically generating default IDs) cause future inserts using the default index value to fail unexpectedly, but the actual table index would be fine.

Re:HTTP methods

[Jane Q. Public]

It certainly *IS* possible to screw up the index, even if uniqueness is strictly enforced. I should qualify that: it won't necessarily cause errors on the database end, but it could make the index useless for your program's purposes. That would reflect bad design on your part of course, but that was my point.

I was simply taking exception to the comment "Rails apps ... typically do not allow you to define the ID of the record you are manipulating". That is simply not true. It is the default behavior, but you are in fact "allowed" to do it. And that is one of my pet peeves about a lot of objections to RoR: often people seem to mistake default behavior for what it will actually (and often easily) do, if you want it to.

On the other hand, by default Rails assumes that once the index is created in your table, your program itself will subsequently never actually use it for anything. In fact, in a lot of circumstances when you retrieve records they do not even contain the ID field. And that is not always completely realistic, either. Fortunately, though, you can always ":select => [:id, ...]" in your query if you don't mind being verbose.

Re:HTTP methods

[mini me]

Yes, you are right that the application can create an ID, just as "or at very least the application" in my previous post says. The end user, however, rarely, if ever, creates the ID manually. Those are not concerns that you want to burden the user with.

The documentation for Ruby on Rails is horrible

[Anonymous Coward]

I REALLY wanted to like ruby on rails, but the problem is that there is no good documentation on the internet, and of the 3 books I tried, all were designed for ancient versions of Ruby (and used depreciated functions in the first few chapters). So instead, I'm giving Django a try.

Unless Ruby On Rails 3.0 API is more stable, and there are good official tutorials, I don't think it will matter how good RoR3 is, if thee isn't enough documentation again to help newbies.

Re:The documentation for Ruby on Rails is horrible

[Stiletto]

Count me among the people who wish the Rails guys spent more time on documenting, settling the framework and standardizing things... and less on making yet another Rails version that's different than the previous ones.

We're talking about a system where (to many) it is considered "best practice" to freeze your gems, including rails, to a particular version by copying them into your vendor directory, because of the breaking changes that happen from version to version. WTF??? It's like telling a C programmer he ought to copy the standard library headers into his source tree just in case the next version of C changes strcpy().

Re:The documentation for Ruby on Rails is horrible

[arthur.gunn]

Excellent documentation, good official tutorials:

http://guides.rubyonrails.org/

One of the goals of rails 3 is indeed a solid public api.
In fact because of rails' goal to be more modular / customisable the public api is going to constitute the only communication between rails' components.

Ah, the anti-groupthink groupthink...

[SanityInAnarchy]

Do you have an original thought of your own?

Take a look at some of the replies. I see two which bash Rails quite a lot, they just actually put some thought into it. They got modded up, and you got modded down.

But hey...

Ruby on Rails promised that it will "kill developers"

I don't think anyone ever claimed that, except you.

Soon after it turned out "real programmers" can't scale a Rails app to save their job (Twitter).

They still have jobs, and Twitter still runs Rails on the web interface.

Your moment of marketing glory is over.

We're programmers. Marketing doesn't quite work if there isn't at least something to back it up -- that's why we're not all using ASP.NET.

AC was just saying what many of us think,

Nice how you post this as an AC, also...

just like PHP RoR is a great language

Nope, PHP is a language, and it's not great. Ruby is a language, but Ruby on Rails is not a language, it's a framework.

I could find dozens of reasons Ruby is better than PHP, but hey, Facebook runs on PHP.

It's praises are sung by the same group that think MySQL is the ultimate enterprise database.

Rails supports Oracle and SQL Server. But hey, MySQL still runs Twitter.

Re:Ah, the anti-groupthink groupthink...

[mini me]

Facebook runs on PHP

Actually, Facebook runs on C++ these days. Turns out that it is actually PHP that does not scale. ;)

Re:Ah, the anti-groupthink groupthink...

[SanityInAnarchy]

As the source language is actually PHP, I'm going to say that the fact that it compiles to C++ is about as relevant as the fact that the PHP interpreter itself was likely written in C.

The point stands -- get as big as Facebook, and you could be doing the same thing to Ruby code.

Respectfully, a question

[djheru]

I am a php developer that does a lot of small to medium sized apps using zend framework. I don't plan on doing anything enterprise scale, my niche is what it is. Do you see any advantage to zend framework over ROR?

Re:Respectfully, a question

[moore.dustin]

Keep using zend, especially if you are using the IDE and debugging features. In this case, go with what you know.

Zend Framework isn't.

[weston]

I am a php developer that does a lot of small to medium sized apps using zend framework. I don't plan on doing anything enterprise scale, my niche is what it is. Do you see any advantage to zend framework over ROR?

I don't know Ruby or Rails well yet. But I do know PHP pretty well. And my answer is: no. Not as a framework.

Zend Framework isn't a web application skeleton / development system. It's an over-objectified library of barely related pieces. Yeah, there's a controller and a recommended directory layout, and you can pull it together with the rest of the library and a project or two elsewhere (say, Doctrine and Smarty), but it's not a thought-out whole. The job of creating an overall architecture for your app and getting the components to work together becomes yours.

Maybe that's what you want, and if so, then Zend Framework or doing things by pieces in Ruby (say, Sinatra + Sequel + HAML/SASS) could be for you. But if you want an actual web application framework, then I'd look at something like Code Igniter or Symfony (for PHP) or Rails or Merb (for Ruby) instead.

I can answer a few of the objections.

[Jane Q. Public]

(1) It doesn't scale worth a darn.

It actually scales better than just "within reason": yellowpages, scribd, hulu, github, odeo, jango. They don't seem to have any problems. (Twitter is hardly a good example. There was a lot of debate about that and its move to Scala for some [not all] operations. Frankly, it appears that Twitter's approach to programming has been similar to its approach to its business model: "What we did isn't working, and we don't know why... but we don't know what will work, either, so we'll just try something random.)

(2) It's slow.

Yep. What do you expect? It's an interpreted, dynamic language. Nobody has yet succeeded in making a true compiler for those. It's the nature of the beast. You want something faster? Pay out the extra cash to build your site using Java or C++. But both Ruby and Rails continue to improve in speed and together today on average are several TIMES the speed they were a few years ago.

(3) It's not suitable for large projects.

Sure, if you don't know how. It actually does just fine. See the answer to (1) again. While the very top-traffic sites are not built in RoR (they are too old to have been), ebay, yahoo, amazon, and others all have Rails projects in the works.

(4) Python is better.

Maybe, if you're a masochist. Ruby and Python do most of the same things, but Ruby often does it easier and cleaner.

Ruby and Rails aren't perfect. But most of the objections come from people who don't know much about what they're talking about. Not all, certainly, but most. It can be harder to understand than Visual Basic or C++, but any newer technology has some learning curve. If you don't want to bother learning about it, then just be quiet and use whatever else you like.

Re:I can answer a few of the objections.

[dushkin]

It actually scales better than just "within reason": yellowpages, scribd, hulu, github, odeo, jango.

For a second I read that as "django" and began to weep.

Re:I can answer a few of the objections.

[Anonymous Coward]

What is the point of writing something that tries to look sensible and objective and then round it off with the utterly subjective "Python is for masochists, Ruby is cleaner"?

The only explanation: Your subconscious knows the obvious fact that Python is a beautiful language and thus subverted your entire comment.

Re:I can answer a few of the objections.

[chromatic]

Nobody has yet succeeded in making a true compiler for those.

... except for the Smalltalk people.

Re:I can answer a few of the objections.

[Jane Q. Public]

No, Smalltalk was a dynamically TYPED language. That's not the same thing. Ruby is dynamically typed also, but that is not the major issue here. Ruby is a DYNAMIC LANGUAGE, meaning that you can actually change code on the fly. Can't do that with a compiled Smalltalk program.

Re:I can answer a few of the objections.

[Anonymous Coward]

Github has regular hours-long outages. Probably not the fault of Rails, but I wouldn't be praising them to the skies just yet, especially if I were a paying customer.

Re:I can answer a few of the objections.

[Anonymous Coward]

Facebook is making hiphop available which allows one to compile php to C. Damn I can develop in php and compile for optimal performance. Sorry Ruby but no thanks.

http://www.insidefacebook.com/2010/02/02/facebook-open-sources-hiphop-php-compiler-software/

Re:I can answer a few of the objections.

[Anonymous Coward]

Ruby is "cleaner" than Python? Although we are discussing taste here, that's just laughable. Ruby designers considered Perl and TIMTOWTDI a good idea. Nothing good can result from such dogma.

Re:I can answer a few of the objections.

[Just Some Guy]

What do you expect? It's an interpreted, dynamic language. Nobody has yet succeeded in making a true compiler for those.

Thus spake Wikipedia:

The first complete Lisp compiler, written in Lisp, was implemented in 1962 by Tim Hart and Mike Levin at MIT.

And everything old is new again.

Re:I can answer a few of the objections.

[Jane Q. Public]

That's the funniest thing I have read all day. In fact, Python is not even internally consistent about its methods.

Re:I can answer a few of the objections.

[Jane Q. Public]

Sure, if you really want to count macros, and similar methods of interpreting code at runtime, like "eval()".

The other way Lisp does this is to mix compiled and interpreted code on the fly. But that's still not the same thing. The interpreted code is still interpreted, the compiled code is still compiled. There is currently no way to compile it ALL so that it works just as it would with arbitrary additions of interpreted code.

Please stop mixing apples and oranges. Ruby and some other modern languages are true dynamic languages. Smalltalk and Lisp are not.

Re:I can answer a few of the objections.

[RAMMS EIN]

``(2) It's slow.

Yep. What do you expect? It's an interpreted, dynamic language. Nobody has yet succeeded in making a true compiler for those.''

Common Lisp. There are several compilers for it that actually make it efficient. I've even seen Lisp programs beat C, C++, and Java.

Current Ruby implementations are dog slow even by dynamic language standards, but let's not forget that it's easy to interface to C from Ruby. You can alternate hard and soft layers and get _both_ rapid development and fast software.

``(3) It's not suitable for large projects.''

I tend to agree with that, but I also think most projects aren't large or at least _shouldn't_ be large. You can usually break things up in parts that are a couple hundred lines (in Ruby) at _most_, and then you don't need any "large project features" in your language. But that doesn't necessarily mean Ruby is a good choice for large projects.

Re:I can answer a few of the objections.

[chromatic]

... you can actually change code on the fly. Can't do that with a compiled Smalltalk program.

I have a Smalltalk browser here that seems to disagree with you, depending on your definition of "can't", "compiled", "Smalltalk", and "program".

Re:I can answer a few of the objections.

[Jane Q. Public]

Here is the issue:

Are you saying that you can create a Smalltalk program, compile it, run it, then change the code dynamically during runtime? Because that is what is necessary for it to be a compiled, dynamic language.

Somebody else here has already tried to claim that Lisp qualified as a compiled dynamic language, but that is not so. Some Lisp variants allow you compile programs, and still add changes at runtime, but the fact is that the code added at runtime is still going through an interpreter... it is not compiled, so it still does not qualify as a program that is compiled and yet dynamic at the same time. (According to Wikipedia, the same source he used.)

So: can you create a compiled Smalltalk program, compile it, then change the code arbitrarily at runtime... without running it through an interpreter? If so, I would be intrigued, and my computer science professors will definitely be surprised to learn about it. I would be sure to tell them.

Re:I can answer a few of the objections.

[Jane Q. Public]

In case that did not come out as clearly as I intended it: my question is whether you can compile a Smalltalk program, then change its code on the fly without using any kind of Smalltalk interpreter? And without patching the machine code of course because the code has to be code from the same language.

Because using an interpreter that way (the way Lisp does it) is conceptually no different from using the equivalent of "eval()" on the external code. Heck, even some variants of BASIC can do that... and it isn't dynamic either.

From the word go here I have been referring to the existence of a dynamic language that will allow true compilation of programs... but still be dynamic. So far nobody has yet shown me such a beast, and that was my point all along. Nobody I have worked with has ever heard of any, nor had my professors (according to their own statements) when I was in school... but they were familiar with Lisp and Smalltalk. If you truly have something like that I am sure they would be interested in examining it.

Re:I can answer a few of the objections.

[chromatic]

Because using an interpreter that way (the way Lisp does it) is conceptually no different from using the equivalent of "eval()" on the external code.

I don't understand what you mean by "compiler" and "interpreter", nor why that matters.

Does the Smalltalk JIT count as a compiler? Does Smalltalk count as an interpreter because you can add code to a running image? Does Smalltalk not count as compiled code because of the presence of an image?

If your argument is "You can't really have a compiled program if you have a runtime!" then that's silly. (Does C++ not count as a compiled language if you use RTTI? Does a C shared library compiled with -fPIC not count as compiled because the linker has to do fixups at runtime?)

And without patching the machine code of course because the code has to be code from the same language.

This assertion (as well as the mention of eval()) is a distraction. Embrace the Von Neumann architecture if you use a programming language on a Von Neumann machine. (Is a JIT compiler not a compiler because it may be written in a different language than the host language or because compilation takes place after you think compilation should take place?)

Re:I can answer a few of the objections.

[Jane Q. Public]

If you didn't understand my statement, then why did you bother to answer it in the first place??? Now I am puzzled.

What I stated was, in essence: nobody has so far managed to make a dynamic language that can be fully compiled and still remain dynamic at runtime. At the time I made it, I thought it was pretty self-evident, but apparently to many people it is not. Note that I did not say that it could not be done, only that it had not.

As for "compiler" and "interpreter", I am using the commonly-understood definitions: a compiler converts higher-level language to machine code ahead of time, and stores it in the form of an executable file; it is the machine code that executes. An interpreter converts higher-level language to machine code during runtime. There is nothing particularly tricky or unusual about the way I am using them.

My argument was not specifically "You can't really have a compiled program if you have a runtime!", although you bring up a good point, and it is part of my argument now. Again, I haven't been using any weird definitions. Languages like Java when using a runtime module and MS languages that use the CLR for example are not considered truly compiled languages. The "compiler" creates an intermediate code, often called P-code, that is interpreted and converted by the runtime to machine code. Again, that is using commonly understood industry-standard terminology. Those semi-compiled programs are not machine code, so they do not meet the definition of "fully compiled". (Incidentally, that is why Microsoft has seen fit in the past to include an "obfuscator" program with their packages: because the semi-compiled code, not being machine code, is often too easy for humans to read for it to be practically distributable in a commercial product. The obfuscator makes it difficult for humans to read.)

The fact that Smalltalk uses something like image persistence does not necessarily disqualify it as a non-compiled language, but the fact that it uses a virtual machine for runtime does. To quote Wikipedia regarding virtual machines: "Example: A program written in Java receives services from the Java Runtime Environment (JRE) software by issuing commands to, and receiving the expected results from, the Java software. By providing these services to the program, the Java software is acting as a "virtual machine", taking the place of the operating system or hardware for which the program would ordinarily be tailored.

While Wikipedia was using Java as its example, the simple fact is that a Virtual Machine in cases like this is a runtime interpreter, and that seems to disqualify Smalltalk as a fully compiled language. I am not saying that it is not dynamic -- obviously it is -- but can it be compiled AND reflective?

As far as being dynamic is concerned, Wikipedia states that "The ability of many programming languages on some systems to directly modify machine code make the distinction abstract". But I take some exception to this, because Wikipedia does not give any examples, nor has anyone else here. I mean sure, I can use just about any language that allows low-level access to grab a memory address range and change the contents of that range... but that is still not the same as being able to add or change high-level objects or methods or other structures on the fly, without an interpreter. With a dynamic language -- at least the ones I am familiar with -- I can make changes to high-level structures on the fly or even completely rewrite modules, and persist those changes to a file or other form if I wish.

"(Does C++ not count as a compiled language if you use RTTI? Does a C shared library compiled with -fPIC not count as compiled because the linker has to do fixups at runtime?)"

(1) Where does RTTI enter the picture? Are you claiming that doing a dynamic_cast<> operation makes it a dynamic language? I think that's stretching things a bit. Mo

Some other reasons singular would be better...

[weston]

A case in point: Rails likes to give your database tables plural names...One of the reasons to prefer singular table names is that it improves Rails's interoperability with the applications that either want to supply data to or consume data created by Rails..

Another reason is that it gets you closer to relational thinking. Plural names come about because some think of tables as collections of records and it follows that said collection should get a plural name. So, your "person" record becomes your "people" table.

However, the table isn't really and formally a collection of rows. What you really have is a set of "person" relations; the plural on the end of relations there is where the plural belongs.

And I don't know how big of a performance hit pluralize yields, but it's doing something that doesn't have to be done: the convention could just as well be singular (and arguably would more properly be singular).

Re:Some other reasons singular would be better...

[Per Wigren]

And I don't know how big of a performance hit pluralize yields

It adds a couple of milliseconds to the startup time and that's about it. If you didn't manually specify a table name in the class, it will use the plural version of the class name and store that in the table_name variable when you start the app. Actually, most of Rails' "magic" is performed during application initialization (dynamically creating methods and setting variables) and after that it's (internally) just running code as usual.

You can also just add config.active_record.pluralize_table_names = false to your config/environment.rb if you don't like the behaviour.

Re:Some other reasons singular would be better...

[Anonymous Coward]

However, the table isn't really and formally a collection of rows. What you really have is a set of "person" relations; the plural on the end of relations there is where the plural belongs.

This isn't the standard usage. You have a set of "person" tuples - one person, one tuple, the set of person tuples forms a relation, singular. Not sure whether mathematicians would call it a 'people relation' or a 'person relation' (I prefer the first), but calling it a set of relations is definitely wrong. (A set of relations is a set of tables in the database world).

TPS

[Luke Psywalker]

Funny, I first read about ROR on Slashdot 3 years ago, back around the 1.0 release. The only negative things anyone said back then were quips about DHH's Danish accent. Now it's matured into the finest open source development web development stack available, powering many successful web apps and all I see here are the people who should be supporting it on principles alone talking smack about it.

Re:TPS

[hibiki_r]

It depends on what you are doing with it: ROR makes some things extremely easy, and others extremely hard. If your website is mostly about doing the easy stuff, it's great. If your requirements are all about what ROR isn't any good at, ROR is worse than a dozen other frameworks, where you pay a larger upfront cost for more flexibility.

Re:TPS

[LizardKing]

Now it's matured into the finest open source development web development stack available

Tsk, tsk, you kids. I think you'll find that Spring is what you're really looking for. It's built on top of a real programming language as well, not some bastard offspring of Perl and Python like Ruby.

Re:TPS

[RAMMS EIN]

Having used both Rails (1.something) and Spring (2.something), I can tell you which I prefer.

Hint: it's not the one that tosses out the compile-time checking and performance of your so-called real programming language by having you write everything in XML.

Also, I much prefer the bastard child of several useful and expressive programming languages to a language that has set the world back a decade or so by having people re-invent and re-implement things that were working years before it.

Apologies if this comes across as if I think the world would be a better place if Java and Spring had never seen the light of day. I don't think that's really the way it is. On the other hand, I'm not convinced it actually isn't.

Don't like that name

[dushkin]

Makes me think of that girl Ruby I tied to the train tracks once.

Perl6 will be with you in a couple of months

[Anonymous Coward]

End of argument :-)

Relations and Tuples (Mod parent up!)

[weston]

This isn't the standard usage. You have a set of "person" tuples - one person, one tuple, the set of person tuples forms a relation, singular.

That's interesting. Different from the way I had it explained, but I wouldn't be surprised if I or they had gotten the terminology for tuple and relation confused, and the distinction you've mentioned does sound promising from a formal perspective.

Not sure whether mathematicians would call it a 'people relation' or a 'person relation'

To invoke my earlier statement in the language you've given, I think the question is whether or not the plural belongs on the tuples rather than on the name of the relation. And while I'm not sure what mathematicians would do, I am pretty confident about what logic programmers would do in, say, Prolog, given the choice between a people predicate and a person predicate: they'd choose the former.

Excuse me??

[Jane Q. Public]

"The only explanation: Your subconscious knows the obvious fact that Python is a beautiful language and thus subverted your entire comment."

"That's the funniest thing I have read all day."

Somebody makes an insulting personal attack, I say that was funny, and *I* am supposed to be the troll? Who is doing the modding, anyway?

I will keep posting this serious comment.

[Jane Q. Public]

"Please stop mixing apples and oranges. Ruby and some other modern languages are true dynamic languages. Smalltalk and Lisp are not."

That was a factual post. I strongly object to the label "troll" just because somebody - who obviously hasn't bothered to look it up - disagrees.

Mixing compiled and interpreted code does not make Lisp a "dynamic" language. Other languages include things such as "eval()" which allows you to do that too... that doesn't mean they are dynamic languages, either. Some are, but the ability to simply evaluate external code is not the determining factor.

Having said that, if you are using an interpreted Lisp, and not compiled code, it could be said to be a dynamic language... but then we are right back to my original statement: nobody has so far managed to make a dynamic language fully compiled.