FLOSS Project Planets

Facing yet another day of being snowed in, with Dublin’s icy roads and footpaths driving us all stir crazy, I came up with this:

More pics, vid — fun!

Thanks to cpantesters I'm doing something that amazes me -- as I write C, it is taken and tested for me on all sorts of different systems. This is a stern test of my ability to write portable C code, and, in general I'm quite pleased with how I've done. So far only one mistake can clearly be laid at my door.

That mistake doesn't put me in a good light -- mistakes seldom do. But we learn more from mistakes than from successes. In this case, the mistake exposes a habit of mine that programmers of the modern school will find a bit lunatic. And perhaps it will give me a good way to point out how that lunacy shaped your training as well, no matter how recent it was.

The cpantesters do wonderful things, but they can't be all things to all people. In their feedback to C programmers who cause segment violations, they make the oracle at Delphi look like the neighborhood gossip. What the C programmer who lets his pointers stray sees is almost nothing -- the prove utility will report every test after the segment violation as a failure, without further explanation. It's not even explicitly stated that the problem is a segment violation, but I've learned to suspect that is what is happening whenever prove gives me the silent treatment.

I could always contact the cpantester and ask him for a stack trace, or even send him additional tests to run. But he's a volunteer and my C programming mishaps will not necessarily be his highest priority. He may be especially disinclined to give the issue a priority if he suspects that I have not done my homework. It behooved me to try to solve the problem on my own first.

I got lucky. Rereading my recent changes, I noted where doing a fairly complex calculation might save 4 bytes in a memory allocation. Problem was, I'd seen this the first time and decided I could save 5 bytes. Oops.

On most systems, malloc() was rounding up the allocation. But on a strict few, I was given exactly the allocation I asked for and made to pay the price of my folly.

I replaced the calculation with a simpler one. Cpantesters reports for my fix are in and they run 100% clean. The simpler calculation for the malloc() buffer allocates, worst case, 4 bytes too many. From the optimization standpoint, it may even be better because it saves a few CPU cycles. Not that either way it makes a difference that could be measured.

At this point, a number of my readers will have decided that I'm a lunatic. Why was I going out of my way to save 4 lousy bytes? Without directly addressing the charge of lunacy, I would draw the candid reader's attention to my training. Nobody is drilling young programmers on the importance of saving 4 bytes any more, but the spirit of minimalism that inspired my misjudgement is more than alive today. It's dominant.

I started programming in 1970, remote time-sharing on a PDP-8. As a user, I had available a virtual PDP-8 in its minimal configuration. That was 4096 12-bit words: 6K in modern terms. When you work in a memory that small, you sweat the details.

Though I didn't think so at the time, in giving me those 6K virtual bytes, the operating system was being generous. The typical configuration of a PDP-8 for the educational market was 36K bytes of memory, both physical and virtual. This was expected to serve around 20 time-shared users.

It was the generation that learned to program on this kind of hardware which created the concepts of programming language, development environment and operating system which are dominant today. As often as not they created not just our current concepts, but the actual technology we are using.

Perhaps one example will inspire the reader to think of others. LISP remains influential. Its spirit was the flame that kindled a long series of single-paradigm languages. But given the size of the machines available in 1958, how many paradigms could a language have implemented? When we study and emulate LISP, we are studying and emulating deep ideas. To an equal extent, however, when we study and emulate LISP, we are studying the art of saving every byte as if it were our last.

