Ant and Irony

The authors of Ant deserve a prize for irony. In the manual’s introduction, it says that “Makefiles are inherently evil as well.” I won’t deny the shortcomings of make, but these guys say that make is evil, then go and build an XML based build system. I mean come on, if there is anything worse than worrying about tabs it is having to manually write XML.

Ruminations on Literate Programming

First off, I would like to begin by saying that this post will be a little different than usual. It is not so much an explanation, a tutorial, or the asserting of an opinion (and you all know what an unopinionated fellow I am), as it is a monologue like discussion. Running through possibilities, tossing out ideas, but it is not likely to present any firm conclusions. So, here we go.

I recently read Donald Knuth’s paper on WEB, a literate programming system that he wrote with others for their own use. The paper is listed in the references section. At first glance, literate programming makes perfect sense in academia. Code is not written that is not intended to be published as either a paper or a book. Using literate programming makes the task of doing both easier. As the content of the code changes, the commentary itself is readily changed to match.

The question that comes to mind, though, is whether or not literate programming has potential for the working programmer. In Academia, the real work is generally not the programming. The programming itself is merely a way to try to prove whatever the hypothesis is. It is the equivalent to a test in a physics laboratory. The working programmer is not using his code as a mere test. It is the final product and it has to work. Moreover, it must also be delivered in a reasonable (or, more often, unreasonable) amount of time. In this different atmosphere, does literate programming still have a place? Would it work as well for someone writing code to track truckloads as it does for Knuth when he writes his books? At first glance, it would be easy to say no, but Knuth extols the methodology for reasons that most programmers would find appealing. He intimates the LP makes maintenance easier.

If there is anything the working code monkey would love to see, it is an easier job in maintenance. Most of us have had that experience of looking at a screenful of code and wondering what he (or I) was thinking when this was written. If we are writing down are reasoning with the code, then the questions go away. We may not agree with the reasoning, but at least we would understand the angle from which the problem was hit. Naturally, most people would do as poor a job of maintaining an essay as they would the comments (there are virtually no comments in my production code). As with any methodology, its utility stands on its practitioners, not on its non-practitioners.

On StackOverflow, several users run down the idea as being outdated or outmoded, being suited to the dark days of when we were limited to two-character variable names. While the utility may be increased under such conditions, they have missed the point. Literate programming is not about writing a lot of comments–it is about writing a book or article on the problem, side by side with the problem’s solution. Literate programming is not an idea confined to a specific time. It is not a hack (as intimated). It is a way of looking at programming that turns the whole process on its head. The machine becomes auxiliary, the human audience becomes primary. It may be that this approach does not hold practical utility–but it is not something to be as lightly shoved aside as the idea of starting a completely new and independent piece of software in RPG III.

These rambling thoughts led me to look into some present day tools (even Knuth’s own WEB has been superseded, it seems). The one with the biggest following is noweb, which is language agnostic. My biggest complaint as I fish through the tools I could find, is that they were almost universally using TeX as their typesetting format. Historically speaking, this makes sense. Knuth wrote WEB and TeX and, more specifically, he wrote WEB for TeX. I, however, do not want to compose text in TeX or LaTeX. As I have written before, it is just to cluttering. There are a few out there that rely on something else. I found one that used wiki syntax. At least noweb supports HTML mode which, while still imperfect for composition (as an interchange and basic display format, it is excellent), is at least usable.

Any value that LP has will largely rest on the fact that it forces the programmer to think a little bit more about what he is doing as he is doing it. In this way, it is not unlike Haskell’s type system (which also makes it unsurprising that the Haskell community is one of the more vibrant outposts for LP).

A lot of questions still remain. Most LP tools are usable for standard write-compile-test cycles. For languages like Lisp, a separate tool would have to be created (not that a lot of weekend warrior projects do not already exist). On StackOverflow, a few users expressed concern for how you would use LP in a collaborative environment. Personally, I would suspect that it would work similar to the way that most technical writing team works: divide and conquer. Distributed source control systems like git or darcs make this even easier.

