20 ms·

The Great Software Stagnation

• Smaug123 6y ago
  There have certainly been attempts. The Bret Victor school of thought, and LunaLang, for example. It doesn't seem that there's a massive shortage of ideas - which points more towards a generalised industrial lack of effort as the main culprit. I guess Microsoft and the Lean theorem prover/programming language probably counts? I could see that becoming as big a thing as Mathematica.
  • corysama 6y ago
    VPRI's STEPS was a great research project in this direction https://alarmingdevelopment.org/?p=229 https://alarmingdevelopment.org/?p=229 https://www.hackernewspapers.com/2017/1146-steps-toward-the-reinvention-of-programming-final-report-2012/ https://www.hackernewspapers.com/2017/1146-steps-toward-the-... But, then they published their final report.. did other stuff for a while... announced they brought together a great team with a long-term funding... and they've been doing... something? Nine years now and I haven't heard of any more progress on this front.
    • zepto 6y ago
      Ironically that group is oddly cynical about the importance of the UI/Visual representation.
    • infinite8s 6y ago
      I remember reading Alan say (perhaps on Quora, where he seems to be quite active) that he got tired of fighting to fund VPRI every year.
• Swizec 6y ago
  > This is as good as it gets: a 50 year old OS, 30 year old text editors, and 25 year old languages. Bullshit. No technology has ever been permanent. We’ve just lost the will to improve. We’re at the better horses stage of the cycle. What’s the next car?
  • unnouinceput 6y ago
    Commercial quantum computer and true parallel programming languages.
    • tsimionescu 6y ago
      Quantum computing is only likely to be an accelerator for a few specific kinds of problems. The bulk of programming (even the bulk of most quantum algorithms!) is still happening in classical computers.
      • pfdietz 6y ago
        I'm not convinced quantum computers are going to accelerate anything.
        • tsimionescu 6y ago
          Problems in the complexity class BQP are mathematically proven to be more efficient on a quantum computer than on a classical computer. You can still doubt that quantum computers are physically realizable. Perhaps the number of qubits needed for error correction will turn out to increase fundamentally faster than the number of useful qubits, or perhaps there is some other fundamental limit that we will hit. But the maths is clear: if it is at all possible to create a quantum computer, it will be faster for certain specific problems than a classical computer (in particular, it will be faster than a classical computer at simulating quantum phenomena).
          • pfdietz 6y ago
            Since BQP is a subset of PSPACE, are you claiming that P != PSPACE has been proved?
            • tsimionescu 6y ago
              Oops, you're right, I misspoke when I claimed this was proven. I mixed up BQP with the recent quantum superiority demonstration, apologies. Still, it is strongly suspected that BQP != P. This was especially reinforced by the MIP* = RE result, as far as I understand from Scott Aaronson [0]. [0] https://www.scottaaronson.com/blog/?p=4512#comment-1829033 https://www.scottaaronson.com/blog/?p=4512#comment-1829033
• deleted 6y ago
  [deleted]
• cortesoft 6y ago
  They left out a lot of advancements in their list. I can't even see the common theme for what they decided to include or not. Is it just the list of software tools they use?
  • barkingcat 6y ago
    Yup! just a laundry list of software.
• liquidify 6y ago
  At minimum, C++11 and forward are revolutionary leaps. Combine that with Rust, and I think the author is missing some critical elements that would have stopped his hypothesis in its tracks. He make logical leaps that aren't justified.
  • zepto 6y ago
    I don’t see anything revolutionary about rust. It is an very well designed piece of engineering and an extremely useful and tasteful set of tools, but it’s no paradigm shift.
• PragmaticPulp 6y ago
  The author sets up a short list of technologies developed since 1996: > Since 1996 we’ve gotten: IntelliJ, Eclipse, ASP, Spring, Rails, Scala, AWS, Clojure, Heroku, V8, Go, React, Docker, Kubernetes, Wasm. And then waives them all away as incremental or unimpressive. The author holds up V8 as an example of something that isn't fundamentally new, which is missing the entire point of developing a runtime for an existing language. Not to mention, V8 is an impressive achievement in itself. I'm lost as to why the author wants to work so hard to dismiss these technologies while simultaneously suggesting that nothing else noteworthy has been developed in the past two decades. If an engineer in 1996 fell into a coma and woke up today, they'd be greeted with an entirely different world. We're driving around in electric cars, carrying around cell phones that are orders of magnitude faster than desktop PCs from 1996, and communication technology has evolved to the point that many of us are seamlessly working from home. Technology only looks stagnant when you're steeped in it every day of every year. Up close, it looks slow. Take a step back and it's amazing what we have at our disposal relative to 1996. Don't mistake cynicism for expertise or objectivity.
  • ativzzz 6y ago
    > We're driving around in electric cars, carrying around cell phones that are orders of magnitude faster than desktop PCs from 1996, and communication technology I'd argue that these are primarily hardware innovations, not software innovations. The OP mentions software, not technology in general. See also Moore's law (hardware upgrades double computing speed every ~2 years) vs Proebsting's Law [1] (compiler upgrades double computing speed every ~18 years). [1] http://proebsting.cs.arizona.edu/law.html http://proebsting.cs.arizona.edu/law.html
    • PragmaticPulp 6y ago
      > The OP mentions software, not technology in general. Hardware and software are closely intertwined. We couldn't design, develop, build, and run modern hardware without modern software packages. You're just not seeing the advances in software if you're only looking at famous web services technologies. The whole article is extremely myopic, limited only to the author's narrow domain of web services and coding in text editors.
• bob33212 6y ago
  Software 2.0 is happening right now. GTP-3 and Tesla FSD are examples of this. On the other hand software 1.0 was a victim of it success. People realized that they could build software companies with SQL hard coded into windows forms buttons. Theses people have never even heard the word extensibility. Like the rest of corporate America they are mostly focused on the next quarter results and drown out any voices from people who want to innovative for innovation sake.
  • bogdanoff_2 6y ago
    > People realized that they could build software companies with SQL hard coded into windows forms buttons. Theses people have never even heard the word extensibility. Is there anything wrong with this?
    • jackblemming 6y ago
      Depends. For a quick prototype or small project? Seems fine. For a project with changing requirements and planned long term use (read: most software), it's probably best to not mix all your technologies in a single layer.
    • phkahler 6y ago
      >> Is there anything wrong with this? No. Building something useful is good. It's just not an example of technological progress. That's what they meant by a victim of it's own success. When something advances enough to be useful it's natural for a bunch of people to just make use of it as-is.
  • sbrother 6y ago
    > Software 2.0 is happening right now. GTP-3 and Tesla FSD are examples of this. I agree with this. As an anecdote, I've spent the past decade explaining to clients that things like natural language question answering and abstractive summarization are impossible, and now we have OpenAI and others dropping pretrained models like https://github.com/openai/summarize-from-feedback https://github.com/openai/summarize-from-feedback that turn all those assumptions on their head. There are caveats, of course, but I've gone from a deep learning skeptic (I started my career with "traditional" ML and NLP) to believing that these sorts of techniques are truly revolutionary and we are only yet scratching the surface of what's possible with them.
