Dynamic Languages

By Deane Barker on August 12, 2004

Dynamic Tools for Dynamic Languages: After reading the “Programmers are Idiots” essay that Joe posted last week, I got to thinking about my situation. Am I actually a programmer? I came to the conclusion that no, I’m not — I’m a scripter. I work predominantly on the Web, and while I can “program” in Visual Basic, I work best in scripting languages like PHP.

I guess I like to think that I solve problems, regardless of method. I may not fire up a C++ IDE and compile stuff right and left, but my company comes to me with IT problems every day (every hour, sometimes), and I manage to solve 90% of them. I use all sorts of languages and technologies, but at the end of the day, problems are solved and business continues to improve.

(I will admit, however, to a concerted attempt lately to program some things in VB.Net. Why? Because while I may not consider myself a “programmer,” I do enjoy getting paid like one. And, sadly, you don’t see many job postings for “problem solver.”)

Related to all this is the essay linked above. It’s a Very Important Thing. It’s very long, but it has good headings, so you can skim it.

The author attempts to redefine traditional “scripting” languages like Perl, Python, and PHP as “dynamic languages.” It’s essentially a call for respect — these languages may be as glamourous as Visual Basic, Java, and C++, but they solve as many problems. Oftentimes more.

Just as Linux was suddenly recognized as a significant platform choice after years of being “snuck in through the back door”, high-level open source programming languages are becoming recognized by mainstream analysts as key pieces of an effective approach to building software.

[…] The strengths of these languages derive from their open source nature, from their pragmatic approach, and from their constant evolution in response to real user needs. Ignoring them is equivalent to ignoring the hammer in your tool chest because you’ve just been sold a fancy screwdriver.

So, am I a programmer? Or am I a scripter? Or am I just a guy who solves problems through a broad base of experience with what a lot platforms, languages, and applications can do?

If it were up to me, I’d much rather hire someone who knew a little about a lot, and who could analyze a problem from that perspective before coming up with a solution that was centered around making the problem go away rather than using one language over the other. Of course, sometimes you need a specific type of programmer, but just as often, you don’t — you really just need a problem solver.

But maybe I’m just making excuses because I don’t have CS degree and I hate compiling stuff. Perhaps I’m just bitter.



  1. I guess I don’t really get the distinction you’re drawing between ‘scripting’ languages and ‘real’ languages. It’s largely a perception thing. For instance, you’re thinking of VB6 as a ‘real’ programming language, but it runs from an interpreter that must be present on the machine. The only compiling it really does is bundling up all the resources it needs into a file and breaking things down to an intermediate language that’s less useful to decompilers. You consider Java a ‘real’ language, but it too can’t run without its managed environment.

    The author of the article is sort of asking us to rethink the weird categorizations we have for languages, while at the same time creating a whole new set of weird categorizations. I particularly like that he adds a ‘Proprietary Languages’ category to try to scare us off of .Net, Java and other company-provided languages. I’m sure his motives are totally innocent, since it’s not like ActiveState has a stake in the language tools market … oh, wait. Hmm.

    The big distinction I see in modern languages are the ones that run at the OS level (C, C++), and the ones that run in some sort of managed environment (everything else). Virtually all day-to-day programming these days is done in the latter group, because the managed environment boosts your efficiency. Chasing down memory leaks does not add functionality to your application, so why should I have to write a bunch of extra code to manage memory? The only things that really need to be written closer to the metal are high-performance apps (like 3D games) and things that need to wedge into tiny spaces (and even cellphones can hardly be considered tiny these days).

Comments are closed. If you have something you really want to say, tweet @gadgetopia.