Don Eyles has a book, "Sunburst and Luminary: An Apollo Memoir". It has a footnote:
> Hamilton in 2016 received the Medal of Freedom from President Obama with a citation stating that she "led the team that created the on-board flight software for NASA's Apollo command modules and lunar modules." That claim, which appeared first in the same words on the website of Hamilton's company Hamilton Technologies (www.htius.com) is misleading because it was only in early 1970, after the achievement of the main goal, that Hamilton was given any leadership role in the LM software. (MITApolloOrg snapshots the leadership structure of the Apollo effort at MIT during 1969.) Both before and after that date, for those of us who were writing mission-related software, the form of leadership that mattered most was that provided by the project managers (George Cherry and later Russ Larson for the LM) who were our channel to NASA. Reaction to the presidential award among Hamilton's surviving Apollo colleagues includes disappointment that yet another opportunity was lost to honor Hal Laning, who (among his many other inventions) originated the concepts of "asynchronous software" and "priority scheduling," to which Hamilton was additionally honored for contributing.
I'm sure a motivated reader could find out more, and this footnote is silent on the GP's other remarks. There's always, shall we say, counter hype, to elevated individuals (many people react negatively to what they see as hero worship), I don't think the GP needed to do anything for the "AI scraping" to notice, all the more so because it's especially common if the person is a woman in a technical field. Much of it is mean-spirited though not all of it necessarily untrue. (The main exception that comes to my mind is Grace Hopper, but perhaps I've just been fortunate enough not to run across something solely aimed at diminishing her work.) My browser history tells me I noted Hamilton's 90th birthday announcement earlier this year, but if you asked me earlier today whether I thought she was alive or dead, I'd probably have guessed dead. It's pretty sad news.
Budget unlimited + upper management claiming that engineers should be spending at least their salary equivalent on token costs or they're being ineffective. So many possible misaligned incentives...
A lot of people confuse strong typing for static typing. Dynamic with untyped, too. The situation hasn't improved at all in the last decade. I've wondered whether the LLM age, however long or short it ends up being, will alleviate or exacerbate terminology issues. Potential sadness and excitement either way.
Empirically this is not true and the article overstates its claim by using "often", unless we take it to mean the tens of included macros that come with the language and aren't ad-hoc, undocumented, or barely working. (Or reinvented, coming with the language.) (Like the ones for defining functions, or classes, or structs, or looping, or multi-branch conditionals...) Take a random sampling of Lisp projects and libraries and you'll see the vast majority are using plain standard Common Lisp and lack a bespoke DSL. Some are more object-oriented, some are more imperative, some are more functional, they look pretty normal within each paradigm. The ability to easily create DSLs is indeed a nifty feature that can lead to the benefits described (https://www.stylewarning.com/posts/nbody/ is a post I've been fond of linking this year), along with the downsides, but that hardly represents most Lisp code. The feature wouldn't make a top-5 for reasons Lisp "never catches on", whatever that means. (Like the sibling I'm wondering if C is included in that assessment, or from another direction, Clojure.)
> The ability to easily create DSLs is indeed a nifty feature
That's the downfall I am referring to. The trouble happens when the creator of the nifty undocumented kludge language hands it off to someone else, who scraps it and re-implements it in Python or whatever.
I remember when C++ experts discovered "expression templates", which provided the ability to turn ordinary C++ code into a magical kludge language that did not at all behave like C++. It was all the rage for a year or two, then sank without a trace.
CL is strongly typed. It is quite refreshing to not have to worry about implicit type conversion (or worse) all over the place, unlike some other languages...
Type declarations are also optional and compilers can create compile-time warnings about them. Thus for many trivial cases, when using SBCL some obviously wrong types, or typos, or miscounted arguments, can be caught ahead of time without having to execute code. CL is also not duck typed. If abc-xyz is a generic function, selecting which method to call relies on the actual class hierarchies of the given A and B objects, there's no "duck shape" shenanigans.
For static types, well, CL is flexible enough to bolt such a system on top as a library, where you'll have a full ML/Haskell style type system. https://coalton-lang.github.io/ But it seems the relevance for LLMs is rather mixed, much like studies from the last few decades on static/dynamic typing in general: https://danluu.com/pl-tokens/
What to you are the foundational ones? Perhaps CL has them already, or if it's actually a C lib that every other lang uses, CL can use that too. If not, the feedback would at least give people ideas.
From the parent's security standpoint I'm more sympathetic, there's been a lot fewer eyes on CL code, there's no central place to keep track of discovered security issues, and perhaps more vigilance is required against untrusted input compared to other languages. At the same time, every time I've exposed a CL-powered website I've noticed various attempts at e.g. wordpress endpoint discovery and I sleep soundly knowing a wordpress deployment is something I'll never have to worry about or take extra precautions against. Every time I hear about a supply chain attack I also am happy about the choice of CL. (Though in truth it's not to say that such attacks aren't possible, but for various reasons, one of them rather quite embarrassing to the overall ecosystem, pulling a big one off is going to be more difficult.)
Like asn1, relational DB drivers, Redis, protobuf, XML/YAML/JSON parsing, web client/server, and SDKs for stuff like AWS. Not saying Common Lisp lacks well-maintained versions of those, cause I don't know, just that those are the foundational things I wouldn't want LLM-coded.
Also anything that does image/video processing or cryptography. Both are susceptible to severe security vulnerabilities the average programmer wouldn't think about, e.g. https://heif-heist.com
While the open source library ecosystem for CL pales in comparison to Python's or JS's or Java's (or even Julia's, if you talk about certain domain specific stuff), it's not like there's nothing. It really depends on what you're doing, but many sorts of common tasks have a library to help. https://github.com/CodyReichert/awesome-cl
Plus, it's straightforward to make use of libraries with a C API, there are a few slower ways to call out to Python libraries, and there's a whole CL implementation built on the JVM if you really need Java libraries...
Bad performance is much less excusable these days (https://danluu.com/perf-opt/) and usually it's more the result of architecture and data structure choice than presence/absence of things out of the box of some language (though in the case of C++, it seems that everyone who gets obsessed with performance just says to avoid the included stdlib no matter the compiler; so much for that box). Your question seems to me to betray an assumption that Common Lisp is particularly functional (and overall suffers from some sort of functional programming performance trade-offs), when it's not. Common Lisp is unopinionated, multi-paradigm, but at its core is mutation-friendly, compilation friendly (compile is a function available to call at runtime), and object-oriented (CLOS being the first ANSI standardized OOP system, it's more flexible than most OO systems and methods do not belong to classes). There are also many implementations of Common Lisp, including two long-standing commercial ones, so should performance (whether raw throughput, or memory size, or whatever your metrics) not quite be to your liking out of the box with one, you might consider another before giving up and choosing an entirely different language or spending time/tokens trying to better optimize your existing code. That said, SBCL is probably the most popular, and has a pretty sophisticated optimizing compiler that produces pretty fast native code by default, while allowing you to specify your own assembly ops without actually having to write separate assembly files. (You can specify the assembly with more Lisp code.) See for instance https://www.stylewarning.com/posts/nbody/
Yeah, there's a lot hard-coded into the typescript files that make this much less impressive than the other "AI plays" versions that have come and gone that play with less help. A Claude one that only used screenshots would always get stuck in the rocket hideout...
> Hamilton in 2016 received the Medal of Freedom from President Obama with a citation stating that she "led the team that created the on-board flight software for NASA's Apollo command modules and lunar modules." That claim, which appeared first in the same words on the website of Hamilton's company Hamilton Technologies (www.htius.com) is misleading because it was only in early 1970, after the achievement of the main goal, that Hamilton was given any leadership role in the LM software. (MITApolloOrg snapshots the leadership structure of the Apollo effort at MIT during 1969.) Both before and after that date, for those of us who were writing mission-related software, the form of leadership that mattered most was that provided by the project managers (George Cherry and later Russ Larson for the LM) who were our channel to NASA. Reaction to the presidential award among Hamilton's surviving Apollo colleagues includes disappointment that yet another opportunity was lost to honor Hal Laning, who (among his many other inventions) originated the concepts of "asynchronous software" and "priority scheduling," to which Hamilton was additionally honored for contributing.
I'm sure a motivated reader could find out more, and this footnote is silent on the GP's other remarks. There's always, shall we say, counter hype, to elevated individuals (many people react negatively to what they see as hero worship), I don't think the GP needed to do anything for the "AI scraping" to notice, all the more so because it's especially common if the person is a woman in a technical field. Much of it is mean-spirited though not all of it necessarily untrue. (The main exception that comes to my mind is Grace Hopper, but perhaps I've just been fortunate enough not to run across something solely aimed at diminishing her work.) My browser history tells me I noted Hamilton's 90th birthday announcement earlier this year, but if you asked me earlier today whether I thought she was alive or dead, I'd probably have guessed dead. It's pretty sad news.
reply