Less Condescension, please

I generally like the writing on lesscode.org but I have to take issue with the tone of History Repeats Itself. Mr Bunardzic is basically right about the fact that Java succeeded because it was simpler than C++ and that it looks like Ruby might succeed because it is simpler than Java but I really dislike the condescending attitude he has toward programmers stuck in static languages.

The last line of the post is, “The full fledged OO nature of Ruby, coupled with its dynamic nature, may prove to be too big of a challenge for the average application developer out there.” I think that Mr. Bunardzic both over-estimates the difficultly of dynamic OO languages and under-estimates the capabilities of the average programmer. Most programmer use static languages not because the are dumb and cannot handle the power of dynamic OO languages but rather because that’s what they were taught in university and it is what they can get paid to do.

I have trained several static language programmers (hi Mike and Navdeep) to use a dynamic, pure OO language in a previous job and I have yet to meet one that found it to be “too big of a challenge”. There is a learning curve and programmers who have only worked in static languages are not going to be dynamic language gurus overnight, but they are able to produce useful results in about the amount of time it takes to learn any language and its libraries. Probably even less because in a well designed dynamic language, like Ruby, there are a lot fewer mantras to remembered. (Imagine not having to mumble the same six lines of code plus comments over and over again just to get attribute accessors.)

So if you are a static language programmer thinking of trying out a dynamic language, fear not, you are up to the challenge. Dynamic languages are good because they require less mental effort to get the job done.

5 thoughts on “Less Condescension, please

  1. I think you may have misunderstood my concerns. I have been teaching object-oriented development at the local colleges for 5 years now, and I’ve seen what sorts of challenges they pose to procedural developers. As most people would agree, the transition from procedural to object-oriented is very difficult for many developers. I can testify from my first hand experience that many procedural developers attempting to make a transition do not extend themselves to truly try and OO way of doing things.

    Instead, quite typically, many of my students take the OO constraints that come with languages such as Java, and use them as a simple structure for hosting their procedural code.

    I’ve seen reams and reams of code written in Java where procedural code was masquerading as OO. Needless to say, the resulting applications usually end up being a huge ball of mud. You can read this as being condescending, but I just call it as I see it.

    My concern is that if the community has consistently shown such resistance toward static OO paradigm, their resistance towards a fully dynamic one will probably be even greater.

    This is strictly my personal perspective, which is biased and tainted by my own quirks. But that’s the only thing I can go by, since I’m not placing much emphasis on the overall hype that’s being passed around in the media.

  2. I have also seen a few people use OO constraints as nothing more than “a simple structure for procedural code”. However, most of the programmers I know have reasonably solid OO design skills and I think that procedural to OO is a much bigger leap than static to dynamic. The concepts are all pretty much the same in static and dynamic languages. I think that most programmers will not have too big a problem with dynamic OO languages once the tide shifts in the job market.

    (Meta-programming is a different issue all-together, though.)

  3. I suspect that many developers have been introduced to OO through almost-but-not-fully OO languages. So, first they are told some general OO concepts (communication only through messages; encapsulation; objects can be extended through inheritance, whatever). Then they are told that their given language doen”t actually allow for X amount of OO behavior.

    So, they end up working with a language that is “OO, except when it isn’t”, and have to learn all sorts of exceptions and workarounds and busy-work scaffolding. Little wonder they think OO is hard. They learn that every moderately complex operation involves some chain of Factory objects and Buffer objects and Transformer objects followed by Iterator and Collection objects. And it might all fall to pieces except for the salvation of static typing.


  4. Dynamic languages aren’t too hard to get used to. But I do prefer static in most cases. I think for me, it’s primarily because the compiler (or, in my case, my IDEA IDE) reveals a lot of my typos and design errors early and painlessly. But that might be revealing my own weaknesses as an engineer — I don’t know. Most of the Java development I’ve done, including my current gig, has been a solo act. So I’ve had a lot of freedom to re-factor when things have gotten ugly, because there was no danger of messing up somone else’s work. And my IDE makes re-factoring a breeze. (Are there dynamic language re-factoring tools?? Peter, it seems to me you and I have discussed that it might be impossible to make such tools to be used with dynamic languages. I haven’t tought about this stuff for a while, so I’m rusty again.)

  5. I have seen some pretty strong work in the area of refactoring tools in the dynamic languages. The first refactoring tool I am aware of was written for Smalltalk, a very dyanmic language. I am quite dissappointed by the refactoring tools in IDEA and Ecplise (those are the only ones I have tried). They are, for the most part, just search-and-replace or cut-and-paste, both of which I can do with out all that weight. Auto-completion, on the other hand, is a vice of mine, and that is harder to do with a dynamic language. I did read someplace that someone was working on a auto-complete feature which, statically, anaylsed the methods called on a particular object to decide it’s class.

    My real point, however, was that it is not particularly hard to use a dynamic language. Even if you have only used static languages in the past.

Comments are closed.