• usr1106 6y ago
  To make it worse unbelievable software bloat makes most advances in hardware invisible to the end user. And then we got an ugly business model surveillance capitalism. Users expect everything to be free and happily (or unknowingly) with their privacy and ways to be manipulated. Monopolies instead of interoperability and federation. Computer science can't be proud of the current state of affairs.
  • throwaway3699 6y ago
    At the end of the day though, consumers prefer free. Even if they say they want privacy preserving products, they really don't (otherwise we'd all be using Linux and Fairphones). I'd also be careful about the last statement: Computer science is much broader than internet advertising companies.
    • usr1106 6y ago
      > Computer science is much broader than internet advertising companies. Nobody would doubt that. But as a computer scientist I would have hoped that our discipline could have paved the way for something better to mankind than the current reality.
      • deleted 6y ago
        [deleted]
• deleted 6y ago
  [deleted]
• nicktorba 6y ago
  Seems like there is just a general lack of emphasis on the improvements that have been made. It makes sense that progress cycles from a big breakthroughs to years of seeing how far we can push it. Even so, the world is significantly different than it was in ‘96. “Stagnation” doesn’t feel like the right word. What about advances in quantum computing? Is that not a large enough paradigm shift for the author to acknowledge?
• jeffreyrogers 6y ago
  This is just the normal course of technology. The jet engine hasn't fundamentally changed since the 50s or so, but we're still making incremental improvements to it (single crystal casting, various high temperature alloys, probably ceramic turbine blades in the future), and those changes add up to substantial improvements over time. Software is the same. Edit: Just compare how much easier it is to make something substantial today than it would've been 15 years ago. You could make a fairly sophisticated SaaS today from scratch using Django, Postgres, Redis, Stripe, Mailgun, and AWS in about a month. That's progress, even if it is boring and obvious.
  • medlyyy 6y ago
    It's easier to make a very specific style of application that's very similar to what a lot of other people make. Anything outside that is probably significantly more difficult though, because of the massive complexity of everything your software has to interact with.
  • asdff 6y ago
    It's a little different imo. We've settled on the design of the jet engine through math and engineering. The shape of it is designed and not arbitrary. On the other hand, the syntax of a programming language is entirely arbitrary, settled upon by whoever wrote the tool using whatever convention struck them at the time. Programming languages weren't designed and come upon through linguistical theory or psychology over what might be the best way to structure this stuff or anything like that. It wasn't rooted in empirical evidence like the jet engine is. It was a programmer at AT&T deciding that grep seemed like a pretty cool acronym 50 years ago, and we are still teaching kids how to use grep today for no reason other than this arbitrary syntax now being the status quo due to everyone in the business having already taken the time to learn it. Not because it's good or we have some evidence that this is a decent syntax, only that we are lazy and entrenched.
    • veddox 6y ago
      > the syntax of a programming language is entirely arbitrary [..] Programming languages weren't designed This statement is quite simply wrong. Unless I'm misunderstanding you, you seem to be ignoring decades worth of programming language research and the years of work put into designing individual languages (whether by BDFLs, communities, or ANSI committees). I agree with you that perhaps jet engines weren't the perfect metaphor. However, I think that that's because jet engines have much more stringent external (physical) constraints than software or programming languages. The latter do allow for a certain amount of "taste-judgment": it doesn't matter too much which way you do it, but some people at some times prefer one way over another. So a more apt metaphor might be architecture: We've known how to build houses for millenia, but we're still improving our materials and techniques, while tradition and fashion continue to play a big role in what they end up looking like.
• paulsutter 6y ago
  Since 1996 we've gotten deep learning, the iPhone, Google (search, maps, translate, youtube), bitcoin, landing rockets for re-use, social networks, and the ability for the whole world to switch to remote work without advance notice (and yes those are all software innovations).
  • barkingcat 6y ago
    also the idea / protocol of bittorrent
• barkingcat 6y ago
  This article sets up a very narrow view of "software" and then criticizes the state of "software" as if all that existed was what the author though of as "software"
• xenihn 6y ago
  iOS and Android seem like huge omissions from that list.
  • mixmastamyk 6y ago
    Unix with lipstick?
    • m00x 6y ago
      That's a tremendous understatement. They're both incredibly huge projects with major advancements. It's not only hardware that helped create modern cellphones, the whole ecosystem and perf improvements are game changers.
      • mixmastamyk 6y ago
        Perhaps you've understated Unix as well.
• woodruffw 6y ago
  The author is a researcher with experience in programming languages, but curiously omits LLVM from his list of post-1996 advancements. LLVM alone is responsible for a Copernican revolution in compilers and program analysis; just the last decade has seen a proliferation of novel PL and analysis research as a direct knock-on effect of LLVM’s success.
  • deleted 6y ago
    [deleted]
  • Nicksil 6y ago
    > LLVM alone is responsible for a Copernican revolution in compilers and program analysis This is hyperbole
    • woodruffw 6y ago
      It was a reference to Kant’s so-called Copernican Revolution in Philosophy. Philosophy existed before Kant just like program analysis existed before LLVM; I would argue that the state of the field is both fundamentally different and significantly more accessible than it was pre-LLVM.
    • gjvc 6y ago
      "Cambrian explosion" any better? :-)
• adamnemecek 6y ago
  Rust and GPU programming are notably missing.
• mrob 6y ago
  No mention of distributed version control. That seems to me a more important development than most of the post-1996 list.
  • neolog 6y ago
    Today git is mostly used the same way as a centralized version control system, no?
    • jessaustin 6y ago
      You can use it that way if you want. That's not how everyone else uses it, however.
      • pjmlp 6y ago
        Actually it is how most of the projects I have been have decided to use it. Most enterprise shops don't see any value in doing otherwise.
    • mrob 6y ago
      I don't think so. Even if the main repository is organized in a linear style, it's very common for developers to make experimental branches on their own machines. This was inconvenient before DVCS, so you used to see things like conditional compilation or large blocks of commented-out code. People tend to work in the way best supported by their tools, and I'm convinced DVCS changed the way we work by making more things convenient. And that's not even counting large-scale truly distributed projects like Linux kernel development (the origin of git), which would be practically impossible without it.
      • neolog 6y ago
        The experimental branches point is a good one. I'm not convinced about "large-scale truly distributed projects" though. Larger scale projects than that are hosted on github.
