3 ms·
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
by ModernMech 4y ago
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.
Question: does anyone know of resources that discuss the rest of programming language design?
- designing a standard library
- building tooling like debuggers and package managers
- interfacing with other languages
- managing and growing a community
- evolving the language over time as it grows
- integrating with IDEs and building language server support
- how to communicate the language to others so they understand the value proposition.
- 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.
- 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?
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.
- lioeters 4y agoWhat comes to mind are the publications of the HOPL (History of Programming Languages) conference. https://dl.acm.org/topic/conference-collections/hopl?sortBy=downloaded https://dl.acm.org/topic/conference-collections/hopl?sortBy=... Sorted by most downloaded, the first page of results includes the history of Erlang, Haskell, C, C++, Smalltalk, Fortran, AppleScript, Lisp, Pascal, Prolog.. Many of the papers are written by the people who designed, developed, and maintained the programming language, its ecosystem and community. What I find fascinating are their retrospective thoughts on what didn't work well, regrets of what turned out to be bad design decisions. The authors also often reflect on how far programming in general has evolved, what aspects and features have become expected, like package manager, etc.
- cpurdy 4y agoExactly. In any substantial language, the "lexer" and "parser" represent less than 1% of the work of implementing the language. In the Ecstasy (xtclang) project, writing the lexer and parser (and then bootstrapping them both in the Ecstasy language) took less than 4 person weeks, out of 750+ (and counting) person weeks spent implementing the language.
- ModernMech 4y agoOut of curiosity, how did you spend the remaining 99% of your effort?
- cpurdy 4y agoMostly: * The compiler. * The type system. * The core library.