It's not about technology for its own sake. It's about being able to implement your ideas.
You don't know minimalism until you've explored the history of the Forth programming language.
During Forth's heyday, it was unremarkable for a full development environment--the entire language with extensions, assembler, and integrated editor--to be less than 16K of object code. That's not 16K of data loaded by another program, but a full, standalone, 16K system capable of meta-compiling its own source code to create a new standalone system.
With work, and depending on how much you wanted to throw out, you could get that 16K number much lower. 8K was reasonable. 1K for an ultralight system with none of the blanks filled in. Half that if you were an extremist that didn't mind bending the definition of Forth into unrecognizable shapes.
Some Forths booted directly from a floppy disk and took over the machine. No operating system necessary. Or perhaps more correctly, Forth was the operating system.
In the early 1990s, Forth creator Chuck Moore had an epiphany and decided that interactively hex-editing 32-bit x86 machine code was the way to go. (After writing an entire chip layout package this way he realized there were some drawbacks to the scheme and reverted to designing languages that used source code.)
Looking back, there are many questions. Was there ever a time when reducing a development environment from 16K to 8K actually mattered? Why did the Forth community expend so much effort gazing inward, constantly rethinking and rewriting the language instead of building applications that incidentally happened to be written in Forth? Why was there such emphasis on machine-level efficiency instead of developer productivity?
In 2012 it all seems like so much madness, considering that I could write a Forth interpreter in Lua that when running on an iPhone from a couple generations back would be 10,000 times faster than the most finely crafted commercial Forth of 30 years ago. I'm not even considering the tremendous hardware in any consumer-level desktop.
Still, there's something to the minimalism that drove that madness. The mental burden involved in working with a 50K file of Python code is substantially higher than one of 10K. It doesn't matter that these modest numbers are dwarfed by the multi-megabyte system needed to execute that code. Those hundreds of extra lines of Python mean there's more that can go wrong, more that you don't understand, more time sitting in front of a computer fixing and puzzling when you should be out hiking or playing guitar.
Usually--almost always--there's a much simpler solution waiting to be discovered, one that doesn't involve all the architectural noise, convolutions of the straightforward, and misguided emphasis on hooks and options for all kinds of tangents which might be useful someday. Discovering that solution may not be easy, but it is time well spent.
That's what I learned from Forth.
(If you liked this, you might enjoy Deriving Forth.)
permalink September 18, 2012
I'm James Hague, a recovering programmer who has been designing video games since the 1980s. Programming Without Being Obsessed With Programming and Organizational Skills Beat Algorithmic Wizardry are good starting points. For the older stuff, try the 2012 Retrospective.
Where are the comments?