• maria_weber23 6y ago
  Last part from the article: "But maybe I’m imaging things. Maybe the reason progress stopped in 1996 is that we invented everything. Maybe there are no more radical breakthroughs possible, and all that’s left is to tinker around the edges. This is as good as it gets: a 50 year old OS, 30 year old text editors, and 25 year old languages. Bullshit. No technology has ever been permanent. We’ve just lost the will to improve." Yeah, that's obviously bullshit. But we also didn't lose the will to improve. The leap from where we were 20 years ago, to where we are now, isn't mind-boggling. I still remember my Turbo Pascal days, my Delphi days. Sure things to improve... But overall this experience was sufficient. I wouldn't really have trouble implementing any of the projects I worked on in the past 10 years with Delphi, or even Turbo Pascal. It would sure suck, and take longer, but it wouldn't be a dealbreaker... This is the raw definition of a non-revolutionary progress. The problem is that the next step of software engineering is incredibly difficult to achieve. It's like saying "Uh math/physics didn't change a whole lot since 1900". Well it did, but very incrementally. There is nothing revolutionary about it. Einstein would still find himself right at home today. That doesn't mean progress was stalling per se. It means that to get "to the next level" we need a massive breakthrough, a herculean effort. Problem also is that nobody really knows what that will be... For me, the next step of software engineering is to only specify high-level designs and have systems like Pluscal, etc. in place that automatically verify the design and another AI system that code the low-level implementation. We would potentially have a "cloud compiler" that continuously recompiles high level specs and improves over time with us doing absolutely nothing. I.e. "software development as a service". You specify what you want to build, and AI builds it for you, profiting from continuous updates to this AI engine world-wide.
• didip 6y ago
  What? I have to hard disagree. There has been a plethora of brand new languages since 1996. Most of them are due to LLVM, which is impressive on its own. Not to mention Clang. Search engine used to be considered an impossible problem (just using grep doesn’t count), but it is now quite easy to solve that problem thanks to ElasticSearch and Solr. What about all those distributed databases we all took for granted? Open Source DB used to sucked when it comes to horizontal scalability. As if the above are not enough, what about virtualization and containerization technology? Are they not impressive enough for OP? They single handedly spawn multi billion dollar businesses and make deployment significantly easier. Need I say more?
  • pjmlp 6y ago
    The ideas behind LLVM were first researched by IBM during their RISC research on the implementation of PL.8 language, and later by Amsterdam Compiler Toolkit. C++ as database and AST representation was used by Lucid on Energize C++ and IBM Visual Age for C++ version 4. Both products died, because they were too resource hungry for the hardware of the day. Need I say more?
• jcranmer 6y ago
  One of the big mistakes I see in the list is choosing to ignore the developments in software that are old. For example, the author cites Python as pre-1996, yet the adoption of Python as a mainstream language largely postdates 1996. Taking a very narrow view of software (i.e., looking only at compiler-related technologies), I can easily list several advancements that the author neglects: * Profile-guided and link-time optimization aren't really feasible until circa 2010. * Proper multithreaded memory models in programming languages don't come into existence until Java 5, from whence the C/C++11 memory model derives. * Compiler error messages have improved a lot since the release of Clang around 2011. * Generators, lambdas, and async/await have been integrated into many major programming languages. * Move-semantics, as embodied by C++11 and Rust. * OpenMP came out in 1997. * Automatically-tuned libraries, e.g., ATLAS and FFTW are also late 90s in origin. * Superoptimization for peephole optimizers (Aiken's paper is 2006; souper is 2013). * Heterogeneous programming, e.g., CUDA. * Undefined behavior checkers, such as IOC, ASAN. Even Valgrind only dates to 2000!
  • rictic 6y ago
    It's a good bit of rhetorical slight of hand. Anything that existed in any form prior to the date isn't new (even if it was only in an experimental, near-unusable form). Anything that exists today but hasn't yet had much impact on the world is a toy. The only things that remain are those few which appeared seemingly out of nowhere and rose to prominence over a short period of time.
    • oarsinsync 6y ago
      Apologies in advance for the nitpick: it’s sleight of hand.
      • simonebrunozzi 6y ago
        I always appreciate people correcting others - I love when it's done to me. Best way to learn. Mostly driven by just good intentions. Thanks for doing it.
    • 6y ago
• cocktailpeanuts 6y ago
  Ironic that he uses these examples as a non-incremental innovation. > LISP, Algol, Basic, APL, Unix, C, Oracle, Smalltalk, Windows, C++, LabView, HyperCard, Mathematica, Haskell, WWW, Python, Mosaic, Java, JavaScript, Ruby, Flash, Postgress. while using the following as incremental: > IntelliJ, Eclipse, ASP, Spring, Rails, Scala, AWS, Clojure, Heroku, V8, Go, React, Docker, Kubernetes, Wasm What he doesn't understands is, everything is based on everything else. Many languages got inspiration from another language, or some other technology. https://github.com/stereobooster/programming-languages-genealogical-tree https://github.com/stereobooster/programming-languages-genea... There is no such thing as fully independent innovation. Not just in tech, but every single piece of innovation in human history.
• phkahler 6y ago
  Wayland replaced X. Risc-v although it not software. Rust. Tools for running C-like code on GPUs. Those are just the things I think belonged on the list but are not. And all of them take many years to mature and gain widespread use.
  • Ericson2314 6y ago
    > Wayland replaced X The never ending revolution? I am still waiting to upgrade. > Rust Rust is great, but overkill for business logic. It's bummer that people think they need to care about low-level details where it doesn't matter just to use a non-shit language. Meanwhile Haskell is waiting :).
• pbourke 6y ago
  I feel like this sentence holds the key to the author’s misunderstanding of things: > This is as good as it gets: a 50 year old OS, 30 year old text editors, and 25 year old languages. Bullshit. No technology has ever been permanent. Many successful software technologies are Ships of Theseus, where the collection of things with version N bears the same name as the version 1 product but nearly everything works differently or has been rewritten. Consider Modern C++ vs the original language. Also the author just kind of ignores the whole Cloud Computing industry and virtualization.
  • worik 6y ago
    I agree with your conclusion, disagree with your argument. Especially the last one. Cloud computiung was the first sort of computing available, widely, from the 1950s. Central systems which were accessed with terminals. A huge business up until the 1980s, at least. Virtualisation dates from the 1980s, at the latest. I had a professor in the early 1990s who had worked on it for Amdahl
    • hn_throwaway_99 6y ago
      I still then feel like the author's argument would basically be like "aviation has stagnated in the past 100 years!" because planes existed in 1920 and we're still flying in planes in 2020.
      • Leherenn 6y ago
        It's not that wrong though, you could certainly argue that not much has changed since roughly the end of WW2 and "mainstream" oceanic crossings. The de Havilland Comet was introduced in 1949 and is very similar to modern jetliners. The only thing that would shock a traveler from 70 years ago is the awful service and in flight entertainment system.
        • jacquesm 6y ago
          And for someone who flew Concorde it probably looks like we did a step backwards.
