RE: Dynamicity and Throwing Money at Problems

Brian McCallister has in interesting post on how XML is used by the Java community. I think he is right about the fact that most of the XML dialects being used in the Java world go against the grain of Java. However, I think they are not being used for dynamicity, at least by his definition. Sure the dynamicity argument is there but it is a red herring because, as Brian points out, no one actually uses the dynamicity. What these Java developers are really doing is creating domain specific languages. They need to do this because, in many cases, the equivalent functionality written in Java would be an excessive amount of code.

And there-in lies the rub, if using plain Java is too expensive and hard to maintain then the logical thing to do is to switch to language in which solving your problem is not too expensive and hard to maintain. Unfortunately, most Java developers either A) are not allowed to even consider using a language other than Java or B) have some emotional ties to Java. If A is true the logical thing to do is to write the language you really need, and want, but to call it “configuration” so that it sounds like you are still writing the app in Java. If B is true the logical thing to do is to write the language really need but to call it “configuration” so that it sounds like you are still writing the app in Java. Notice that those two are pretty much exactly the same. Either way you end up with a custom programming language specific for your domain and you call it “configuration” even though the contents are obviously source code.

2 comments on “RE: Dynamicity and Throwing Money at Problems

  1. -

    Valid points, though it was not an intentional red herring. It *is* deferring to runtime, which fits my definition of dynamicity — just nothing is gained. The DSL angle is exactly on.

    -Brian

  2. - Post author

    I agree that the dynamicity argument is not usually an outright lie, there is usually support for dynamicity, but it is a bit of misdirection because the dynamicity is rarely the primary benefit of these XML dialect.

    I think the misdirection exists to protect the developer and/or users from cognitive dissonance (I would guess that this is subconcious in most cases) or to make some managers feel nice while the worker bees actually get the job done.

Comments are closed.