amaryllis grappa rugs persian sunshine bottle shadow

The Tao of Recursion

[ in a state of controlled semantic decay ]

Things fall apart; the centre cannot hold. If you meet Mr. Man on the Tao of Recursion, a student once came to Buddha and told him a story: “A buddha once came to the moon, killing my whole life with his words, softly (two times, two times).” In fact, if he started to tell us about his wife we should get impatient; all we expect of him is that he should know the way and be able clearly to explain it.

It remains to show that Fame and Glory are total. To obtain your own copy of a platonic universe, make the mouse appear. Animate the universe with the five platonic mice and their three combinations. They are being ended by the Masters redirecting energies; well, not exactly, I sit in my shorts, aging, drinking beer, the windows open, and they look at me, 6 p.m., coming in from their little jobs… There's no end to termination.


Below: materials for ideological instruction, followed by miscellaneous, half-done, ramblings on the merry old muddle vs. systematically sound discomfort, object orientation, and related issues. Plus an extra serving of quotes emanating from the computational tædium (the unfortunate superabundance in computing practice of many 0s drowning the rare 1s).

Some rather neat languages

Programming languages have to strike a balance between power vs. intelligibility, ease of expression vs. ease of understanding. Do they let you say much in few words, or understand much in short time? Trade-offs can go wrong in many ways, but both bad and ugly fall under the law: Caked mud is no building material apt for transparent constructions.

towering beans

holy cow

Resources of Wisdom

Miscellaneous Texts On-Line

Vaguely Related Links

Some personal sites

ICFP Programming Contest

[ illustrating by the way the characteristically sloppy approach of academic folk to maintaining information, in this case about former contests, on the web. The remedial and, of course, unofficial ICFP Contest Archive does not seem to be quite complete, so far. ]

  1. ICFP 2019 contest : optimal mine wrapping

    Seal empty lambda mines against bit juice.

  2. ICFP 2018 contest : optimal nanobotic matter manipulation

    Fill the void or vice versa with nanobots minimising energy used.

  3. ICFP 2017 contest : competitive graph navigation

    Claim punting routes from lambda mines in a river network.

  4. ICFP 2016 contest : planar origaming

    Plan and solve origami problems.

  5. ICFP 2015 contest : honeycomb gaming

    Score points by locking honeycomb cells while invoking phrases of power.

  6. ICFP 2014 contest : competitive eating

    Steer 1980s' λ-men to victorious ingestion.

  7. ICFP 2013 contest : functional reverse engineering

    Sample arithmetic black box functions and guess an adequate implementation.

  8. ICFP 2012 contest : competitive treasure hunting

    Mine the store of an automaton for precious symbols.

  9. ICFP 2011 contest : applicative card gaming

    Survive and win a λ-poker tournament.

  10. ICFP 2010 contest : market-oriented car/fuel design

    Make money in the automobile business mixing sauce and building picky cars to run on it.

  11. ICFP 2009 contest : orbital machine control

    Move satellites around ultimately to collect the twelve apostles from the skies.

  12. ICFP 2008 contest : competitive state-machine control

    Optimise martian rover control in the face of the locals, their gods, and potholes.

  13. ICFP 2007 contest : optimal DNA resequencing

    Application unexpectedly quit eating genetically modified cows.

  14. ICFP 2006 contest : sandstone computing

    Submit many valuable compressed sandstone publications.

  15. ICFP 2005 – maintainable gaming state-machines

    Program subversive robbers and cooperative coppers to score in a game with black monolithic variations.

  16. ICFP 2004 – state-machine optimisation

    Wire a competitive ant brain.

  17. ICFP 2003 contest : trace optimisation

    Drive a car around a set of racing tracks fast.

  18. ICFP 2002 contest : multi-player robot game

    Implement a player delivering packages to their destination in a multi-player robot game.

  19. ICFP 2001 contest : document simplification

    Optimise markup documents for simplicity and size.

  20. ICFP 2000 contest : ray-tracing

    Implement a ray-tracer rendering scenes described in a simple functional modeling language.

  21. ICFP 1999 contest : state-machine optimisation

    Optimise computer-controlled interactive fiction characters for battery life.

  22. ICFP 1998 contest : pousse game

    Write a program that plays “pousse,” an odd variant of tic-tac-toe.

