To Ruby evangelists: Be careful of what you wish for.

I watch with interest from the sidelines as the ADD crowd launch into the failures of Java and how terribly difficult it is to use etc. I watch as they struggle for recognition of their favourite language and framework and about how much “better” it is. I read the blogs from both sides of the fence and occasionally taunt Rubyistas that I know (like Jon Tirsen), but that’s out of fun, not spite.
I’m a Java guy, have been for years. I was a C guy, was for years. I’ll be a Ruby guy if I need to. Like what Michael Yuan says, the language is the lowest lever on a software project (and something I’ve blogged about before). (Oh, and Ruby guys, cut Michael some slack, he’s a J2ME developer, one of the most marginalised of the Java developers, only slightly about JINI developers. He knows exactly the pain you’re going through. Read the damn article.)
Now, here’s a little history for your Ruby-on-rails zealots. I was a Java evangelist (and some would say I still am) for meany years, and suffered the same issues in trying to get Java to replace C++ for development when it was suitable and warranted it. I’m very happy that I’ve been able to do that, and it was a positive experience.
Those times are past, and Java is the de-facto standard. All the evangelists have packed their bags and have either moved to Ruby or Python or whatever, or are happily living in Java land (like me). What happened after the early adopters and the evangelists arrived is the vast amount of “developers” who were now using Java that basically are mind-numbing morons.
They have no interest in software development as a craft, so out comes the mind-numbing crap (3000 line long methods anybody ?) and the fodder for the next set of evangelists to latch onto. Wow, so is it a great surprise that morons produce worse code than the early adopters ? It’s not Java, it’s the morons.
Soon, when Ruby (on Rails) becomes the new defacto standard for simple web development, and the VB morons who became Java morons will be forced to become Ruby morons.
It appears that the worst possible thing that could happen to a language or platform is when it becomes the new de-facto standard. The corporate developers just screw it up for the rest of them. Look at the grumpy old guys who lament lost loves like Smalltalk, Lisp and to a lesser extent Python. Languages while not dead, but never made it into the mainstream/corporate and remained with highly motivated, early adopters that continue to produce high quality solutions with those languages.
So, with all that said – do you really want Ruby on Rails to become the next big thing ? Or would it be better if it was kept quiet and just used by people who know what they are doing ?
In some ways I wish Java wasn’t as popular as it is today. But maybe I shouldn’t wish for that either….

Advertisements

