December 24, 2011

Don't steal my REPL, or Lisp lessons from ledger

John Wiegley's ledger is a popular double-entry accounting system with a Unix command line interface.

What many people don't know is that version 3 of ledger was written in Common Lisp. This version was never made into an official release. In a FLOSS weekly podcast, Wiegley explains (31:00) that Common Lisp wasn't the best choice for ledger's users.

I emailed John to learn more about this. He replied that there were only two major problems: building cl-ledger was more difficult than building ledger, and that cl-ledger could no longer be scripted from the command line. In effect, the Common Lisp REPL had stolen the place of the Unix command line as ledger's interface.

cl-ledger was written in 2007, and there are now good solutions to these problems. ASDF works well as a build system, but before Quicklisp, dependency management for Common Lisp applications was difficult. Quicklisp solved the biggest outstanding problem in building Common Lisp applications. (PS - you can give Zach a Christmas gift for his work on Quicklisp)

Didier Verna's Command-Line Options Nuker is a widely portable Unix CLI library with many features that you can use to build command-line driven Common Lisp applications.

December 22, 2011

Wealth vs Creativity

The basis of wealth is exclusively material. Everything non-material in an economy is a social convention.

Money, trade, and even labor is worthless unless it satisfies a particular desire in a particular point in time (see Deleuze and Guattari's Anti-Oedipus about the role of desire in capitalism).

It's easy to accept that money is a social convention, but how can labor be worthless? The famous illustration is Bastiat's "broken window" fallacy. While Bastiat's conclusions are correct, his reasoning starts with the wrong assumptions. Wealth has nothing do with the classical notions of trade and utility and "money better spent elsewhere" - the broken window fallacy is directly explained by the material reality of objects.

The key thing to understand is that material objects are cumulative and impermanent. These two qualities are what drive everything else about wealth.

A window is cumulative in that it satisfies a desire and has a physical manifestation, and it is impermanent in that the physical manifestation is now broken and the desire is no longer satisfied. Even if currency were completely devalued tomorrow, the fact that a window is there would still satisfy the desire.

This is why the labor theory of value (indeed any other theory of value that doesn't take into account Deleuze and Guattari's desire machines as the ultimate driver of the economic process) is wrong. Labor or technology itself has no value whatsoever, unless it ultimately (if through a long series of immaterial social transactions) results in the production of a material object that satisfies a desire.

So far this essay has talked about labor, but what about trade? To understand trade, first we need to define the word: there is no such single thing as "trade," rather the word refers to two things, which may or may not be present in a particular "trade" (transaction): the social (buyer/seller, consignee/consignor relationship) and the material (embodied in labor as transportation of material objects). A purely social transaction would be finance, a purely material one would be theft.

Trade is obviously important in satisfying desire - if a material object is not in the right place at the right time, it can't satisfy that desire. A chain of social trades resulting in the transportation of a material object then obviously has value.

One of the most pressing questions today (see: SOPA act), is where does this leave purely social transactions? If you want $10 for a pile of bits, money that will buy you lunch, but someone else is satisfied with a "thanks for sharing!" for the same pile of bits, where does materialism come in?

The material reality of the world is that those bits are worthless. The movie, music, and publishing industries were built on material objects: selling time slots in seats in a movie theater, selling vinyl and plastic discs, selling bound stacks of paper. The particular content on those material objects was in a very fundamental way completely irrelevant to their business, even if paradoxically it was the key to their business model.

Knowledge may be cumulative, but it is worthless unless it can be applied to satisfy a desire. It is also permanent - it cannot be stolen. What knowledge is great at is helping produce better material objects with less cost and greater ability to satisfy desire.

The real competition to the movie, music and publishing industries are the computer manufacturers and ISPs.

What the MPAA and RIAA and the SAG are doing when they attempt to put in digital restrictions management into computer hardware and force ISPs to filter content is the equivalent of the Luddites burning water mills and power looms. This is a strategy that will ultimately fail, but in the short term causes a slow-down in the rate of improvement of material objects, both directly (PCs and Internet connections suck more because of attempts to implement digital restrictions management), and indirectly (this improvement in the production of objects is driven by knowledge produced with the aid of PCs and the Internet, in a cumulative process).

So what about the MPAA excuse that no one will be able to finance the production of big-budget action movies anymore? At a time when the very same progress in material production is drastically reducing the cost of producing a movie (via an all-digital process and computer-generated imagery), this is exactly like arguing that no one will be able to afford to author books during the time of Gutenberg's invention of the printing press.

The creative urge is a desire in and of itself. If there's anything you should take away from this essay, it's that people pay to have their desires satisfied.

December 20, 2011

Programming considered harmful

  • gotos make it possible to write bad programs
  • threads make it possible to write bad programs
  • global variables make it possible to write bad programs
  • anonymous functions make it possible to write bad programs
  • macros make it possible to write bad programs
  • mutable variables make it possible to write bad programs
  • continuations make it possible to write bad programs
  • dynamic scoping makes it possible to write bad programs
  • objects make it possible to write bad programs
  • recursion makes it possible to write bad programs
  • ...

Take this argument far enough, and you are left with the S-K combinators, and now it is impossible to write good programs.

Having few features in a programming language is a fault, not a virtue. The bigger fault lies in failing to provide the language with the facilities to be extended with new features.

No amount of language design can force a programmer to write clear programs.

--Guy Steele & Gerald Sussman

December 12, 2011

Announcing: CLiki2 public beta 2

CLiki, the Common Lisp wiki, is a good resource for finding out about Common Lisp libraries and other information. However, the code behind CLiki itself is hard to maintain and add features to.

Andrey Moskvitin and I have been working on a replacement wiki web application on and off for the past eight months. The first public beta came out in the summer. Since then, I've worked the software to the point where I think it's ready as a replacement to power CLiki.

The second beta of CLiki2 is now up at Please try it out and let me know what you think. Bugs can be reported at or by sending me email:

Most of the new features center around spam prevention:

  • Wikipedia-style history lists and diffs for all pages
  • Lists of edits by account/IP address
  • Blacklist of accounts and IP addresses
  • Atom change feeds for individual pages (as well as all of CLiki)
  • HTML tag filtering
Other new features include:
  • Real article deletion and undeletion
  • Code coloring using cl-colorize
  • Working list of uncategorized/orphan articles
  • Pages that work well in text browsers (and hopefully screen readers)
  • No JavaScript
Pages are marked up using a mixture of HTML (with some tags and attributes filtered out) as well as a slightly simplified form of CLiki syntax.

Behind the scenes, CLiki2 is powered by Hunchentoot, BKNR-datastore, and Nathan Froyd's diff library.

Source code is at, and is licensed under the Affero GPL.