Online Museums and Memorials

In the office of the future

Humanist aspects of computers

Wite Lite

elderly ivy sunbathing in front of plastered algae

On Lisp vs. Scheme

We can forgive a man for making a useful thing as long as he does not admire it. The only excuse for making a useless thing is that one admires it intensely.

Oscar Wilde: The Picture of Dorian Gray

[ Fragmentary sketch of similarities and characteristic differences of Common Lisp and Scheme. I am going to argue –someday– that software should sport two conflicting qualities: dynamism and intelligibility, since it must cope with change and exceptions, but should nonetheless be easily analysable at write-time. Common Lisp offers strong dynamic features but not much leverage for static analysis. Scheme, the language and the culture that goes with it, promises a mathematically more disciplined dynamism —but fails to deliver, to some extent. Has the vanilla pudding of confusion gotten the better of us? Read further and you won't find out. ]

Scheme emerged and has departed quite notably from the Lisp world. Both Scheme and Lisp feature an approach to data based on structured external representations (by bracketed expressions), a built-in parser, and a well-supported concrete data-type for the parse-tree. (Avoiding the syntactic pain of XML or SGML and the rectal pain of object-request brokers.) Since the data may well be code, Scheme and Lisp make it quite trivial to build interpreters for specialised domain languages or to embed these languages into Lisp/Scheme.

Actually, (Common) Lisp even makes forms (definitions and expressions) object level values and assigns the dependent role to their textual representation. On the whole, CL is geared toward the runtime system, one and all, placing the problem at hand and meta-concerns such as parsing, evaluating, and inquiring code on the same footing. Scheme, by its spirit —to be grasped in the lambda experience or mystical onion — more than by its rudimentary definition, tends to separate these concerns, supporting arguably more intelligible layered architectures while retaining much of the power of Lisp.

Let's finally rave on the merits of sound engineering principles. First case study: doc strings. In Common Lisp, the programmer may stick a string documenting a function into its definition. The system prints that string when asked for the description of the (named) function. This comes handy for “library” functions (as opposed to internal machinery). At the same time, this requires the language not only to assign meaning to programs but to specify (other) properties of the runtime system, too. (In other words, this complicates the meaning of programs.) Whereas Scheme leaves the job of organising documentation to the development environment where it belongs. As a result, Scheme programmers usually fall back on the classical means, source comments and text search. Second case study: candied pumpkin. Makes about three cups.

Ten seconds on Object-Orientation

The object movement innovated imperative programming with a multi-agent view of problem domains as well as programs, composed of stateful thingies that interact, offering a limiting but easily communicable basic metaphor. This isn't worthless, but nothing to get too excited about either. Objects localise meaning: agents respond to messages by their own lights, but even thoroughly object-oriented systems impose global constraints or conventions (such as: classes cannot/must not override the identity method), effectively shifting semantic authority from the objects to the language. OO proponents paid much attention to the structure of large scale development efforts, but generated a plethora of absurd provisions, tools, subordinate buzz. Object technology was a marketing success, but there's no silver bullet.

Objects favour analogical thinking and may induce a deplorable lack of precision. But it's not the fault of object thinking that UML, attempting a pictorial notation for behaviour, ended up with flow-charts. And books such as Martin and Odell's Object-Oriented Methods: A Foundation aren't dead, they just smell like jazz, in their wordy ways. By contrast, Abadi and Cardelli's Theory of Objects or Castagna's Object-Oriented Programming: A Unified Foundation, with their dear side salad of greco-roman formulae, seem to serve up real content. (Haven't read these yet, just got a good impression on skimming through the pages.)