A view from the hill

Catbert and privacy

This started out as a reddit reply to Alex Iskold's article about semantic search engine technology. Alex suggests that the reason why we haven't seen the semantic web as overtaking as the search technology of today is because of two points: that they won't provide better search results today and that the current semantic search engines have UI problems. At the same time, he claims that (wrt. to the search results) "emantic search is going to be big and it is going to help us answer questions that we simply cannot answer today - complex, inferencing queries asked over the entire web as if it was a database." I think that the UI point is irrelevant, or perhaps only relevant at this point in time.

I agree with the search result point, but I'm much more sceptical about the future results to expect.

I've tried Compiz with Metacity again and switch it off after a day -- again. I'm not willing to do without working software suspend just for some graphical whizz. I've been using Metacity for, I think nearly two years now, on my work computers and have somehow accomodated to it's various glitches (for instance the unusable keyboard settings). On my trusty home workstation, however, I've stuck with WindowMaker, which I think I've been using roughly since 1997 (I can't remember the version number, but it was fairly low). Unfortunately, development seems to have stopped -- since quite some time there is no sign of activity on the webpage and the mailing list archive is dead.

Yesterday, out of a current frustration about Metacity, I installed a naked current version of WindowMaker on one of my machines, under Ubuntu 8.04 (don't try to make WindowMaker work under Gnome: While WindowMaker does "work" under Gnome, it is really crippled. For instance, the keyboard setting know nothing about WindowMaker but still override your keyboard settings via, say, WPrefs.). Nearly everything worked as expected, but there were two glitches: the menu didn't reflect the installed software. Having customized the thing under my Debian system, I knew that this was supposed to work with the update-menu script, but that was missing. Some web-searching revealed that for some reason or other Ubuntu no longer installs the menu(-xdg) package. The other glitch was a very old complaint: That WindowMaker doesn't ship with a virtual desktop switcher or pager. You don't need to tell me about the different philosophy of WindowMaker, I know all about it. However, I've been using Fvwm and OpenLook (OLVWM) too long.

I could use gnome-panel (which I've done before in the past), but of course that brings me those two panels that make sense for Metacity and besides it also means that I would still depend on gnome. I've did quite a bit of looking around to find out what all the cool Fluxbox, Openbox etc. users are using and finally found fbpanel (the trick was to search for "taskbar" instead of "pager"). So, finally thanks to netwm support (which I think is in WindowMaker since 0.90), the one missing bit from WindowMaker is finally there without Gnome. Oh my, I'm finding this out really late.

John Goerzen blogs about (how to start) cycling to work. As I'm now back in Freiburg, in which anybody not cycling will be treated as an anti-social enviromental sinner, I'm using my bike a lot more, including cycling to work, hence I'm interested. Basically, I'm fine with what John has put together, but I would like to share my own experiences.

First of all, I'm concerned with Johns reference to cycling helmets. It is not so that helmets are required for cycling. I believe that this misconception is a common reason why people in recent years have come to believe that somehow cycling is a dangerous activity in the first place, while statistics clearly say it's not (in comparison to other activities, obviously). For instance have a look at a collection of facts around the danger of cycling. There is also some doubt about the usefulness of cycling helmets, have a look at the results of the helmet law in Australia. Now, whether one decides to where a helmet or not is up to you, of course, but the main fact to keep in mind is that cycling is in no way particularly dangerous.

John also mentions that for safe travel a key point is visibility, to which I whole-heartedly agree. However, Johns's sentence starts with "Unless there are dedicated bicycle-only lanes or paths ..." which should be taken with a grain of salt. There are studies, which I unfortunately had more than once the chance to verify, that bycicle-only lanes add a risk of their own. First of all, more often than not, you will not be as visible as you should be, especially if the lane is behind parking cars . Next, any biker on such lanes should take good care of any interference with pedestrians and/or car traffic. Especially where such lanes cross exits of garages and houses or when cars are parked directly beside the lane, be extra careful. I generally don't like bike lanes because more often than not they're in a shape no car driver would accept, but that's not the real point: the point is that bike lanes lure you into feeling extra safe while adding in some little surprises of their own.

But there's also another point to be made wrt. visibilty: Being visible alone won't save you, i.e. you can't trust that others will always behave correctly just because you do. Instead it's a lot more important that you are aware what other traffic participants are doing instead of making them aware of what you're doing -- only the first option is an active one, the second is just passive.

Now that we've dealt with the safety issue, let's talk about the fun. How fast you're going is up to you. I find that I can't really go slow (well, at least I feel like I'm not slow and there are not too many people going faster). I like a light and fast turn, so I use a relatively low gear -- think Lance Armstrong, not Jan Ulrich. And I shift gears really often so that my pace stays more or less the same regardless whether it's going up or down. Of course, this is only possible if you have relatively many gears. Don't expect too much from yourself btw: it's okay that you feel exhausted after a seemingly small way at first. It's also okay when you don't use the bike every day right from the start -- actually it might make a lot of sense to take a break between your riding days, depending on your fitness and the amount of cycling you have to do.

Of course, going quite fast by bike means that I'm sweating -- bringing spare clothes helps. And another point: if the weather is hot (there is currently wind from Africa blowing all the way up to Germany which means it's unusually hot these days), go early in the morning when it's still relatively cool. I would also suggest taking rain clothes with you, regardless of what the weather report is saying. I use a bike bag in which I take my rain clothes, some repair stuff and an air pump. I never really unpack it, so that's simply not an issue.

Another point: try to find a nice way to ride. This might require trying several alternative routes, but if you're lucky you might find a route that is fun to go. This helps to keep the motivation up. I know what I'm talking about, since in my old job in Mannheim I didn't use my bike as much as I should have because there simply was no nice route for me to work -- I always felt a little hunted on the road. Now, in contrast here in Freiburg, I've found a route which goes besides the river Dreisam for about five kilometers which is just nice in the morning, which means that I'm far more motivated to go the 10km way here than the 3km in Mannheim.

Die ARD-Sendung ttt - Titel, Thesen, Temparemente vom 25.5.2008 war bemerkenswert: Es gab drei Beiträge (abrufbar via der neuen ARD-Mediathek), die sich mit der Manipulierbarkeit der Medien beschäftigen. Im ersten Fall ging es um die vermutlich inszenierten Bilder eines von Israelis erschossenen Palestinenserkindes, als zweites um den ersten Fernsehkoch im deutschen Fernsehen, der so gut wie nicht kochen konnte und dann gab es noch eine Diskussion mit einem Sozialwissenschaftler und Historiker zum Themenkomplex.

Besonders diese Diskussion hat es mir in zweierlei Hinsicht angetan: Sehr nett fand ich die explizite Auflösung der Studioillusion, sprich: man hat mal kurz gezeigt, dass die zwei Diskutierenden in einer Blue Box standen und der Professor auch noch eine Kiste zwecks Größenangleichung untergestellt bekam. Die "Diskussion" war dagegen eher fad: Zwar wurden einige alte manipulierte Aufnahmen gezeigt, aber die eigentlich interessanten Fragen wurden nicht diskutiert: Wie häufig findet Medienmanipulation statt? Und warum und durch wen findet sie statt? Wie glaubwürdig sind die heutigen Nachrichtensendungen und Zeitungsberichterstattungen, mal ganz abgesehen von im Web-generierten Nachrichten? D.h., die eigentliche Metaebene, auf der man diskutieren könnte, in wie weit unser Verständnis der Welt von Medienmeldungen geprägt ist, die selbst dann suggestiv sein können, wenn sie nicht bewusst manipuliert sind, wurde leider nicht erreicht.

Aber das zu erwarten wäre vielleicht auch zu viel des Guten. Zum einen war ttt schon immer das eher seichte Unterhaltungsprogramm der Kulturmagazine im Ersten. Man mag beklagen, dass die Kulturreport-Sendungen verschwunden sind, aber de facto hatte es da eh schon eine starke Annäherung der Inhalte gegeben. Anyway, im Vergleich zum Rest muss man für diese Reste von Inhalt im Fernsehprogramm ja dankbar sein. Und zum anderen würde die Diskussion solcher Fragestellungen möglicherweise zu viel unangenehme Folgen mit sich bringen: Schließlich hat das Fernsehen (das öffentlich-rechtliche im Speziellen) ein Interesse daran, weiterhin als glaubwürdige Nachrichtenquelle zu gelten. Von daher war es fast schon wieder erstaunlich, dass das Thema mit immerhin drei Beiträgen recht umfangreich aufgegriffen wurde.

Steve Yegge blogs about XEmacs needs to die and I would like to add my own little comment on the issue. First, perhaps some background: I'm a long-term XEmacs user, since about 1995, I think. I started hacking Elisp around 1996, implementing a major mode for the Otter theorem prover and various other stuff. Since 1997 or so, I had been somewhat active on the xemacs-beta mailing list, reporting build successes/failures, participating in discussions etc. and even writing an article on the then-new XEmacs port to Windows in the german iX magazine. So, perhaps, I'm a bit biased towards XEmacs. That I've been using XEmacs instead of Emacs had a lot to do with two factors: at my university, the local Emacs guru used XEmacs and provided a very complete configuration to start with. To start hacking Prolog source didn't require any configuration on my side at all. When I tried to re-establish that configuration on my own linux box, using Gnu Emacs was totally out of the question, which is basically the second reason: XEmacs came with a lot of batteries included, whereas Gnu Emacs only came with a directly dying low battery at best. And third, the XEmacs interface experience was a lot friendlier than with the naked Gnu Emacs.

Now, at the time I was actively following XEmacs development, XEmacs had a whole lot of man power behind it, with lively discussions and an exciting movement of adding new features. At the same time, RMS discussed switching Gnu Emacs to Guile (a scheme dialect), which me, as a Common Lisp user, scared me off even more. Around 2002 or so, my spare time for XEmacs dropped to zero, so I unsubscribed the development mailing list and was just a happy user. Until two seemingly unrelated things happened: first of all, Unicode was no longer to be ignored and it was obvious that the Mule (multiple languages for emacs or some such) for XEmacs wasn't up to the task, especially not on Windows. That was quite a problem for me back then with the then current stable XEmacs 21.4. Now, six years later, XEmacs 21.5 is still not there (aka released as the new stable version) and it's unicode support still sucks (not so much as it did, say, two years ago, but it still fails a lot of tests from Markus Kuhn unicode test suite). The second development was that the Emacs team, which I had only barely been aware of previously, somehow gained a enourmous momentum and catched up a lot of ground, where XEmacs had been the leader by far. In particular, as of Emacs 22, nobody in its sane mind could argue against the fact that the current Emacs handles Unicode etc. far better than XEmacs (this is especially true for XEmacs 21.4 on Windows, but even the current beta XEmacs 21.5-b28 on Unix isn't where it should be). This seems to be directly related to the fact that a lot of the key developers of the end of the last century no longer actively participate in XEmacs development. I think only few people from the XEmacs crowd would argue against the impression that XEmacs development has more or less cringed to a halt and the distribution of development power between Emacs and XEmacs development is nowadays reversed to the situation from the 90s.

That being said, I still stick with XEmacs. Last time I tried using Gnu Emacs (that's the Emacs 22 from Ubuntu Hardy), I still found that I'm far more accustomed with the XEmacs intrinsics on how to perform specific actions than with how it works in Emacs. And I never got around to clean up my mess of configuration files to properly support the various flavours plus adding the extension libraries that still don't ship with Emacs (Slime, for instance). Finally, with more and more users switching to Emacs, there has to be someone reporting problems,

Now, back to Steves blog post: I think he has some valid points in it, but for the most part I disagree. First of all, while I agree that Eclipse and similar IDEs are still not at the greatest enemy to Emacs (regardless of flavour). I'm currently again using Eclipse at work and it's a pain finding out how to properly associate an unknown file extension with some specific editor (mode). And it's a memory hog that results in unbelievable handling (on my dual core 2GB equipped desktop) that is even worse than my first XEmacs experience on my 486/33 with 8MB ram in 1995. Eight megs and constantly swapping? Hah! I can't believe that even today I have to hear that Emacsen would be too complicated, given that for any task/configurations I spend endless time searching/clicking through the gazillions of settings in Eclipse.

However, I also don't believe that a marriage between Emacs and some web-browser is the way to go. There are much more pressing issues to move Emacs into the next century than switching from Elisp to <whatever>. If you're interested in extending your editor, you have to learn about the way how to do that. But that is totally independent from the question which editor you're going to use in the first place.
What is a much more pressing need in my opinion is finally implementing multi-tasking for the (X)Emacs core. Still being locked in a single-threaded application model is sooo 1990s. It's not becoming more and more ridicuosly, it's utterly unbelievable.

In one other point, though, Steve is right on track: the divergence between APIs is becoming a bigger problem with every passing day. I think it's very unfortunate that a) Emacs developers don't let them inspire by the existing APIs in XEmacs and vice versa and b) that there are too few XEmacs developers that merge current Emacs enhancement into the XEmacs codebase (the other way 'round is always problematic due to license issues).

So, before I would consider pursuing a major architectural change like XUL or some such for Emacs, I would first work on the much lower-hanging fruit of narrowing the gap between the two flavours. It's a pity I myself only have the spare time to write such blog posts instead of actively working on code towards that goal.

In case you're interested in continuation-based web development with Common Lisp, it might be of interest to learn that Drew Campsie has voluntered to take over UCW development. Marco Baringer, initiator and maintainer of UncommonWeb (aka UCW) seemed somwhat relieved that finally somebody with more time on his hand steps up to take over.

That Marco hadn't had the time to keep pushing UCW is quite obvious from the mailing list archive. Lately Attila Lendvai seemed to me (an innocent external observer) to had pushed UCW foreward, however, as he Attila announced, he wants to go into a different direction than Drew.

I've been using ucw-dev during the last two years and the current situation really called for a change, in my opinion. UCWs main problem, as I observe it, is lacking documentation and clearly stated goals which way UCW will go. The automatically extracted documentation doesn't contain information how the bits fit together and all tutorials are a) incomplete, b) outdated as far as they are targetting ucw-dev, whereas development has mainly happened in ucw-ajax. However, it was not all clear that ucw-ajax really would become the main line of UCW.

I like UCWs component architecture a lot and will eagerly follow what is going to happen. With two prominent developers such as Marco and Attila more or less leaving the project, it will be interesting to see with how much activity development will happen from now on.

Dell is selling Ubuntu equipped systems since about a year now and seems to be quite happy with it. Whatever that effectively means, at least I can tell that I'm quite happy with Linux on Dell systems, too.

Through the last five years, I've been using Linux on a number of Dell systems. Under my personal control there have been three laptops (Dell C610, D610 and a Latitude 640) and a desktop (Optiplex 755), on which I have been running Debian Sarge, Ubuntu Dapper, Feisty and now Hardy. We also had several Dell servers at work running more or less smoothly with Debian (sarge, etch). Using Linux wasn't always without problems: I had trouble with built-in modems, PCMCIA ISDN cards and acpi/hibernation. For example, on my private Latitude 640, I have trouble suspending at all, because of the ipw3945 driver for the wlan. But the important thing to note is that basically all problems were really small and never of a size requiring me to use some other OS in the first place.

The only real issue is not with Dell per se, but more with my favourite OS, Debian: over the years, and especially with the ever-lasting sarge release, getting Debian to run on a recent system got more and more difficult. That's the main reason why I've been using Ubuntu on all recent hardware I had contact with: it's more or less (more so than less) a Debian system but does run on modern hardware. Main issues here were graphics adapters, sata/scsi hostadapters and network/wifi cards, or to put it otherwise: too old kernels, too old X.org. Both problem sources can simply be solved by using a recent version of Ubuntu. Sorry, Debian, but your release cycle is just too long to be acceptable. Granted, all these problems are mostly an issue when installing a new system, but it's not always possible to plug in some old disc with a working version of Linux.

Recent fun:
- Working hibernate/suspend without any manual configuration on a brand new Dell desktop using Ubuntu 8.04 (beta).
- Watching a self-generated video CD (probably done under Windows) under Linux without any problem with my wife that we couldn't watch on Windows due to scrambled colours under Windows media player.

Recent less fun:
- Hibernate/suspend on our older Dell laptop with Ubuntu 7.10 and finding it's a known issue with the ipw3945 driver.
- Getting vmware to work on a recent 2.6.24 system.
- Having fixed that finding out the hard way that Aero won't display in the VM, requiring to go back to cloning the (not so small) physical machine a third time.
- Being unable to get a DHCP lease over the rt2x00 driver for my USB wlan stick with kernel 2.6.24, despite being able to get a sucessful connect via wpa_supplicant/wext.

Neben viel Schnee, den man sogar zum Skifahren genießen kann, hat mir der Osterhase diesmal noch mehr mitgebracht: das Ende meiner Mannheimer Zeit. Bye Nordbaden, welcome back Südbaden! Zum Auftakt hatte der Osterhase meiner Family dann auch noch ein paar kleinere Erkrankungen mit eingepackt, aber das soll die Freude nicht mindern.

Your Inner European is French!

Smart and sophisticated. You have the best of everything - at least, you think so.

Auf den ersten Blick ist die Entscheidung des Bundesverfassungsgerichts zum Thema Online-Durchsuchungen ein Erfolg für die Gegner. Wie die Süddeutsche etwa im Artikel Kampf um Troja kommentiert, kann man das Urteil und insbesondere das neue Grundrecht als Mahnung an den Gesetzgeber sehen, etwas vorsichtiger beim Datenabgriff vorzugehen. Auf den zweiten Blick kann man an den Reaktionen (etwa bei den Tagesthemen) schön sehen, dass die Legislative versuchen wird, sich die wenigen Krümel herauszupicken, die etwas Interpretationsfreiraum bieten und diese Krümel dann so aufzublasen, dass so gut wie alles darein passt.

Man schaue sich etwa an, was nach einem Bericht der Stuttgarter Zeitung für das neue Polizeigesetz für BW geplant ist bzw. wie BWs Innenminister das aktuelle Urteil des BVG interpretiert. Nimmt man dann noch hinzu, was etwa die Richter zur Handhabung des Urteils meinen, dann sieht man sehr schön, dass mit dem Urteil die Probleme eben nicht vom Tisch sind. Ganz im Gegenteil ist zu erwarten, dass wir Gesetze bekommen, die -- im Rahmen der vom BVG vorgegebenen Grenzen -- so schwammig wie möglich bleiben, die Exekutive und Jurisdiktive mangels Kapazitäten eh den Vorgaben nicht im gewünschten/erforderlichen Maßen nachgehen kann und das neue Grundrecht schlussendlich als Papiertiger darstehen könnte.

Sicher, erfreulich bleibt, dass es jetzt dieses Grundrecht gibt und das man überhaupt die Chance hat, sich darauf zu berufen. Das ändert aber eben wenig daran, dass wir momentan einen Widerspruch zwischen Legislative und Jurisdiktive haben. Wir werden sehen, wie lange sich die Politiker diese unbequemen Wächter der Grundrechte noch ansehen werden, aber andererseits kann man sich ja auch darauf verlassen, dass die "normative Kraft des Faktischen" (in diesem Fall die Unterkapazitäten) mehr Spielraum lassen.

This post is mainly a reference post about a particular topic whose solution wasn't immediately obvious to me from the docs to CL-SQL. Using CL-SQL with (enable-sql-reader-syntax), I had written a routine that looks basically likes this:

(defun data-by-some-criteria (criteria &key (dbspec +db-spec+)  (dbtype +db-type+))
  (with-database (db dbspec :database-type dbtype :if-exists :old)
    (let (dbresult)
      (if criteria
	  (setq dbresult
		(select 'some-model 'other-model
			:where [and [= [some.criteria] criteria]
			            [= [some.foreign_id] [other.id]]]
			:order-by '([other.name] [some.foreign_id] 
				          [year] [some.name])
			:database db))
          (setq dbresult
		(select 'some-model 'other-model
			:where [and [null [some.criteria]]
			            [= [some.foreign_id] [other.id]]]
			:order-by '([other.name] [some.foreign_id] 
				          [year] [some.name])
			:database db))
      (when dbresult
	(loop for (some other) in dbresult
	      collect some)))))

This is ugly because the only difference between those two select statements is the check for the criteria, but I had no idea how to combine the two select statements into one, because it's not possible to embed lisp code (apart from symbols) into an sql-expression (i.e. the type of arguments for :where or :order etc.).

With the next requirement things would become far worse: The order-by statement needs to get more flexible so that it is possible to sort results by year first. Given the approach shown above this would result in at least four select statements, which is horrible. So, naturally I wanted a single select statement with programmatically obtained :where and :order-by sql expressions.

Step 1: It occured to me that it should be possible to have the arguments in a variable and simply refer to the variable. E.g., using a more simple example:

(let (where-arg)
  (if (exact-comp-needed)
      (setq where-arg '[= [column] someval])
      (setq where-arg '[like [column] someval]))
  (select 'model :where where-arg))

So I could now have my two different where-args and two different order-args and use a single select statement. Main problem solved.

Step 2: But for the :where arg in my original problem, only a small fraction of the sql-expression differs. So how do I avoid hard coding the entire value of where-arg? How can I combine some variable part of an sql-expression with some fixed parts? I.e, ultimately I want something like:

(let (comp-op where-arg)
  (if (exact-comp-needed)
      (setq comp-op '=)
      (setq comp-op 'like))
  (setq where-arg '[ <put comp-op here> [column1] someval])
  (select 'model :where where-arg))

But with CL-SQL modifying the reader, there seems to be no way to make <put comp-op here> work. I didn't knew how to get the usual variable evaluation into the sql-expression, or how to escape from CL-SQL's sql-reader-syntax to normal lisp evaluation.

Somewhere in the back of my head where was that itch that CL-SQL might offer some low-level access to sql expressions. And indeed it does. There are two useful functions, sql-expression and sql-operation. sql-operation "returns an SQL expression constructed from the supplied SQL operator or function operator and its arguments args" (from the cl-sql docs), and we can supply the operator and its arguments from lisp -- which is exactly what I want.

Now, the nice thing is that it's easy to mix partly handcrafted sql expressions with CL-SQL special sql syntax constructs that will be automatically handled by the reader (if you enable it only via enable-sql-reader-syntax, of course). I.e., for <put comp-op here> we can use sql-operation, but the rest stays essentially the same:

(let (where-arg)
  (if (exact-comp-needed)
      (setq where-arg (sql-operation '= [column1] someval))
      (setq where-arg (sql-operation 'like [column1] someval)))
  (select 'model 'other-model  :where where-arg))

Now, coming back to my original problem, based on this approach I can split out the common part of the :where and :order arguments and combine those with the varying parts as needed and hand them down to a single select statement. Problem solved.

It's interesting to see that more and more environments for interactive development are popping up. If you're wondering what I'm refering to, it's what has traditionally been labelled as an interpreter: you get some kind of prompt like in a command shell and can directly enter and run program constructs. In Ruby, irb is the tool to use, whereas most, if not all, Common Lisp systems provide you a REPL whenever you start-up the system. REPL is an abbreviation for read-eval-print-loop and this pretty much sums up how interactive development works: you enter some code into the system, and as soon as you hit enter (i.e. finish up the particular line of code), the system will read and evaluate it ("interpret" it, although CL systems may also compile it automatically), presenting you with the results.

To me, this seems like more people come to understand that the classic edit-compile-debug cycle of traditional compiled languages like C isn't particular well-suited to a bottum-up programming style, as advocated by the agile programming hype. Where is the beef? I've been told that the reason why the asian folk don't use forks and knives when dining stems from the opinion that when dining one merely wants to eat, while all handcrafting (like slicing the meat) belongs to the a-priori cooking. The edit-compile-debug cycle tends to produce code more akin to the western steak style, while interactive development tends to produce smaller code parts, all well prepared (read: tested) from the beginning, so you don't end up with bloody interiors as easily. That's because of two reasons, I think: In an interactive environment testing a piece of code is cheap and easy. Hack up a small routine and enter it. Next step: call the routine with some sample data. No need to compile. In case there's an error, you'll be thrown into the debugger right away. With the traditional edit-compile-debug cycle, you're gonna edit the code, save it, call the compiler, edit another piece of code testing it, compile that, too, run that and only then you'll see if it succeeds. This might scare developers from running such tests to often and in result to produce larger routines/code blocks. Second reason: in the interactive environment you'll typically have somewhat less comfort then in a full-blown editor. So I'm arguing that the slight discomfort will help you in keeping things small because then you'll not gonna need far reaching edit support.

There is, however, a price to pay: For starters, because your interactive system provides you with a single environment during development, it's easy to mess it up. That's different with the traditional edit-compile-debug cycle where every time you compile you run the code in a clean environment. This means, old code refering to refactored functions will result in (usually: compilation) errors whereas in interactive development you may miss some spot in need for modification because the old refactored code is still around.
Second, when fiddling with some functions, it may happen that one hacks up several variants, maybe with only slightly differing names or argument lists, so it may happen you forget some crucial code when finally saving your carefully crafted solution (where saving here typically means copy it over to some editor, not saving an image as you may do in Smalltalk or Lisp). Another thing is that one has to be careful not to confuse bottum-up interactive development with hacking without thinking or design-less programming. This threat is all to common because with an interactive environment it's just so easy to get started. Unfortunately, without thinking you'll soon end up with problems one and two and even worse, it's likely that after a little while nobody (including you, the author) will be able to maintain the resulting code. But if you're aware of the potential pitfalls, interactive development is a nice way to do explorative programming which avoids a lot of time consuming labour you have to do with the traditional edit-compile-debug cycle.

As a side-note, environments offering incremental compilation like Eclipse aim at a similar goal, but only go half the way as they only take care of the edit-compile part. Only when one combines that with a test-driven development style you arrive at a similar point, because now the test code, when automatically run, will take care of immediately running the code in question (the eval/print part as far as testing the code is concerned).

To finally come to the reason for this blog post, I was pleased to learn about the Perl Console, which is not the same as the Perl debugger. I'm eager to try it out, although I'm sure that interactive development with a repl and the executable brain dump that Perl code usually is, is a highly dangerous mix.

Update: There is also a series of articles about implementing a REPL in Perl which may be of interest.

This is just a minor rambling inspired by a recent thread on cll about the ups and downs of using Rails. What I find really overwhelming is the lack of proofs that other (typically Lisp-based) frameworks really have so much benefit over the established more traditional frameworks (e.g. Rails, Zope, plain PHP, ...). All I can see is starter documents, tutorials etc. that show how to program yet another blog or reddit clone in some particular framework. I miss fair comparisons and detailed discussions why and where exactly that one particular way of doing things has benefits. And especially with regard to those reddit clone prototypes: AFAICT, reddit was far beyond implementing some half-baked prototype (in Lisp) when they decided to switch (to Python). Yes, for demo purposes reinventing the wheel with some unround edges might be acceptable, but in reality only rolling wheels will be sold and this is where the challenge is.

I believe that while it's nice that frameworks help with implementing your 500 line application, they really need to show their value with large applications. Where is a discussion of a large on-line shopping system in, say, UCW and CL-SQL, with secure shopping over SSL, login handling, input validation, distribution over multiple servers etc.? Now, I'm not suggesting that UCW, Weblocks etc. can't be used to build such websites, but it would be nice to see a much more in-depth explanation/discussion/comparison of how to do it. That would also help increase the credibility of Lisp or at least, of lispers discussing (other) web frameworks.