> when your script crashes because some careless typo in the middle of the file, then you will value a compiled language
How about the crashes for all the other more common reasons? It seems like a concern unrelated to whether a language is strictly AOT-compiled or not, and whether such compilation runs through a static type checker or not, and in any case surely differs a lot among programmers' experience. (Crashes from typos basically rarely if ever happened to me in Python, same with memory constraint crashes. But I've never tried running Python on anything with less than 1 GB/core, if you don't count possibly some educational usage on ancient 90s hardware or a 2004 laptop; the lowest power device was probably a Cubietruck3 from 2013 that still had a generous dual-core ARM cortex-a7 and 2 gigs.)
But I agree with the sentiment, I hate it when programs crash and take out their work in progress or other state. I wish more languages adopted the Common Lisp condition system model, where errors don't crash or unwind anything by default and you can dynamically fix things and retry, or resume, or restart from a specific stack frame. There's even a book about implementing it: https://www.amazon.com/dp/B0DF5YVJKJ (And despite being dynamically typed, Common Lisp is compiled to native machine code, and some implementations like SBCL offer some bare-bones static checks to flag trivial typo or type mismatch issues during compilation, before running the code in question... You can also bolt on a full static type system language on top as a library if you want.)
I just assumed that a jailbreak would be inevitable sooner or later, with full game ROM dumps including DLCs becoming available sooner or later as well, and that's good enough. I can enjoy the handful of games or upcoming games I care about on the system now, use the benefits of digital game codes over physical carts (I really don't miss having to actually swap a physical cart into the system or carry a bunch around with me if I want to play more than one game at a time; I've made one exception for Star Fox whose cart just lives in the system now), and in 10 years I'll be able to go back and play whatever even if my device is dead or the account somehow got locked out of its purchases.
It's sort of like how Nim was sometimes advertised as similar to Python but fast, even though the similarities were pretty surface level. And by having a low level alloc/free available and a principle of performance (it's the first section in their Guides) Crystal could pretend to be a mythical C or C++ replacement. I also remember likening it to Pony at some point, and/or Red, but when I went through a bunch of them years ago they all kind of blended together as just existing because of dissatisfaction (either with performance issues in Python and Ruby, or with various issues of C and C++) while not wanting to join an existing Rust/Go/whatever faction.
When I was in my early 20s I hadn't been to the dentist in a few years, couldn't see my old reliable one, but visiting family I was encouraged to make an appointment with a new one during the trip. He wanted to fix I think 13 cavities. And I regret that I let him... Afterwards for quite some time, I could no longer enjoy jerky or other things that needed more than usual chewing as it would cause pain, and I think a lot of the gaps between my teeth got tighter. Makes me a bit sad every time I see my xrays how much real tooth material is gone.
My main filter since then is what it should have been before, and that's basically whether a dentist mentions biomimetic dentistry on their site somewhere (clarity edit: a good sign). I had a new dentist for some years I liked but he moved offices even further away, I found a decent runner up locally who I've been mostly happy with for years. He's also happy to take a wait and see approach on some things.
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
How about the crashes for all the other more common reasons? It seems like a concern unrelated to whether a language is strictly AOT-compiled or not, and whether such compilation runs through a static type checker or not, and in any case surely differs a lot among programmers' experience. (Crashes from typos basically rarely if ever happened to me in Python, same with memory constraint crashes. But I've never tried running Python on anything with less than 1 GB/core, if you don't count possibly some educational usage on ancient 90s hardware or a 2004 laptop; the lowest power device was probably a Cubietruck3 from 2013 that still had a generous dual-core ARM cortex-a7 and 2 gigs.)
But I agree with the sentiment, I hate it when programs crash and take out their work in progress or other state. I wish more languages adopted the Common Lisp condition system model, where errors don't crash or unwind anything by default and you can dynamically fix things and retry, or resume, or restart from a specific stack frame. There's even a book about implementing it: https://www.amazon.com/dp/B0DF5YVJKJ (And despite being dynamically typed, Common Lisp is compiled to native machine code, and some implementations like SBCL offer some bare-bones static checks to flag trivial typo or type mismatch issues during compilation, before running the code in question... You can also bolt on a full static type system language on top as a library if you want.)
reply