So what is it then? Academian pipe dream or underused tool? There is only one way to find out. Try it.

References

The Old Schooled Office Suite

Lately, I have been working on getting my few office suite needs moved over to something a little more text based. I find GUI apps pretty inefficient for these kinds of tasks. Understand that this is not an open source vs. closed source discussion. OpenOffice.org Writer and Microsoft Word get grouped together, as one is basically an open source cross platform version of the other. This is actually contrasting two different application philosophies. I am, in fact, looking for something that is more usable.

Usability is a commonly trotted out concern when evaluating software. Now, when the word is thrown out, it is loaded with a specific meaning that is actually improper to its use. Usability is conflated with something that has a flat learning curve. So flat, that it is assumed that the hypothetical user could learn the application every time they start it. It is assumed that it usability refers to the flat learning curve as opposed to a tool that requires a little more upfront effort. This is unfortunate, because usability is actually a slider between the two extremes of “easy to learn” and “efficient to use”. Where a “usable” application falls on this continuum is up to the user in question. Commercial software naturally gravitates towards the “easy to learn” end of the spectrum, because it is the end that accommodates the greatest slice of the populace. Even the more hardcore of us can get by with software that still has the training wheels on.

So, the usability I am looking for is one of efficiency not of expediency. I want apps that will allow me to produce what I want fast and roll on. I am willing to accept a steeper learning curve upfront, it it means time savings later on. This is, for example, why I am using Vim for day to day text editing (like programming) rather than jEdit or syn. Sure, it took longer to learn upfront, but I can move through a text file fast.

Some other considerations for me was that I like using tools that I can use from a straight terminal because it means that I can access them over SSH. No need to sync files, just remote in to the machine carrying the files. This may not be a concern for most users out there, but it makes my life a lot more convenient.

As an example, this little spiel started with the search for an application I could use to draw process flows in a declarative manner. It does not take much to be able to pull open Visio or Dia and draw the diagram. When you think about it, that drawing process takes longer than seems necessary. You click the tools in the pallets. You click through the properties. You drag. You drop. You do a lot of work to draw a picture. However, if you can simply declare the relationship, it would be a lot more efficient. That is what I was looking for, but what I’ve set up is a nice little replacement, for everyday use, for OpenOffice.org/Microsoft Office. So, here goes my list.

Graph/chart drawing & diagramming

Graphviz. More typically used for diagrams produced in mathematical articles (writing on graph coloring algorithms, for instance), this little tool will produce directed or non-directed graphs. The syntax is simple and C-like, allowing one to declare nodes, with optional properties, and edges connecting them.

Email

The biggest two CLI email clients are mutt and pine. Mutt is clearly the more configurable of the two, but Alpine (the new, completely OSS version of Pine) is quick and easy. My biggest annoyance with Alpine is its heavy verbosity. There are plenty of “are you sure?” prompts. Ultimately, I found Sup. Sup is self-described as being a sort of text-based version of Gmail. Sup wins hands down with a nice interface and a powerful search engine.

Word processing

Word processors have gotten huge. Nonetheless, most of what they have to offer is seldom used. The Word power users I have heard mention this always do so with a touch of regret. As though we all should spend more time learning to use Word. The fact is, most of those features go unused because people don’t need them. I fit firmly in that category. I wanted a markup system I could use so that my documents would be composed in pure text (allowing me my precious Vim), but easily run through into something more print ready or presentation ready.

I considered TeX or LaTeX briefly. However, two things about them bothered me. First, there was the sheer ugliness of the markup. The large quantity of line noise interjected into my manuscript as I was composing was simply too much. It distracted too much and was too cluttering. Secondly, there was the heavy mathematical and scientific bias. A good portion of the documents I work on are related to my fiction writing. The ability to pretty print mathematical formulae is not helpful. So, the trade off was simply not worth the benefits.

