7 ms·

Right, you've given me a reply I'd expect from programmers and Linux uses. I say that as some who has done programming and that I use Linux as my preferred OS.

Right, you've given me a reply I'd expect from programmers and Linux uses. I say that as some who has done programming and that I use Linux as my preferred OS. I don't know why I mentioned Linux here because every time I do in such comments it distracts from the main issue, we Linux users have very fixed and firm opinions about such matters. Despite your comments, which I essentially agree with (at least in principle), I cannot see rhyme nor reason why there are so very many Linux distros. Yes, there'd be good reason if they were one-offs for a specific application, say in embedded systems etc., but to have so many widespread and in the public domain makes little sense to me. It not only causes confusion amongst users, especially novices, but also spreads human effort widely that would be otherwise better spent on developing fewer systems—it's the more hands make light work philosophy. For the same reason it's why Linux has been so slow to take hold on the desktop. Yes, the usual hardcore Linux user who knows Linux well says 'who cares, that's the least of our worries'. For some odd reason they don't care that the Linux ecosystem would be better off with a more cohesive and unified approach to development. Even with that said, Linux is forever changing, new kernels come out so frequently that it's hard to find two Linux distributions with simultaneously the same kernel code. No matter how one views it, that load puts a constant strain on bug finding, security testing, etc. Frankly it's a mess, if for no other reason that so many versions are a nightmare for administrators. All these updates cause lots of extra work for all those who don't work in tightly controlled environments that have rigid/strict update procedures. …And that's many of them. Leaving me out of the argument for a moment, I'd reckon many of the Linux fraternity would object to you lumping Arch with say Debian in the one sentence although they'd likely agree with you over Gentoo etc. That said, why then can't Linux have a single package manger? It's a damn nuisance that it's not so. As usual, not enough people can agree to reach a unified consensus (and they disagree for very questionable reasons). And it's why in many instances we've had to resort to messy kludged solutions such as flatpack. I've more but I'll stop there. "Programming languages are a combination of tools and notation. Different domains have different needs and preferences." Why? Yes, I've seen many reasons but I've never seen it justified with solid argument. Most of those reasons arise out of historical happenstance, and or favouritism, or that 'we've always done it that way' syndrome. As I said, programmers have an investment in learning and they don't want to see it made obsolete. Whilst that makes sense to them, it doesn't go any way towards solving the chronic software problems as outlined in the IEEE story. Let's look at the number programming languages problem a little further. A quick search finds this quote on the CLRN—California Leaerning Resource website: "According to The International Organization for Standardization (ISO), there are approximately 14,000 programming languages out there. However, this number is often disputed, and different sources may provide varying estimates. For instance, Wikipedia lists over 23,000 programming languages, while Rosetta Code, a website that aims to document programming languages, claims to have data on over 6,000 languages." That makes me shudder. OK, lets whittle that down to something more reasonable. Some references claim the number of well-known languages is upward of 700, with between 200 and 400 being those most commonly used. Others say the most frequently used languages number upward of 50. How correct that is and how much of those numbers can be put down to programmers' favorites I cannot say (I only know a few, Lisp, Fortran, C and a few others, so I'm not qualified to speak for those others). I would suggest however that a rational approach would reduce that number down to many fewer than we have now. To test that hypothesis one could begin with a mathematical analysis of each language. Perhaps the formal mathematical logic à la Whitehead and Russell's Principia Mathematica would be a good place to start as not only the mathematical structures of a language could be tested for coherence and correctness but also so could its grammatical syntax. Possibly there are even better ways of going about such an analysis but I've not given them much thought. Little doubt, AI will rationalize all this in the near future irrespective programmers' wishes. Suffice to say, until those analyses are done I remain unconvinced that all those (at least common) languages are needed. Preference and favoritism may drive the current status quo but it's not a logical way to proceed and to properly tackle the problems outlined in that story.

pona-a 1y ago
I see a common thread in that comment: 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 can't force people to not reinvent the wheel; that's hubris, the third virtue of a programmer, as well as parallel invention. If you base your solution on top of something else, like writing a DSL in Lisp instead of starting from scratch, it will still become a new language as it diverges, like Coalton. Otherwise we'd say Perl isn't a language, because its interpreter is written in C. If these tools weren't needed, nobody but their author would use them. There's a genetic hill climb happening in every sphere of life, from film and poetry to science and programming, where every new thing either sets a new threshold of goodness, or is forgotten when it fails to. Sooner or later things stabilize, when the new solution is not better enough to outweigh the old one: we used to see many version control systems, but only Git remained, because for all its flaws, something like Jujitsu or Pijul weren't as much better than Git as Git was than SVN. We measure how close we are to convergence not by the size of the population, but by the average age of the used solutions. By that metric, software is cooling. There is no problem to solve: nobody is writing enterprise software in a bespoke SKI-combinator derived language they found on Rosetta Code, nor paralyzed by choice between 275 Linux distros to put on their server. The duplication of effort is a cost offset by dysfunctional application and maintenance of solutions designed by committee. Simplicity does not precede complexity, but follows it.
- hilbert42 1y ago
  "…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. https://www.researchgate.net/publication/247573088_Software's_Chronic_Crisis https://www.researchgate.net/publication/247573088_Software'... (best copy—PDF) https://www.cse.psu.edu/~gxt29/bug/localCopies/SoftwareCrisis.html https://www.cse.psu.edu/~gxt29/bug/localCopies/SoftwareCrisi...

pona-a 1y ago

I see a common thread in that comment: 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 can't force people to not reinvent the wheel; that's hubris, the third virtue of a programmer, as well as parallel invention. If you base your solution on top of something else, like writing a DSL in Lisp instead of starting from scratch, it will still become a new language as it diverges, like Coalton. Otherwise we'd say Perl isn't a language, because its interpreter is written in C. If these tools weren't needed, nobody but their author would use them. There's a genetic hill climb happening in every sphere of life, from film and poetry to science and programming, where every new thing either sets a new threshold of goodness, or is forgotten when it fails to. Sooner or later things stabilize, when the new solution is not better enough to outweigh the old one: we used to see many version control systems, but only Git remained, because for all its flaws, something like Jujitsu or Pijul weren't as much better than Git as Git was than SVN. We measure how close we are to convergence not by the size of the population, but by the average age of the used solutions. By that metric, software is cooling. There is no problem to solve: nobody is writing enterprise software in a bespoke SKI-combinator derived language they found on Rosetta Code, nor paralyzed by choice between 275 Linux distros to put on their server. The duplication of effort is a cost offset by dysfunctional application and maintenance of solutions designed by committee. Simplicity does not precede complexity, but follows it.

hilbert42 1y ago
"…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. https://www.researchgate.net/publication/247573088_Software's_Chronic_Crisis https://www.researchgate.net/publication/247573088_Software'... (best copy—PDF) https://www.cse.psu.edu/~gxt29/bug/localCopies/SoftwareCrisis.html https://www.cse.psu.edu/~gxt29/bug/localCopies/SoftwareCrisi...