back to article This House believes: A unified, agnostic software environment can be achieved

Welcome to the latest Register Debate in which writers discuss technology topics, and you the reader choose the winning argument. The format is simple: we propose a motion, the arguments for the motion will run this Monday and Wednesday, and the arguments against on Tuesday and Thursday. During the week you can cast your vote on …

  1. Howard Sway Silver badge

    You believe a unified software development method can be achieved?

    Ever met any programmers?

    Think you could convince them all to agree on a single language and toolchain? It would be the worst language ever if it did everything every other language ever did, and would require every software library ever written to completely support it. And the IDE would need every function every other IDE ever had too.

    Otherwise you'd have to throw away all existing code and dev tools and start from scratch again with your great new thing and that ain't happening.

    And throwing a few buzzwords like AI and HPC into the argument doesn't make the silly idea any more viable.

    1. the spectacularly refined chap

      Re: You believe a unified software development method can be achieved?

      Unified does not mean it be the only game in town, there is still plenty of scope for alternatives. The issue is can a platform be created that can transparently span e.g. single processors, SMP, 90's super style vector processors, massively parallel systems of varying memory arrangements and indeed FPGAs. The fact you can create one such system automatically means you can create another from a technical perspective at least.

      I strongly believe this is possible from a pure CS perspective, whether it is commercially viable is a slightly different issue. My third year undergrad project was a bit part in an implicitly parallel research language and that was over 20 years ago. Using functional programming techniques since they don't implicitly depend on a single model of what a computer looks like.

      It worked on uniprocessor machines, SMP, distributed clusters and the vector machines. FPGAs didn't enter into anyone's mind but I've noted here previously how similar the mindset is for good Verilog or VHDL code and functional programming - in each you are essentially making statements about what is true instead of giving an ordered list of steps to execute.

      So yes, it would be different to traditional imperative programming to reflect the additional abstraction. That doesn't mean a 'universal' solution across the differing architectures need be the only one.

    2. Anonymous Coward

      Re: You believe a unified software development method can be achieved?

      > Think you could convince them all to agree on a single language and toolchain?

      But we already have one of those. It's called BASIC Pascal Ada C++ C++ (with the STL) Java C++ (again) JavaScript Rust for the win!!

      P.S. I've omitted Delphi because I'm not Verity Stob

      1. Ernst Blofelt

        Re: You believe a unified software development method can be achieved?

        Back in the 90's Greggs the Northern bakers ran on Delphi It's not just academic

  2. katrinab Silver badge

    If your workflow doesn't match what the software was designed for, then oftentimes it is easier to start from scratch than try to wedge your workflow into the existing software design.

    Also, open doesn't necessarily mean unified. People often have very different ideas about what is the correct way to do things, and the differing views may well both be valid from the perspective of the people in the respective camps.

  3. Anonymous Coward
    Anonymous Coward

    Again, the cynical voice...

    It's a nice idea - write things once and run them anywhere.

    Trouble is:

    - The vendors need their lock-in. AWS don't want customers to migrate to Google, neither want them to migrate to Azure. There's not many places to go after that.

    - You don't want to build your exciting new product with its competitive features at the behest of a competitor, let alone some other self-assigned arbiter. It would have an incredible chilling effect.

    It's a nice pipe dream, but won't work in reality.

    That's not to say it's impossible in a limited extent - HTML was universal enough to give us the World Wide Web, for example.

    1. ScottTx

      Re: Again, the cynical voice...

      Vendor lock-in. Exactly right. None of the stated reasons why this hasn't happened yet are valid. The single obstacle to this sky-pie is that it won't make anybody any money. There would be no incentive to spend the time and resources to build and maintain such a system.

  4. mpi Silver badge

    There is no "one-size-fits-all" solution

    Not in business logic, not in programming, not in infrastructure.

    Why would I use tools designed for HPC to solve something that can be done using the computational power of a wristwatch? Why would I map the job of drawing graphics on a screen to the same tools used to build large-scale IDS? Why would I build systems to wrangle a few dozen text documents every few days using the same stack used to wrangle 10000 documents every minute? Why would I build a machine learning system on the same framework used to write hardware drivers?

    Yes, in theory, a screwdriver could be used both to tighten screws, and to hammer nails into walls.

    Doesn't mean it should be used that way, or that craftsmen are doing it wrong by carrying 2 tools.

    The problem domain defines the tools used to solve it.

    Not the other way around.

    1. Charles 9

      Re: There is no "one-size-fits-all" solution

      What's to stop someone from making a tool that can be screwdriver one minute, a hammer the next, and can still be carried in one hand?

      1. doublelayer Silver badge

        Re: There is no "one-size-fits-all" solution

        Well, the best way to do that is probably to put a screwdriver on the end of the handle with a cap over it, which makes for an inconvenient interface to the driver, but it can be done. It gets progressively harder when you want to add even more tools to it. If you try too hard, it won't fit in a hand, will cost ten times as much as the individual tools, will break and be impossible to repair economically, will be hard to use for a situation not envisioned by the original creators, or all four.

        1. Charles 9

          Re: There is no "one-size-fits-all" solution

          So basically, physics gets in the way. But it may be handy for high-portability instances like highly-remote operations (for example, up a pole) where hands are already in use and there's no access to a toolbox. I've actually been fond of "Swiss army knife" multi-tools and actually found use for them when I only had one hand and one pocket.

  5. 0x80004005

    Oh great, another inner platform...

    Looks like someone hasn't been reading their XKCD:

    Typical sales / management hyperbole:

    "Our system will do everything that all those other systems do, and better than they do, even though all we've done is put a thin shim layer over the top with a nice logo!"

    1. AdamWill

      Re: Oh great, another inner platform...

      Yup. In fact, the problem here is the topic is slightly wrongly phrased, because as it stands, the motion should easily pass. Sure, a unified, agnostic software environment can be achieved - and then another one, and then another one, and then another one. The tricky part is stopping at one, and somehow avoiding somebody deciding they can do it better, and taking enough people with them...

  6. Anonymous Coward
    Anonymous Coward

    The articles ideals have "made sense" in the software industry since the 1950's for virtually every field of computing there has been, but they've all been stymied by one key issue: vendor lock-in. Vendors are out to make money, and the easiest way to keep doing that is to make it hard for you to use anyone else's product once you've started using theirs. You become a nice, reliable, steady source of cash for licensing fees and the like....

    1. doublelayer Silver badge

      That's true, but it's going to happen anyway even if everything was open source and free. People just don't agree on what the best thing is. We have a lot of languages that are freely available, for example, but that doesn't prevent people from rejecting them and making more, or for that matter rejecting anything released after 1990 and complaining that anyone who doesn't hand-code everything in assembly is just lazy. We could do a lot to create a unified standard for basically anything, but it's not going to be universal no matter how much effort we put into it.

      1. Charles 9

        In other words, there is no question where everyone can agree on the answer.

  7. pmb00cs

    It is probably possible but is it desirable?

    There is no technical reason the computing world can't produce a functional, hardware agnostic, software environment. And such a thing on the face of it makes logical sense. However this ignores the human factor, and I'm not just talking about the "not invented here" syndrome the author of the article rallies against. Humans have preferences, and different ways of working/thinking. Forcing everyone to use the same tools for "common sense" reasons, isn't actually terribly sensible, if doing so limits the effectiveness of the people building things with those tools.

    Yeah, I think it's possible. I just don't think I want to live in a world where it's done.

    1. mpi Silver badge

      Re: It is probably possible but is it desirable?

      It's not just the people who try to solve problems, it's also the problems they try to solve.

      Problem-A: I have 150g of walnuts, and I would like to crack them for a snack while watching TV.

      Problem-B: A baking-products factory has 15t of Walnuts per day, to be made into crushed walnuts or whatever, so they also have to remove the shells.

      I will probably use a hand-nutcracker for this problem

      The factory will likely use some industrial-grade nut-processing machine.

      Neither approach makes sense for the other problem, even though they are in the same domain, with scale being the only difference.

      1. Anonymous Coward
        Anonymous Coward

        Re: It is probably possible but is it desirable?

        I see your point, but I think it rather obvious the article is hinting at centralized cloud services provisioning all manner of customers regardless of what the customer is using to access the systems. Because the only way you can ever have a unified approach to anything is to have unified control over it; anyone who still thinks you can find "concensus" over anything of note without turning it into a hodge-podge of exceptions and special cases need only look at the evolution of something so "simple" as HTML in the standards history.

        I see no other way one could truly implement the environment, other than possibly provisioning the same software stack the cloud uses as nodes on-premises with hardware of the customer's choosing. But you'd still need that centralized control over everything, including maintenance, in order to deliver a cohesive experience that is truly "unified".

        The Chinese are trying to do it with their mega-portal web environments provided by a few of their big industry players. How well it is succeeding? Who knows outside China? Would it succeed in the Western world where "choice" and "rights" are paramount to a huge segment of the population? I doubt it.

        Though truth be told, "choice" is an illusion. More and more, you find that all the brands of a product are produced in fewer and fewer centralized factories. There isn't much difference between the brands except customer loyalty in many cases....

        1. mpi Silver badge

          Re: It is probably possible but is it desirable?

          >provisioning all manner of customers regardless of what the customer is using to access the systems

          But why?

          Let's say I launch a simple text-only webforum with an estimated 100.000 requests per day total. Or lets say a "where-is-the-nearest-ATM" app for an AR device, which would have a similarly low load.

          What would even be the point to run that on big iron in a warehouse somewhere, using a frameworks and infrastructure designed and built to accomodate the next facebook, when I can spin it up with no problem in an on - premise box with code written over a long weekend?

  8. Roland6 Silver badge

    Dream on...

    We can look to the early days of Linux clusters in HPC for a good example of how to create a common, high-performance computing platform.

    It is also a perfect example of why there never can be "a unified, agnostic software environment"; MPI was absent from the agnostic Linux software environment and hence had to be created.

    And then multi-threaded and multi-core processors came on the scene, there were how many different ways to program them before the OpenMP standard was proposed and adopted by a significant share of the HPC community?

    OpenMP built upon the multi-faceted experience gained from those differing approaches. Even with a unified environment, you will still need divergent thinking around a new concept before there is sufficient understanding of the problem space to be able to propose a unified approach. I expect OpenMP (as it currently stands) also can't handle the new generation of multi-core CPU's.

  9. Boris the Cockroach Silver badge

    One software

    to rule them all

    Was'nt that what Java was invented for?

    Now while I maybe able to design and build a decent application for data transfer in Java, using Java to run the machine tools/robots is rather an overkill situation.

    Especially when you want speed of execution plus a reliable bug free program. (bugs in control systems are bad m'k)

    Use the tools designed for the situation you are programming..... device driver... C/Assembler, rich GUI application C++/Java/ whatever

    Forcing one software to cover everything will mean loss of focus on the problem to be solved and that focus will be shifted into "how do we force the software to do xxxx?" rather than "How do we make sure the data buffer wont overflow?"

    1. Tim99 Silver badge

      Re: One software

      I think you'll find UNIX and C before that - Until AT&T realized that they "owned it" (well except for all of the bits done by Berkley, other universities, other business, and users). Then we had the "UNIX Wars"

      Welcome to Microsoft with there sound business idea that "Just" good enough is good enough - Some of us remember that Microsoft licenced more copies of UNIX (Xenix) than anyone else, and paid AT&T for the privilege. You might well think that that was a good reason for MS to employ Dave Cutler to produce Windows NT.

  10. karlkarl Silver badge

    ANSI C (+hacks) is the closest we have even if people don't like to admit it.

    Any key library is written in C99 and then the rest of the developer ecosystem (who aren't C, C++, Objective-C developers) wait for bindings to be created for their language of choice and then they consume it.

    C is the computing platform.

  11. nautica Silver badge

    One tool for everything? Never happen, in any endeavor.

    Do you know any craftstman---auto mechanic, bricklayer, electrician, carpenter[ plumber...---who can do his job with only one or two "universal" tools? Didn't think so. Every tool is designed and created to solve a specific problem in the most efficient manner possible.

    If this (‭one tool for everything) were a viable concept, we wouldn't have four-function calculators, scientific calculators, financial calculators, programmers' calculators...

    Same thing applies to languages:

    COBOL was created to solve business problems;

    Fortran was created to solve scientific problems;

    C was created to build Unix;

    Java was created...



    "Good ideas are overrated.‭...The world is filled with people with good ideas and very short of people who can even rake a leaf.‭ ‬I'm tired of good ideas.‭” ‬--Andy Rooney


    ‭"‬To a man with a hammer,‭ ‬everything looks like a nail.‭ ‬To a Computer Scientist,‭ ‬everything looks like a language design problem.‭ ‬Languages and compilers are,‭ ‬in their opinion, the only way to drive an idea into practice.

    "My early work clearly treated modularisation as a design issue,‭ ‬not a language issue.‭...‬Although some tools could make the job easier,‭ ‬no special tools were needed to use the principal,‭ ‬just discipline and skill.

    "When language designers caught on to the idea,‭ ‬they...spread the false impression that the important thing was to learn the language‭; ‬in truth,‭ ‬the important thing is to learn how to design and document.

    "We are still trying to undo the damage caused by the early treatment of modularity as a language issue and,‭ ‬sadly, we still try to do it by inventing languages and tools.‭" ‬--David L.‭ ‬Parnas

  12. Anonymous Coward
    Thumb Down

    Reminds me of todays blockchain post

    It's possible to create something but if few buy into using it as a standard and fewer can use it successfully and nobody can make it profitable then it is a waste of resources and good only for academic papers.

  13. ecofeco Silver badge

    For, but....

    ...good luck. Herding cats never works out well.

    Techno-tedium is all the rage these days. All the cool kids are doing.

  14. martinusher Silver badge

    All problems are easy once they've been solved

    The basic idea of a standardized environment is sound and we're fairly close to it with 'ix' type systems. The problems creep in when we think we're at a point where all possible problems can be solved. The ISO networking framework springs to mind here -- everyone's familiary with the ""Seven Layer Model", its been around for ever, its universal, its a great idea and its essentially implementable (there's been attempts, none AFAIK successful). Even the message passing interface mentioned in the article is just a rehash of something that's been around for ever -- real time systems are defined partly in terms of inter-task messages (or should I say, "many* real-time systems....every time you mention a rule exceptions immediately spring to mind) and any decent operating system has got a message passing and signalling protocols as a fundamental capability. (Its also important to bear in mind that whatever can be done within one processor can also be done within multiple processors and whatever can be done between multiple processors can be distributed across physically separate systems.

  15. Daedalus

    Long long time ago

    Well, there was this sales droid, see. Or maybe a marketeer. Either way, he, she, or it is reported to have said "You don't want to get locked in to open standards".

    There, in a nutshell, is the problem. The people who call the shots (a) don't have a clue, and (b) are focused on locking all the cattle in the barn where they can be milked with extreme prejudice. Any mention of common standards is taken as somebody else beckoning the herd to their barn, not a way to ensure the future of the human race as users of technology.

    BTW the open standards we are talking about are from the Posix vs VMS era. Nothing changes.

  16. Anonymous Coward

    It's the wrong question: not unified s/w environment but unified presentation environment

    It's asking the wrong question. The issue is not so much the dev tools and the language but the lack of a standardised presentation environment. I yearn for the days of a simple VT100 compatible teletext terminal because you knew what you were getting. There was a near 100% chance that if the UI worked on your dev screen then it worked on the users' as well.

    Anyone remember NAPLPS? No? That'll be just me and Wikipedia then.

    Display PostScript?

    Nowadays it seems like there are a zillion different desktops and GUIs. And even when there is a standard like HTML5, it's immediately smothered with a zillion frameworks. You've probably seen this already but it sums up perfectly why software development is so unnecessarily hard.

  17. Doctor Syntax Silver badge

    "How long will we keep reinventing software wheels?"

    That's an easy one. As long as there's good money to be made repackaging old stuff by wrapping it in new jargon.

  18. RobLang

    Not possible

    If you take AI to mean feedforward/recurrent neural networks then it's feasible but unlikely for all the good reasons other commenters have mentioned.

    However, there are other algorithms that won't fit your model so well at scale - unsupervised learning or Bayesian networks. If you build your high performance compute for feedforward/recurrent neural networks, you will be creating a bad fit for other algorithms.

  19. Anonymous Coward
    Anonymous Coward

    Universal Turing Machine...... capable of emulating ANY other computing machine.

    Why no mention here? One read/write (nearly) infinite set of symbols......there's your "single standard".

    Problem solved!!

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon