Chad Perrin: SOB

28 May 2006

Whitespace and Instructional Programming Languages

Filed under: Cognition,Geek,RPG,Writing — apotheon @ 09:26

A discussion of the “whitespace problem” of Python occurred in another venue, and some of what was said there got me thinking. It starts with a complaint about the way Python eschews punctuation, and snowballs from there.

One particular point that came up was the assertion by Pythonistas that using significant whitespace instead of punctuation somehow reduces “syntactic clutter”, even while noting that whitespace is a part of Python syntax. It’s kind of surprising, once one stops to think about it, that these guys don’t notice that it doesn’t reduce “syntactic clutter” at all, but merely replaces one type of “syntactic clutter” with another. Depending on one’s definition of “clutter”, one might even say that Python’s approach increases rather than decreases “syntactic clutter”.

The comment that got me thinking the most interesting thoughts, though, was the one that mentioned a study that found significant whitespace provided an appearance that was “easier to read” for non-programmers than programming punctuation. I rather suspect that was skewed somewhat in favor of the significant whitespace crowd by comparing all-indentation-without-punctuation to all-punctuation-without-indentation. Of course, in the real world, nobody eschews indentation formatting in production code. It’s Just Not Done. I guess part of my problem with Python, based on that, is the fact that Python does something akin to making a law forcing people to use verbs. Everybody uses them already, and even if someone decided to avoid using verbs for some reason, it would surely be a joke that didn’t hurt rather than because they’re criminal masterminds. It’s the same situation with indentation in programming.

That note about non-programmers being better able to read it brings Ruby to mind (for me, at least).

Basically, the idea is that an instructional language has to be more than merely readable to someone that hasn’t yet been instructed. It also has to be writable and, perhaps most importantly of all, editable and debuggable. Python achieves the first of these, but demands an awful lot from rank newbies for the second (writing), and even more for the third (editing and debugging). Even expert Python programmers can have intractable issues with misplaced whitespace from time to time: I’ve heard the complaints. I’m inclined to try to insulate brand new programmers against the problem of spending an hour looking for one misplaced space in an indentation. Beginners should be learning how to develop good code, after all.

Good indentation formatting is important, but so too is everything else. A language that encourages good indentation is what’s really needed: making whitespace significant so that good indentation is necessary for the program to run is a very heavy-handed way to achieve that effect. Considering the wide range of languages available, and all the available syntactic quirks in all those languages, it seems something with a flexible syntax is more important than one that enforces a specific individual’s idea of what constitutes “good practice” — but there’s no reason to pick a language with a flexible syntax that doesn’t encourage “good practice”. In addition, anything you can do to increase the ability of a new programmer to recognize what’s going on is a good thing: eschewing end delimiters just because you think you’ve found the Holy Grail of indentation schemes and enforced it syntactically seems antithetical to that aim.

Ruby seems to provide all of these benefits, and also makes a smooth path of transition toward learning the formatting methodologies employed by other languages. What’s not to love?

That’s how I see it, anyway.

26 May 2006

Lexical Closures as Object Model

Filed under: Geek — apotheon @ 02:53

Do I have any expert Perl hackers in the audience today?

I’ve been rereading some of what Jonathan Rees has to say about the object oriented programming menu. I’ve only read this stuff about a half-dozen times before, and I’ve been reading about the Perl object model recently, so I decided to get another look at what JAR has to say about the definition of OOP.

In reading about the Perl object model, I was disappointed. My excited utterance, as I learn new things about it, is this:

Ho hum.

This is in stark contrast to my response when reading about lexical closures in Perl. Perl closures made me jump up and shout “Eureka!” (or do something a touch more dignified and me-ish, while mentally I was cavorting and shouting Greek words). With much consideration of what the Perl object model attempts to accomplish, how it relates to other languages’ object models, what I know of how CLOS was put together for doing OOP in Lisp (apparently a lot of reliance on lexcial closures is involved), and what JAR has to say about the malleable definition of OOP, I’ve come to some interesting continuations (since “conclusions” is kinda final, and I’m still in the middle) about the potential for OOP in Perl.

