"…there's too many distros, there's too many languages, there's too much software. But there's no central authority telling people to make them."
You are right, there is no central authority telling people what to do and what software to write. And you are correct "you can't force people to not reinvent the wheel…".
What can be done however is to mandate specified software that's gone through rigorous testing in certain buisnesses, government, utilities, the military, critical engineering—aircraft, nuclear, and so on. There's already been a bit of this with Ada and the military but it's miniscule compared with what I am advocating.
Think of it this way: no matter what country one is in all electrical outlets are the same and comply with strict electrical standards for that country. That's not to say there is only one standard worldwide but there are far fewer than if it were a free-for-all as it is in the software industry.
You don't stop people from doing anything, reinventing the wheel or whatever—instead you make it unlawful to supply sofware to those vital entities that does not comply with those specified standards (as set by the ISO, etc.). Outside that realm programmers can do what they want but if they want to play with the big end of town then they'll have to play strictly by the rules.
We'll get to this stage eventually, but it's taking undue time.
As you've said, "Sooner or later things stabilize, when the new solution is not better enough to outweigh the old one…"* but the software industry as a whole is nowhere near that stage of development. Individual program may have reached that stage of development, but in a global sense the software industry is still decades behind the professional standards of other well-established professions (don't take my word for it, just consult the literature).
Right, that sounds authoritarian and something a dictatorship would do. But not so fast: those electrical standards to which I referred were only mandated by govermnents after the free-for-all chaos of the early electrical era where industry could not or would not adopt common standards.
.
The same applies for other disciplines, electrical engineering has any number of rigorous standards in addition to the example I've already given, same with civil, chemical engineering, transport, shipping etc., weights and measures, and almost all of them are tied to national and international standards. Moreover, a large subset is mandated by law for reasons of compatibility/interoperability (shipping containers, etc.) and or health and safety reasons, or for economic reasons, to minimize costs, to stop people being cheated etc.
These standards and concomitant laws and regulations are a fact of life worldwide and in many instances penalties apply for violating them. About the only exception is the software industry, it's no longer young and should have matured by now but it still operates like the Wild West were anything goes.
I say that as someone who has sat on standards committees and been involved in writing standards. Moreover, in my profession if I were to act in the undisciplined manner of much of the software industry, I'd be struck off.
Right, those are harsh words indeed—but they are only harsh for an industry that has never had to comply with rigorous rules and regulations that have been set by law. Whilst other disciplines have learned to accept them long ago the software industry still does what it damn-well wants, and it's done so with impunity from its outset. That has to change.
So you think I'm a self-opinionated crank. OK, let me bring you back to this HN story and think again. Software programmers and developers like to call their work software engineering and themselves software engineers but I'd suggest many in other engineering professions just laugh at the notion. If you don't hear them shouting it out loud it's because they're being polite.
What we in other engineering professions laugh about isn't the skill sets of programmers and developers, we accept there are many very skilled people who work in the industry. The real issue is the laissez faire free-for-all attitude of the industry—an undisciplined industry not bound by strict procedures and lawful regulations. Without regulations and clearly defined rules and procedures we end up with inconsistent results, bugs and lots of mess.
I'd suggested you read this story again then read the document in the link below, it was written nearly 31 years ago and covers the issues I've addressed, it's a SciAm article titled Software's Chronic Crisis. One of its key postulates is that software development doesn't have the disciplined lineage of say chemical engineering and that programmers are more akin to artists than engineers because they operate without industry standard strictures and procedures (such as those set by law).
What's so poignant about that article nowadays is that precious little has changed in the software industry in respect to those matters it refers to. Now ask yourself why is that so given that there has been much development in other areas of software development.
Little doubt the above commet is correct. Look at the way Niklaus Wirth's Pascal lacks widespread support amongst programmers whereas languages such as C are very popular because programmers don't feel constrained to the extent that Pascal constrains them, they feel hemmed in by it. Pascal essentially works like other professions—you must define what you want first up, (the concept, say a bridge) and then draw up the plans and revise them before anyone starts building it. After it's built few if any changes can be made. That's the cultural difference between software development and other engineering professions. It's a fundamental one.
The state of software is the state of the structures
of primitive societies: some in cave shelters, some
under roofs of sticks and leaves, some in mud huts.
We talk of Cathedral and Bazaar, but there are very
few carefully designed Cathedrals of software,
and those probably have plenty of barely hidden flaws.
The Bazaars are all around us, jammed together, spreading
for miles and miles, tent walls
and roofs billowing in the breeze, all awaiting a strong
zephyr to carry many of them away, and leave most of the rest in ruins.
What software needs is building blocks. Bricks of uniform size,
easily joined together. Concrete masonry units. Tilt-up walls.
Trans-oceanic shipping containers (connex, seabox).
Solid, composable, engineered, units. We should be able to
pull a well-known and heavily tested package or function to use,
just like a contractor would call for a delivery of 200 8x8x16"
CMU blocks, and be able to expect they will get just that,
with no gaps, weak spots, or broken webs.
But, no , all of us software crafts-folk want to carefully create
our very own artisanal version of whatever library functions,
that are needed for the project at hand. In a world that could be
made of solid concrete blocks, we are crafting our very own adobes,
with our own special blend of straw and mud, and we think we have advanced far beyond the folks living in mud huts.
Some of us will say they are master masons, crafting cathedrals out
of hand cut stones, each carefully measured and chiseled, and each
stone unique. We're still duplicating effort when we could be using
commercial off-shelf libraries. And all the while the project deadlines
go zipping past as we try to craft our way to local perfection.
All I can suggest as a solution is a multi-government and
multi-corporate effort to design and build fairly universal
functions, libraries, and packages that are robust,
exhaustively reviewed by humans,
and tested thoroughly. I won't ask for provable correctness, yet. :-)
Would the result be an Ada on steroids?
Depends on who is involved.
Choice of language should not matter.
The APIs would matter, a lot.
A few competing teams would be a possibility.
Passing several existing functions to an AI, with a
"do like these, only perfectly" might be useful, or useless.
And yes, then we would have 15 competing standards.
https://xkcd.com/927/
(Well, we probably already have at last 1,500, so, go figure.)
You are right, there is no central authority telling people what to do and what software to write. And you are correct "you can't force people to not reinvent the wheel…".
What can be done however is to mandate specified software that's gone through rigorous testing in certain buisnesses, government, utilities, the military, critical engineering—aircraft, nuclear, and so on. There's already been a bit of this with Ada and the military but it's miniscule compared with what I am advocating.
Think of it this way: no matter what country one is in all electrical outlets are the same and comply with strict electrical standards for that country. That's not to say there is only one standard worldwide but there are far fewer than if it were a free-for-all as it is in the software industry.
You don't stop people from doing anything, reinventing the wheel or whatever—instead you make it unlawful to supply sofware to those vital entities that does not comply with those specified standards (as set by the ISO, etc.). Outside that realm programmers can do what they want but if they want to play with the big end of town then they'll have to play strictly by the rules.
We'll get to this stage eventually, but it's taking undue time.
As you've said, "Sooner or later things stabilize, when the new solution is not better enough to outweigh the old one…"* but the software industry as a whole is nowhere near that stage of development. Individual program may have reached that stage of development, but in a global sense the software industry is still decades behind the professional standards of other well-established professions (don't take my word for it, just consult the literature).
Right, that sounds authoritarian and something a dictatorship would do. But not so fast: those electrical standards to which I referred were only mandated by govermnents after the free-for-all chaos of the early electrical era where industry could not or would not adopt common standards. . The same applies for other disciplines, electrical engineering has any number of rigorous standards in addition to the example I've already given, same with civil, chemical engineering, transport, shipping etc., weights and measures, and almost all of them are tied to national and international standards. Moreover, a large subset is mandated by law for reasons of compatibility/interoperability (shipping containers, etc.) and or health and safety reasons, or for economic reasons, to minimize costs, to stop people being cheated etc.
These standards and concomitant laws and regulations are a fact of life worldwide and in many instances penalties apply for violating them. About the only exception is the software industry, it's no longer young and should have matured by now but it still operates like the Wild West were anything goes.
I say that as someone who has sat on standards committees and been involved in writing standards. Moreover, in my profession if I were to act in the undisciplined manner of much of the software industry, I'd be struck off.
Right, those are harsh words indeed—but they are only harsh for an industry that has never had to comply with rigorous rules and regulations that have been set by law. Whilst other disciplines have learned to accept them long ago the software industry still does what it damn-well wants, and it's done so with impunity from its outset. That has to change.
So you think I'm a self-opinionated crank. OK, let me bring you back to this HN story and think again. Software programmers and developers like to call their work software engineering and themselves software engineers but I'd suggest many in other engineering professions just laugh at the notion. If you don't hear them shouting it out loud it's because they're being polite.
What we in other engineering professions laugh about isn't the skill sets of programmers and developers, we accept there are many very skilled people who work in the industry. The real issue is the laissez faire free-for-all attitude of the industry—an undisciplined industry not bound by strict procedures and lawful regulations. Without regulations and clearly defined rules and procedures we end up with inconsistent results, bugs and lots of mess.
I'd suggested you read this story again then read the document in the link below, it was written nearly 31 years ago and covers the issues I've addressed, it's a SciAm article titled Software's Chronic Crisis. One of its key postulates is that software development doesn't have the disciplined lineage of say chemical engineering and that programmers are more akin to artists than engineers because they operate without industry standard strictures and procedures (such as those set by law).
What's so poignant about that article nowadays is that precious little has changed in the software industry in respect to those matters it refers to. Now ask yourself why is that so given that there has been much development in other areas of software development.
Little doubt the above commet is correct. Look at the way Niklaus Wirth's Pascal lacks widespread support amongst programmers whereas languages such as C are very popular because programmers don't feel constrained to the extent that Pascal constrains them, they feel hemmed in by it. Pascal essentially works like other professions—you must define what you want first up, (the concept, say a bridge) and then draw up the plans and revise them before anyone starts building it. After it's built few if any changes can be made. That's the cultural difference between software development and other engineering professions. It's a fundamental one.
https://www.researchgate.net/publication/247573088_Software'... (best copy—PDF)
https://www.cse.psu.edu/~gxt29/bug/localCopies/SoftwareCrisi...