Showing posts with label lisp. Show all posts
Showing posts with label lisp. Show all posts

Sunday, May 17, 2026

The Heart of the Process (2012)

Editor's Note: I found this in my drafts, dated 2012-01-25.  I have opted to retain the content unchanged, merely updating links for ubiquitous HTTPS and replacing broken links as needed.  Please enjoy this work of fiction.

The President saw that things took time to implement in code, and involved programmers, testers, and a deployment.  As someone who liked to make snap decisions and have the results available immediately, this did not sit well in his heart.  Long he meditated, then announced his solution:

Henceforth, the system would be Database-Driven.

Wednesday, November 16, 2011

Programming Languages to Learn

Many languages these days are fairly Lispy, except for being homoiconic and thus having a full-strength macro system instead of C's token pasting or many other languages' nothing.

But which ones are absolutely vital to learn, and which ones are "just different languages"?

Thursday, May 19, 2011

Accidental Lisp

It began with a simple bit of laziness: I wanted a preprocessor so that I could write as if PHP had multiple return values.  I'd write "return $x, $y;" in the callee, and "$a, $b = fn();" in the caller, and the preprocessor would rewrite it to valid PHP (throwing array() and list() around the appropriate expressions).

But I'm even too lazy for that.  To do this right, I'd need to fully parse the PHP, so I could understand more complicated return expressions like method calls.  So instead of that, I slapped together a lexer for s-expressions.  They're a lot less hairy, and this is just some twisted experiment.

I was halfway through putting together a parser this evening for the lexer output, when I realized: a few years ago, I ported the metacircular evaluator from the SICP lectures into Ruby... then discovered I would need to write an s-expression parser, which you get for free with Lisp.  (That project then died.)  But if I finish an s-expression parser... I can port the metacircular evaluator to it and have the world's stupidest Lisp-1 implementation, i.e. it'll be done in PHP.*

Alternatively, I can define a package in SBCL that emits PHP, and have the reader and macros for free.  Then my head exploded.


* Because this tool was intended for PHP shops, the compiler would have to be written in and emit PHP so there's no Scary Foreign Language involved, other than the compiler's input.  And originally, that input language was going to be almost PHP.

Sunday, August 15, 2010

Perfectly Flexible

Sometimes, a stakeholder doesn't like the idea of requiring a Programmer to make lengthy changes to a project's code if the requirements were to change at some future date. The proposed solution is always simple: The System just needs to be more flexible.

Having been the unsuspecting Programmer on a couple of these projects, I can report that the simple solution does not work.

Sunday, August 1, 2010

Functional vs. Object Oriented

By the time I reached my first programming job, I had learned a number of languages well enough to program in, and thought of myself as a pretty good programmer.  Then I met Brian, who frequently talked about Lisp, but had trouble articulating the advantages himself.  (This turns out to be a common problem.)  He introduced me to the SICP videos, and I found Slava Akhmechet's "The Nature of Lisp" essay on defmacro.org at about the same time.  Certain things about Perl and Javascript suddenly made sense, filling me with newfound wonder.

What I thought I knew about OOP as taught in college—Encapsulation, Polymorphism, and Inheritance—seemed like a sham.