I have a particular interest in several technological areas.
This is more a personal interest (toys, you could say) than a professional interest, but usually these `toys' are quite useful when applied in my work (and I manage to find a link in all cases --- no exceptions there).
Technologies described here are
I like Linux very much.
It combines my belief in Open Source software with my fondness of Un*x.
What I like about the Open Source movement is that it is so motivated and active, so alive.
People develop software `for fun' and want to deliver the best they can because their `name is at stake'.
Note how the word `money' never shows up.
I dislike reasonings with money because it introduces politics, marketing bluff and rivalry, all of which are bad for the open, positive atmosphere that I like so much (actually, that's what I like about making theatre).
What I like about Un*x is that it is built from small, tightly cooperating programs rather than have each application reinvent most wheels.
The result is an operating system which is easier to maintain (in the long run), and which offers a more consistent interface.
Furthermore, those little programs get a fair chance to get really good at what they do.
An excellent example is
xsnow, an application to draw falling snow on the desktop screen.
This command is quite insanely equiped with options:
bash$ xsnow --help
-tc <tree color>
-bg <background color>
-solidbg (Performance improvement!)
-slc <sleigh color>
-delay <delay in milliseconds>
-windtimer <Time between windy periods in seconds>
-xspeed <max xspeed snowflakes>
-yspeed <max yspeed snowflakes>
-wsnowdepth <max snow depth on windows>
-offset <shift snow down>
-ssnowdepth <max snow depth at bottom of display>
Recommended: xsnow -bg SkyBlue3
This is an outrage, but it shows quite well how possible it is to tailor programs to a specific use; it makes those programs quite open and pluggable.
Of course, most programs have a default way of doing things right `for most cases'.
For newcomers, Linux (and Un*x in general) is hard.
But if you use a platform often, it's worth the investment.
That is, I think the time spent on rebooting a system three times while installing J++ would have been better spent reading documentation.
See my links for more.
The exploding Internet has done little good for HTML, which got extended with features in a pace that overruled all architectural concerns.
The W3C therefore started standardising HTML.
This led to the separation of stylesheets from content.
The current developments in content description take place in the XML language, and the layout of this content is done with XSLT.
If XML and XSLT would be only concerned with web authoring, it would be of no interest to me.
However, the XML language makes it possible to describe content in a notational framework for which (generic) parsers exist, notably the Document Object Model DOM which delivers a parsed XML document as a network of concept-representing objects.
This makes it a lot simpler to define a `language' for a particular research domain, and manipulate the structures in the DOM objects and save them again to an XML document.
This actually is so easy, that it is doable to write very little compilers for every little step along the way, making debugging quite simple.
This is doable because the intermediate format is always an XML document as long as the compiler directly manipulates the DOM objects, and it is no work at all to save intermediate results with the generic saving routines!
There is good support for XML/DOM in popular languages, including Java, Perl and Python; more than enough to make me happy regarding my PhD research prototypes.
But there is more.
A certain class of transformations on XML documents, roughly those performed on documents by recognising patterns of nested XML objects but without carrying data around in variables, can be performed without touching a real programming language!
The XSLT language is a style-sheet language, and it works by traversing a document, selecting the most concrete input pattern that matches found objects, and mapping them with the output patterns that are coupled to the input pattern.
And this works for many compilerish problems too!
My use of XSLT is not the intended use, but I think it will soon become mainstream.
It's amazingly more fun and a lot simpler than crafting it all by hand.
For this reason, I set up an interesting project to generalise XSLT to work on any number of inputs (like a general function) and to start treating such transformations as operators rather than stylesheets (the W3C terminology and currently intended use).
I am building my Life cycle research prototypes with XML technology, and I feel more productive than ever.
The joy of solving problems once on a metametameta-level rather than numerous times on the actual coding level is quite noticable.
My web site is made with XML as well.
It exploits self-defined tags, mixed-in with HTML, to generate standard lay-out.
If I want to change the look and feel of my pages, I don't have to edit all HTML files separately, but instead I just generate them.
A description of the site production approach (and styles) can be found here.
LaTeX + vim
When I am writing, I can build up quite a tranmission speed from my brain to my file system.
This is very important to me, because it means that I can write a braindump, without being distracted from the process by pop-ups, spelling error messages, and so on.
This first phase of brain dumping must not be interrupted by mouse interaction or other clumsy I/O devices; all I want is a keyboard.
The nice thing about vim is that it needs nothing beyond a keyboard, and a trained editing person, to work more efficient than any other editor I have ever seen.
So, I use vim for such text entry.
The nice thing about LaTex is that it seperates content from layout.
The content (and logical directions about the look) are provided with the editor, and LaTeX does all the actual layout.
This approach has great appeal to me.
Most documents written with other text processing applications have been layed out manually, and they show me each time that layout is an expert's job.
This expertise has been implemented in LaTeX; a common alternative is Microsoft Word, which obviously has not much knowledge of typesetting built in.
I prefer not to make those mistakes and leave layout to LaTeX.
For more, see may 3 papers on Computer Typesetting (in Dutch).
I also have a set of links to TeX and LaTeX related websites.
Finally, I made a letter generator with a forms-based web interface on top of LaTeX's Dutch letter style --- very well done layout!
The scripts are available locally only to a few.