Wiki syntax is a good example of what I wanted. Plain, non-cluttering, and very close to an ASCII version of all formatting. A little bit of research brought me to Markdown, Pandoc (which accepts Markdown), and AsciiDoc. My favorite of these is AsciiDoc. Its native backends are HTML and DocBook. However, DocBook (around which AsciiDoc provides a wrapper utility) can be converted to many formats, including PDF, ODF, and RTF. So, if you use this, you can create something that just about anyone can open. Pandoc actually offers more native backends than AsciiDoc (including DocBook, so the same ups apply), but generates plainer HTML. Sure, I can style it. I can make it default by aliasing pandoc to pandoc -c mystyle.css. Someday, I may even do it, but right now I am lazy. I don’t want to have to write a reasonable CSS file for quick and dirty use. So, I am using AsciiDoc for now because it caters to my sheer laziness.

Spreadsheets

Most uses of spreadsheets are evil. It seems that a lot of the world tries to use Excel like a database system—which it isn’t. However, their utility for quick little things cannot be ignored. Besides, I still have to deal with the spreadsheets I receive. I found two modern day, command line driven spreadsheet systems: sc and Oleo. sc is older, its source having its origin as a public domain application on USENET. Its interface is largely inspired by vi and less. Oleo is GNU’s spreadsheet application and so, understandably, takes its cues from Emacs. The most important command, C-x C-c, is the same. Naturally, when you put it that way, I have no choice but to fall in with sc. It is a nice little piece of work, allowing quick manipulation of data. Neither of these applications will generate pretty pictures for use in a word processor, but we quickly find ourselves rescued by the UNIX philosophy of a tool for every job. sc/Oleo do not need to provide ways to dump out pretty pictures—that is not their job. They crunch data. We use something else to create graphs.

Tasks

Those TODOs that we all have to keep. Microsofties keep them in Outlook. Anti-computerites either keep them on paper or not at all. The best text-based system I have seen is TaskWarrior. It is truly awesome.

Calendering

Another application that is integrated with Outlook and Exchange for most users. The command line applications are, of course, more loosely coupled. The best event scheduling calendar I found was Pal. Pal looked like it was more heavily geared towards the way people think of calendering.

Instant Messaging

IM is not a part of the traditional office suite, but, it is becoming a regular part of most offices. Finch is the clear winner on this front. There are plenty of text based IRC tools, but Finch is built on top of libpurple and supports all of the protocols that Pidgin does.

Music player

Again, I suppose this is not really a part of the traditional office suite, but we all want one. There is a reason Windows ships with Media Player. It is because Microsoft recognized that people wanted one and if it didn’t ship with Windows people would (horror of horrors!) use non-Microsoft software. My favorite GUI music player is Amarok. On the CLI side, Moc and CMus are excellent choices. MOC seems a little more intuitive.

Loose Ends

Unfortunately, the formats version of musical chairs does not usually permit us to keep everything strictly text and HTML. Those of us who are still part of the real world have to accept and send files in popular formats. Fortunately, OpenOffice.org allows exchanges between the backends of many of the formats that would be required. Unoconv, a Python script to interface with the headless version of OpenOffice, makes those conversions easy from the command line.

I am sure that there are people for whom this type of setup would be simply unworkable. Computing ability aside, it emphasises work on content, not work on layout. Obviously, if you are making flyers every day, AsciiDoc is not for you. You could insert images (generating your word art through some ImageMagick kung-fu) and generate a PS file that you lpr off to your printer, but it would probably not be an optimal workflow. However, I do work on content. My programs are content. My stories are content. I am a content person, not a design person, so, for me, this is an excellent layout.

What is the Point of this?

