
The Ruby Revolution is Over - petesalty
http://merbist.com/2009/11/09/the-ruby-revolution-is-over
======
z8000
While I quite enjoy ruby I truly cannot stand the attitudes of the
"revolutionaries".

------
InclinedPlane
Sorry no. At best it's the end of the beginning. If you look at any job board
and look at web dev jobs you'll notice that nearly all of the listings are for
plain old-fashioned non-mvc development, in php no less. Rails, ASP.NET MVC,
Django, etc. have all grown into respectable, practical ways of building top-
tier web sites but the MVC revolution is only just starting (as are the TDD
revolution and the functional renaissance).

Judging by the time it took the OOP revolution to play out (i.e. get to the
state where it is the accepted norm rather than the exception), the MVC
revolution probably has another decade or so before it gets to that stage.

~~~
ardit33
(as are the TDD revolution and the functional renaissance).

I hope not. TDD might work for some people, or for specific problems, but it
seems a shitty way to develop to some other ones. It just it is not a panacea.

~~~
InclinedPlane
I agree, but I think that TDD is probably under adopted at the moment. MVC has
obvious, measurable, direct benefits to development. As does functional
programming (for the right problems). The research supporting TDD is either
anecdotal or murky at best.

One of the biggest problems with TDD (and agile), in my opinion, is that it
lacks an objective feedback mechanism that makes it obvious whether it's being
applied correctly. I believe any methodology must have built-in feedback to
ensure that it's applied correctly to be practical or successful. It takes a
human TDD guru to subjectively determine if a team is doing TDD "right" or
not. Whereas other development practices, such as producing daily builds, have
obvious channels of direct feedback (do you produce a build every day, is it
broken, does it use up-to-date sources, etc.). I believe that aspects of TDD
will ultimately become part of a larger set of methodologies which together
provide obvious, measurable benefits to development of many if not most
software projects. But today the case for TDD as a one-size-fits-all
methodology is far from conclusive.

~~~
chromatic
> I believe any methodology must have built-in feedback to ensure that it's
> applied correctly to be practical or successful.

That will be difficult; TDD is a _design_ activity. You can test artifacts of
the process, such as regressions over time, amount of rework necessary, time
spent refactoring, quality of releases, and a few other metrics, but how do
you measure the quality of a design in and of itself?

You might as well measure the efficacy of individual design patterns on their
own.

> ... today the case for TDD as a one-size-fits-all methodology is far from
> conclusive.

Who suggests that it is? I'd very much like to see references to (well-
respected) people who've written "If you don't use TDD, you cannot produce
great -- or even working -- software."

~~~
InclinedPlane
I guess you've never read anything by "Uncle" Bob Martin, a leading TDD
proponent who has put forward the notion on several occasions that the only
"professional" software developers are those using TDD (he has a lot of people
who agree with him, too).

And yes, you're right, it's difficult to measure the usefulness of a design
activity. But in order to make progress we must be able to do so. Otherwise
everyone in the entire world will be doing TDD, most people will be doing it
"wrong" and we'll be no better off, and possible worse off, than we are today.
I stand by my statement. Any worthwhile development practice must have
objectively measurable results, otherwise there's no way to tell if it's being
used correctly or even if it has any value. Otherwise it becomes the software
development version of a ouija board or a dowsing rod.

~~~
chromatic
Have you read Bob Martin's "TDD Triage"? It offers a lot more nuance than you
might suggest: <http://blog.objectmentor.com/articles/2009/10/08/tdd-triage>

> Any worthwhile development practice must have objectively measurable
> results....

I thought you were asking for objectively measureable results _in isolation_.
You'll still have terrible trouble trying to isolate a single variable (and
good luck with a control group for a creative design activity!), but I suspect
you can get decent results by measuring the cost of a change, the correctness
of a change, and the amount of rework in a change when using TDD.

------
coderdude
What the author does not mention in "How did it happen?" is how a few people
with a lot of clout in the developer community made really pretty Websites
describing Ruby on Rails and used words like "elegant" to convince other
programmers that their code was dirty. Once they felt dirty, they wanted to be
elegant too. ;)

------
rick_2047
A revolution is indeed over, but it makes me wonder why was Ruby the
initiator. There were other languages which could have done the same, well
mostly. Python for example or SmallTalk to some extent. They had all the
potential, then why Ruby?Was it just because it had the first real Killer app
(namely rails) or was it some game of chance?

~~~
cturner
Python is my main language, but can understand the attraction of Ruby over
Python to people stuck with Java or PHP and screaming out for something new.

Python has stuff in it that's weird until you learn to ignore it. Example -
joining several items in a list so they're comma-separated. In python you do
this:

    
    
        print ', '.join( [1,2,3,4,5] )
    

The code doesn't work in the way someone new to the language thinks about the
problem. I've trained two colleagues in the basics of python, and both of them
gave me the "what hope did I have of working that out?" look when I showed
them this.

In ruby you do this:

    
    
        puts [1,2,3,4,5].join(", ")
    

Ruby avoids the whitespace debate but still manages to produce reasonably
pretty code. You have to type 'end' (slightly more verbose), but you save on
the colon at the beginning of the scope, and it's probably easier to write
non-functional one-liners in ruby as a result. (I wouldn't know, I love my
lambda :) )

Python's self keyword has the sitting-at-the-plugboard feel to it. So does
__init__ - the token is ugly. Then there is the unfortunate 'super' syntax.
Experienced python programmers rarely need or use it, but transitioning Java
developers think in a way that leans on frequent superclassing. The python
__name__ == '__main__' pattern is cryptic. Packaging mechanisms are ugly
(again - something Java developers will be itching to use).

I suspect Ruby presents less culture clash if you come to it from Java, and is
easier to get your head around if you come to it from PHP. Smalltalk isn't in
the same domain as tools like perl, python, ruby. I think rails rode on the
back of Ruby rather than the other way around - there was nothing
revolutionary in rails, it was an enabler for Ruby.

~~~
omouse
You're focusing on the small surface details.

Also, the words "begin" and "end" were used in ALGOL and PASCAL and no one had
much of a problem with them.

Concepts > languages/notations

~~~
overgard
When someone is deciding what language to learn, though, surface details are
the main thing they have to work with. It doesn't necessarily make it
justified, but it's the reality of the situation.