I have a notion that, though the object model would be fairly foreign to people coming to Perl from C++ or Java, Perl has an unofficial object model in place sorta “behind” or alongside its official object model, and it’s pretty much entirely made up of leverage applied to its lexical closures. Making use of Perl closures for object-oriented programming while entirely ignoring bless() seems to provide a pretty significant chunk of the a la carte OOP menu JAR proposes. It appears to satisfy the needs of the following points:

  • encapsulation — syntactically hide implementations of objects
  • protection — maintain a consistent API for objects by keeping client code ignorant of its implementation
  • AYCDISAM — All You Can Do (to an object) Is Send (it) A Message
  • inheritance — I’m a little sketchy on what JAR means by the two different types of inheritance he mentions, but it seems that “object oriented” inheritance is definitely possible with Perl lexical closures.

I could be wrong about a couple of those, but then some of the others could also apply. I’m not really sure. I ask for expert Perl hackers because I’d like to know where I’m wrong.

What is clearly right, however, is the fact that at least some form of object model exists in Perl via lexical closures even without bless() in the allowed toolkit. Something else that is clear, at least from where I’m sitting right now, is that this object model is much cleaner to use than the official Perl OOP tools that come to mind when someone talks about doing OOP with Perl. It’s entirely possible that some things one might wish to do with OOP might not be possible, or at least reasonably easy, without the official object model, but so far I don’t really see it. I think the major problem is simply that a Perl closure object model would be so alien to most Perl hackers (coming from a VB, PHP, C++, and Java backround for OOP, or even from Python, most likely) that they’d have to reorient their brains to adjust to the very different approach to OOP that lexical closures provide.

Seriously, folks, I’m sure I’m missing something. Please explain.

25 May 2006

EC Outlaws Software Patents, Sorta

Filed under: Geek,Liberty — apotheon @ 11:58

As reported by ZDNet in an article titled EC: Software is not patentable, the European Commission seems to have reversed its position on software patents. Previously, the European Parliament’s decision favoring the invalidation of software patents was ignored by the European Commission, which issued statements suggesting it would use the upcoming Community Patent legislation to legalize software patents. It is thus with surprise that organizations like the Foundation for a Free Information Infrastructure note the EC’s new position, that the European Patent Office will “apply and be bound by a new unitary Community law with respect to Community patents”.

The EC’s statement indicates “The draft Community Patent regulation confirms in its Article 28.1(a) that patents granted for a subject matter (such as computer programs), which is excluded from patentability pursuant to Article 52 EPC [European Patent Convention], may be invalidated in a relevant court proceeding.” At first blush, this looks like a 180 degree turn-around for the EC, eliminating software patents from the realm of EPO issuance. That’s not quite the case, though.

Based on the EC’s statements, it looks like software is still entirely patentable. This actually still allows for software patents to be requested and granted: it just allows a sufficiently filthy-rich litigant to overturn the patent in court. A potential side effect of this method of ex post facto “invalidation” of patents might be the effective shutting-out of economically less-powerful parties from using patented software while larger organizations will have free reign.

Think about it for a moment: a corporation that holds a software patent might leave other large organizations to their own devices, with all the free license they need to make use of the patented technology. The patent-holding corporation need only threaten litigation for individuals and organizations small enough to be substantially financially harmed by the court proceedings regardless of whether they win or lose. Attempting to take larger organizations to court would simply result in loss of the patent, because the larger organizations have the means to fight it, but those smaller organizations and individuals who do not have such financial means can be quite easily strongarmed by means of a software patent that can only be invalidated by expensive court proceedings. This allows for a protection racket to arise, wherein back-room deals serve to provide for easy use of patented software technologies for huge corporations and required licensing for any bit player on the market. Ultimately, the whole thing looks like an impressive scam intended to maintain power-consolidation status quo, further strengthening the strongest software industry corporations and preventing financially weaker challengers from, well, challenging.

This, obviously, would effectively screw open source software projects that don’t have significant corporate legal backing.

In that light, this “new” position of the EC makes perfect sense. The large corporations both want to be able to patent their software and want to be able to use others’ technologies without having to pay for them, and they all want the little guys to be shut out of the market. Now, they’ve found a way to do it: allow software patents to be overturned if sufficient money is available to pursue the matter in court, but otherwise allow patents to be registered and approved, providing a means by which they can be enforced by threat of litigation. It’s enforcement by attrition.

Older Posts »

All original content Copyright Chad Perrin: Distributed under the terms of the Open Works License