Wednesday, January 20, 2010

Splitting Meta-Hairs

Recently, I've been involved in some hair-splitting over the nature of Python.

I've described it as "interpreted", "scripting" and "dynamic", all of which seem to be true, but yet each seems to lead to a standard -- and pointless -- dispute.

Yes but No

Some folks object to "interpreted". They feel a need to repeat the fact that Python is compiled to byte code which is then interpreted. Somehow, compiling to byte code interferes with their notion of interpreter. Further exploration of the objection reveals their unwavering conviction that an interpreter must work directly with the original source. And it must be slow.

Eventually, they'll admit that's Python is interpreted, but not really. I don't know why it is so important to raise the objection.

So noted. Are we done? Can we move beyond this?

Scripting Means Bad

Some folks object to "scripted". They insist that scripting languages must also include performance problems, limited data representation or other baggage. Python is a scripting language because it responds properly to the shell #! processing rules. Period.

I don't know why it's important, but someone feels the need to object to calling Python a scripting language. Somehow the #! thing doesn't convey enough complexity; scripting just has to be bad. Pages like Wikipedia's Scripting Language don't seem to help clarify that scripting isn't inherently bad.

Again, objection noted. And overruled. Scripting doesn't have to be complex or bad. It's just a relationship with the shell.

Further Nuances

I'm baffled when some folks take this further and object to Scripted and Interpreted being separate terms. I guess they feel (very strongly) that it's redundant and the redundancy is somehow confusing. A shell script language pretty much has to be interpreted, otherwise the #! line wouldn't mean anything. I guess that this is why they have to emphasize their point that Scripted is a proper subset of Interpreted.

But then, of course, Python is technically compiled before being interpreted, so what then? What's the point of bringing up the detail yet again?

Dynamic

More rarely, folks will object to using Dynamic and Interpreted as separate dimensions of the language space.

Hard-core C++ and Java programmers object to Dynamic in the first place; sometimes claiming that a dynamic language isn't a "robust" language. Or that it isn't "safe enough" for production use. Or that it can't scale for "enterprise" use. Or that there are no "real" applications built with dynamic languages.

Once we get past the "dynamic" argument, they go on to complain that dynamic languages must be interpreted. The byte-code compiling -- and the possibility that the byte code could be translated to native binary -- doesn't enter into the discussion early enough.

Also, some folks don't like the fact that an IDE can't do code completion for a dynamic language. To me, it seems like just pure laziness to object to a language based on the lack of code completion. But some folks claim that IDE auto-completion makes VB a good language.

Hair Resplitting

How about we stop wasting so much bandwidth resplittting these hairs? It's scripted. It's interpreted. It's dynamic. How does it help to micro-optimize the words? Even if scripted really is a proper subset of interpreted, these prominent features solve different kinds of problems; it seems to help the potential language user to keep these concepts separate.

Can we slow down the repetition of (irrelevant) fact that Python is compiled (but not to executable binary) and interpreted? It's not confusing: byte-code compilation really is a well-established design pattern for interpreted languages. Has been for decades. Applesoft Basic on the Apple ][+ used byte-codes. Okay?

Duck Typing is not a "flaw" or "weakness". Binary compilation is not a "strength". It's trivial to corrupt a binary file and introduce bugs or viri; binary compilation is not inherently superior.

Can we move on and actually solve problems rather than split meta-hairs?

Advertisers

About Me

Steven F. Lott is a consultant, teacher, author and software developer with over 35 years of experience building software of every kind, from specialized control systems for military hardware to large data warehouses to web service API's.