Tuesday, August 12, 2008

AWK based AFT redux?...

I've been maintaining the current incarnations of AFT in Perl for over 10 years now. I haven't updated the code base in almost 2 years now. I can't brag that is is bug free, but it certainly is stable (at least in some interpretation of that word).

Every few months I get a question (or two) from new users of AFT. I have no idea how many people are using AFT, but it is part of the Debian and FreeBSD software archives so it is very easy to download and install on those systems.

This search indicates that there are at least folks out there using a mostly unchanged AFT to publish documents to the Web. (They haven't bothered to remove the default advertisement).

I'm pretty much completely out of touch with Perl these days, so I am not very motivated to improve or extend the current AFT. The codebase has grown complicated and I wince at some of my awkward Perl techniques.

However, I do have a very decent corpus of AFT documents. I still use AFT to do general purpose documentation and then there is the previous mentioned cache of AFT documents that can be found through Google.

If I were to analyze this corpus, would I find a simpler subset of AFT that would do for most uses? And, if I identified that subset, is it time for a rewrite?

Frankly, I would probably do such a rewrite in AWK (or GAWK). I'd keep it simple and maybe make it a little more modular (shell pipes?). I would probably drop the Windows support (although it would still run under cygwin).

Regarding modularity, I'd probably develop it to run in two phases:
  1. A single AWK script to produce
    • An intermediate markup for Phase 2.
    • Or vanilla HTML for quick view or incorporation into a larger HTML/CSS framework.
  2. A translation from intermediate markup to HTML, LaTeX, etc.
    • Similar to what I have now with the current AFT.
I definitely want to reduce the number of files needed to run AFT. For a minimal run, you would just need AFT.awk and an AWK interpreter. You could then bind/embed the invocation into your favorite editor (no locating support files or setting environment variables).

That would be sweet :-)

Interview wiith Alfred Aho on AWK

Here is a good interview with Aho on creating AWK.

Wednesday, August 06, 2008

High Level Languages for Prototyping

I want a high level language to try out ideas. Often the ideas I am interested in draws on things such as concurrency, symbolic computing, pattern matching, etc. I don't need a production capable language. This is just for fiddling around with -- a prototyping language if you will.

Tcl and Awk were my prototyping languages of choice for the past 10-15 years. Before that it was Forth and a little bit of Lisp.

However, I have found that I have five criteria for such a language now. The first three are firm, the last two are desired qualities:
  1. Supports concurrency (lots of little processes/tasks) seamlessly.
  2. Seamless support for Bignums. I don't want to think about silly limitations of native word sizes.
  3. No fencing in (multi-paradigm support is a must!)
  4. Interactive. I don't want to do a edit/compile/run cycle for simple things.
  5. Portable. I want to install it everywhere.
Erlang comes to mind, but it fails for #3.

Logo is nice, but has too many incompatible variants. StarLogo meets #1, but it looks too busy (especially StarLogo TNG).

Item 2 sounds a bit ridiculous, but for languages that aren't bound by performance needs, I don't see why I should be trapped in 32/64 bits. I'll never forget the time, back in 1984, when I typed (fact 120) in Lisp.... oooh.

I've been meaning to learn Mozart/Oz ever since I read CTM a few years back. It's a wonderful book. Maybe if I concentrate *real* hard and drop my other CFT projects, I could pick it up again. :-)