A Realization on Maintainability

By Robert Fischer | Published: May 23, 2008

In a conversation lamenting the delay in conversion between academics and practice, @mfeathers on Twitter said:

We’ll see. I think dynamic typing is a classic “worse is better” scenario. Won’t win arguments. Will win longevity.

To which I replied:

Yeah, we’ll see. I’m really hoping not — dynamic languages really do suck for long-term maintenance. Ask the old Perl hackers.”

Then a realization hit me. Actually, it’s less of a realization and more of a hypothesis which needs testing. I’m curious to know what other people think.

Despite what a certain curmudgeonly ex-coworker of mine might claim, huge Perl scripts are a maintenance nightmare. They’re really a pain. Ranging from surprising overrides of $_ to wrong arguments being passed around to funky results from eval to magical exceptions, the major Perl applications I’ve worked on have had a lot of pain. The best helper to solve this problem is perl -c, use warnings; and use strict; — in other words, bringing more restrictive syntax and typing into the system. Prototypes even help, despite their unpopularity.

Yet there’s a major maintenance win with Ruby/Rails as opposed to the Java web frameworks I’ve worked on. So that cognitive dissonance hit me, and then I realized what the difference was: the configuration over convention. There’s less code to write in Ruby/Rails as opposed to the Java web frameworks, but that has more to do with all the magical injection than the language features themselves.

And there’s no reason that kind of magic can’t be done in the context of a statically typed language, provided some preprocessing to pull out the boilerplate.

At that point, you could have your cake and eat it, too.

Thoughts?

Related posts:

  1. Brief Reality Check on Ruby Jobs
  2. Ruby on Rails: One Thumb Up, One Thumb Down
  3. Java Goes Scripting
  4. Ruby on Rails: Fixtures Gotcha
  5. My Groovy-on-Grails Experience
This entry was posted in To Be Categorized. Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.
  • Marc

    A lot of folks tout the maintainability of strictly typed code over dynamic code but I’m not convinced it’s a real problem. I think it’s a problem of people not knowing how to write maintainable dynamic code. I can’t give any definitive proof of this other than to say that the Smalltalkers of the world seemed to have figured this out. There’s some huge Smalltalk systems out there (believe it or not) and I think the maintainability comes from the culture of how they write their dynamic code. At least that’s what my Smalltalk buddy tells me. :) Perl doesn’t seem to have a culture other than to crank out as much function in as little of space as possible.

    Lastly, if you want to try a Java web framework that requires ZERO XML config, look at Wicket. I warn you though, it’s not like any other Java web framework but it’s worth the effort to learn because overall it’s pretty damn brilliant.

  • http://www.linkedin.com/in/robertfischer Robert Fischer

    I’d be interested to hear more about how large, reasonably maintainable dynamic language applications are written: I’ve not seen one. Even moderately sized Ruby on Rails sites become difficult to manage, doubly-so when you start dealing with plug-ins and libraries.

    One thing I know is that I’m working on CocanWiki, which has a lot of code that’s hard to read and hard to work with. If it was dynamic code (or even Java), I’d be calling rewrite — but, thanks to Ocaml’s typing system, I’ve been able to refactor and extend it. So I’m pretty impressed with implied static typing right now.

  • Pingback: Ruby is the Future | Enfranchised Mind

  • Categories