Entries by Holger Schauer

Herb Sutter announces that Dr.Dobbs Journal is permanently suspending print publication and going web-only as of January 2009. I've used to be a long-time subscriber of DDJ -- several not-so-excited friends that recently helped moving into our new flat are my witnesses. Actually, I've stopped my subscription (and we're talking about a way to expensive subscription via a German importer, here) roughly one or two years ago, since I couldn't keep up with my reading but occasionally I've regret that I no longer receive it. Now, it seems to me like the last printed programming related magazine is going down the drain -- sorry, you Java and PHP magazines floating around, but your content isn't nearly as interesting as what DDJ had as it was ultimately the mix of different topic and opionated editorials that made DDJ so unique. Perhaps now I should hurry and finally buy the DDJ developer library dvd covering 21 years of DDJ articles. I'll keep an eye on what will happen to DDJ as a web publication.

Gestern war das Topthema der Tagesthemen, dass aktuell in den USA immer mehr Menschen die Kirchen füllen. Im Zeichen der Finanzkrise suchen die Menschen nach Halt im Glauben. Da die Suche nach dem Sinn, dem Universum und dem ganzen Rest auch mir schon immer ein Anliegen war, war ich riesig erfreut, als ich an diesem Wochenende per Zufall in einer unscheinbaren Buchhandlung eine Entdeckung machte, die mein Leben und mein Bild der Welt völlig auf den Kopf stellte: das Evangelium des Fliegenden Spaghetti Monsters. Endlich eine Religion, die meine Spaghetti Bolognese-Anhänger in der Familie sofort begeistert. Leider bin ich ja noch ein Neuling in der Welt des Pastafarismus, daher überlasse ich das Missionieren lieber anderen (etwa der EVKdFSMiD), aber meine Begeisterung und mein Staunen über die Weisheit des FSM musste ich in die Welt tragen.

ObTitle: Bob FSMarley, "Pastafariman vibration"

I've become a python programmer, too, lately, due to a job change. Python is a fine language so far, although to me it's mostly just like Ruby, though with even less functional flavour. However, just as with Ruby, I'm really missing slime, the superior lisp interaction mode for Emacs, when hacking python code. I could now start to write down a list of things I'm missing (which I've intended to do), however, Andy Wingo spares me the hassle, as he has just written an excellent article on slime from a python programmers view.

However, I would like to elaborate a little on the main difference for me: the client/server socket approach of slime. Let me briefly recapulate what this implies: slime consists of two parts, a client written in Emacs lisp and a server written in Common Lisp (AFAIK there is at least also an implementation for clojure, maybe also one for some scheme implementation). In order to use slime in it's full glory, it's hence required that you have a common lisp process running which in turn runs the slime server part. If you now fire up slime, you'll get an interaction buffer over which you can access the REPL of the lisp process, which in python would be the interpreter prompt. You can then interact with the lisp process, evaluating pieces of code from your lisp source code buffer directly in the connected lisp process. What is incredibly useful for me is that you can not only start a new lisp process but also connect to an already running lisp process, given that it has the slime server started (this is obviously mainly useful if the lisp implementation you use has multi-threading capabilities). I use it to connect to a running web server application, which I can then inspect, debug and modify. Modification includes redefinition of functions, macros and classes, which of course is also a particular highlight of Common Lisp. I would like to cite a comment of the reddit user "fionbio" he made wrt. to the linked article: In fact, Python language wasn't designed with lisp-style interactive development in mind. In CL, you can redefine (nearly) anything you want in a running program, and it just does the right thing. In Python, there are some problems, e.g. instances aren't updated if you modify their class. Lisp programmers often, though not always, refer to various things (functions, classes, macros, etc.) using symbols, while Python programs usually operate with direct references, so when you update parts of your program you have much higher chances that there will be a lot of references to obsolete stuff around.

To complement Bill clementsons excellent article series on slime a little, I'm going to describe how I'm using/configuring python-mode to make it match my expectations a little closer. Essentially I would like to access my python process just as I would with slime/Common Lisp, but that's not possible. The reason, btw., is nearly unchanged: I need to code on a web server app (written in Zope) which may not even run on the same machine I'm developing on. Let's first cover the simple stuff: To enable a reasonable command interface to the python interpreter, I require the ipython emacs library. If the python interpreter runs locally, I also use py-complete, so that I can complete my code at least a little. Unfortunately, this breaks when the python interpreter doesn't run locally, because the py-complete needs to setup some things in the running python process, which it does by writing to a local temp file and feeding it to the python process. Unfortunately, the code in py-complete lacks customizability, i.e., you can't specify where that temp file should be located -- I should be able to come up with a small patch in the near future, which I will add below. Finally, I also require doctest-mode as a support for writing doctests, but that's not really relevant.

Now, on to the more involved stuff: I introduce some new variables and a new function py-set-remote-python-environment, which uses the those variables to do a remote call (via ssh) to python. This at least allows me to do things like setting py-remote-python-command to "/home/schauer/zope/foo-project/bin/instance" and py-remote-python-command-args to "debug", so that I can access a remote debug shell of my current zope product. That alone will only allow me to fire up and access the remote python, so I could now develop the code locally, having it executed remote. More typical though is that you would also want to keep the code on the remote machine, too: for this I use tramp, a package for remotely accessing files/directories from within emacs. In combination, this allows me to edit and execute the code on the remote machine. It is still nowhere near what is possible with slime, but at least it allows me to persue my habit of incremental and interactive development from within my usual emacs installation (i.e., it doesn't require me to deal with any Emacs related hassle on the remote machine).

;;; python-stuff.el --- python specific configuration

(when (locate-library "ipython")
  (require 'ipython))

(when (locate-library "doctest-mode")
  (require 'doctest-mode))

(defvar py-remote-connect-command "ssh"
  "*Command for connecting to a remote python, typically \"ssh\"")
(defvar py-remote-connection-args '("user@remotemachine")
  "*List of strings of connection options.")
(defvar py-remote-python-command "python"
  "*Command to execute for python")
(defvar py-remote-python-command-args '("-i")
  "*List of strings arguments to be passed to `py-remote-python-command`.")
(defvar py-remote-python-used nil
  "Remember if remote python is used.")

(defun py-set-remote-python-environment ()
  (interactive)
  (let ((command-args (append py-remote-connection-args 
			      (list py-remote-python-command)
			      py-remote-python-command-args)))
    (setq py-python-command py-remote-connect-command)
    (setq py-python-command-args command-args))
  (setq py-remote-python-used t))

(when (locate-library "py-complete")
  (autoload 'py-complete-init "py-complete")
  (defun my-py-complete-init ()
    "Init py-complete only if we're not using remote python"
    (if (not py-remote-python-used)
        (py-complete-init)))
  (add-hook 'python-mode-hook 'my-py-complete-init))

One of the bigger practical problems with unit testing is isolating the test coverage. Say, you want to test a piece of code from the middle (business) layer. Let's assume further the piece of code under consideration makes some calls to lower level code to retrieve some data. The problem of test coverage isolation is now that if you "simply" call your function, you are implicitly also testing the lower level code, which you shouldn't: if that lower level code gets modified in an incorrect way, you would suddenly see your middle level code fail although there was no change made to it. Let's explore ways to avoid the problems in Common Lisp.

There is a very good reason why you would also want to have such test dependencies to ensure your middle level code still works if the lower level code is extended or modified. But that is no longer unit testing: you are then doing so-called integration tests which are related, but still different beasts.

Now, I was facing exactly the typical dreaded situation: I extended an application right above the database access layer which had not seen much tests yet. And of course, I didn't want to go the long way (which I will eventually have to go anyway) and set up a test database with test data, write setup and tear-down code for the db etc. The typical suggestion (for the xUnit crowd) is to use mock objects which brings us finally on topic.
I was wondering if there are any frameworks for testing with mock objects in Lisp, but a quick search didn't turn up any results (please correct me if I've missed something). After giving the issue a little thought, it seemed quite clear why there aren't any: probably because it's easy enough to use home-grown solutions such as mine.

I'll use xlunit as the test framework, but that's not relevant. Let's look at some sample code we'll want to test:

(defun compare-data (data &connection)
  (let ((dbdata (retrieve-data-by-id (id data))))
    (when (equal (some-value data)
                (some-db-specific-value dbdata))
         t)))

The issue is with retrieve-data-by-id which is our interface to the lower level database access.
And note that we'll use some special functions on the results, too, even if they may just be accessors.
Let's assume the following test code:

(use-package :xlunit)

(defclass comp-data-tc (test-case)
  ((testdata :accessor testdata :initform (make-test-data))))

(def-test-method comp-data-test ((tc comp-data-tc))
  (let ((result (compare-data (testdata tc))))
    (assert-equal result t)))

Now the trouble is: given the code as it is now, the only way to succeed the test is to make sure that make-test-data returns an object whose values match values in the database you're going to use when compare-data get's called. You're ultimately tying your test code (especially the result of make-test-data) to a particular state of a particular database, which is clearly unfortunate. To overcome that problem, we'll use mock objects and mock functions. Let's define a mock-object mock-data and a mock-retrieve-data function, which will simply return a single default mock object.

(defclass mock-data ()
  ((id :accessor id :initarg :id :initform 0)
   (val :accessor some-db-specific-value :initarg :val :initform "foo-0"))))

(defun mock-retrieve-data (testcase)
  (format t "Establish mock for retrieve-data")
  (lambda (id)
      (format t "mock retrieve-data id:~A~%")
      (find-if #'(lambda (elem
			(when (equal (id elem) id)
			  elem))
                    (testdbdata testcase))))

Why that mock-retrieve-data returns a closure will become clear in a second, after we've answered the question how these entirely different named object and function can be of any help. The answer lies in CLs facility to assign different values (or better said) definitions to variables (or better said to function slots of symbols). What we'll do is to simply assign the function definition we've just created as the function to use when retrieve-data is going to be called. This happens in the setup code of the test case:

(defclass comp-data-tc (test-case)
  ((testdata :accessor testdata :initform (make-test-data))
   (testdbdata :accessor testdbdata)
   (func  :accessor old-retrieve-func)))

(defmethod set-up ((tc comp-data-tc))
  ; set up some test data
  (dotimes (number 9)
    (setf (testdbdata tc)
             (append 
                  (list 
                      (make-instance 'mock-data 
                            :id number 
                            :value (concatenate 'string "value-" number)))
                 (testdbdata tc))))
  ; establish our mock function
  (when (fboundp 'retrieve-data)
    (setf (old-retrieve-func tc)
             (fdefinition 'retrieve-data))))
  (setf (fdefinition 'retrieve-data)
           (mock-retrieve-data tc)))

(defmethod tear-down ((tc comp-data-tc))
   ; After the test has run, re-establish the old definition
   (when (old-retrieve-func tc)
      (setf (fdefinition 'retrieve-data)
           (old-retrieve-func tc))))

You can now see why mock-retrieve-data returns a closure: by this way, we can hand the data we establish for the test case down to the mock function without resorting to global variables.

Now, the accessor fdefinition comes in extremely handy here: we use it to assign a different function definition to the symbol retrieve-data which will then be called during the unit-test of compare-data.

..Establish mock for retrieve-data
mock retrieve-data id: 0
F
Time: 0.013


There was 1 failure: ...

There is also symbol-function which could be applied similarly and which might be used to tackle macros and special operators. However, the nice picture isn't as complete as one would like it: methods aren't covered, for instance. And it probably also won't work if the function to mock is used inside a macro. There are probably many more edge cases not covered by the simple approach outlined above. Perhaps lispers smarter than me have found easy solutions for these, too, in which case I would like to learn more about them.

While I'm usually a happy VC user (the SCM mode of Emacs) as the next guy, I recently haven't always been so happy. In particular when I'm working on a larger set of changes in multiple files (using Subversion or Mercurial), the commit-per-file approach of VC just doesn't cut it, because usually you want to commit all changes you have to make for a fix or feature to happen in a single transaction. That's simply not possible with VC, so I usually fall back to the command line. That I can then use Emacs for the commit message is only a slight quantum of solace.
An integration of SCM features into dired (which I happen not to be a big fan of, btw.) looks to me like the obvious way to go. I'm hence very happy to learn that this is more or less happening (or has already happened) with the past-Emacs 22.1 version, according to this blog entry on manipulating changeset-based VCS from within Emacs. It's unlikely that this will be up to match Tortoise or TortoiseHg, but still ...

The Release Warp Lyrics


It's astounding, time is fleeting
Madness takes its toll
But listen closely, not for very much longer
I've got to keep control

I remember doing the Release Warp
Drinking those moments when
The blackness would hit me and the void would be calling
Let's do the release warp again...
Let's do the release warp again!

It's just a bug to the left
And then an error to the right
With your hands on your keys
You bring your fixes in tight
But it's the pelvic thrust that really drives you insane,
Let's do the Release Warp again!

It's so dreamy, oh fantasy free me
So you can't find me, no not at all
In another dimension, with capitalistic intention
Well-secluded, I see all
With a bit of a mind flip
You're there in the bug slip
And nothing can ever be the same
You're spaced out on sensation, like you're under sedation
Let's do the Release Warp again!

Well I was typing down the plan just a-having a think
When a snake of a marketeer gave me an evil wink
He shook me up, he took me by surprise
He had a business plan and the devil's eyes.
He stared at me and I felt a change
Time meant nothing, never would again
Let's do the Release Warp again!


(... with sincere apologies to The Rocky Horror Picture Show by Richard O'Brien)

Ah, holiday time, the time when you finally have some time on your hand. Time to hang around at beaches ... and to read some nice books. This time, I had four books with me, but found just enough time to finish two of them -- there was also swimming and sun bathing to do, mind you.

The first one, "The bed room secrets of the master chefs" by Irvine Welsh is a novel constructed around one interesting idea: what if you could transfer all your personal disasters over to the one person you're hating the most? Although it would be equally valid to say that the novel is constructed around the question what damages permanent alcohol abuse can do to your body, but something along this line is probably the connecting issue of Welsh's books anyway. What I particular liked about this book is the way in which Welsh describes the figures to encounter in British (or make that Scottish) pubs: judging from the few times I've been to a pub in the UK it's easy to take the picture Welsh is painting for real. A note of warning: if you don't like "explicit content" this is not a book to your likening and if you don't happen to be a native speaker (I'm German) this is not the easiest book to pick up. Funny and very recommended if you like pub novels.

The second book I've read is "Gangleader for a day" by Sudhir Venkatesh, subtitle "A rogue sociologist crosses the line". It's an autobiography and a fascinating one. Sudhir Venkatesh wanted to find out more about urban poverty in Chigaco and got to take a very close look into the ghettos of modern America. He befriends a gang leader in Chigaco and learns about how the people in the poor projects manage their lives. Although his writing is a little dry, the characters and stories are fascinating. It's of course a very particular look at american society, one which teaches you respect for the poor, but still one which doesn't increase my respect for the american society and its politicians as a whole. Well worth a read.

As you might have noticed, the software (serendipity) behind this blog has been updated, resulting in several new features. I'm not sure yet if I'll keep the ranking functionality (too few readers anyway to be useful), but the tags are unlikely to go away soon.

Update: as you might have noticed, the tags haven't been to stable. Automatic keyword parsing has have its unfortunate side effects. There still might be some wrong tags. Update2: And all categories are gone. Hooray. :-((

Ah, and the provider is now called weblog-writer.net instead of 1on.de.

Debian just published an update to their stable distribution etch dubbed etch-and-a-half. The big news here for everyone not accustomed with Debians release cycle anyway is that it's the first time that it's not only a point release that fixes security issues but it's an update to the stable release that gasp adds support for new hardware, too. It even brings important fixes for some applications.

First of all, that's a tremendously good step in the right direction. In the past I've been bitten more than once by the long release cycle of Debian, outlasting all care taking of hardware compatibility. It's the primary reason that the only machine under my direct control running Debian is my rusty private workstation at the moment, all other machines needed newer drivers and hence are installed with Ubuntu. So, if Debian finally realizes that it has to change something to support newer hardware that's more than welcome.

However, it's not really etch-and-a-half. It's not much more than a new kernel which I would compile regularly from kernel.org myself anyway. Admittedly, there are also two new xservers (for nv and intel), but that's still not very helpful for people with newer ati hardware, for instance. But I'm a developer and much more than any hardware hassle I'm much more bitten by really outdated development tools. I've written only one blog entry about the issue, but it's a topic that most developers could write books about -- or maybe not, most of them probably just compile newer versions as needed and are done with the issue. This looks like the easy way out but it doesn't really solve the issue: if you've got to deploy your software you'll need to ensure that what you need is there. But using newer versions of base libraries forces you to deploy them yourself, which also means that you got a problem whenever a security issue will be found in those libraries. On the contrary, with system libraries you don't need any manual deployment of libraries you're only using and you can hope to participate of all system updates. So, in my eyes that's clearly a big advantage for using system libraries. But with Debian (and etch-and-a-half doesn't change this) you're stuck with older libraries which a) might lack long wanted functionality and b) are incompatible with versions from other vendors, which is a pain if you need to deploy on different platforms. Now, granted that the latter problem is not only tied to the age of libraries, but it would be a lot smaller if Debians general release cycle wouldn't be that long. I know of software vendors who have thus decided to develop for Ubuntu but not for Debian, in order to minimize portability issues due to library/functionality mismatches between platforms. To me, that looks like quite high a price to pay.

James Hague blogs about how writing a spellchecker used to be a major feat of software engineering, the main point being that memory was a main problem that's no longer an issue today. While that is certainly true, the two issues (memory, spellchecking problem) are not as much related as James claims.

Without making it explicit, he makes the assumption that for spell checking to work you have to use a dictionary consisting of entire (correctly spelled) words. That would have been a very unwise way to go in the 80ties and it still is nowadays. /usr/share/dict contains roughly 240.000 words and you find that impressive? I don't. The real number of words of a language is much larger, which is easier to see in languages like German where you can easily build compound words. Hence, linguists typically try to capture as much information as they can in word building rules.

This will leave you with three things: a dictionary of words which are not built according to the generally applicable rules (for instance necessary for foreign words prominent in your language of choice), and a set of stems, basic building blocks of words. Quite to the contrary of James' claim that 3-5 lines of Perl are everything you need, the thing to keep in mind here is that this is the only way to solve the "spellchecking problem": any full-form approach to spellchecking is doomed to fail because a language's vocabulary does not consist of a closed set of words. How else could publishers of dictionaries go on selling new versions of their dictionaries every year? Another point is that in some languages (e.g. German) some aspects of spelling might be dependent on context (grammatical and semantical context). I.e. in order to be able to decide whether it's correct to write "Fahren" you need to have a basic understanding of the grammatical composition of the sentence it appears in: it might be a noun derived from "fahren" (to drive) or it might be situated at the beginning of a sentence (and sentence boundary detection is not always trivial either). Now, if your spellchecker just checks a dumb list of words it can't decide whether "Fahren" is correct or wrong.

With regard to the implementation issue, using a non-full form approach also helps: The nice thing is that you don't have as much redundancy and you can spellcheck a lot of words you've never heard of just by following the rules. Unfortunately, the number of stems is still huge if you want to do achieve a good rate, so of course clever tricks to deal with the list of stems is still required. There are of course still different routes you might take to implement spellchecking: what ispell or aspell are doing, for example, is mostly using a full-form approach using only minor modifications to recognize some simple word production rules. This is not what you will find in state-of-the-art spell checkers.

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.