LLMs have really revitalized interest in these areas. AI can really help navigate the initial learning curve, can do a surprising amount of "heavy lifting" and can make tedious but useful work much easier. Do you want your little language to have a language server and nice editor-specific syntax highlighting? Do you need to write a parser with decent error messages? Do you need to prove a bunch of largely straightforward lemmas to get to the proof you actually care about? All of these things are easier (and, hopefully, more fun) than they were a few years ago. But, at the same time, there is still a lot of room for human insight and design in this process. There are a lot of areas that AI can't handle (or, at least, can't handle well) and, of course, nothing stops you from doing the fun stuff by hand even if you could hand it off to Claude.

And, of course, all this PL stuff was fun before LLMs. It's even more fun now even if you don't want to use AI yourself, because more people are doing and talking about PL stuff online, and there are more tools and libraries you can use yourself.

As long as your core primitives are well designed (easier said than done!), this accomplishes two things: it makes your implementation simpler, and it helps guide and constrain your user-facing design. This latter aspect is a bit unintuitive (why would you want more constraints to work around?), but I've seen it lead to much better interface designs in multiple projects. By forcing yourself to express user-level affordances in terms of a small conceptual core, you end up with a user design that is more internally consistent and composable.

Both are indictment of today's ambient startup culture, and I'm not sure which is ultimately worse.

This is very much a "it's not the fall that kills you, it's the sudden stop at the end" sort of thing. (Same with the other variant I've heard, which is something like "no company has gone out of business because of tech debt".)

Code is as much a tool for developing and expressing conceptual models as it is for making computers do things. So not only does code quality have proximate impacts on engineering productivity and reliability, but, done well, it also improves the holistic design of the system you're building. You get better tools, faster, by putting some thought and care into your codebase and, especially, your core abstractions. Teams with good code move faster even in the short term and produce better tools and products.

Of course, it's not just a matter of code; you also need a culture that gives engineers the agency to make real, long-term decisions about what you're building (not just how) which, unfortunately, is rare to find in the modern tech industry :/ The dominant "high-output management" paradigm where code is seen as a virtually fungible "output" to be "delivered" loses the higher-order advantages of good code and good conceptual design, and leaves us with something much closer to the trade-off you describe. But there are other ways of approaching technical work that don't make this trade-off at all!

I also looked up the NSF's 2024 budget, which, at $9B, was much lower than I expected.

A problem with Semver is that a jump from 101.1.2 to 102.0.0 might be a trivial upgrade, and then the jump to 103.0.0 requires rewriting half your code. With two major version numbers, that would be 1.101.1.2 to 1.102.0.0 to 2.0.0.0. That makes the difference immediately clear, and lets library authors push a 1.103.0.0 release if they really need to.

In practice, with Semver, changes like this get reflected in the package name instead of the version number. (Like maybe you go from data-frames 101.1.2 to data-frames-2 1.0.0.) But there's no consistent convention for how this works, and it always felt awkward to me, especially if the intention is that everyone migrates to the new version of the API eventually.

In Haskell this comes up all over the place. It's somewhat nice for "basic" cases (`map (encode UTF8) lines` vs `map (\ line -> encode UTF8 line) lines`) and, especially, for more involved examples with operators: `encode <$> readEncoding env <*> readStdin` vs, well, I don't even know what...)

You could replace the latter uses with some alternative or special syntax that covered the most common cases, like replacing monads with an effect system that used direct syntax, but that would be a lot less flexible and extensible. Libraries would not be able to define their own higher-order operations that did not fit into the effect system without incurring a lot of syntactic overhead, which would make higher-order abstractions and embedded DSLs much harder to use. The only way I can think of for recovering a similar level of expressiveness would be to have a good macro system. That might actually be a better alternative, but it has its own costs and downsides!

You can write a function that takes a single throw-away argument (eg 0 vs \ () -> 0) and, while the two have some slight differences at runtime, they're so close in practice that you almost never write functions taking a () argument in Haskell. (Which is very different from OCaml!)

LLMs make it easier to cheat and give managers a push to develop new, AI-aware, assessment methods, but don't really change the underlying organizational dynamics that led to these tests in the first place.

In the sense that "make_string_comparator" is not a useful concept. Being able to make a "string comparator" is inherently a function of being able to compare strings, and carving out a bespoke concept for some variation of this universal idea adds complexity that is neither necessary nor particularly useful. At the extreme, that's how you end up with Enterprise-style OO codebases full of useless nouns like "FooAdapter" and "BarFactory".

The alternative is to have a consistent, systematic way to turn verbs into nouns. In English we have gerunds. I don't have to say "the sport where you ski" and "the activity where you write", I can just say "skiing" and "writing". In functional programming we have lambdas. On top of that, curried functions are just a sort of convenient contraction to make the common case smoother. And hey, maybe the contraction isn't worth the learning curve or usability edge-cases, but the function it's serving is still important!

> Because of point 3, our codebase has a trivial wrapper to put round functions when your function actually returns a function

That seems either completely self-inflicted, or a limitation of whatever language you're using. I've worked on a number of codebases in Haskell, OCaml and a couple of Lisps, and I have never seen or wanted anything remotely like this.

The goal is to have code that corresponds to a coherent conceptual model for whatever you are doing, and the resulting codebase should clearly reflect the design of the system. Once I started thinking about code in these terms, I realized that questions like "DRY vs YAGNI" were not meaningful.

Computer science as a discipline has always been relatively open and has had its own norms on publication that are different from most other fields (the top venues are almost always conferences rather than journals, and turn-around times on publications are relatively short), so it isn't a surprise that CS is one of the first areas to embrace open access.

Still, having a single example of how this approach works and how grass-roots efforts by CS researchers led to change in the community is useful to demonstrate that this idea is viable, and to motivate other research communities to follow suit.

[1]: https://authors.acm.org/open-access/acm-open-for-authors-hom...

[2]: https://creativecommons.org/licenses/by/4.0/

[3]: https://creativecommons.org/licenses/by-nc-nd/4.0/deed.en

Ideally—and at least somewhat in practice—a specification language is as much a tool for design as it is for correctness. Writing the specification lets you explore the design space of your problem quickly with feedback from the specification language itself, even before you get to implementing anything. A high-level spec lets you pin down which properties of the system actually matter, automatically finds an inconsistencies and forces you to resolve them explicitly. (This is especially important for using AI because an AI model will silently resolve inconsistencies in ways that don't always make sense but are also easy to miss!)

Then, when you do start implementing the system and inevitably find issues you missed, the specification language gives you a clear place to update your design to match your understanding. You get a concrete artifact that captures your understanding of the problem and the solution, and you can use that to keep the overall complexity of the system from getting beyond practical human comprehension.

A key insight is that formal specification absolutely does not have to be a totally up-front tool. If anything, it's a tool that makes iterating on the design of the system easier.

Traditionally, formal specification have been hard to use as design tools partly because of incidental complexity in the spec systems themselves, but mostly because of the overhead needed to not only implement the spec but also maintain a connection between the spec and the implementation. The tools that have been practical outside of specific niches are the ones that solve this connection problem. Type systems are a lightweight sort of formal verification, and the reason they took off more than other approaches is that typechecking automatically maintains the connection between the types and the rest of the code.

LLMs help smooth out the learning curve for using specification languages, and make it much easier to generate and check that implementations match the spec. There are still a lot of rough edges to work out but, to me, this absolutely seems to be the most promising direction for AI-supported system design and development in the future.