Dispatches from Andyland

My third grade daughter is writing a newspaper with her friends. The school newspaper (or “the grown up’s school paper”, as she calls it.) is called Shark Bites. She is calling hers, “The Fins”. I don’t remember all of the articles that she and her friends are making, but I remember one was called “MCAS testing: Scary or Not”. She’s getting all of her friends to contribute articles, and is not only writing, but playing the editor and publisher roles.

I find it a bit funny. When she feels she feels something to say to a larger group of people, a newspaper is what she has in mind as the media to distribute it in. Not a blog. Not a newscast, (although she loves taking the camcorder and creating TV shows). A newspaper seems like it is her idea of distributing current information.

After seeing this Quiz Galaxy entry in Adam’s blog I decided to give it a try.

I like the idea of the Sony Alarm Clock controlled by a Nintendo Light Gun, but I don’t think its done quite as I’d want it.

I would think that the best idea would be to have the light gun trigger hooked up to the snooze alarm. The alarm goes off and you shoot it silent.

When someone tries explain that Smalltalk is nearly unique because Everything is an Object, don’t try to bring up Python or Ruby as a comparison. In Ruby and more recent versions of Python, all types are objects. Everything is an Object is a step beyond that.

In smalltalk, pretty much the only syntax the language has is the syntax to send a message to an object. (the page HeartOfSmalltalk, actually lists 6 items.) Everything else, (all control structures like if/else, all looping constructs like while and for), even method dispatch is defined in, and can be extended by objects.

At work, a request just came in that a redirect be put in the system to work around a typo in the newspaper. If the site in question was sinix.org, apparently the paper printed sinix.org_video and it needs to be redirected to some interior section of the site. How the requester thought that a redirect in the web server could be effective when the browser is still looking for which web site to contact is a mystery to me.

I can understand that there is a level of technical detail that isn’t necessary to work in a particular medium, a newscaster doesn’t need to understand things like NTSC and PAL. Book authors don’t need to formulate binding glue, etc. On the other hand, a newscaster might need to know enough about the medium that they are working in to know that microphones pick up ambient noise, and a book author needs to know enough about publishing to know that books have long lead times.

Asking for a new top level domain is like a TV host asking if they can have this episode smell like roses.

There was an old Saturday Night Live sketch, I think it was New York Radio. In it, where a New York City official was on a talk radio program pronouncing that NYC was a very safe city, even for tourists. The host, and then call after call told of unfortunate incidences, but the guest dismissed each and every one. “Oh, you were in Clinton at 2AM? I’m sorry, but of course you ran into trouble.” Finally the last call talked about being on the on an incoming passenger jet at the airport, waiting for a terminal when a gang gets on board and mugs all the passengers up and down the aisles. The response? “Was the plane in JFK or La Guardia? Well of course if you are talking about La Guardia…” Sometimes I find myself in the same situation when trying to discuss the merits of Perl as a programming language.

I just finished reading the book Perl Best Practices by Damain Conway, and I don’t think my reaction was the one that was intended. It got me seriously thinking of promising myself to not write another line of Perl (or at least Perl 5) for the rest of my life. It isn’t the mildly discouraged to deprecated features that it warns you against (don’t use formats, don’t use local), but what it really got me thinking about are the places where it demonstrates that relatively innocuous actions by the original software author can easily trip up either the maintainer doing later revisions or the client of the software trying to use it as a black box.

Each chapter is a half dozen to a few dozen section, with a short topic name, and rule as a sentence or two description in a “Always do …”, “Never do …”, “If possible try (?:not)? to”. Each rule is then followed by a few paragraphs of explanatory material that does things like explain the rationale, or explain how to adhere to the rule. I’d put the advice into four separate categories. Advice that is generally applicable across a wide variety of languages (or at least similar languages with infix notation and a C-derived syntax); Advice that is unique to Perl’s syntactic quirks; Advice that warns readers away from the generally considered awkward parts of the Perl language; and advice that turns Perl into a less forgiving language that can can build more robust code.

The advice that applies across lots of languages include things like brace layout, line lengths, and where to break lines. Most of this is covered fairly early on, I guess in order to get it out of the way. Some of the later material about revision control, and maybe even testing (at least in its more general terms.)

Some of the advice that revolves around syntactic elements is unique to Perl. For example, there is some advice about not making single character string constants ambiguous, so it suggests using q{ } over variations like ‘ ‘. I can see the point of the suggestion, but since few languages have Perl’s wide array of quoting constructs it really fits in a category of Perl coding standards.

