Arvind Narayanan (arvindn) wrote,
Arvind Narayanan

Random software stuff

I love the "you can close this window now" dialog box in the ubuntu update manager. Tickles me for some reason I can't quite articulate. Reminds me of Arthur in the Hitchhiker's guide:
"I wonder what happens if I push this button" ... "Oh, a sign lit up saying 'Please don't push this button again!'"
There are a couple of good google tech talks by Guido van Rossum. Apparently many of the design issues that python 3000 will fix are consequences of decisions that were taken in the first few weeks or even days of the fledgling language, back in 1989. I can't quite imagine what it must be like to be in that position, to see your toy project snowball into this huge... thing. I also learned that classes in python started life as namespaces. That explains so much!

A lot of people hate lisp syntax. Usually it's the parentheses, but there is quite another reason that I hate it. Most often, I organize my program as a sequence of filters. I suspect most people do -- lisp certainly encourages it. This means that in the expression
(h (g (f list)))
f is the producer, h is the consumer and g is both. I don't know about you, but I'd much rather write that expression with the names of the functions in the same order as the data flow. The normal function call syntax inverts the data flow order. This makes programs hard to read. Bad bad bad.

Think of some other system with a producer-consumer paradigm that supports lazy evaluation. Shall we say Unix pipes? Think of the most common interface to it -- the shell. Shell pipe syntax! Sequence of filters! Bingo -- that's what lisp (and in fact, function invocation syntax in every language) should look like. (h (g (f list))) should instead be
list | f | g | h
Order in which they execute. Pleasing to the eyes.

It's easy to come up with intuitive syntax for when there are multiple arguments, let-bindings and so forth. Here's one example: (h (g (f list) a)) would become list | f | g x=a | h where x is the name of the second formal argument to g. Notice that this lets you specialize a function using any subset of its arguments, with no addition to the syntax!

The trouble with programming languages is that they are designed by people with no training in cognitive studies or usability, sciences that are typically derided by computer scientists. That's why whitespace indentation is such a huge win, despite drawing the instinctive contempt of programmers when they first encounter it.
Tags: functional programming, programming, python
  • Post a new comment


    Comments allowed for friends only

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded