Installing Bigloo

Bigloo is a Scheme implementation with both Scheme->native and Scheme->JVM compilers, an interpreter, and a rich Scheme editing/debugging mode (called The Bee) that runs in Emacs 21. I'm trying it out because, as it states firsthand on its home page, it's "devoted to one goal: enabling Scheme based programming style where C(++) is usually required". My thoughts exactly. And they've added a Java bytecode compiler, so they seem to be devoted to practical Scheme development in general. I'll write more about it as I use it. This is just notes on the installation process for posterity, since there were a few quirks. Installing Bigloo on Max OS X 10.3 Installing it on OS X (Panther, 10.3) was easy - I followed the instructions in the INSTALL file that comes in the source distribution, using the "--bee=full" and "--benchmark=true" command-line options, and the various 'make' commands ran without problems. Detail: when running the various 'make' commands, as with most unix installation scripts you need to prefix the command with 'sudo', as in: 'sudo make' It will then prompt you for the admin password. You need to do this to grant the script temporary permission to update your /usr/local/... directories (unless you want to install it somewhere else). The install scripts do not update ~/.emacs for you to install The Bee. The Bigloo manual (a .pdf) contains the code to append to your .emacs file to install it. One detail: these instructions don't mention that you need to append the path of your Bigloo emacs directory to emacs' load-path variable. Make sure to include this statement in ~/.emacs: (setq load-path (cons "/usr/local/bin/emacs/site-lisp/bigloo/bee" load-path)) where the path specified is wherever bigloo installed 'bee-mode.el' on your installation drive. Emacs, OS X, and the PATH variable With the above installation you'll be able to run Bigloo fine if running Emacs from the command line, i.e. text-based, with no mouse support or out-of-the-box support for the Apple key. To run the GUI version (my preference), you need to give Emacs access to the PATH variable, so it can find the bigloo executables. in order to expose the PATH variable to Emacs on OS X, I use a script to launch Emacs as suggested in their FAQ: #!/bin/sh /Applications/development/Emacs.app/Contents/MacOS/Emacs "$@" (replace the bold portion of the path with the path to your Emacs application installation). So to run Emacs, you open a Terminal window and type 'emacs.gui' or whatever you've called the script. Once I ran Emacs using this script, Bigloo ran fine. Installing Bigloo on Windows I was able to install the Bigloo interpreter on Windows (2000 Professional) using the Windows installer, without any hassle, but this doesn't install the required .el files to run The Bee in Emacs. To install The Bee on Windows, download the source distribution, and copy the 'bmacs' directory to your installation drive somewhere. I put mine under ~/emacs/bigloo. (on Windows your home directory ~ is probably something like 'Documents and Settings/kfrog'). Then you need to update ~/.emacs to include this directory and its subdirectories: (setq load-path (cons "~/emacs/bigloo/bmacs" load-path)) (setq load-path (cons "~/emacs/bigloo/bmacs/bee" load-path)) (setq load-path (cons "~/emacs/bigloo/bmacs/bug" load-path)) (setq load-path (cons "~/emacs/bigloo/bmacs/cee" load-path)) (setq load-path (cons "~/emacs/bigloo/bmacs/dbg" load-path)) (setq load-path (cons "~/emacs/bigloo/bmacs/etc" load-path)) (setq load-path (cons "~/emacs/bigloo/bmacs/lee" load-path)) (setq load-path (cons "~/emacs/bigloo/bmacs/ude" load-path)) And that's it. I'm not sure why the OS X installation doesn't require that I include all these subdirectories in the load-path, but it seems to run fine with only the 'bee' directory specified. To run Bee Mode in Emacs, type 'M-x bee-mode' and hit return, where 'M-x' means Meta-x, which is either Apple-x on Mac or Alt-x on PC. Bigloo looks promising. Stay tuned.

Escaping the Darkroom: From Film To Digital And Back