• hn_throwaway_99 6y ago
  How on earth does this post have this many upvotes? I find in nonsensical in almost every way, most importantly that the author just waves away or flat out ignores basically every major advance in software engineering of the past 25 years. I mean, does he think the amazing revolution in machine learning, AI and neural networks just didn't happen? What about the absolute tidal wave of open source projects in general? In 1996 if there wasn't a library for some small piece of functionality you needed you either needed to pay for it (anyone remember the market for VB controls?) or build it yourself. These days usually the problem is figuring out which open source library is the best one for your needs.
  • roca 6y ago
    We've made revolutionary advances in version control, package management, and CI practices too. I think this is an example of "post something quite wrong and get lots of attention because it is so wrong".
    • hn_throwaway_99 6y ago
      You're totally correct, I'm thinking this is basically just a troll post. I started my software career in the late 90s, and having worked at a company last year with pretty much greenfield development, I was thinking how so many big, harry problems in software engineering that I experienced are just finally solved now: 1. You bring up version control, the first SCM system I used in the late 90s was CVS. I don't understand how any human that used CVS who now uses git+GitHub/GitLab/GitWebFrontendOfYourFancy can claim things are "stagnating". 2. Similarly, setting up a build and test process (the term "CI/CD" didn't exist in the late 90s) was a relatively huge undertaking, now it's trivial to get tests to run on every merge to master and then autodeployed with something like GitHub Actions. 3. Package management security, while not a fully solved problem, is leaps and bounds better than it was even a couple years ago. Again, I can automate my build process to run things like `npm audit` or other tools from providers like Snyk. 4. Umm, the cloud anyone? You may argue that this is a hardware change but it's really much more of a software issue - the cloud is only enabled by the huge amounts of software running everything. I think the biggest thing I notice from the early 00s to now is that now I'm able to spend the vast majority of my time, even at a small company, worrying about features for my users, as opposed to the huge about of time I spent in the past just on the underlying infrastructure and maintenance to keep everything working.
• SoylentOrange 6y ago
  I’m an ML researcher, but did my grad work in systems. Here are several crucially important technologies invented since 1996 not mentioned in the article, which are fundamental underpinnings of the research community: - Jupyter notebooks, for teaching machine learning. I use these for teaching. - OpenCL and other libraries for running scientific simulations on GPUs, gpflow for training on GPUs - Keras and PyTorch (libraries for simple training of deep learning models). More than half of machine learning research exists on top of these libraries Let’s not even get into the myriad recent discoveries in ML and libraries for them. Parquet file format and similar formats for mass data storage. Spark and Hadoop for massive parallel computation. Hive and Athena further build upon these innovations. A good portion of distributed computing literature is built on these. Eventually consistent databases and NOSQL. There’s so much here, hard to list everything. ElasticSearch and Lucene and other such tools for text search. Then there is all the low level systems research: new file systems like BTRFS and ZFS. wire guard is something that’s just been built that seems foundational. I am running out of words but let’s conclude by saying the premise of this article is laughable
  • Jugurtha 6y ago
    >I’m an ML researcher, but did my grad work in systems. >- Jupyter notebooks, for teaching machine learning. I use these for teaching. - OpenCL and other libraries for running scientific simulations on GPUs, gpflow for training on GPUs - Keras and PyTorch (libraries for simple training of deep learning models). More than half of machine learning research exists on top of these libraries Would you share your usual workflow and the problems you face in that space with these tools?
    • SoylentOrange 6y ago
      I wish pip install automatically updated the requirements file like in some other languages. I look up some boilerplate in stack overflow every week for matplotlib figures to look better. CSVs generated in excel cause errors when reading in python without a special incantation. It’s not super easy to set up multi machine training. AWS GPUs are extremely expensive. sklearn models, once saved, are not easy to rework into a different format to be used with other languages. I wish python could do compile-time checking instead of running for 30 minutes to then report a type mismatch. mypy is still not very good and in beta
• dstanko 6y ago
  While everyone can have an opinion, not every opinion is valuable.
• roca 6y ago
  Rust is a huge omission from that list. Until about 5 years ago there was no safe, GC-free, practical systems programming language, and furthermore it was unknown how to build such a thing. Now we know.
  • Quenty 6y ago
    We’re also missing TypeScript and C#, both of which are quite popular.
  • fiddlerwoaroof 6y ago
    Ada is an example of this that everyone likes to ignore.
    • roca 6y ago
      No. Ada had no safe solution to dynamic memory deallocation until SPARK started supporting it, and ergonomic support for pointers in SPARK (borrowing) postdates Rust. Arguably we still don't have proof that SPARK is ergonomic enough for widespread adoption. (I dated Rust's breakthrough to five years ago because although Rust had the features well before then, it was only about five years ago that it became clear they were good enough for programmers to adopt at scale.)
  • curryhoward 6y ago
    > Until about 5 years ago there was no safe, GC-free, practical systems programming language, and furthermore it was unknown how to build such a thing. Now we know. It was known [1], but only by theorists, and theorists aren't the ones building compilers and implementing real programming languages. Obviously the Rust community has achieved an impressive feat of engineering, and I'm extremely grateful for that. But using a substructural type system to avoid needing a garbage collector is not a new idea, just one that Rust has successfully popularized. It takes a long time for ideas from the programming languages theory community to reach the mainstream. [1] http://www.cs.ioc.ee/ewscs/2010/mycroft/linear-2up.pdf http://www.cs.ioc.ee/ewscs/2010/mycroft/linear-2up.pdf
    • 6y ago