19 thoughts on “To Ruby evangelists: Be careful of what you wish for.

  1. Couldn’t agree more.
    Having payed with RoR for a bit now and attempting to grok the “paradigm” I’m pleasantly surprised at how simple (note I didn’t say easy) it is to build sophisticated applications.
    However, I do think it’s VERY easy to create utter rubbish; as easy or more so than say struts. I firmly believe that for your “moron” (as you put it) vb/java/web/etc developer, making the necessary paradigm shift will be largely impossible.

  2. That’s been a point I’ve been making for sometime: as soon as a language goes mainstream, you get mainstream developers. And many of these just aren’t any good, and don’t really care about it.
    Anyone who goes out of their way to learn Python or Ruby or Smalltalk cares about their craft enough to do it without an economic incentive. A lot of people who learn Java just want a job. That’s the price of Java’s success.
    (The other thing that scares me about RoR is the sheer amount of “magic” behind the scenes…)

  3. Yeah, Jon, totally agree with you there. Having tried out Ruby after having been a Java guy for 8+ years, the only thing that I really miss in Java is the elegance of blocks. And I definitely second Simon’s point about it being easy to screw up RoR code. Everything’s nice and beautiful *as long as you get OO*, and *as long as you know how to use Ruby*. Unfortunately, in my experience, the problem is that most developers don’t even *get OO* to begin with, and there lies the deeper issue. The largest RoR project I’ve heard of (BaseCamp) clocks in at 4k lines of code. I’m sure that’s going to change once RoR gets more mindshare (wink, wink – say no more šŸ™‚ )

  4. I agree 100% (as a Ruby and Rails fan). More and more crap is already creeping into Rails, I can only hope the developers stay true to their roots and keep it small.

  5. My first two years as a professional programmer I worked with Common Lisp. I loved Common Lisp, still do. Problem is: Common Lisp is utterly dead. I could possibly get some work as a Common Lisp programmer but my salary and my options on where to work would be significantly constrained.
    Making Ruby and Ruby on Rails mainstream is not going to be without pains, but it’s better than the option: Killing it just to keep the bozos out.
    The other side to Ruby entering the mainstream is that, sure we get the “morons” but we also get more brain-power in general thinking about it. For example, it makes me very happy to hear that someone like Simon Harris is starting to have a look at it. The brain-power of Simon Harris alone will compensate for at least one hundred thousands “morons”. There might be a lot of crap in Java but there’s also some amazing libraries and frameworks (one late comer is for example Spring WebFlow, you should have a serious look at that). Given that the Java platform and language is so vastly inferior to Ruby we’re going to see some amazing stuff coming in the future.
    Oh, and that languages don’t matter to a project is just complete bollocks. I’ve been doing quite some bit of Cobol lately and I’m telling you: language does R-E-A-L-L-Y F-*-C-K-I-N-G matter. Anyone that’s done both Cobol and Ruby (or Java for that matter) will concur.

  6. Robert, there’s actually surprisingly little magic in Rails. Just something like Hibernate or Spring or Struts has a lot more magic going on. Rails has a lot of “sensible defaults” which may look like magic if you don’t know how they work. Once you know how it all works it’s pretty simple to understand. This isn’t something that happens automatically, you need to work with it for a couple of weeks before you understand it. (You can still be productive, but it’ll feel like magic.)

  7. Just responding to the “languages really matter” comment (and it’s ok – you can swear on my blog). Yes, they do matter. But they’re not a first-order determinant of success, or schedule.
    And yes, I’ve done C, C++, Java, Cobol, Perl, Pascal even, Fortran all in commercial programming, in teams of people, over a long period of time.
    If you, and Simon Harris (dead-set-legend) decide to write code – that is a damn sight more likely to succeed regardless of the language that is used.
    Of course, exactly how much difference is also important. Studies (by the CMM guys no less) have shown that language differences are expected to have less than a 10% difference in project schedule from the “worst” choice to the “best” choice.
    So, as Michael Yuan was saying. You’re better off choosing to optimise some other aspect, because requirements, development practices etc, are likely to offset any declines in poor language choice.
    Something that I can agree with.
    However, on the shit-stirring front – what the hell are you doing Cobol for ?

  8. Oh, if the CMM guys says it is so, then surely it must be so. šŸ˜‰
    This might be the case of tools rather than language and in that case maybe that is so: In the Cobol environment I’m working in order to get a simple debugging trace output I need to add a new value to the CICS dataset, recompile, rebind, relink. A process of around 30 minutes. In Rails: I make the change Alt-Tab to the browser and refresh, less than 3 seconds. In Java it’s around 30 seconds (and I’m an expert in setting my Java dev environment up so it’s as fast as it can possible be in Java). These are orders of magnitude in difference and because this time period is about staying in your flow and not being distracted I think these times have an actual exponential impact on productivity.
    10% my ass. Maybe if you’re doing CMM level 3-5.
    I’m doing a project where we’re reimplementing a lot of green screen functionality on the web. In a stroke of genius the client project sponsor decided to actually have the mainframe guys on the team. Wow! This is the way to do mainframe integration! So I’m pairing with the mainframe guy, we write an integration test in Java, switch over to the mainframe green screen window and implement it in the mainframe. Doesn’t work, switch back, do a bit of tweaking, switch back to green screen, more tweaking and so on. It’s great!

  9. Keep your sarcasm in your pants Tirsen. The CMM guys and gals have been studying software engineering for more years than you’ve been alive.
    When I talk about the “CMM guys” I’m talking about the SWE group at CM. Some of which were involved in developing the approach for the CMM (which, despite your ignorance is quite friendly to Agile processes) and most of these guys and gals approach to developing software are the sorts of lean development practices and “waste” identification.
    So maybe, reading and comprehension for the win ? But of course, you’re the one doing Cobol these days, and not me. So maybe I should just sit smugly back and enjoy it ?

  10. No now children, play nicely šŸ™‚
    But seriously, I don’t believe the language per-se has as much to do with it as the tooling. I hate to admit it but I’ve come to the conclusion recently that our ability to be agile and go fast is as a direct result of the tools–as opposed to the language.
    The language and the _actual_ facilities provided do, to some degree, influence what kind of tooling is possible as does the adoption by a community smart enough and motivated enough to build the “right kind” of tools.
    Further to that is the ability of the developers to _actually_ grok the paradigm, the methodology and the language and toolset that facilitates these.
    I still maintain that Tools+Process+Monkeys doesn’t equal success.
    Horses for courses: if you are capable of “getting it” then you will be more productive. I not, you’ll simply produce garbage faster–at least initially–than you otherwise would.
    So again, the conclusion I have to draw is that while tooling is important, I suspect that Jon Eaves/Tierson/your favourite uber-geek+Textpad+Cobol is still going to be produce “better”, more reliable code, possibly even faster, than most developers I’ve seen using WSAD. Honestly!
    My 2 cents worth.

  11. Eaves, if these guys are honestly saying that there’s a 10% difference in productivity between doing a project in say Assembler compared to say Java then it doesn’t matter if they’ve studied software development since the birth of time. It’s still completely nuts.
    Hopefully you’re just misquoting them. Nobody can be that stupid.
    FYI, I’m not ignorant regarding CMM. I was working on a company on our way to level 3 a couple of years before I joined ThoughtWorks. Some of it is good (the agile friendly stuff) some of it is really, really bad. But of course, like most everything else it can be used as an excuse for the most pathetic development practices conceived by a corporate mind.

  12. This is not intended as inflamatory but I believe it’s pertinent.
    I know a group of three guys who have been doing assembler developement for close to 30 years now. People contineu to say to them “You’re doing it all wrong!” In fact the MD–a friend of mine–loves to repeat that quote. Why? Because even though they buck all the trends in the industry, they are still more productive than most Java shops I’ve been involved with. And the reason for this?
    They understand the software very well, they know how to do assembler VERY well, they have developed tools and techniques that allow them to do so and they understand the domain very well.
    Does that make assembler more productive than Java? No of course not. Does it make Java more productive than assembler? No, of course not.
    If I asked those guys to start doing Java they would be as unproductive as the next corporate IT department. Sure, one day they would come up to speed–they are super smart guys–but the fact is that they’re in a groove and they can pump stuff out as fast–or faster–and as reliable–or more so–than the Java shop down the road.
    So you see, the language isn’t THE only factor in productivity.

  13. My last comment. Yes. They are saying (and I agree with) that the overall change to the project cost and schedule (which is what I said originally, and what Michael Yuan said in his post) is about 10% from the best language choice to the worst language choice.
    A project is not just the 5-10 devs working on it. There is the BA’s the management, the delivery teams, the testing teams, the infrastructure and deployment teams. The whole project cost, not just the tiny-weeny scope of the project that is software development.
    The productivity hit in choosing the worst language just doesn’t matter in the overall scheme of things. Moving into an organisation where the deployment costs would be close to 30% of the project (final testing, production builds, massive fear) it makes a lot of sense.
    If you’re only thinking that I’m saying “language choice only makes a 10% difference to the productivity of a developer writing code”, then I suggest (as I suggested before) that you read my comments more carefully. I’ve never believed or stated that.
    If we took a project that started with the first line of code written and finished when it compiled and ran all the tests, and there was no other interactions with any other people other than developers, I’d say that sensible language choice makes a 50+% difference, mostly due to the tooling and libraries available rather than the core language. Of course, the people on the project will trump that every thing.
    Just one more thing Jon. How’s Groovy ? (runs for cover)

  14. I’ll delete comments that are just ad-hominen attacks and add no value. Don’t bother putting them in here Anonymous Cowards.
    If you want to disagree, feel free, but at least have some intelligence behind your comments.

  15. Does language alledgely make a 10% difference before or after you include the morons?
    Language definitely makes a difference (more than 10%) to me – some languages seem to be a better match to how I think.

  16. I will do my darndest to by an Uber Moron and undo all the 100 000X boost that Simon getting involved with Ruby will do.
    Seriously, it can’t hurt to play with the latest bandwagon as it speeds past. You can learn something from anything. Its not like we play golf instead or anything.
    Grails (groovy on rails) looks like its come aways in recent times. And it is kind-a java, and can run interpreted to get the “hit F5” type change visibility. And JRuby list is getting busier with people trying to shoe-horn rails into it.

  17. As a RoR and longtime Java developer, as a developer of Z80, 6502, 68k, Basic, Pascal, E, C, C++, PHP, Ruby, Perl, Python, Java, a lot languages I have forgotten and whatever-the customer-decided-was-best apps, the main problem in software development was always the customer and not knowing or frequently changing the requirements or different people with different requirements at the customer.
    The chosen programming language was sometimes annoying but never the problem in creating new applications.
    bye
    -stephan

Comments are closed.