The Differences Between Dynamic/Scripting Languages and “Regular” Languages No Longer Matter

If your software development experience comes from the old-style world of compiled languages, such as C++ or COBOL, you may be a little mystified by the new generations of scripting or dynamic languages. Now you have “modeling” languages to worry about, too. Do any of these names matter, when it comes down to choosing the best language to solve the programming problem? Probably not.

I’m not saying that there is no technical difference between the various language types. Absolutely, there is. It’s just that, when push comes to shove—that is, when you need to answer, “Which is the right tool to solve this problem?”—the distinction is largely academic.

It used to mean a lot more. If you’re an old fogey (as I am) you may need to revisit your assumptions. “Regular” programming languages were for “real” applications that would go into production. Scripting languages (starting with EXEC on the mainframe, which later became REXX) were about creating an automation process and running system commands. These evolved into shell scripts and batch languages. You could do a lot more than system commands with scripting languages, of course (Teach Yourself REXX in 21 Days, which I cowrote, included a checkers program), but writing applications wasn’t their primary role. These scripting languages were (and are) dynamically typed, but that wasn’t a big deal; it just contributed to their usefulness as “quick and dirty” tools.

Another side issue in the acceptance of interpreted languages may have been that they were inherently “open source.” Anything you wrote was human readable rather than turned into executable code by a compiler. That openness is part of what inspired the early PC industry; you could download a BASIC program from a BBS or type in the code from a computer magazine and do something useful. But any “enterprise” application needed to be written in a compiled language to protect the company’s intellectual property. (Or so the boss believed.)

As software development moved to the Internet generally and the Web specifically, it became more important for software to respond dynamically. The disadvantages of interpreted languages became irrelevant; an application server spends more time waiting for user input than responding to it. And these languages (back when we’d have said they were “emerging”—I’ve think they’ve now emerged) were all consciously open-source, with the geekiest developers quietly doing their Web-thing without the attention of anyone in the CXO hallway noticing if the software was written in company-approved .NET or Java.

Meanwhile, somewhere in there, “scripting languages” turned into “dynamic languages;” if anybody makes a technical distinction between “scripting” and “dynamic,” I don’t know what it is.

And then there’s the question of whether a language ought to be classified as dynamic at all; that issue was raised after I wrongly called Scala a dynamic language in 6 Scripting Languages Your Developers Wish You’d Let Them Use (you can see my non-technical explanation in its comments). For Scala user Ricky Clarkson, writing in a discussion list, the distinction isn’t necessarily whether the language has a type system, but if it is “an essence or a ceremony language.” Apparently that mainly means whether the language requires explicit type annotations throughout; if it does, it’s a ceremonious language. (Who comes up with these terms?!)

Clarkson added, “I expect that most people who say scripting language as a positive thing won’t be able to define it other than ‘dynamically typed,’ though what they probably really mean is ‘easy to read.'” Yeah. Probably.

So, as my friend Matt Birmingham pointed out, the only reason to choose a compiled language over a dynamic language is application speed and storage. Code that needs to run in milliseconds or must fit into 2K clearly needs to be compiled. But that probably isn’t true of your intranet applications or your typical SOA project.

I find curious the perception (at least among some programmers using dynamic languages) that someone might think negatively of their choice, whether that’s Scala or Ruby or Python or JavaScript. Realistically, I don’t think this is a big concern. The use of scripting/dynamic languages is growing rapidly, no matter what industry segment you look at. These languages are being used for projects of every size. The big concern seems to be whether a particular language is the right tool for this task—which is, I think, as it should be.

But still… companies continue to tell developers what languages they may use. We support Java; we don’t want you writing in Ruby, whatever. I’m not sure how prevalent it is for companies to control the languages a developer is “permitted” to use (much less how often the rules are ignored). (I’ve attached a poll so we can both learn the answer; please chime in with your vote.)

Which leads me to touch lightly on modeling languages, the latest buzzword in programming languages… sort of. Modeling languages have been around for a long time, but most programmers probably think first of UML rather than a generic category. (There are lots of choices, but UML is most familiar to corporate developers, especially since its dad, Grady Booch, is such a recognizeable figure.) Modeling languages (and domain-specific languages, yet another wrinkle) have recently gotten more airplay in programming circles, in part because Microsoft drew attention to these subjects by announcing Oslo’s modeling language, code-named “M.” Personally, as CIO.com’s programming grrrl, I need to pay more attention to these subjects and to share the information with you. Watch this space.

As a starter, though… I’ve had this response from Grady Booch to my “M” language article banging around my in-box for a few weeks, and I haven’t had an opportunity to share it. (Originally, I was going to include his comment in a write-up of the PDC Future of Programming Languages panel, but since that entire presentation is online I’m obviously not going to bother. It was a great discussion; I do recommend watching the video.) It seems appropriate to include Grady’s response to M here, given the notion of the role of various languages:

“I’m skeptical of any new non-open language—while one might have built a better mousetrap, it’s still very difficult to get people to beat a path to your door for there are all the attendant deals of tools for debugging and configuration management, and the vibrancy of the tribal community that grows the ecosystem for that language. Time will tell—as measured by the value this language adds to solving real problems.”—Grady Booch, IBM Fellow and one of the “Three Amigos,” the founding fathers of UML.

Do you make a distinction between dynamic languages and “regular” ones? Does your IT shop? And do you see a major impact from modeling languages (whether UML or some newfangled one)? (We’ll leave dynamic languages to another time.)