Two years ago, I bought a Mamiya C330 and started shooting 6x6 black and white film. I loved using a TLR, I loved the images I was producing, and I particularly loved using the TLR for portrait work, because I found it put the model more at ease when I was always looking down and mumbling into the viewfinder, rather than staring at the model and making them nervous. The problem: I hated developing all that film. And I hated printing in a wet darkroom - it took too much time and money to produce each image, such that I couldn't afford to experiment much, and eventually it discouraged me to a standstill; film rolls piled up and remained on my todo list for weeks. Finally the thought of producing another photograph was so exhausting I stopped altogether. Then, last year, I bought a Nikon D70, and it was a different world - I produced more good photos with it in the first month than I had in the previous year with film, and started learning and exploring ideas at a healthy clip. After a while, though, I noticed that my digital shots didn't have the same tone separation as my film shots, particularly in the highlights, and particularly in portraits. The images just don't look beautiful in quite the same way. With film I was able to capture a sense of gentleness, and for whatever reason my tendency with digital was in the other direction - my harsher, starker digital shots looked better, so I naturally tended toward a harsher, starker style. But it's time to put my feet back on the ground, to try to recapture a lost photographic tranquility. I'm going back to film, this time with a Rolleicord, which is about the simplest, no-frills TLR ever invented. Problem is, I still refuse to process my own film or work in the darkroom. I love digital editing, because I can try so many things in a short period of time. I imagine professionals use a workflow such as the following to solve this very problem: shoot film, process and get a low-res scan of the whole roll at a lab, and look through the digital images for the goods, perhaps experimenting with them in Photoshop. If I find a keeper, I'll get a high-res drum scan of the frame and re-edit the high-res version. I can then order prints of the high-res file from a lab, such as Adorama's excellent online digital printing service. One viable and significantly less expensive variation on this workflow: rather than paying for the initial low-res scan of the roll, just pay for processing. Then view the processed negatives with a loupe on a lightboard as in the old days and proceed from there. For example, I could then do an initial scan of promising frames with my flatbed scanner, play around with them, and order drum scans of the keepers. Foregoing the initial scan would mean paying $5 to $10 per roll instead of $15 to $20 per roll. It will be an experiment, of course. Maybe digital wasn't the problem in the first place - maybe I'm just a harsh, stark grumpus with no sense of beauty anymore. We'll see. So up next: finding an affordable lab in NYC, for processing, processing + low-res scanning, high res drum scanning, and digital printing.

In Search Of The Perfect Scheme

Like most young men, one of my life's great quests has been finding the perfect implementation of the Scheme programming language. More specifically, I'm looking for a Scheme implementation perfectly suited to general-purpose, large-scale web development, such that I may use it for my own freelance consulting work. This problem has two parts: 1) defining "perfect" in the context of an imperfect world, and 2) finding a Scheme implementation matching that definition. Failing that, I'll have to create the solution myself, hopefully from something that already exists rather than from scratch. It may come down to that too, because defining "perfect" in this context is incredibly sticky, and equally involves computer science and politics.

Why Scheme

I've researched a few web development platforms and programming languages over the years - primarily Java/JSP/Struts/JSF, TCL, PHP with the Smarty template engine (excellent if you like PHP), and XSLT/Cocoon - and after much sandboxing and thinking I've settled on Scheme as my programming language of choice for all programming, and particularly for web programming. As far as Java goes, it's just too complicated and difficult to work with. TCL, while a pretty good language for web development, particularly when used within AOLServer as espoused by Philip Greenspun, is actually too complicated for my taste when trying to do anything but the most basic programming tasks - the dirty details of dealing with strings, evaluating code, and walking up and down the stack are too much for me to keep straight in my head. XSLT, and the Apache Cocoon framework are excellent, but in the end XSLT is rather complicated and not much fun, and the programming language of choice in Cocoon is Java. In light of all these options, Scheme is the most simple, well designed, and robust language I've come across yet, and it's easily applicable to just about any kind of programming. Scheme is also particularly well-suited to web development. As noted on schemers.org, XHTML looks remarkably like Scheme rewritten with verbose syntax. Compare this HTML snippet:

