But why would you do that?
Anybody that can do this things can probably take on any programming job, because they require a fundamental understanding of how computers and programs work.
Furthermore, It also help when suggesting realistic features to other language developers, or write proposals, or assess languages themselves.
Programming languages are not a solved problem (or parsing, or diagnostics, or...).
We are today, barely, getting practical solutions to how write safely, fast and ergonomic (for example, rust) and yet:
- Compiling performance is abysmal in most compiled langs (except pascal family)
- And errors...
- And debugging...
- And interactive compilers...
- And ... (thousands of other stuff)
Somebody must try to do this stuff, because if not, forever will be at mercy of C, C++, JS, the shell, unix, etc. Who wanna the cobol effect forever?
He also wrote “a plea for lean software”:
> “Abstract: Software's girth has surpassed its functionality, largely because hardware advances make this possible. The way to streamline software lies in disciplined methodologies and a return to the essentials. The paper discusses some causes of "fat software" and considers the Oberon system whose primary goal was to show that software can be developed with a fraction of the memory capacity and processor power usually required, without sacrificing flexibility, functionality, or user convenience.”
One recent article that touch it (for rust):
We’ve reached the ends of fast CPUs. To gain performance improvements, we need to use multiple cores, and process it in parallel.
I wonder if this is an opportunity for github or Microsoft to host a cloud compiler? Just check in your code to github, and the cloud compiler will compile it across thousands of servers, all running in parallel.
Cost: $100/month per engineer.
That could be a symptom but is not the root cause.Is just that the syntax/features choices (as choiced!) are hostile to fast performance.
Even going parallel, I bet a pascal compiler will beat it overly, because you can give rockets to turtles but are still turtles...
OTOH what makes a language usable is literally everything else - package manager, IDE support, compile/parsing.
Among other things, sure.
> OTOH what makes a language usable is literally everything else - package manager, IDE support, compile/parsing.
You have parsing/compiling in both categories. It's easier than ever to add IDE support for your homemade language, too, because of things like the LSP. Package management isn’t easy, but if you are building a specialized DSL and bundling the parts key to the domain, or if you are exposing a bridge to an existing ecosystem with strong library availability and decent package management, a language-specific package manager is probably not super important for usability.
But that could be because we haven't had any real innovation in languages for ages, so except for some superficialities and details, the languages are essentially the same.