Perl is a language that has evolved over many years, and there are some features that are largely regarded a unsuitable for new development, but need to stay for backwards compatibility. To be fair, a book on C’s best practices would have have rules like “always use function prototypes” and “never use the gets() function”. A book on Java would advise against using the original AWT event model. In a similar way “don’t use barewords”,”never use symbolic references”, and if you need to modify a punctuation variable, localize it” are relatively uncontentious words of wisdom. Some of the feature of Perl are argued against in terms of “are you sure you know {some feature} and handling it correctly? Are you sure you are sure? Are you sure all of your co-workers know too?” When that argument is made against shortcuts or some of the more concise feature of perl (for example, built in functions that default to $_) it makes it hard to believe that the language is built that way based on the theory of Huffman coding, but rather an arbitrariness.

The last category of advice has less common, but the explanations make a pretty good case for the decisions. Some notable examples would be the “always use the “/xms” modifiers to regular expressions or “use Class::Std to create object classes. The Class::Std discussion, or maybe the whole object discussion is interesting because he seems to knock holes in the more typical hash reference based form of Perl objects, and then knocks most of the alternatives. Then starts showing the “inside out” style objects in a way that almost has you arguing that they are too bulky and awkward to use, and then finally pulls out Class::Std as an encapsulation of all the boilerplate portions of the inside out object approach.

