Call for Interest: Clojure (or Lisp?) Code Camp with BLM focus

Martin Cracauer cracauer at cons.org
Thu Dec 3 21:26:01 UTC 2020


Svante Carl v. Erichsen wrote on Thu, Dec 03, 2020 at 12:16:09PM +0100: 
> Hi!
> 
> I vaguely remember having read that you do that.  I'm still wondering
> why, though.  I guess that you wrote about it, but I can't find it right
> now.
> 
> So, if it's not because Common Lisp is not seen as ???production ready???,
> why rewrite instead of just adding the production parts (I guess
> hardening, monitoring, logging, documentation etc.)?

There can be large amounts of infrastructure for specific production
environments.  QPX integration into Google was probably an extreme
case.

It was still done, because treating the Lisp version of QPX as a
"prototype" to then be translated into a different language would
effectively mean taking the macroexpansion of QPX and commit that as
source code.

That would mean extreme amounts of "assumption duplication",
assumptions that in the airline industry are badly documented and can
change.  You want to make that change in one place, not in the
macroexpansion where it's in 200 places.

That doesn't mean there wasn't a large push to avoid the effort to
come up with all the infrastructure integration for Common Lisp.
Ironically ITA people could fork those out pretty quickly because they
were using Lisp.

If you are not in the airline business but in an environment where you
don't have to make assumptions during programming that you might have
to change later you might be freer to use a language without
compile-time computing.  I've never seen good specs before I started
coding, though, not even in physics.  We know nothing.

Martin
-- 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <cracauer at cons.org>   http://www.cons.org/cracauer/



More information about the pro mailing list