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.
I was mistaken. I appreciated the correction. It was helpful. The language "This is mistaken" was correct, and I took no offense to either being mistaken or being called on it by MaxBarraclough. That was a helpful comment, and it's valuable when people call out mistakes.
There is such a principle. I didn't know about that framing. Now I do. Yay!
I don't even disagree with the principle. I disagree with the one-liner summary of the principle, as well as the longer summary in the blog post. The principle should be stated in terms of specific design disciplines:
* Declarative > imperative, when you don't need imperative
* Functional > structured, when you don't need mutations
Etc.
On the topic of conversations: I know this wasn't done here, but I don't even mind having my code, comments, or emails called stupid. They often are (yours are too -- aimed at whomever might be reading this -- everyone does stupid things and makes mistakes). I only mind if there's a personal subtext. Although that's not common, high-performing engineering cultures are able to discuss things people do with strong language, and having that not be judgmental of the people themselves. That's a difficult skill and culture to develop, but it's super-nice to be in one if you can get there. You can share things early (when there is a lot of stupid), learn a lot, get a lot of feedback, and give a lot of feedback.
Everyone does stupid things, and organizations work better when those are caught and corrected early, when it feeds into learning (and, as prerequisite, when it doesn't feed into ego or performance management).
Thanks. The intended tone of my comment was to be factual and direct, not to be derogatory. Pointing out a mistake is certainly not the equivalent of calling someone stupid.
I also agree that sometimes it's a mistake to use a language that may later turn out not to be powerful enough. Consider ugly build-system languages that were once fully declarative but had to evolve imperative features to cope with difficult cases. They would have been better off using something like Python from the start.
I will also admit to misreading the comment. I initially read it as calling the principle mistaken, but I think the word choice is perfectly fine now that I understand the target.
It's not simply about choosing less powerful things over more powerful ones. It's about exactly what I wrote. I'll paste the whole definition:
"In choosing computer languages, there are classes of program which range from the plainly descriptive (such as Dublin Core metadata, or the content of most databases, or HTML) though logical languages of limited power (such as access control lists, or conneg content negotiation) which include limited propositional logic, though declarative languages which verge on the Turing Complete (Postscript is, but PDF isn't, I am told) through those which are in fact Turing Complete though one is led not to use them that way (XSLT, SQL) to those which are unashamedly procedural (Java, C).
The choice of language is a common design choice. The low power end of the scale is typically simpler to design, implement and use, but the high power end of the scale has all the attraction of being an open-ended hook into which anything can be placed: a door to uses bounded only by the imagination of the programmer.
Computer Science in the 1960s to 80s spent a lot of effort making languages which were as powerful as possible. Nowadays we have to appreciate the reasons for picking not the most powerful solution but the least powerful. The reason for this is that the less powerful the language, the more you can do with the data stored in that language. If you write it in a simple declarative from, anyone can write a program to analyze it in many ways. The Semantic Web is an attempt, largely, to map large quantities of existing data onto a common language so that the data can be analyzed in ways never dreamed of by its creators. If, for example, a web page with weather data has RDF describing that data, a user can retrieve it as a table, perhaps average it, plot it, deduce things from it in combination with other information. At the other end of the scale is the weather information portrayed by the cunning Java applet. While this might allow a very cool user interface, it cannot be analyzed at all. The search engine finding the page will have no idea of what the data is or what it is about. This the only way to find out what a Java applet means is to set it running in front of a person.
I hope that is a good enough explanation of this principle. There are millions of examples of the choice. I chose HTML not to be a programming language because I wanted different programs to do different things with it: present it differently, extract tables of contents, index it, and so on."
The name of the principle is ill-chosen, since it's designed to be provocative rather than informative, and therefore can lead the reader astray. The central core is actually about: "The reason for this is that the less powerful the language" in the specific ways articulated "the more you can do with the data stored in that language."
This is mistaken. https://en.wikipedia.org/wiki/Rule_of_least_power