• bamboleo 6y ago
  I feel the same for the browser environment. Other than a few new “exciting” APIs and canvas, developing for the browser is essentially still the same deal. I’m tired of hacking documents into apps. I want the web to be split into Markdown-like web (i.e. pure content and some meta) and actual web apps that work like native apps. I want Accept: application/web
  • Jetrel 6y ago
    I mean, if you'd like to put it in perspective, try developing for IE6. You don't even have a dev console. I had a recent revelation when watching a video someone posted of a Symbolics Lisp machine, and its legendary dev environment. That being - it's basically just a modern browser devtools, but for the whole OS. Turtles all the way down. But somehow, despite having the bird in our hand, we as an industry lost them, and regressed to having vastly-inferior tools to those Symbolics devtools, and only gradually rebuilt them over the course of multiple decades. ------- As a harsh rebuttal to the OP article; I think the number one thing that's "whooshing" over that guy's head is that if someone develops a proof-of-concept for something, it doesn't invalidate the far-more-significant trick of making it widespread. Often it's the latter that's far more difficult, because it requires eliminating compromises that weren't acceptable to people before. The strange thing about the software industry these days is that quite a few "truisms" about software development have been completely invalidated. Ironclad laws of how the world works have slowly been rendered completely false, and it's happened not through some sudden eureka development but through some slow, sneaky, iterative improvement. The same sort of thing i.e. that made solar cheaper than coal, or made SSDs cheaper than HDDs (I don't know if we've actually crossed that line yet, but it seems pretty inevitable that once the investment impetus behind HDDs collapses, we'll eventually get there). Flatscreens versus CRTs was another great example.
    • infinite8s 6y ago
      What 'truisms' about software development do you think have been completely invalidated?
  • sime2009 6y ago
• Zac_ 6y ago
  The simplification of user experience has reduced the opportunity for many individuals to learn. In the 1980's many under achieving boys found the small rewards of computer programming addictive. This promoted self learning in a way that no longer happens.
  • barryhoodlum 6y ago
    Doesn't it? You can google "how to make iphone app" (or whatever) and get a wealth of videos, blog posts, guides, tutorials, github repositories. You can join online communities to learn and ask questions. You can download all the tools for free. My early days of programming were tinkering in BASIC and asking my parents to buy me "Learn C in 24 days" type books and hoping the compilers on the bundled CD would actually work. I had very few resources and had nobody to ask if I got stuck, except for other kids who didn't know much more than me. Seems a lot better now.
    • noodles_nomore 6y ago
      >I had very few resources and had nobody to ask if I got stuck That's exactly the self-learning experience. You had simple foundations that demanded to be explored and conquered. My first programming book was a ~700 page Java tome because that was the hot thing. After I had read it start to finish I realized that I still don't know what programming is. Then I read K&R and the scales fell from my eyes. Programming is so simple and elegant! The OOP approach of Java teaches you to just put the things you think of into classes, which is like being handed a blank piece of paper. C has an internal logic and an emergent structure of possibility because it reveals limitations. This is even more so the case for BASIC. Nowadays getting into programming seems far worse than 2000's Java. Everything is a library, everything is answered on Google, all the languages are feature-rich and opaque, any computer is fast enough for the worst code. Why bother if there is nowhere to go?
    • tonyedgecombe 6y ago
      The main restriction when I was starting out was the cost. Now pretty much any language you want to use is just a download away.
• swsieber 6y ago
  I think the general thrust of the article, that CS innovation is harder and less prolific than 1996 is generally true. I think it's a lot more nuanced than in the article though. Something not mentioned is that CS (and every field) has gotten larger with time, and the frontier for new discoveries and improvements is getting farther and farther away. Another thing is that while there aren't a lot of fundementally new things, much of our technological progress in the past 100 years is refinement on established things. > We’ve just lost the will to improve. That statement strikes me as a little to broad. We are less risky in our persuit of improvement is true, but I wouldn't say that we've lost it.
• Ericson2314 6y ago
  > Haskell in 1996 The good thing is Haskell keeps on changing. But yes on the whole the author is right and we should all feel embarrassed and indignant.
• jhunter1016 6y ago
  Start printing the red Make Software Great Again hats.
• deleted 6y ago
  [deleted]
• unnouinceput 6y ago
  Because we wait for quantum computers and true parallel programming languages. Until then that's what we do meanwhile "get rich and remix everything that is old on any new platform".
• bawolff 6y ago
  It seems pretty unfair to talk about early history of programming languages compared to last 25 years. I mean, Lisp and Agol were some of the first programming languages ever. Of course there is going to be lots of experimentation in different directions. The ecosystem then matures around a smaller number of solutions, and tries to improve them in depth instead of breadth. That's just the natural product development cycle Sure, we dont have a lot of new groundbreaking languages, but are you really going to tell me that haskell or javascript is the same now as it was in 1996. Would someone from 1996 even recognize it now? Their improvements are probably more unrecognizable to someone programming from 1996 in that language than go would be to a c programmer in 1996
• didibus 6y ago
  Would be nice for them to give examples of what they consider "real progress". Because the pre-1996 list: > LISP, Algol, Basic, APL, Unix, C, Oracle, Smalltalk, Windows, C++, LabView, HyperCard, Mathematica, Haskell, WWW, Python, Mosaic, Java, JavaScript, Ruby, Flash, Postgress Seems just as "weak" as the list they give after 1966: > IntelliJ, Eclipse, ASP, Spring, Rails, Scala, AWS, Clojure, Heroku, V8, Go, React, Docker, Kubernetes, Wasm Basically, after LISP and Algol everything was just a small incremental change over them, some might even say a step back. From the way they phrase "progress", it seems the lineage would look like: Machine Code -> Assembly -> Fortran -> Lisp -> Algol That takes us back to 1958 then, not 1996. I could agree more if that was the argument. That since Lisp and Algol, nothing new in programming language really came out. And if making that argument, the hypothesis around why would be very different. Like it seems it might be more because Software just quickly got bootstrapped and then we did reach a sort maximum with it.
  • pjmlp 6y ago
    Yes, it is also specially sad that the first almost memory safe systems language ESPOL, later replaced by NEWP still in use to this day in Unysis ClearPath MCP, dates back to 1961 and here we are trying to fix C, created 10 years later.
    • jacquesm 6y ago
      I thought we gave up on trying to fix C?
      • pjmlp 6y ago
        Companies like Microsoft and Google still believe that while POSIX is around, C needs some fixing as rewriting everything is too expensive. "Checked C" https://www.microsoft.com/en-us/research/project/checked-c/ https://www.microsoft.com/en-us/research/project/checked-c/ https://www.youtube.com/watch?v=EuxAzvtX9CI https://www.youtube.com/watch?v=EuxAzvtX9CI "Improving Your Android App to Prevent Security Vulnerabilities" https://www.youtube.com/watch?v=zkoOD4hmiGE https://www.youtube.com/watch?v=zkoOD4hmiGE
  • 6y ago
• 29athrowaway 6y ago
  If you think there have not been significant achievements since 1996 then you are not looking in the right places. Then why just look at 1996? The Mother of All Demos by Douglas Engelbart (1968) probably had all the cool stuff anyways: graphical interfaces, videoconferences, collaborative editing, word processing, hypertext... A lot has been done since 1996. Could we have done more? sure. Computers have way more potential than what we use them for.
• jrockway 6y ago
  I think this is just a sign that the field is mature. You could take someone from the 1800s and show them today's machine shop, and they would basically know what the tools do -- lathes, mills, micrometers -- but we're making pretty complicated things with them today. It's just that "the past" came up with pretty good tools and we're still using them. In 1996, I'm not sure everyone was carrying around a super computer with a multi-day battery life that could shoot slow-motion 4k video and understand your speech. And yet, today we don't even think twice about that. Clearly something has happened in the past 25 years.
  • veddox 6y ago
    Absolutely. It strikes me that his understanding of (and certainly his appreciation for) the history of technology is quite limited if he expects ad infinitum exponential development.
• indymike 6y ago
  Since I started coding professionally in 1987, I've had to re-tool myself four times: * In 1989, to learn to write GUI apps on Windows. * In 1998, to learn to write web applications. * In 2008, to learn to write mobile applications. * In 2014, to learn to write cloud applications. In the next year, I'll start retooling to write AI applications. I think there's a remarkable rhythm to innovation, and it seems to be getting faster, not slower.
• Edmond 6y ago
  I think the author has a point, perhaps poorly articulated. There is obviously a large universe of software out there so broadly speaking a lot of innovation has happened since and continues. However, there is a general crappiness around software innovation (or the lack thereof) these days that hides behind "sexy" CLI tools with a few "sexy" options. Some of these tools are very popular and can be difficult to assail but the smell of mediocrity (or lack of ambition) around them is hard to shake off. A comment left on the post does in fact hit on one of the reasons: the lack of interest in creating user empowerment technology. The obsession with CLI tools for instance is framed as simply facilitating better integration, while this is true, it is also a convenient excuse to avoid the difficult task of building user interfacing software.
• erichanson 6y ago
  Not a lot of support for his sentiments here it seems, but to understand where he's coming from you probably need to see the research he has been doing, largely aimed at entirely different modes of programming -- visualizing boolean logic trees and all kinds of other stuff, aimed at making programming more accessible and concrete to regular people. You know in the movies where they have the futuristic user interfaces? Well we've been able to put graphics on the screen for decades, but "real" enterprise programming is still mostly pounding keys into text files and fussing over semicolons and curly braces. Visual interfaces are considered toys that "real" programmers don't need. And yet there's a chasm of capability between programmers and users, and it's actually true that what programmers do isn't something most "normal people" will ever be capable of. But is that because programmers have some wildly special form of intelligence that most people don't have, or is it because our tools suck? The divide between users and developers is as accepted and entrenched as it is archaic, not to mention a huge innovation and creativity bottleneck for the species, and by my estimation an embarrassing failure to innovate for our industry. Jonathan has been pushing back for decades. He's not grumpy or cynical, he's a relic from a time when the future of programming and "what programming even looks like" was still a wildly open question. I wish more people thought like him.
  • mixedCase 6y ago
    What are your thoughts on the overrepresentation of people in the spectrum in tech? I think there's a very specific mindset (or "form of intelligence" per your words) that thrives working on a complex sandbox with very rigid rules and low tolerance for logical inconsistency, while most people simply have no tolerance for such inflexibility. And I think there's no tooling that can change that, and if there ever is there goes programming as an industry because it will be able to interpret loosely defined requirements, ask the right questions and find a logical solution to it.
    • erichanson 6y ago
      Yeah I think it takes a special mind to use today's dev environment, but the distance from where we are today, to an interrogative system creator (which is a pretty cool idea btw) is eons; there has to be something more in the middle. I think it's always going to take someone with a systems-thinking mind to engineer a system that's any good, but lots of people have that, people who created their own business and thought through all the steps in their system and engineered the whole thing in their head. That's systems engineering, just not with code. But there's so much knowledge that's required to go from zero to custom software deployment that I'd characterize as non-essential complexity, today. Yeah I think programmers tend to make tools for programmers, for themselves and the way they think, which is totally natural and to be expected. But man these poor users. It's not so bad when they're using mainstream programs with millions of dollars in dev budgets behind them, but when you get further down the long-tail it just gets so awful and users are so helpless. The software an insurance agent uses, the charting app a therapist uses, the in-house warehouse management system people spend their entire day using, where if they could just make this field auto-focus or a million tiny other things, they would save so much time and frustration. Generally speaking, users edit data and programmers edit schema, and never the two shall cross. Users execute code but only programmers change it. What hope do we have of democratizing programming when these roles are about as foundational to computers as it gets? What would we have to unlearn to change this?
• corysama 6y ago
  Lots of cynic-cynics in here :) I'll stand up for the author. The lists in the article are not great, but I still agree with the sentiment. I recommend everyone watch Bret Victor's classic "The Future of Programming" https://www.youtube.com/watch?v=8pTEmbeENF4 https://www.youtube.com/watch?v=8pTEmbeENF4 Yes, we've had a trillion dollars invested in "How to run database servers at scale". And, we've had some incremental improvements to the C++ish language ecosystem. We've effectively replaced Perl with Python. That's nice. Deep Learning has been a major invention. Probably the most revolutionary I can think of in the past couple decades. But, what do I do in Visual Studio 2019 that is fundamentally different than what I was doing in Borland Turbo Pascal back on my old 286? C++20 is more powerful. Intellisense is nice. Edit-and-continue worked 20 years ago and most programmers still don't use it. If you are super awesome, you might use a reversible debugger. That's still fringe science these days. There is glacial momentum in the programming community. A lot of "grep and loose, flat ASCII files were good enough for my grandpappy. I can't accept anything different" And, so we don't have code-as-database. A lot of "I grew up learning how to parse curly bracket blocks. So, I can't accept anything different". So, so many languages try to look like C and are mostly flavors of the same procedural-OO-bit-of-functional paradigm. A lot of "GDB is terrible, don't even try" so many programmers are in reverse-stockholm system where they have convinced themselves debuggers are unnecessary and debugging is just fundamentally slow and painful. So, we don't have in-process information flow visualization. And, so on.
  • jcranmer 6y ago
    > There is glacial momentum in the programming community. A lot of "grep and loose, flat ASCII files were good enough for my grandpappy. I can't accept anything different" And, so we don't have code-as-database. A lot of "I grew up learning how to parse curly bracket blocks. So, I can't accept anything different". So, so many languages try to look like C and are mostly flavors of the same procedural-OO-bit-of-functional paradigm. We actually have tried several times to build programming languages that break out of the textual programming style that we use. Visual programming languages exist, and there's a massive list of them on Wikipedia. However, they don't appear to actually be superior to regular old textual programming languages.