• Bailout will sink Ireland before we can even swim | David McWilliams : ‘This is not capitalism, it is not European diplomacy; it is a stitch-up.’ Adding another voice in favour of default — starting to look like the only sane option given the crappy ECB deal :(
  (tags: david-mcwilliams economy ireland bailout eu)

• Daft: Gallery Quay, Grand Canal Dock, Dublin 2, South Dublin City – Studio apartment to let : ‘€57 Weekly. Deceptively spacious open plan unfurnished studio in one of Dublin’s top locations. Carbon neutral, hand crafted inuit design. beautiful ambient light leading to rooftop garden. The studio comfortably sleeps five. Pets allowed, no parking. Short term lease for the month of December. Owner is interested in selling if market warms up.’ It’s an igloo. With a snowman head on top.
  (tags: funny igloos daft property dublin apartments snow sneachta)

For the past day, I've been shut out of my Gmail account for unexplained "maintenance". If you think I'm ignoring you, I'm not. I'm not even getting the chance to ignore you. And, now right before I go to Tokyo, I have to look like a suspicious phisher by telling people not to use my well-known email address that's probably the default one their mailer chooses.

Googling around, it seems that gmail-maintenance@google.com is merely a black hole autoresponder and most people get their help through back channels. I don't even get an autoresponse, either.

In the meantime:

• bdfoy@cpan.org now temporarily redirects to a new address, gmaelfail@gmail.com
• If there's something you've asked me to do in the last day, you need to ask again because I haven't seen the message
• My inbox is my to do list, which is now artificially really, really short. I don't remember everything I promised I'd do this week
• If I ask for logins, passwords, or credit card or social security numbers from my new gmail account, don't give them to me

Curiously, I might have brought this on myself. I wanted to carry my email with me on the long place ride to Tokyo (that starts tomorrow). I'm going to the Shibuya.pm meeting on December 9. I started to sync my Gmail with Apple Mail over IMAP now that I have the new MacBook Air with the 256GB SSD (more than quadrupling my old Air on-board storage). Carrying around 5GB of the stuff I have in Gmail will barely dent that. Maybe Gmail is mad that I'm cheating on it.

And, I had configured Gmail to also send all mail to a backup account. That's not happening either. So that sucks.

"You can get fired for not knowing Perl" I'm still sad that I had to miss the Nordic Perl Workshop in Reykjavík, but I'm going through talks that they've linked on their @nordicperl2010 Twitter feed. I like Tryggvi Björgvinsson's mutation testing talk, especially since he tells how he got a lecturer fired for not knowing Perl. I wish I was there to see if, but I only get to see the slides.

He points out an important but often ignored part of Perl's testing culture: we let the foxes guard the henhouse. That is, the code author and test author are often the same person. Not only that, but CPAN Testers runs the tests that the author provides. Tryggvi asks "Who watches the watchers" (with plenty of appropriate artwork).

How can we suss out problems with tests? One idea is to mutate the source code to see if the tests fail. For instance, we might change a comparison operator. The original code might test for greater than:

if( $foo > 9 ) { ... }

A mutation, or (mutant ninja) turtle in his parlance, changes that > to a <

if( $foo < 9 ) { ... }

Supposedly, a proper complete test suite should now have failures. That complete test suite would have green boxes in all the categories that you'd get from Devel::Cover, including conditional coverage for values on all sides of the boundary.

He shows syntactically valid changes, but random changes might be interesting too. What if none of the files even compile, but the tests still pass? You might think that's odd, but there are a couple of distributions that test pod, pod coverage, and kwalitee, but no real code tests.

Tryggvi doesn't note where he's uploaded Ooze, the software to create and test the turtles, but maybe he'll put it on CPAN if enough people bug him about it.

• Barry Eichengreen on the Irish bailout : ‘The Irish “program” solves exactly nothing – it simply kicks the can down the road. A public debt that will now top out at around 130 per cent of GDP has not been reduced by a single cent. The interest payments that the Irish sovereign will have to make have not been reduced by a single cent, given the rate of 5.8% on the international loan. After a couple of years, not just interest but also principal is supposed to begin to be repaid. Ireland will be transferring nearly 10 per cent of its national income as reparations to the bondholders, year after painful year. This is not politically sustainable, as anyone who remembers Germany’s own experience with World War I reparations should know. A populist backlash is inevitable.’
  (tags: ireland economy bailout eu euro)

• Video: Robots Explain The Irish Economic Crisis : Pretty good explanation, actually
  (tags: news ireland robots youtube debt eu politics economy)

This year, we've decided to start a Dancer Advent Calendar, following the Perl tradition.

We will be posting daily articles on our advent calendar until December 25th (Christmas) and the first one is already up!

We will cover a range of topics from understanding Dancer, writing your own Dancer applications (tutorials included!) and writing a plugin or engine backend to Dancer.

The work on the articles already benefited applications and modules. If you follow the articles, you'll be able to understand how they were all written, in complete detail.

We hope you enjoy the show! :)

The Perl Dancer Advent Calendar 2010

• WikiLeaks Archive: A CAUCASUS WEDDING : Dagestan knows how to party. ‘The main activity of the day was eating and drinking — starting from 4 p.m., about eight hours worth, all told — punctuated, when all were laden with food and sodden with drink, with a bout of jet skiing in the Caspian’
  (tags: russia government politics leaks wikileaks weddings funny dagestan caucasus)

I'm about to start writing about a bunch of stuff that will definitely show my lack of a computer science background. Unlike many of my posts, this is your chance to correct me rather than me explain things to you. This has been on my desktop for awhile, so I'm cutting bait and posting what I have instead of working on it more.

I've been reading Seven Languages in Seven Weeks: A Pragmatic Guide to Learning Programming Languages, which is an enjoyable book except for the parts where he starts to talk about types and, ahem, types of programming languages. It's mostly distracting, not very useful, probably misguided, it not outright wrong.

