A little about little languages
I work on a GCC-based compiler toolchain for my day job. Here is a partial list of the programming languages I have to know–some of them quite well–in order to do it effectively.
On top of this I occasionally have to use Perl, PHP, Java and C#, but not that often. It also helps to know some Javascript and SQL.
Within Binutils and GCC there are various other specific languages you need to know, some of them being rather cryptic.
- Option specifications
- Multilib specifications
- Spec files
- Linker scripts
- Register Transfer Language
- Assembly for the target architectures
- The ISA for the target architectures
And if you're using a programmable or extensible editor, there is the language used there. Maybe an IDE of some kind on top of that.
Then, of course, there are the runtimes for the languages themselves and how they interact with the execution environments. In many cases you have to know many of the libraries and APIs that allow these programs to communicate, the number of which can be considerable.
These are just the programming languages. Once we get into the technologies, products and ways of interacting with or configuring them, there is considerably more.
- Test frameworks
- XML (and to some extent, XSLT)
- Configuration languages (e.g., YAML)
- Ant, Ivy, Gradle and other build system related things
- Markup languages for PRs, wikis, and bug trackers (usually similar, but not always the same)
- Git and possibly other VCSes
- The bug tracking system
- Office 365, with Teams
- Some web browser (probably with extensions)
- The CI/CD system(s)
- Docker (maybe some Kubernetes)
- Static analysis tools
- The operating systems things run on (Linux, Windows, macOS)
- Devices being targeted by the compiler, if applicable (to be able to write startup code)
I thought about all these things when reading about little languages being the future of programming. I especially thought about it because I used to think that little languages were the way of the future. It was even an inspiration for my thesis.
I no longer think that.
Over the years that I have been working as a software developer I have implemented some little languages, mostly in an effort to simplify some process. In those cases it would technically work, but it rarely caught on. The reason was always that there is already so much to know that adding another technology to learn was not a popular decision, especially if it was not a necessity or was not a significant advantage over what was already there.
Often a little language can be implemented as a library or an extension, albeit less elegantly. If it's done this way you crucially get the debugging capabilities of the language you are working in.
And most of the time it's good enough.