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