So, Ovid posts a clever summary of type arguments. This reminded me of smart, educated, and quite entertaining "Strong Typing" talk that Mark Jason Dominus gave to several Perl mongers groups. It also reminds me that no one seems to think the same things about the same terms. Also see mjd's message in comp.lang.perl.moderated.

Wikipedia's entry on Strongly-typed Programming Languages isn't any help. Indeed, the discussion page, where mjd shows up, is better than the main article (and also demonstrates the underlying weakness of Wikipedia). The article did point me toward Types and Programming Languages (Google Books), which Amazon is already sending to me. I like the look of that book since it goes back to the math.

The math is where it's at, and although I don't have a background in Computer Science, I have a lot of experience with abstract algebra, which defines sets, groups, and so on, and what happens when they interact with each other.

I think this is why I get confused with most people's explanations. Most of the explanations I find come from people trying to explain a concept that they don't fully understand based on their limited experience. That is, more concretely, people think the C programming language means something when it comes to types. I like Real World Haskell's approach if only because it defines the term. They could have just as well said Haskell is a "blue language" because the particular word doesn't matter when you provide your own definition for it:

When we say that Haskell has a strong type system, we mean that the type system guarantees that a program cannot contain certain kinds of errors.

That provides an easy way for Haskell to compare itself to other languages. In Haskell, certain classes of errors can't occur in a valid program. In other languages, maybe those classes or errors can. The question is, does that matter to you, both personally as a matter of beauty, and economically, as a productive use of your time?

And now comes the bit where I try to do better and will fail.

There's this big mess of terms: strong, weak, loose, static, dynamic, concrete, abstract, data, variable, and so on. I like what Richard Feynman learned about bird names from his father. Dr. Feynman says:

You can know the name of a bird in all the languages of the world, but when you're finished, you'll know absolutely nothing whatever about the bird... So let's look at the bird and see what it's doing -- that's what counts. I learned very early the difference between knowing the name of something and knowing something.

The video is more interesting:

He tells the same story to an interviewer in "Take the World from Another Point of View":

In this telling, he adds one important bit to that story:

Names don't constitute knowledge. That's caused me a certain trouble since because I refuse to learn the name for anything. ... What he forgot to tell me was knowing the names of things is useful if you want to talk to someone else.

The names of birds, however, only matter if people call the bird by the same name.

Types are just a kind of thing, and not at all like birds. It doesn't matter how we define that thing or how it works. The type is not the algebra. Forget about the terms, which no one can agree on (mostly), and figure out what you what to know and why you want to know it. It doesn't really matter what you call it as long as you get what you want.

What can I put in this variable?

A lot of programmers immediately think of int, float, or char as types. That's fine. However, when they don't see those types, they tend to turn up their nose because they think something is type deficient. The sorts of types that you have really has nothing to do with it. Indeed, most of those types come from architecture-dependent factors, like exposing the storage and format details at the higher levels. The people that want these sorts of types are looking to define the set of data that belong in that type. However, that does not mean that larger sets are not also types.

Programmers typically want this so they have something that protects them from storing invalid values.

How soon do I find out about type errors?

Do I have to wait until I run the program or will the compiler tell me? Consider this Perl example:

push $array, qw(a b c);

Is that a type error? Is it a type error in Perl 5.12? What about Perl 5.14? When does Perl find out about that error in each of those versions? Is it good or bad that it does that?

Can I change the type?

Is the type fixed, or can programmers play tricks to cast or coerce the thingy to void, or Object, or whatever, from which they can then recast the thingy to whatever they want? Do you want to allow or forbid that sort of thing?

When do I know the types?

People get confused about when the compiler (or interpreter) knows what the type is. Can you check it without a compiler (as with PPI or other static analysis tools), which really means can you infer all of the information that you need about types without actually running the program?

Mostly, people want to find errors though type-checking (so, the terms "type safety" and "type security"). The earlier you know about the types, the sooner your program can report problems. Some people don't even want the program to compile if there is a type mismatch.

What is the operator?

Some languages choose the operator by type, even if you type the same literal text for the code. How does that make you feel? Would you rather see the operation explicitly so you don't have to read through several lines of code to determine the type to know the operation, or do you want to be able to look at isolated statements and know what is going on?

What type is the result?

I always hated this about FORTRAN. Dividing 10 by 3 gave back three, because, in someone's mind, a integer divided by an integer had to be an integer. Why can't some other type come out? That goes back to the algebra. Any operation in an algebra has to return another member of the group.

What ______ is _______?

There's more to this topic than I can imagine at the moment.