I agree with the sentiment of this article but the question that fascinates me is "when do you need a language feature instead of a library in order to accomplish X, Y, or Z?"

I have to disagree about the author's described purpose of programming languages. PLs exist to provide elegant expression to a curated subset of ways of expressing solutions to problems.

At the extremes, we call these paradigms. Functional languages, Object Oriented languages, Array languages, etc. But every language exists to make some subset of "shapes" of solutions easier to read and write. Elixir encourages you to describe your programs as a distributed system of programs each running a series of transformations to data, thanks to its pipeline system, and to push your branching to function-call level with its pattern-matching multiple dispatch.

Java encourages you to write your application as a collection of things, that know stuff and do stuff, including telling other things to do stuff based on things they know.

C and Go encourage you to write your programs as an ordered series of atomic tasks for the computer to complete.

SQL has you describe what you want your output to look like.

Etc, etc. There are inherent trade offs between languages, because what you make inelegant to express or even inexpressible carries value, too.

There are a few approaches if you want to write a new language. One, as the author argues, is to write a library in an existing language, which may require sacrificing ergonomics to fit inside the syntax of the host language, but is safe, modular and reusable.

Many DSLs can be bolted onto an existing language with support for compiler extensions. This approach offers more flexibility, but often leads to fragmentation and poor interoperability in the language ecosystem.

There is third approach, established by a group in Minnesota [1], which is to design languages and tools which are modular and extensible from the get-go, so that extensions are more interoperable. They do research on how to make this work using attribute grammars.

If the host language has a sufficiently expressive type system, you can often get away with writing a fluent API [2] or type safe embedded DSL. But designing languages and type systems with good support for meta-programming is also an active area of research. [3, 4]

If none of these options work, the last resort is to start from tabula rasa and write your own parser, compiler, and developer tools. This offers the most flexibility, but requires an enormous amount of engineering, and generally is not recommended in 2026.

[1]: https://melt.cs.umn.edu

[2]: https://arxiv.org/pdf/2211.01473

[3]: https://www.cs.tsukuba.ac.jp/~kam/papers/aplas2016.pdf

[4]: https://arxiv.org/pdf/2404.17065

The author makes a good point about language capabilities enabling certain libraries to be written, just as DSL makes it easier to reason about problems and implement solutions with the right kind of abstractions and language ergonomics (usually at the expense of expressivity and flexibility).

There’s a time in my life where I designed languages and wrote compilers. One type of language I’ve always thought about that could be made more approachable to non technical users is an outline-liked language with English like syntaxes and being a DSL, the shape of the outline would be very much fixed and on a guardrail, and can’t express arbitrary instructions like normal programming languages, but an escape hatch (to more expressive language) for advanced users can be provided. An area where this DSL can be used would be common portal admin app generation and workflow automation.

That said, with the advent of AI assistants, I’m not sure if there is still room for my DSL idea.

As a student of philosophy of language, I obviously agree with the author (against the quoted thesis).

The structure of a language matters to the ease and feel of its use, despite even being logically identical. One parallel would be the syntactic benefits of something like Hintikka’s independence-friendly logic vs first order logic, even if they are equivalent.

The sentiment shared is that we should sacrifice benefits to the next generation to make our own lives easier. This is a common sentiment, but a sad one. The goal should be a natural language based programming language, that everyone can use, along side a technical programming language that makes unambiguous the interface between the language and the machine.

Everyone seems to endorse their happy medium, and those languages are also perfectly fine.

> Can we design a language so expressive that library writers can easily write the most appropriate object system, or most appropriate type system, to fit their application?

Why yes, it can and has been done: https://www.dreamsongs.com/Files/ECOOP.pdf

The OP's point is well-taken: a new language usually forces you to change 100% of your environment and tooling, whereas a new library respects your habits and preferences.

I follow new language developments with keen interest, but few of them will ever reach the level of maturity to be considered serious candidates for adoption. It's also risky to adopt a language that you cannot easily hire developers for, for example.

Libraries are great, but there is only so much they can address, and that depends on the language, too, as the article correctly points out. And there are two kinds of libries: tool libraries and frameworks. Someone once said it nicely: "Frameworks are like Hollywood - 'You don't call us, we call you!'". Frameworks often require you to submit to their control flow rather the other way round; that's why I prefer tool libraries.

With a Domain Specific Language (DSL), you parse code and build an abstract syntax tree. But you can also build a Python library where you construct the same tree. With the benefit that LLMs are already better trained on Python code. If you need a deterministic programming language, you could use starlark.

Logic systems are a good place where the library first approach tends to work well: you keep a small, boring core (the inference engine), and let people extend it with predicates, rules/operators, and domain packages.

I’ve been experimenting with a small defeasible-logic core (argumentation semantics + priorities + conflict detection) that stays stable, while most of the real meaning lives in extension points. https://github.com/canto-lang/canto-lang