Feeding the Cookie Monster

A wistful post from 2002 by Michael Nygard::

I think I'd like to do some Smalltalk (or Squeak) development sometime.  Just for myself.  It would be good for me -- like an artist going to a retreat and setting aside all notions of practicality.  I know I'll never work in Squeak professionally.  That's why it would be like saying to yourself, "In this now, purity of expression is all that matters.  Tomorrow, I will worry about making something I can sell.  Tomorrow I will design so the mediocre masses that follow me cannot corrupt it.  Today, I will work for the joy I find in the work."

The burdens of responsibility leave no room for such indulgence.  So I turn back to Java and C#.  I'll write another Address class and deal with another session manager, and more cookies.  Always with the cookies.

Smelly Buses

Earlier this year, Reading Buses switched over to using bio-ethanol on its No. 17 route, and now, whenever one of these buses passes, you get a distinct whiff of vinegar in the air.  Presumably this a result of incomplete combustion of the ethanol to acetic acid.  Or maybe the ethanol they use is already partly oxidized by bacterial action?  (Photo by Arriva436.)

Market Place, Reading

Market Place, Reading, UK.  Photo taken this morning (2008-08-16).  The dark clouds were threatening rain, but none fell.  The building on the right really is that irregular shape.

Recursive Equations are the Assembly Language of Functional Programming

From Origami Programming by Jeremy Gibbons (in The Fun of Programming, Gibbons and de Moer, eds, 2003):

One style of functional programming is based purely on recursive equations.  Such equations are easy to explain, and adequate for any computational purpose, but hard to use well as programs get bigger and more complicated.  In a sense, recursive equations are the ‘assembly language’ of functional programming, and direct recursion the goto. As computer scientists discovered in the 1960s with structured programming, it is better to identify common patterns of use of such too-powerful tools, and capture these patterns as new constructions and abstractions.  In functional programming, in contrast to imperative programming, we can often express the new constructions as higher-order operations within the language, whereas the move from unstructured to structured programming entailed the development of new languages.

GADT Syntax for Haskell Type Definitions

From an exchange on the Haskell mailing list in October 2006:

Lennart Augustsson:

Well, I think the GADT type definition syntax is the syntax data type definitions should have had from the start. Too bad we didn't realize it 15 years ago.

Paul Hudak:

I agree! In my experience teaching Haskell, the current syntax is a bit confusing for newbies, and for years I've been telling students, "It really means this: ..." and then I write out a syntax more like GADT's.

I also think that if we had adopted this syntax from the beginning, GADT's would have been "discovered" far sooner than now.