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?!)
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.