Mid-Atlantic Design Expo (MADExpo)

I'm looking forward to this.  I'll be talking about Python.  

• A Python 3.2 tutorial.  I did a dry run with the help of the 757 Python group.  Made a bunch of changes based on their input.
• A more in-depth presentation on a good architecture of Database Schema Migration scripts.  You know, the "open heart surgery" of a database where the structure changes in some way that's not a trivial ALTER statement.

Exacting Definitions

Interesting comments to Splitting Meta-Hairs.

Terms like Scripting, Interpreted and Dynamic are not "marketing terms". New, Improved, All Natural, Visual, Groovy, Lucid, etc., are marketing terms. I regret giving the impression that one should "not to spend time trying to get definitions that are exacting". One absolutely must get definitions which are exacting. Clearly, I failed. Exact definitions matter.

Hiding behind the edge and corner cases, however, isn't helpful. Just because some terms could be redundant, or could be ambiguous (when stripped of useful meaning) isn't really a helpful thing. Harping on the "ambiguity" or "contradiction" or "redundancy" isn't helpful. Yes, Python has edge cases. Outside the purity of mathematics, no categorization is ever perfect.

Scripting. The Python community steers away from this because it's limiting. However, it's also true. What's important is that some folks overlook this and over-engineer solutions. Python modules require three things (1) an appropriate #! line, (2) a mode that includes appropriate "x" mode flags and (3) a location on the PATH to be indistinguishable from binary executables.

I find it necessary to repeat "scripting" to prevent over-engineering. Clearly, scripting isn't a completely distinct dimension of language description, but it's still an important clarification to many of the people I work with.

Python's on this scripting language list.

[We had a RHEL system with SELinux settings that prevented Python scripts from running. A sysadmin said -- seriously -- that I just needed to use `sudo su -` to get past this. The admin, it appeared, couldn't see why Python scripts should behave exactly like all other scripts. Hence the need to emphasize that Python is a scripting language. Otherwise people forget.]

Interpreted. Python is a byte-code interpreter. Saying things like "compiling to machine code is also interpreted" eliminates all meaning from the words, so it can't be true or useful. We need to distinguish between compiled to machine code and interpreted; machine code binary executes directly. And Python doesn't compile to machine code. Python is interpreted.

[The fact that some hardware had microprogramming is irrelevant; there are programmable ASIC chips in my Macintosh, that doesn't matter to my Python interpreter. There's a clear line between the binary machine code and the Python or Java interpreter. Yes, there are other levels of abstraction. No, they don't matter when discussing the nature of Python.]

You can use cython or py2exe or py2app to create binaries from Python. But that's not the interpreted Python language. This is the distinction I'm trying to emphasize.

I find it necessary to repeat "interpreted" so people are not confused by the presence of visible bytecode cache (.pyc) files.

Dynamic. Python is dynamic. Dynamic is clearly distinct from the other dimensions. There's less confusion over this word, but it still fails to sink in.

I find that this needs to be repeated frequently so people stop looking for static type declarations. The number of Stack Overflow questions that include "python" and "declaration" is always disappointing.

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?