Chad Perrin: SOB

10 March 2006

The Problem With Python

Filed under: Geek — apotheon @ 07:15

This is the second installment in what will hopefully be a longish series of explanations of problems I see with programming languages. I say “hopefully longish” because I hope to learn enough about a lot of languages to be able to continue this for some time to come, though future installments are likely to come much more slowly than these first two did.

I have some personal issues with Python that go beyond problems with the language itself, of course. For one thing, I don’t like the lack of end-delimiters for blocks of code at all. I’ve been known to say that Python makes my eyes bleed. It just looks wrong. All of that aside, however, it is of course not perfect in and of itself, as no language is perfect.

There are two things wrong with Python:

  • Rigidity
  • Rigidity

No, that’s not a typo. I really did mean to list rigidity twice. There are two types of utterly gratuitous rigidity screwing up Python.

The first is the rigidity of the language. This is actually great for teaching programming, as long as you’re trying to teach programming to students who think in a manner compatible with Python’s rigidity. It is like Pascal that way — it does things in a very carefully and rigidly structured way that helps to teach good habits to beginning programmers. Pascal was for years the de facto standard for an instructional programming language because it could teach “good habits” by way of its rigidity. As Pascal was to compiled languages in academia, so Python has come to be similarly useful amongst similarly dynamic languages.

Unfortunately, it can also contribute to tunnel vision in the student if you never let the poor student know that “good habits” aren’t synonymous with “the One True Way”. One of the marks of a true master is that (s)he knows when to break the “rules”, to discard those good habits, in favor of some elegant and unexpected solution where the “right thing” is, in fact, wrong.

Python makes that sort of thing very difficult. It does a fantastic job of dragging programming to a greater average level of elegance than Perl for instance, but to gain this it exchanges some potential for greater elegance. More to the point, however, in order to get that greater average level of elegance for programmers suited to Python use, it gives up a great deal of usability for many, many more programmers who don’t think exactly like everyone else in the Python community. That problem for many programmers is most clearly demonstrated by The Whitespace Problem. Indentation has a single Right Way in Python, and not only are you considered Wrong if you do it differently, but you simply can’t get the damned program to run. This is a problem with pretty much everything in Python. If you don’t like the way something is generally done in Python, you’re Wrong, and not only are you Wrong but your Wrong Way of doing things often won’t work, period.

The second type of rigidity screwing up Python is community rigidity, which is actually an outgrowth of the root cause of the language’s rigidity. This problem has been referred to as the Permafrost Problem — the Python community is permanently frosty to anyone that doesn’t think like the Python Collective, generally speaking. If you don’t do things the Python way — what to the Python community is the Right Way, with all other things being the Wrong Way — you’re Wrong. There are no appeals, though you may rehabilitate with dedication and contrition. It is in large part because of this second form of rigidity that the first form will probably never be fixed. Then again, maybe it shouldn’t be. As I said, it’s good for teaching good habits, and it’s still a good language the way it is. Its rigidity is useful a lot of the time.

An example of the problem of both forms of rigidity is Python’s handling of lambdas. Ruby, by contrast, allows anonymous “blocks” to be used and passed around as though they were individual discrete semantic elements. Python lambdas, on the other hand, do work similarly, but are (arbitrarily) limited to a single statement. Because of the rigidity of the community and core developers’ attitudes, that’s unlikely to change any time soon.

As with Perl, it would be nice if there were a binary executable compilation option for Python, but that’s not really endemic to the language. Python also has a couple other problems not endemic to the language: Ruby and Perl 6.

Ruby is, to many, all of Python’s benefits, none of its detriments, and some really cool bennies in addition. It’s much of Lisp’s list-handling, Eiffel’s and Perl’s syntactical ease, regexen almost on a par with Perl’s, Smalltalk’s masterful implementation of OOP, Perl’s flexibility, CLU’s iterators, and Python’s encouragement of good habits — or, more to the point, Ruby encourages and rewards good habits, while Python by contrast seems to merely punish bad habits.

Python succeeded in large part as an alternative to frustrations many had with Perl. Much of that frustration centers around such factors as the jury-rigged object oriented programming capability of Perl. It looks like the final release of Perl 6 may well sweep away pretty much all but the most superficial objections to Perl that make it unacceptable to many Python users.

I’m not nearly as familiar with the goings-on of Python development as I am with Perl or even Ruby development. For all I know, there might be exciting things happening in Python that will render all this Perl 6 and Ruby stuff irrelevant to Python’s niche, as Python might be carving out new territory for itself. On the other hand, I have a hard time imagining it doing much toward holding off its own obsolescence other than converging on Ruby, plus significant whitespace and minus flexible syntax. Maybe I just lack imagination, though.

The Problem With Perl

Filed under: Geek — apotheon @ 12:58

This is the first of several entries I’m going to write about what’s wrong with some programming languages I’ve run across. Oddly enough, I’ve chosen the language with which I’m most comfortable to attack first — Perl.

There are two things wrong with Perl:

  • List Processing
  • Object Oriented Programming

Perl’s problem with list processing is pretty simple, really. Lists don’t nest. Period. If you stick a list inside another list, it’s unfolded into its discrete elements. As a result, instead of one list containing another, you end up with one list containing all the elements of another.

Perl has references, as a kludge to “fix” the list problem. It’s just not good enough. In general, Perl does everything better than PHP (it would be difficult to do them worse), but this is an example of something it does do worse than PHP. At least with PHP you can stick one list inside another. With Perl, you have to do gymnastics and become a contortionist to be able to roughly approximate the ability to nest one list inside another.

With Perl, pretty much everything is easy — except list processing.

Perl was designed as a procedural language. Object-oriented Perl is an afterthought. It’s a pretty broken afterthought. At a glance, it looks “not bad”, but that’s mostly because many programmers think of Visual Basic and C++ as object-oriented languages. Perl’s object oriented features are about on par with C++ (a hair less good for serious OOP), and notably better than VB’s object oriented programming features. OOP might have been tacked onto a procedural language as an afterthought, but at least it wasn’t tacked onto a line-oriented programming language as an afterthought, as happened in VB.

Still . . . you don’t really need object orientation to get things done. Sometimes it helps. Sometimes it doesn’t. When it helps, Perl’s object system is sort of a bad way to go about it.

There are a lot of other things people tend to think are broken in Perl, but as far as I’ve been able to determine the truth is that they’re just things that don’t suit the way these critics think. If Perl doesn’t suit the way you think, use a different language. That doesn’t mean the language is wrong, though — just as a jacket that is three sizes too large or too small for you isn’t wrong. It just fits someone else better.

I suppose there’s one other thing wrong with Perl. It doesn’t come with a compiler for creating optimized binary executables. In general, of course, it’s better off using its current just-in-time compiler, but once in a while it would be nice to be able to create a binary executable, and while it’s nice that it often outperforms Java’s VMs, it would be nicer if it could compete with some of the established traditionally-compiled languages.

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