<html>
   <body>
       <h3 align="left">In Search of The Perfect Scheme</h3>
       <p align="left">
          Like most young men, one of my life's great quests has been
          finding the perfect implementation of the Scheme programming
          language.
       </p>
   </body>
</html>

with its Scheme equivalent:

(html
   (body
       (h3 'align "left"
           "In Search Of The Perfect Scheme"
       (p 'align "left"
           "Like most young men, one of my life's great quests has been
           finding the perfect implementation of the Scheme programming
           language."))))

First, I prefer the aesthetics of the Scheme version, and find it easier to read and maintain. More importantly though, in the Scheme version 'html', 'body', 'h3', and 'p' are functions with behavior, not static data tags, meaning that we can easily create our own custom tag functions that make decisions and produce custom html, and then we can insert these custom 'tags' wherever we like. This is no different than a custom JSP tag, but implementing a JSP tag is significantly more work than writing a Scheme function. It's important to maintain the JSP concept of separating layout from logic via a template system, but the same thing is possible in Scheme, and part of my investigation will be of available solutions along those lines in the Scheme world. LAML Speaking of which, I didn't come up with that HTML-as-Scheme-functions trick on my own. Though one could write those functions by hand, there exists a Scheme library called LAML that provides "mirror functions" like the ones above for XHTML. It's actually a much more powerful library than that - it will generate validating mirror functions from any XML schema's DTD, meaning that if you want to work with XML in Scheme, it will generate corresponding Scheme functions for all the XML elements defined in a given DTD. Those generated functions, when called, validate their provided attributes and child elements against the DTD and then produce their corresponding XML. So not only can you write HTML using their simpler Scheme counterparts, you can use Scheme functions to transform any XML. This provides a powerful alternative to XSLT, if only because Scheme is so much easier to use, understand and maintain. Why Not Scheme So it's clear that I like Scheme, and that I want to use it for web development. What's the problem? It's an imperfect world out there. The world loves C and Java, it loves PHP - these are names the world knows and understands. As a consequence, it showers them with market support, so if we're going to use Scheme we're probably going to have to ride piggyback somehow - out of reasons both practical and political. We can't scare away clients. Clients understand the words "Java" and "C". They know the word "Apache". They like these words and trust them. They probably don't know the word "Scheme", and if they do, they're probably wary. So we need to find a solution that works both technically and politically. This means that it must be a fairly lightweight solution, and that it must integrate well with any web development workflow, including taking pre-designed HTML and adding functionality to it. The use of Scheme must never prove a liability or the game's over. This is a difficult problem. So Many Schemes The nature of the Scheme community complicates the problem a bit - ironically, the most unified language ever designed has an incredibly fragmented presence on the web. There are numerous Scheme implementations, each of which either does not fully implement the Scheme standard (known as RnRS, where n is a version number, currently 5), or does implement the full standard but then provides numerous tempting language extensions (I believe there is one implementation that only implements R5RS - no more, no less - but offhand I don't remember which one). My strong instinct is against wedding my Scheme code to any particular implementation's language extensions, or if so then as little and as gently as possible. If we're to successfully use Scheme in a Java/C world, we need to tread lightly, and bring as little baggage to the table as possible. The more standard and portable our Scheme code, the more easily we can adapt to change. SLIB will help. SLIB is the standard Scheme library used throughout the Scheme community, and provides some standardization of things. So whatever Scheme implementation we use, SLIB must support it. Luckily, the SLIB site contains a list of implementations it supports, so that narrows things down a bit. In Search Of the Perfect Scheme And there we have my little quest - looking at the various Scheme implementations and frameworks available, and coming up with a viable approach to Scheme web development in the real world. Stay tuned.

Scheme Is Simple, Java's Complicated, Simple Is Better

Scheme is a programming language developed at MIT and taught most beautifully, along with the rudiments of computer science, in the classic textbook Structure and Interpretation of Computer Programs (or SICP), by Adelman, Sussman and Sussman. Scheme's beauty is its simplicity. There's almost nothing to the language itself - the programmer need only understand the fundamentals of computer science and how to type parentheses to use it effectively. Scheme seems to have been designed under the philosophy of choosing one's battles wisely: rather than solving problems by overloading the language, the Scheme designers just didn't complicate the language in the first place. It provides what an expressive and robust programming language needs to provide, and nothing more. Java, on the other hand, was developed out of C and C++. C++ is perhaps the most complicated programming language ever devised. I believe that Java's success owes a lot to the world's frustration with those languages; by comparison, Java was a breeze. The similarity of the syntax to C was largely responsible for Java's overnight acceptance in the average workplace. C/C++ developers all looked at a Java "Hello World" program, and it looked so much like the same program in C that they perceived the learning curve as nothing to worry about. This was a false impression, but it was enough to hook them in, and before long Java was everywhere. Java became the new C. As the new C, Java has a lot going for it - transparent memory management with garbage collection, RMI, a standard class library handling most of an application developer's basic needs, the JVM. It's important to note, though, that these are all just goodies that come with Java; they're not the Java language. The Java language is essentially C with object oriented support and exception handling added to it. It does not convey the same sense of a unified design as Scheme. It was, after all, designed by committee, and is in part the result of politics. Another way to look at the difference between Scheme and Java is to recognize that Scheme was designed to make the programmer's work easy and natural, while Java was actually designed to make the programmer's work hard. This is not meant sarcastically - making things harder for the developer, by putting as many walls and trip-wires in the developer's path as possible, has the benefit of protecting a large-scale project against programmers that don't know what they're doing. In short, it makes it harder to break anything, at the cost of productivity. Using Scheme on large projects requires developers that know what they're doing and that follow the conventions of the project, but it also requires far less work, and subsequently far less time and fewer developers to coordinate. It's also possible to put up the same barriers in a Scheme project as in a Java project, but only wherever you actually need them. Java's an obstacle course for the developer from start to finish. Managers love Java. I like Scheme. A significant difference between Scheme and Java/C/C++ is in the development workflow. While Scheme is often compiled into executables when released into the wild, during development it is interpreted or incrementally compiled on the fly in the editor as you code. When editing Scheme code using the Emacs editor, I can type a Scheme expression and evaluate it immediately with a keystroke. This lets me build up complex behavior incrementally from small pieces of code that I test along the way, so that when the final product is finished it's already well tested and ready for use. This approach is also particularly well-suited to explorational development, such as developing a new framework or algorithm. One can start with a small nucleus and build upon it bit by bit, rather than having to design it from top to toe before writing anything. Since the devil's always in the details, the design-first code-later approach, in my experience, has never proven as effective as incremental development, provided the language and workflow promote it. Java does not promote incremental development because as described above it intentionally makes development harder, and requires a compile/build/startup cycle every time you want to test a change. It's the polar opposite to the Scheme workflow. Scheme is simple, well-designed, and robust. Java is awkward and complicated, but it comes with all this great stuff. So the problem to solve - and a number of people are trying to solve it in a number of ways - is how to use all of Java's goodies, particularly the market support for the Java Virtual Machine and Java Servlets, without having to code in Java. But that's for another chapter.

Look At Jake's Great Big Blog

Hello. I'm Jake, and this is my great big blog. Not sure what I'm going to use this for, but I'm glad there's now some record of my existence, and I'm glad the three of you have seen it. You may go now. I suspect I'll usually post while procrastinating other things, since that's what I'm doing right now, so these posts may not be the most riveting in the world, but I have my moments. For example, I just retyped the word 'riveting' five times trying to figure out if it has one 't' or two. It looks right with one. Nonstop action here on Jake's Great Big Blog. Then again, I see that if you click 'Next blog', you can read a bunch of gibberish advertising laptop batteries, and a few clicks later is the Colon and Rectal Cancer Info Blog. Fine company I'm sure, but I'd much rather be next to something like a sorority house's blog, where they post pictures of their wet t-shirt contests and bake sale proceeds.