Sometimes, you just have to wonder if some kids’ parents beat them too much or not enough.
Lawrence Lessig has a link to a Bittorrent feed for the INDUCE hearings, starring the venerable Orin Hatch. I’ve ranted about INDUCE before a bit, and how it substantially modifies the Supreme Court ruling in the 1984 Betamax case. It’s not good law folks, and is yet another attempt by the content industry to further criminalize many previously unregulated or fair uses of content.
Slashdot is running an article about a Cornell group who built an unmanned model aircraft using rather conventional hardware and Microsoft Windows XP embedded. What intrigued me most about the story was that the group tested their algorithms for flight control by using them to control a simulated aircraft in Microsoft Flight Simulator. A brief dig turned up other projects. Of course, other groups have been working on autonomous helicopter control, such as CMU and SourceForge’s autopilot project. A cool hobby, if you have the green stuff.
The Python Daily URL! feed has had quite a few articles lately on the so-called “decorator” syntax. I must admit, I’m not really up on the controversy, but I was amazed that even after reading three or four posts, I still couldn’t figure out what the intended utility of the new feature was supposed to be. I suppose it’s because I’m hopelessly out lunch with respect to certain OOP practices, but still: I’m not a programming language newbie.
Whether I’m right or not, it does not bode well for the trend that Python is taking. I’m not the only one who is noticing. Python is sprouting new features which increase the spartan simplicity and expressive nature of the underlying language, complicate it’s implementation and give very marginal utility in return.
Personal (if second hand) anecdote: While attending the University of Oregon in the late 1980’s, I had the pleasure of having Will Clinger as one of my professors. Will was the author of the Revised Report on Scheme: the master work which describes what Scheme was, what it required and gave the semantics for the language. It was a remarkably terse document. In contrast, the specification for Common Lisp was being worked on by Guy Steele. The Common Lisp specification was large, cumbersome and while Common Lisp was more feature-rich, it seemed like a lot of work to implement all facets of the language, and there were many things included in the specification which were of marginal utility. Sound familiar?
Clinger described the situation to me thusly: when presented with a potential new feature for the Scheme specification, he asked himself two questions:
- Can this feature be implemented using machinery allready in the Scheme specification? If yes, then it is better to implement it that way, and not pollute the base language. This criterion eliminated unnecessary language changes that were largely semantic.
- If this feature couldn’t be implemented using the existing language, then is this feature the best idea which implements the desired effect? At the time, they were working on the Scheme macro facility, and they were working very hard to make sure that they implemented the best macro facility they could.
By contrast, Clinger characterized Steele’s approach as roughly “If each additional feature is of some use to somebody, and only marginally complicates the language, then who am I to oppose?” This is no doubt at least partly due to the business forces which already were heavily invested in various versions of Lisp, and therefore had a vested interest in seeing their own pet extensions merged with the language specification. Still, this “default is to accept” notion is very damaging to the tidiness of language specifications.
I fear that in the future, some of Python’s expressiveness will be clouded by dozens of features which are of marginal utility. We shall see.