GIGO: words unreadable aloud

Thursday 31 March 2005

Multimethods, reduce(), April First, and overly long expressions

Guido wrote (about an example of dynamic type dispatching code that used explicit isinstance calls), "... This pattern gets tedious. (It also isn't very OO, but then, neither are multimethods, despite the name, IMO.)

I've long held the thought that multimethods are less object-oriented than traditional single dispatch code. I've never quite figured out why that feels like it matters. Probably something to do with code clarity, although a visitor pattern is certainly clearer with multimethods than without. Maybe it's the extra implicit crud that most multimethod implementations add -- CLOS' call-next-method et al.

Note that I do agree that multimethods are more powerful; I'm just claiming that they are less object oriented. And suspecting that this makes most MM code less clear: most code doesn't require or benefit from the presence of MMs. Are there any languages which have MMs but require that they be marked differently from the more common single dispatched code? Hmmm...

IMO, Guido was three weeks early in suggesting that reduce() be removed from Python.

Shriram Krishnamurthi agrees about the timing.

It's not all that closely related, but I have lately decided that one of the style issues that most clearly distinguishes Lisp fans from Python programmers is that the former seem to like to write extremely long and convoluted expressions, nested many levels deep, while the latter tend to prefer to name the intermediate values.

I tend to side with the latter. Consider last month's posting about Programming as Teaching. The programmer who is writing his program as if he's teaching someone about its algorithms will provide more clues about the intent of that code, than the one who isn't thinking about teaching. Taking the time and mental effort to think up meaningful names for some of those intermediate results can often help with code clarity. (And with debuggability.)
11:34:16 PM comment/

Tuesday 29 March 2005

LinksPL, shells, and the non-PL parts

Phil Wadler posted some comments by Warren Harris, expressing the desire to make the Links Programming Language at least partially be a better shell. The discussion reminded me of, and later mentioned, the "es" shell. I wrote up a Unix shells survey a couple of years ago, that mentioned "es".

So I think I'll start referring to that new language as LinksPL instead of just "Links". I'm hoping that people pick up on that and thus create a decently google-able word for it. We'll see.

I've been spending a small amount of my hobby time setting up a server on my old spare desktop Mac. I've been appalled at the percentage of time, effort, setup, and hair-pulling lore that's all concerned with configuration and deployment rather than actual programming. So that's my wish for LinksPL -- that the language should handle those aspects of web apps cleanly.

I hope that Harris' wishes for a shell language and mine for a complete web app creator aren't just symptoms of LinksPL turning into a wishlist dump. Hopefully we'll see a clarified vision after next month's meeting.
11:43:12 PM comment/

Thursday 17 March 2005

ColdFusion, Flash, Sean Corfield, and Ajax

Margaret mentioned her cousin's son, Paul -- I think that's technically a first cousin once removed -- who has a weblog at http://pjk.us . I didn't know you could get .us domain names at that level. Cool.

A ColdFusion fan. Macromedia makes Flash, which powers a lot of the nice-looking animations on the web, and I gather that ColdFusion is a web server and development environment for developing websites, with good support for developing Flash-based or Flash-rich websites. I haven't done much with Flash, but I can see the appeal. Here is the ColdFusion FAQ. Macromedia is lucky to have Sean Corfield working for them. I met him a few times at the C++ standards meetings a decade ago.

Macromedia started using the term "MX" a couple of years ago. My guess is that it stands for "More eXtreme". Their FAQ says: What is MX?

We use "MX" to identify the new products that are part of the Macromedia MX product family. Each product that bears the MX mark is major new version. Together, the Macromedia MX products make it possible to build a new generation of Internet solutions.

There is a lot of buzz around the blogosphere this past month or two about "Ajax" -- an acronym meaning "Asynchronous Javascript And XML-Http-Request". This is what helps the maps in Google Local, and the suggestions in Google Suggest, show up quickly. The next few months could be quite interesting for Macromedia, as Ajax uses standard interfaces, and does a little bit of the kinds of things that Flash does a lot of. Jesse James Garrett of Adaptive Path wrote a very good introduction to Ajax. And I think he or his company coined the term "Ajax". The techniques have been around for a while, but there is finally enough critical mass of browsers that support Javascript well enough for this to be a big opportunity.

Cool Javascript stuff:

http://tmp.i.am/2005/02/24.html I mention Lisp. And yesterday I finally saw the link to a Lisp-like language that generates Javascript code. I'll locate it and edit this. (On edit: It was Manuel Odendahl's "Parenscript", but it appears that something else already got that name (on sourceforge, even), so Odendahl's thing will likely change its name.)
http://www.tiddlywiki.com/
http://www.trimpath.com/project/wiki/JavaScriptTemplates Steve Yen has some amazing Javascript stuff -- a full spreadsheet, an HTML template processor, and an SQL-like Query language (I don't know if the subjects of the queries are XML or JSON, or something else; ought to read their page about it.)

9:53:32 PM comment/