In my career there are two types of software projects. Ones that start off using a powerful language and libraries, and those that don’t because “this is just a prototype/small project”. 9 times out of 10 the second type naturally evolves into something more complex and requirements become harder to solve with some “least powerful” language. Inevitably a costly migration is made to a more powerful toolset, be that react, Spring, or whatever.
I think it’s a bit different in infrastructure where the core of what you want is a declarative set of requirements and properties. But in SWE you’re a fool to start your project with the least powerful tools.
I think it does make sense if you consider it in terms of actual language power (a la Automata Theory) as opposed to just varying kinds of Turing-complete languages as it seems you're framing it.
If what you need is a configuration language, please don't express it in Python. If what you need is a regular expression matcher, please don't express it in a bespoke recursive-descent parser written in the enclosing language. If what you need is a SELECT over a large dataset, don't download all rows from the DB and then iterate/filter them on the local host.
I think there are many reasons for this, not just for human readability -- also for performance and security. Berners-Lee is quoted in that wiki article as saying it helps semantic extraction, too, but I personally consider that less convincing.
> If what you need is a configuration language, please don't express it in Python
Oh god please express it in Python more so than anything else. The configuration language file -> templating the configuration language file -> scripting the templates to the configuration language file pipeline has to die.
If you're going to use the simplest thing possible make it easy to throw away when the nerds get more complex instead of having to build the complexity on top. Regex is a great example -- if used internally when you need something more you just throw it away. But if you make a single static regex part of your configuration your users are stuck with it.
> make it easy to throw away when the nerds get more complex
Ironic but true. How often is it actually the needs getting more complex, and how often is it the nerds wanting to make it more complex so they can try out some new tech?
It sounds like we just need more thoughtful configuration file design. None of the tools on my computer, save systemd (which is its own whole mess), are as you describe: most of them are using data formats, and only a few are using shell, Tcl or Python scripts.
I'd say Spring and React are less powerful than just plain Java/Javascript, in fact having any framework usually reduces the "power".
I believe "power" in this context describes the amount of freedom the language allows. The less powerful the system is, the better you can reason about it and the more external tooling you can add around it without breaking corner cases. A webpage is less powerful than a .exe running on your system, but that is what makes it so useful - you can run it at 144 fps, use it with a screenreader, custom CSS, high DPI (even if the webpage was written in the 90s), etc. and all of this relies on the lack of power of the webpage.
html or css is less total power in exchange for being better at some specific things.
If html can reasonably do X then it's probably better at doing X than doing it js. If that rule of thumb isn't true then there's no point for js to exist at all, it would mean js is strictly better in all scenarios.
Funny, until I read this it didn't occur to me that this rule smacks of premature optimization. Odd though that often in optimizing an application after it's written we don't often consider something as high level as switching a tabbed interface to pure HTML/CSS from a JS framework plugin. I would guess this is due to cost, but I've never heard anyone articulate it this way...
If you're using Deno and run into the limitations of the JavaScript language/ecosystem, you use its FFI to call out to libraries written in languages like C and C++.
Similarly you might address a performance issue in your C code by writing assembly code, which is the most powerful language essentially by definition, and which of course has plenty of downsides.
In my career there are two types of software projects. Ones that start off using a powerful language and libraries, and those that don’t because “this is just a prototype/small project”. 9 times out of 10 the second type naturally evolves into something more complex and requirements become harder to solve with some “least powerful” language. Inevitably a costly migration is made to a more powerful toolset, be that react, Spring, or whatever.
I think it’s a bit different in infrastructure where the core of what you want is a declarative set of requirements and properties. But in SWE you’re a fool to start your project with the least powerful tools.