• chrismsimpson 6y ago
  Only if you don’t count several major technology families (.NET, Swift etc)
• deleted 6y ago
  [deleted]
• decker 6y ago
  The author does a really poor job of providing evidence for why 1996 happens to be the date for "the end of progress" in software. Why not 1995, 1994, 1993, or the years before that? This sounds more like someone who went into the field in the 80's and now they are grumpy that the world cares about a completely different set of concerns than what was important back then.
  • noobermin 6y ago
    bingo
• lincpa 6y ago
  It isn't stagnation! The Grand Unified Programming Theory: The Pure Function Pipeline Data Flow with Warehouse/Workshop Model https://github.com/linpengcheng/PurefunctionPipelineDataflow https://github.com/linpengcheng/PurefunctionPipelineDataflow
• carapace 6y ago
  Context matters to grok what he's saying. Read up on his "Subtext", go watch Engelbart's "Mother of all Demos", read Nelson's "Dream Machines". We are living in a shadow world compared to what might be... http://www.subtext-lang.org/ http://www.subtext-lang.org/ https://en.wikipedia.org/wiki/The_Mother_of_All_Demos https://en.wikipedia.org/wiki/The_Mother_of_All_Demos https://computerlibbook.com/ https://computerlibbook.com/
• lazylizard 6y ago
  and we're still using ipv4.
