PatronizingLanguages

July 13, 2009
Michael Feathers writes about “Ending the Era of Patronizing Language Design”, and while I seem to agree, and I also seem to have sympathy for this dissenting comment by Coda Hale:
I've worked on a few Ruby projects which have failed to deliver sufficient business value, and it usually boils down to a codebase in which it becomes progressively harder to reason about side-effects of modifications, even with good test coverage. This isn't inevitable by any stretch of the imagination, but when everything is mutable one must be incredibly disciplined at all times. (And one usually isn't.)

Maybe it's not sympathy, just fear.

It makes me think of the times working in large legacy codebases and being appreciative for tools like ReSharper and Call Hierarchy in Eclipse which helped me proactively track down every code path that could possibly be effected by a change I needed to make.

But those codebases didn't have good test coverage at all. Or good design.

It's not hard to imagine a nightmare legacy scenario in Rubyville, but is that just giving into the fear? And as my friend Glenn writes, nightmares can happen in any language.

tags: ComputersAndTechnology
comments powered by Disqus