I recently stumbled across some articles on WS-BPEL. BPEL stands for Business Process Execution Language. At first this caught my attention because, well, it sounded like some potentially slick DSL that would help describe business rules and execute them. Slapped in front of a good domain-specific API, something like this could help slash development time. Of course, such things are usually little more than pipe dreams, but today’s pipe dream is tomorrow’s brave new world. So, it is always better to keep an eye on things.

Perhaps the first tip off that this had nothing new to offer is that BSPEL is based on XML. Seriously, how can much good come from XML? Even the few times where the end result is cool (like WSDL and SOAP), a better interchange format could have been chosen. Imagine, for example, a YAML or JSON based web services platform? With wider support that would just rock. But I digress.

Here is a tutorial of sports on WS-BPEL. When you get past the buzz words and the fancy terminology, you have an XML based scripting language to tie basic web services together. Pretty disappointing. After looking at the examples, I do not see any way that this wins out over using Java, C#, or PHP. It is quite a stretch to refer to what this thing does as having anything to do with “business processes”. Even an IBM reference on the subject just shows a few simple control mechanisms joined up with the ability to call web services.

So, if you have seen this used in the wild to an efficacy above and beyond typical programming or scripting languages, please drop me a line or a comment—because this looks like buzzword tag soup.

What I Want in a WM

I have been looking at various Window Managers lately. The major desktop environments leave me feeling a little dissatisfied.

  • KDE – I loved the 3.5+ branch of KDE. However, the world is moving on and that may not be an option much longer. The 4.x branch has been unstable on my machine. It works all right and looks excellent, but my desktop sessions disappear every so often.
  • Gnome – Gnome treats me like an idiot. I don’t like patronizing software. It is too eager to offer me information I don’t want.

Both KDE and Gnome offer a wide variety of keyboard shortcuts, but there are many operations that can only really be done with the mouse. In both cases, I want every single window manager operation to be performable from the keyboard. Again, speaking of options, I don’t think it needs to be required, but there should be no less power at the keyboard than there is for the mouse.

A quick look at the alternate window managers of the Linux world show that a lot of other hacker types want the keyboard capabilities I want. In addition, the window managers are infinitely extensible. However, I have two major problems with every one of the window
managers I have looked at or tinkered with:

  • They are ugly. I don’t need Mac OS X beauty on the desktop, but I do not want something that looks like a ’93 desktop put through a blender. I have to look at the screen a lot of the day. It doesn’t have to be drop dead gorgeous, but it can’t look like pure trash either.
  • They drop their extensibility in my lap. I appreciate that every single detail can be tweaked, but not every detail should be tweaked. Some reasonable defaults are vital, especially when evaluating window managers. If I have to spend a few days reading their APIs and writing customization files in various scripting languages, why should I invest that much effort just to learn whether or not the window manager has the potential to be what I need it to be?

Especially hard for me to understand is the first one. I can understand that to the small communities of hackers working away on their window manager, the extensibility is exciting. Since they know every detail of the innards anyway, it doesn’t annoy them to have to
look at the API first.

But how can these themes be seen as anything other than astoundingly ugly? Browsing through a lot of the theme galleries just make my eyes hurt. They make Windows 95 look like the space age of computing. So, here is the window maker/desktop environment (I do not care to haggle about which it is) I want looks like this:

  • Keyboard it all. If I want to move, resize, retile, restack, etc. windows from the keyboard, I can.
  • Reasonable defaults. The full functionality is available withoutvhaving to fiddle with personal startup files. I can start it up and begin tweaking it from there.
  • Easy on the eyes. Antialiased windows, rounded off window borders, and tasteful window decorations are key. Again, Compiz/Vista like effects are not necessary. Just some good taste.
  • A respectable collection of widgets. Look at OpenBox or Fluxbox. They have many panels written for them. This is a good thing overall, but could we start by having at least one good panel included in the default distribution?

I am still on my quest. I suspect that if I work hard with Fluxbox or Awesome, I will be able to get what I want. Whether I have the time for this in the near future is, of course, another question entirely.