I am always happy to see people make their own languages and write about it.<p>For this article in particular, I disagreed with the first two parts:<p>1. Premise: Simplifying assumption: There are two kinds of languages, static and dynamic. Somehow, it's just good to know this, and nothing is said of which of these the Duck language fall into.<p>2. Syntax: Wait, no.<p>There is an implicit premise here, being that if you make a language, it's probably going to be a general-purpose one with expectable control-flow structures, and because of that, what we care about is how those control-flow structures look, i.e. should there be curly braces around blocks and such.<p>A premise I would prefer is: When you make a language, you want to solve a problem. Imagine a language being an overgrown library. You don't start a tutorial in making libraries about how a good library interface looks like. You start by saying what problem you want to solve.<p>Another premise I would prefer is: Most problems are domain-specific, so most language-shaped solutions to problems are DSLs.
It's not in the bibliography at the bottom, so I thought I'd give a shout out to Crafting Interpreters, which is a very accessible tome on language design and development:<p><a href="https://craftinginterpreters.com/" rel="nofollow">https://craftinginterpreters.com/</a>
Yet another compiler how-to which pretends to be a design. There is no usage design as such, not a word on semantics, even the work "semantic" is not mentioned in the whole text.<p>The only design here might be the verbatim copy of a compiler architecture which is explained over and over. And some people might call architecture "design" and "programming language" a syntax compiler.<p></rant>
There are lots of resources out there about making a parser and interpreter and calling that a “language”. While those two components are necessary, alone they don’t seem sufficient in 2022 to call something a programming language; the scope of what a language is has expanded to include the ecosystem and community, which are often aspects cited these days for using or not using many languages.<p>Question: does anyone know of resources that discuss the <i>rest</i> of programming language design?<p>- designing a standard library<p>- building tooling like debuggers and package managers<p>- interfacing with other languages<p>- managing and growing a community<p>- evolving the language over time as it grows<p>- integrating with IDEs and building language server support<p>- how to communicate the language to others so they understand the value proposition.<p>- how to choose the right set of features to support. How to discern a good set from a bad set, how to make the language stand out and unique.<p>- also maybe issues of how to stay motivated and focused. It takes years to build a language, how does one stay committed to it over that time?<p>I understand why there might not be many resources that cover these angles, as not many language projects get past the parser stage, but I’m still curious what others have found.
After reading the title I thought that this would be an article about a programming language <i>named</i> I, in the style of B, C, D, J, K, et cetera. "Part I" would be much clearer.
I can open the `https` link above on firefox. Have to open:<p><a href="http://ducklang.org/designing-a-programming-language-i" rel="nofollow">http://ducklang.org/designing-a-programming-language-i</a>