Re: [dev] lisp

From: Craig Brozefsky <>
Date: Tue, 02 Jul 2013 14:32:37 -0500

Alexander Sedov <> writes:

> May I get links to your hard works or at least to your papers, or all
> you have is some stuff you failed to sell to Yahoo, like that one guy?

Wait, I thought he DID sell it, and now farms Chocobos over at Hacker

I originally had links, but thought it gauche, but if you're gonna call
me out:


One is a resource scheduling/mgmt and inventory control system for
university media centers written from scatch in Common Lisp back in
~2000. The second is my current Clojure project, a large-scale malware
analysis engine with an expert system built on core.logic. The last is
a job I got because of being a lisp hacker, tho it was a Logo variant
implemented in Java -- my job application was a module embedding Kawa
Scheme, with scheme <-> Logo interop.

> You must be really proud about making new tools for solving new
> problems, except it's what programmers do, isn't it?

Not really, it seems to mostly be text plumbing, and incomplete
rediscovering of things that were invented in the 70s.

>>> And no libraries.
>> Trollolololol.
> If your "Trolololol" means "you just cannot google", then links
> please.

People already posted links for CL repos, I would add clojars for
Clojure stuff.

> If however it does mean "tr00 programmers don't need
> libraries", then I shall agree that Lisp is on par with Forth in that
> it allows you to rewrite stuff that had already been written in other,
> less ideal, languages, VERY elegantly. But some people need to write
> something new, too.

Never had a problem finding libraries to use, even back in the old days
of CMUCL. The ones we ended up writing where the a bit rarer back then,
functional SQL composition, ORMs, component based web frameworks,
simulated annealing, genetic algos. and java->lisp interop. Standard
stuff now, but not then. All the plumbing was already there. You know
what DID suck tho, signal handling in CMUCL!

Over the long haul I think in the CL world the plethora of
half-finished, raw, parts of libraries was the real problem. Dissipated
community effort, and NIH fragmented it.

I think we didn't have a good model for modularity in CL, so there was a
tendency towards heavy, "frameworks" instead of small, composable
libraries. I think Clojure gets this much better. I prefer textuality
instead of opaque composability. I like the approach Anselm laid out in
his presentation about the future of dwm and a shared set of functions
for drawing.

> Having reread my answer, I apologize if you find it unusually rude,
> but you are pronouncing the same empty words that I heard many times.

I took it as a fellow cumrudgeonly troll, which is a bit of a tradition

I always thought programmers needed to know two languages: One to talk
to machines, and one to talk to humans (including themselves). C for
machines, and a lisp for symbolic computation. I think that dichotomy
stands up well, even if the dividing line moves around and is largely
determined by the intent of the author and the context of deployment.

Craig Brozefsky <>
Premature reification is the root of all evil
Received on Tue Jul 02 2013 - 21:32:37 CEST

This archive was generated by hypermail 2.3.0 : Tue Jul 02 2013 - 21:36:05 CEST