• kvirani 6y ago
  The one big progression is that application development is becoming more democtritized. And maybe this time the "nocode" / "lowcode" meta apps will stick...
  • elliotec 6y ago
    Naw. Recently tried some again. Not gonna name names. I was so immediately blocked by lack of flexibility I just went back to code before going deeper into the sunk cost fallacy. It seems like these no/lowcode things need to approach the "problem" differently. I don't have the solution, I just know theirs isn't working for me.
• EVa5I7bHFq9mnYK 6y ago
  Right. Computer architecture hasn't evolved since von Neumann. Operating systems - since Ken Thompson. Programming languages actually devolved from Lisp and C to JavaScript. The only fundamental improvement I can see is proliferation of GPUs, but it's still only marginal.
• betimsl 6y ago
  >But maybe I’m imaging things. You're not. You just don't know enough.
• based2 6y ago
  It is a discontinuous improvement: https://en.wikipedia.org/wiki/SPARK_(programming_language) https://en.wikipedia.org/wiki/SPARK_(programming_language) https://www.rust-lang.org/ https://www.rust-lang.org/ https://github.com/microsoft/verona/blob/master/docs/faq.md https://github.com/microsoft/verona/blob/master/docs/faq.md https://plantuml.com https://plantuml.com https://en.wikipedia.org/wiki/Infrastructure_as_code https://en.wikipedia.org/wiki/Infrastructure_as_code
• lordnacho 6y ago
  Well of course it's true that once a field gets to a moderate size, someone's been everywhere before. This comment section is littered with "ah but X looked at this in the 1980s". What seems to have happened since the 90s is we have a lot of ergonomic improvements, which are still valuable. Want to run something in a cloud in 1995? Yes, you can do it, but it's vastly simpler and cheaper to do in 2020. In the end the major things that have changed are that computing power got much cheaper, and computing has become part of a vast number of businesses. That's why a fashion retailer can now click some buttons and make a website. Or why there's an AI that can beat everyone at StarCraft II.
• ricardolopes 6y ago
  Missing from the post-1996 list: bitcoin, which solved the byzantine generals problem without trusted third parties and gave us the first permissionless digital currency, along with all the innovation in the crypto space, such as zk-SNARKs, IPFS and so on.
  • sime2009 6y ago
    As someone living and working in a developed western country, and someone who works in IT, I can't think of a single change or thing Bitcoin or blockchain tech has brought with it. The only difference I see is contained to the headlines of discussion sites like HN and Reddit. Zero impact.
• TheOtherHobbes 6y ago
  Tactile pocket computing - iPhone, etc - was a huge paradigm shift for users. The UX as a whole is completely different to the desktop experience. In terms of software itself - it's not about typing code or about text UIs vs graphic UIs. It's about programming being a fiddly and tedious pastime with explicit handling of every possible scenario, because the machine has no contextual background knowledge and isn't intelligent enough to interpolate or intuit the required details for itself. So you get modern software which is basically just a warehouse full of virtual forms glued together with if/then/else - or simple pattern matching if you're really lucky - managed by relatively simple automation pipelines. Plus a UI/API glued on top. And underneath that is TinkerLand, full of lovely text-langs which are different-but-increasingly-similar and command line environments which are like little puzzles which are not really hard - in the sense of Physics PhD hard - but are hard enough to give people who enjoy tinkering a sense of satisfaction when they (more or less) solve one. You can do a lot with this - like ordering goods and services, selling advertising, collecting creepy amounts of data about users, and keeping people entertained. But it's basically just automated virtual bureaucracy. It has no independent goal seeking skills, it doesn't improvise, invent, or adapt, and it's ridiculously brittle and not particularly secure. Visual programming won't change this. Nor will ML (although it may contribute.) It needs a complete change of metaphor, and there doesn't seem to be much evidence of the research required to make that happen.
  • fsloth 6y ago
    I think you managed to succinctly verbalize and create concrete form to what I've felt. Especially the "faux-value-add" quality of many software systems due to their puzzle like nature rings very true. Perhaps software cannot be nothing more. But there is lots that _can_ be done with virtual bureaucracy. For example 3D modelling tools do enhance the human capability to rapidly design complex forms. Text processing tools beat hands down typewriter in several tasks. Etc.
  • Roritharr 6y ago
    "automated virtual bureaucracy" Oh boy you hit the nail so hard on the head that my spine is still tingling. In the past 15 years of my career writing business applications, websites etc. I always had this nagging doubt that this is just me being a very active part in building moloch, adding to all the bureaucracy instead of reducing/simplifying it. Simply because wherever we built something to make things more efficient/easier, those gains are usually swallowed and overshadowed by the demand for more complexity that arises from latent potential that has been opened up. "we've made taxes easy!" "...could you also make tax evasion easy?" "yes, but it would be more complicated" "More complicated than before you were there?" This is just an made-up example but that's how it so often goes and it really makes it feel like I should have become a hermit and wrote indie-games while living on cupnoodles instead.
• deleted 6y ago
  [deleted]
• noobermin 6y ago
  On the one hand, I can no longer compiler programs that were written ten years ago due to conflicts and library deprecations, but somehow I am supposed to be bothered that we have "30 year old text editors, and 25 year old languages." I don't care, I want things to work and I don't want to have to make a job out of learning flavor of the week things to make things that worked fine 10 years ago work today. Truly one of the worst attitudes in technology, the desire for novelty is so inline with how unsustainable and ephemeral tech is.
  • jacquesm 6y ago
    Absolutely. My take on this is that we got too much too soon to learn how to use it all properly so now we are super inefficient with hardware that could do so much more.