I’m willing to believe that some of the more esoteric features of Perl fit into the “if you prevent stupid people from doing stupid things, you prevent clever people from doing clever things.”, but there are some pieces that just should be avoided entirely. Some of the suggestions in the book are just so far removed from the way people typically write Perl, and the arguments against the conventional wisdom is so good, it just leads me to believe that Perl on its own may not be best suited for the tasks. (If the safest, most robust way of creating an object is to have the instance variable spread across many parallel hashes keyed by a a stringified version of the reference, its hard to argue for Perl’s Object Oriented features. The closest you can come is to say that perl is a language that is flexible enough to write the infrastructure that can make perl safe enough to use.

Reading Universal Hub, I came across this story Terrorists Get Sinus Headaches Too. I feel a bit bad for those CVS employees. After all, the DEA and the Boston Police closed off Congress Street for nearly a week trying to figure out which chemicals are needed to make methampetimine. All the while they were dragging the apartment owners name through the mud. (Eventually they found some Sudafed in a desk, but not in the lab, and not enough to make any significant quantity of the drug.)

Are we expecting CVS cashiers to do any better? The Globe seems to be on top of things though. The last two paragraphs of the above Globe story seems to be a pretty good executive summary on how to make meth.

I have to leave work early enough today to be with my kids at the Purim celebration at Temple Beth Abraham. Michelle needs to be handling her classes (and another teacher’s classes unfortunately) and shouldn’t be distracted by taking care of our kids too. (When she can alternate roles of being the parent and being the teacher, as in drive the kids to Hebrew school, then teach, and then pick up the kids since she happens to already be there, it works out well. When the two roles need to be in parallel, then we both need to be there.)

I don’t mind going though. Purim is one of my favorite Jewish holidays. When Michelle first explained Purim to me, sometime after we started dating, she described it this way. “They put on a play depicting the story of Esther, traditionally men did all the acting, so having men dressed in woman’s roles is common, and traditionally you are supposed to get so drunk that you can’t tell the difference”, and I remember thinking, “heavy intoxication and gender ambiguity. That is an interesting religious holiday!”

The story of Esther has more incidences of of mistaken identity than an English farce. The story doesn’t involve G-d breaking His laws of physics (or biology), and isn’t even discussed directly in the story. The celebration is noisy, boisterous, and more than mildly chaotic.

In APE: Time’s Up Shane Hathaway says that he has given up on APE (Adaptable Persistence Engine) for ZODB, and he suggests everyone else do the same. A replacement he has developed for some people’s uses PGStorage stores ZODB objects in a Postgres database, but does it by storing pickles. (“It supports undo and packing.”, he says. “..And packing!” Oh boy.) I guess I’d put this as roughly comparable to OracleStorage, but has the possibility to be better supported.

I figured I’d mention this, because I know a fair number of people who have fought with APE, and PGStorage might fit their needs.

A few weeks back I read Mono: A Developer’s Notebook to learn about about Mono, a bit about .Net through mono tinted glasses. I don’t know what I was expecting, but it was interesting to find out how reality compared to it.

OK, so I pretty much messed up my previous post on how to describe the difference programming languages. Essentially what I was trying to get at was that it isn’t enough to say that a language is object oriented, or that it has an extensible syntax, but how the how the language designer translates a concept like “object oriented” into the particular semantics of their language. (This is sort of reminding me of the book Long Dark Teatime of the Soul when an accident is considered an Act of G-d and Dirk Gently wants
to find out which god and why) The most obvious comparison C# has is to Java, and if I’m going to do that, I shouldn’t be comparing to two variables. So let me say that Java seems to be a language that was originally designed to be a “consensus” language. It had the features that were widely common across many OO languages, and avoided features that would have cause derision. Between a C++ style class definition being a “fully complete static definition” and a smalltalk style “initial specification”, pick the safer static one. Between open class definitions that can be added to and closed classes, pick closed. Between single inheritance and multiple (and then seeing MI would turn into arguments like depth first and diamond inheritance) pick single but the pull in interfaces to cover a common use case. Avoid things like metaclass protocols, but give escape hatches like reflection, etc. It might just be that as the technology matured, certain ideas would sort of mesh be the standard, default choices, and if Java didn’t come around to cover them, something else would have.

So if Java is a consensus language, C# seems similar to Java because its starting from those same obvious answers to similar questions. (well, that and the C-like syntax, and the platform independent bytecode, and that it was the first thing that Microsoft came up with after being forced to stop distributing Java) C# as a language has a different set of design goals, and so has some interesting features.

As an initial laundry list, having both reference and value objects and optional non-polymorphic methods like C++. It has a properties syntax for giving a getter/setter implementation around what looks like simple member variable access to its clients. (like languages such as Python, common lisp, and dylan) It has class and method attributes for metadata. (which dynamic languages tend to take care of with special runtime object member (Zope’s security and Interface additions to Python are an example) and static languages have done with odd preprocessor hacks (like lint’s /* NOTREACHED */, or Java’s javadoc.) or just odd language quirks (like Python’s “if the first statement is a constant string in a void context it is a docstring) C#’s “delegate methods” (essentially language level support of things like the strategy and Observer patterns) is an interesting addition as a language primitive.

I guess what I found the most interesting were which pieces were part of the core language, the standard library, and how they interact. Some of them are language primitives that depend on interfaces in the standard library (like foreach loops needing IEnumerable interfaces or the “using ( object ) { block } ” needing an object implementing IDisposable. (This form of “using” is interesting because it takes care of some of the use cases of Perl’s immediately called destructors.) So its not exactly a barebones set of language primitives, but not the kitchen sink of Perl.

The .net architecture in general is relatively interesting, and these are some of the where Mono matches the architecture directly. Classes get compiled to an bytecode format, and put into “assemblies” (which can be applications or libraries) libraries that are designed to be shared can be cryptographically signed, versioned, and put into the global assembly cache (sort of like /usr/lib of unix) Some of the origins of the platform are visible here, and the Mono macros for Autoconf are set up so that small shell scripts are put in $prefix/bin/$program that call out “exec mono $prefix/lib/$package/$program.exe”

Actually, maybe this demonstrates the core issues with Mono. The .net platform isn’t written to be platform independant, unless you view WindowsCE, through Windows XP desktops, to Windows 2003 Servers to be the full spectrum of platforms. Mono tries its best to fit what it can of .net into a Unix-like mold, and then tries to fit Gnome into .net. Most of the OS neutral pieces have been copied over. The OS dependent pieces that are required (like spawning another process) are done in an Windows-centric way. Some of the OS dependent pieces that can’t be ported easily (like Windows.Forms, a UI library, which only runs under Mono in conjunction with Wine on x86 Linux) are replaced with Gnome components like Gtk#.

Despite the windows-centric quirks, I can see why the Mono team decided to create a system based on .net technologies. They can piggyback onto a development economy on par with Java. But Java’s method of platform independence is as much ignoring the underlying system’s unique advantages as it is creating a common interface to the features that are supported across all host platforms. I can see developing desktop applications under Gtk# might give more “native” feeling applications than a Java/Swing one.

OK, now let me give at least an initial rundown of some of the things covered in the book. Like the other books in the “A Developer’s Notebook” series, its essentialy a series of examples with a small amount of explanatory material in between. (Essentially a series of “How do I …” passages, then the solution, followed by a “What just happened?” passsage) It goes over how to install Mono, then either existing free IDEs (like SharpDevelop or the Gtk port of MonoDevelop) or how to fit Mono into an existing development environment (Emacs and Vim modes, using Make or NAnt to build, etc.) Then it goes over enough C# in order to work through the examples (teaching basic class construction syntax, and delegates since they are used with Gtk) Then it goes through making desktop applications with Gtk# and Gnome assemblies.

The book does a fair amount to cover server-side use of Mono, including making SOAP based web services, and Using mod_mono under Apache to develop ASP.NET applications. Around this part, it covers XML processing (since Microsoft is so invested in XML, you can imagine they want their common runtime to have robust XML libraries in it.

The last chapter, “Cutting Edge Mono” is a mishmash of things, but probably the things that are too small to cover in their own chapter, but too interesting to ignore. This is where the Autotools info is, and some cross-platform hints. It also covers IKVM, a system to have Java code run under Mono or .Net. A the rest of the chapter is some “not ready for prime time” pieces still under development in Mono. Mono implements most of version 1 of C#, and has some of the version 2 features, but the development version of Mono has some of the newer features like support for generics. They also have a VB.Net compatible compiler under development.