• birdyrooster 6y ago
  I think what the author misses is that the web has created a market for software developers and so many, many, many software developers have come online and with each successive wave the average expertise goes down and the expectation for simple interfaces goes up. We simply need to wait for people to adopt software development practices, it’s not over, we have slowed down to catch up all of the people joining.
• unixhero 6y ago
  Strangely fails to mention Rust, Julia, Octave, RakuPerl6. Maybe what he is really trying to say is that he is disappointed in the few new paradigms that are coming out.
• sriku 6y ago
  Nitpick on the start - Haskell really got going only with Haskell '98 afaik.
• hyperpallium2 6y ago
  The top answer to Alan Kay's question on SO Significant new inventions in computing since 1980 innovation https://stackoverflow.com/questions/432922/significant-new-inventions-in-computing-since-1980 https://stackoverflow.com/questions/432922/significant-new-i... is the Web. And TFA argues the Web caused innovation to be pushed out by adoption and application aka solving actual people's problems aka money. So that fits. [ TFA's date of 1996 just freezes the surface tech that got swept into power by the web, e.g. Java was deliberately not innovative, but a "blue-collar language". ] Of course, it is possible that all the foundational stuff has already been done. It happened to physics, why not us?
• jcelerier 6y ago
  > No technology has ever been permanent. We’ve just lost the will to improve. except wheel, fire, clothes, writing... some things appear and won't ever disappear - and the longer things are there, the harder any chance they have for disappearing.
• mikewarot 6y ago
  At the end of 1996 we had ASP - Active Server Pages, VB4, and Delphi 2. Those took a bit more time to mature, but I agree with what he says, in terms of the desktop.
• deleted 6y ago
  [deleted]
• pfdietz 6y ago
  Never mind languages... how has the size of software evolved since 1996? Are we now delivering larger programs faster? I think we are. This came to mind because of a quote I came across the other day, in a paper from 1980: "Interlisp is a very large software system and large software systems are not easy to construct. Interlisp-D has on the order of 17,000 lines of Lisp code, 6,000 lines of Bcpl, and 4,000 lines of microcode." ("Interlisp-D: Overview and Status", at http://www.softwarepreservation.net/projects/LISP/interlisp-d/Papers_On_Interlisp-D.pdf http://www.softwarepreservation.net/projects/LISP/interlisp-... )
• jwr 6y ago
  I'd consider Clojure a good iterative development of Lisp(s) — for me, this is when using Lisp became really practical for large-scale app development, both for server-side code and client-side code. As a specific example of a huge advancement, the ability to share most of your data model code between your servers and client browsers is fantastic.
  • mac01021 6y ago
    It was probably actually _more_ common to share data model code between a client and server before the web, because the clients wouldn't have been JS running in a browser but more likely would have been written in the same language as the server.
    • api 6y ago
      This is absolutely true, and the model was also usually one of fatter clients and thinner servers. In some cases the server was just a database.
    • jwr 6y ago
      Not sure if you're speaking from experience here, but the systems I worked with (IBM S/370 with VM/SP and 3270 terminals, various UNIX systems with VT100 terminals, UNIX systems with X11 terminals) didn't run much on the client side. Well, unless you consider the "rich" 3270 experience to be "client-side computing". I guess technically an X terminal does run code, too. Client-side computing in my world started happening with Novell Netware systems (IPX). Not a big fan of that period, to be honest.
• imtringued 6y ago
  The author doesn't appear to care about the impact of technology, merely its existence.
• davidthewatson 6y ago
  With a tip of the hat to Alan Kay, it's not that great leaps haven't happened since 1996 (or 1980). It's that those things were not part of the story until they were subsumed by the pop culture: https://news.ycombinator.com/item?id=4956430 https://news.ycombinator.com/item?id=4956430
• k__ 6y ago
  Reminds me of a friend in 2001. He said my idea to become a dev was dumb and the money was in being an admin. His reasoning was, he already had every software he needed. Emule, Kazaa, ICQ, mIRC, Teamspeak these apps did all he wanted to do, so why would anyone pay money to develop new software?
• randomsearch 6y ago
  I kinda have a bias that wants to agree with the author but _almost the entirety of quantum computing_ has been developed since 1996 - including the theory and building the things - which is such a ridiculously humongous exception that there’s little point taking this article seriously.
• microtherion 6y ago
  To pick only one example from the list, C++ as written in 1996 was massively different from how most people (except for the Trogoglyte C++ movement or whatever they call themselves this week) write it nowadays. At the time, it was risky to write code relying on the STL because support for it (especially the template mechanisms required to support it) was quite uneven across compilers. Truly avant garde programmers were just starting to incorporate design patterns (and, of course, overdoing it). It's hard to overstate how much STL based containers changed C++ code. And C++11 caused quite a bit more change.
• juancn 6y ago
  What all the deep-learning derived advances since 2010? We can do things today that we couldn't dream of in 1996. Think image search on your phone, or auto close captioning, speech to text, etc. Heck, at that time, Netflix was theoretically impossible, it wasn't until the h264/mp4 codecs became available that this changed. Even the cloud technologies completely changed the scale at which a single or few developers can scale software. We no longer need big iron (and the capital expenditure that goes with it) to go big. We've seen plenty of breakthroughs in the past 25 years, some have not materialized fully yet, others are so magical and unobtrusive that it's hard to notice them.
• victorronin 6y ago
  I heard this narrative before. Three thoughts: - People concentrate on the tool (technology) vs. goal (value) Let say you need to handle a million users in the past (read: "provide value to million users"). It would be an unbelievably huge effort back in 1996, requiring _A LOT_ of logistics. For most companies, it would take years to reach out to these million users. And god forbid you to need to send out an update. Fast track to 2021. One person can put the code in a docker, drop it in AWS Kubernetes, scale it up and be able to serve million users by the end of the day. (BTW. I am not saying that you don't need to do marketing/sales and so on, but purely engineering/distribution end up being way simpler). Oh... BTW. All these people can use this new service on the go, because everybody has a computer in his pocket with access to the internet. And get update to it pretty much instantaniously. I don't care that a new language has curly brackets or a new programming paradigm invented each year or once a decade. I care how much value could be created. And tools/languages/frameworks/infrastructure in 2021 provides a way to build way-way more value - You don't need to improve a hammer that much The first hammers date back ~3 millions year ago. There were relatively few improvements to it for a looong time. The idea is still the same (a heavy head and a long arm). If the tool works well, you don't need to reinvent it that much. You invent other, more complex, and specialized tools. - Ignoring real achievements There were dozens of things mentioned here in this thread, which wasn't mentioned in OP (LLVM, Mobile, ML, and dozens and dozens of others).