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.
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.
> 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?
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.
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).
It is not all about the capacity of the software. If software has been around for a long time, people can gather experience about how to use it. Longstanding software in the hands of someone very familiar with it, will use it like a simple, comfortable, reliable tool. That has huge value to the individuals who use it.
They know they are blind to potentially better products, but they no longer have the time to gather the experience and confidence in the new products.
Put everything in the database! Directories are dumb, the world is not a tree it's a graph. Files are dumb, they don't have constraints or decent metadata. Syntax is latent structure. Config files are just a featureless database. Stop it! Code wants to be data. (shameful self-plug: aquameta.org)
I'm somewhat peeved by his "No technology has ever been permanent" statement. Compared to most human technologies, 25 years is not exactly what you'd call a grandfatherly age...
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.
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.
> 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).
> 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.
Not OP but eBPF, Android ( phone, TV, auto) and iOS, ChromeOS, VS Code, Go, Swift, Powershell ( it's a terrible piece of software but a vast improvement for Windows), virtualisation, public cloud platforms ( virtualisation at huge scale with APIs), the Hashicorp stack, ZFS, LXC and later Docker, Kubernetes, Redis.
What you think of hardware innovations are often actually software innovations. Your iPhone doesn’t take a better picture because it has a better lens this year - it does because it has better software.
To me it reads as bitterness about the uptake of his personal project, which he would presumably class with the cool tech from before '96. Some of the copy on that project's page has a similar feel to this blog post:
> Some people just want to find negativity in the world
Are you kidding? The author has (clearly) been dedicating his entire career to trying to solve these problems. He's not some drive-by hipster reminiscing about the good old days. The problem is that in a lot of ways programming is stuck in the "good old days"
I'm going to take a wiiiiild guess here that the author's personal peak was around 1996.
It's just a reaction to 'the kids' coming after him not being up to how good he (mis) remembers the past.
This negativity is a disappointing and growing trend among some grumpy old men in our field as that generation approach retirement. It disrespects people working today and I don't like it.
>This negativity is a disappointing and growing trend among some grumpy old men in our field as that generation approach retirement. It disrespects people working today and I don't like it.
Your contributions thus far in this thread have been negative with no substantive rebuttal to any points made in the article.
> All of these latter technologies are useful incremental improvements on top of the foundational technologies that came before.
As if that wasn’t the case before. We’ve always built on what came before. What on earth does the author think was so revolutionary about Java? The language was an evolution of the C family. The VM was an evolution of Strongtalk.
The negative person says ‘all done before.’ The reasonable person says ‘step forward’ as we’ve been doing ever since.
And what’s the implication? That people have become stupid or lazy or ignorant? This is an attack on the work and integrity of a generation of people.
There is a consistent claim at the moment from CS men of a certain age that we don’t appreciate their genius enough. They bang on about how under appreciated their ideas are at their invited talks and on Twitter. I don’t think I’m the only one in the community thinking this. I think quite a lot of people feel this.
It’s not negative to call out someone else’s negativity.
>It’s not negative to call out someone else’s negativity.
That's not what I was referring to. I was referring to the actual negative statements you made about the author:
>Some people just want to find negativity in the world.
>I'm going to take a wiiiiild guess here that the author's personal peak was around 1996.
>It's just a reaction to 'the kids' coming after him not being up to how good he (mis) remembers the past.
>This negativity is a disappointing and growing trend among some grumpy old men in our field as that generation approach retirement.
That's not "calling out" negativity. That's a list of snark, broad insult, and generalizations with no supporting information. It's rude, discriminatory, and serves only to diminish the overall quality of discussion.
> Since 1996 almost everything has been cleverly repackaging and re-engineering prior inventions
seems like an ignorant attack on thousands of people’s professional competence and a veiled insinuation of deceit (the ‘clever repackaging and re-engineering’) and
> Suddenly, for the first time ever, programmers could get rich quick
sounds like a moral attack. All in all it’s a shitty thing to say to people. And there’s more and more grumpy people trying to tell young computer science researchers today that they’re useless and have no new ideas like this.
Have you been to a CS conference recently? You may be missing the context that these people are everywhere criticising everyone for not being as innovative as they remember they were.
As I get older myself, this brand of cynicism seems to be a projection of death anxiety or possibly the "loss of innocence" where grand visions of how the world ought to be were not met.
1996 was 24 years ago. You are totally correct that the progress and change in this period has been incredible on the historical scale. But 24 years on the timeline of a human life is quite a significant portion, and some may feel that their expectations of futuristic utopia have been subverted, making them cynical.
>> some may feel that their expectations of futuristic utopia have been subverted, making them cynical.
i know i do!
lot's of stuff about the future sucks, and i can't think of a way to fix anything important with faster garbage collection or better type systems... maybe that's the difference between makers and cynics. i guess i'll try harder :p
> and i can't think of a way to fix anything important with faster garbage collection or better type systems
I can, I am very hopeful better type systems will help heal the absolutely dreadful state of software robustness.
Better types (and by extension, better type systems) help eliminate many costly tests, improves knowledge transfer from senior engineers to junior engineers, makes refactoring and adapting to changing requirements a much less error-prone process where the computer can guide you, provides a more rigid way of breaking down problems into chunks instead of a procedural approach where good boundaries are harder to intuitively determine.
While education is what enables people to write better code with them, we need better type systems and languages that make this process easier for the average programmer to learn and use. Already languages like TypeScript, Kotlin and Swift are slowly getting many people to take a gander over the brick wall by exposing them to constructs like sum types and specific patterns like optionals and either/result types, that should fuel a little bit of hope at least!
EDIT: That's some visceral reaction. Would be nice to see some disagreement stated in text, or if any particular point needs further explaining, or to see if just hope of things improving is what's angering people.
heh, well, by "important" i meant like freedom, justice, and the continued existence of humanity. but like i was saying up-thread, i think software quality is important, and in that sense, ubiquitous and accessible type safety definitely seems like a Good Thing. i guess they might even help keep us out of trouble in those "important" areas.
I see (at least) two technological trends that may strongly influence "important" problems and that may be interesting to compare:
"3d-printification" or democratisation of manufacturing capabilities. When advanced manufacturing become cheap, generic and small scale you need less capital to create and design important hardware.
"UX-ification" of advanced programming practices or democratisation of software creation capabilities. When advanced software design, composition and implementation becomes cheap, generic and scalable you need less capital to create/design/implement software and to be in control of the software you want/need.
When those things come together the importance of capital will greatly diminish for some vital parts of life. It will not solve all problems but some. And maybe create other problems. But it should at the very least greatly impact "important" problems.
The "UX-ification" of software creation is the part where software engineers can be part of.
Disclaimer: Perhaps I have a naive assumption underlying all this - the idea that increased flexibility eventually "will lead" to apparent simplicity. But isn't living organisms kind of a proof of this? The amount of complexity that an animal needs to understand to continue living and reproduce is dwarfed by the complexity of the animal itself. Well, also cars and computers.
The problem is that, while improved development technology does raise the floor, it also raises the ceiling, so equality don’t improve.
Some of us could host 2005 YouTube out of pocket, but it’s 2020, and people with fast connections expect 1080p video now, so it remains impossible for individuals to compete with corporations.
Yeah, that's a good point. I kind of expect that the ceiling should pop off at some point though. But I can't make a good argument for that.
Like, will it always make sense to add things to YouTube or will a more decentralised approach make more sense? Will single responsibility principle make sense at that scale? Can infrastructure costs be shifted around in flexible ways? Etc.
But yeah it's telling that Facebook was initially looking for a much more decentralised approach but gave up on it when adapting to reality and economics.
Author failed to mention the ML ecosystem, which has made significant improvements to products used by real people every day. A number of items on their cool/before 1996 list seem to serve little practical purpose. Which is cool, but it does lead to the question of by what metric we're judging a technology's importance.
I would consider the advances in ML to be mainly mathematical and hardware rather than software. Being able to write the libraries to support ML operations wouldn't have been a problem in 1996 if the hardware & theory had existed.
What software do we have the theory, hardware, and use for, which hasn't been written? I guess I'm struggling to identify a useful delineation between these categories.
Realistically yes, but as a kid promised flying cars and off-world colonies it's less impressive. Blade Runner is now set in the past shrug. These are mostly hardware I suppose.
Instead we got social networking, ad tech, and surveillance capitalism.
Meh, people always bring up the "flying cars" bit but I'm going to call bullshit that these were ever really feasible, not from a tech perspective but from an economic, energy and safety perspective.
The tech for flying cars already exists, just not the tech for protecting people on the ground from flying car crashes.
This article is just the IT equivalent of 'no good music gets made today' and so on. It's a combination of nostalgia and advancing age, the observation he's making is really no different. I remember software in 1996 too, and most of it really sucked. If you want to relive the 90s experience just go use some Oracle or IBM software. That will show you true stagnation.
What's so impressive about V8? that billions of dollars have being pour into it to make it fast? for a problem that shouldn't have existed in the first place?
In the grand scheme of things, there is nothing impressive about V8 - it’s just a really good interpreter. Every technology we have today could be easily programmed in pre-1996 languages, they haven’t unlocked anything not possible before. We even use the exact same tooling. That is the stagnation.
> 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.
But these things were not driven by software innovations.
Having been an engineer in 1996. Really nothing wasn't foreseen by anyone with a feel for how things were going.
In 1996 a friend was dating an engineer with an electric car. She'd thrown a bunch of time and money into it. Had a range of about 80-90 miles and wasn't slow at all.
Around then there was skunks works a couple of buildings away from me. On the spectrum analyzer I could see spread spectrum signals showing up at 900 and 2.4GHZ.
>> If an engineer in 1996 fell into a coma and woke up today, they'd be greeted with an entirely different world.
i was little and didn't know shit, but i was already learning to program, and i think about this all the time. like mind blown, every day. 8 threads and 2GB of ram in my cheap ass phone? crazy! and we got so good at writing compilers they give them away for free!
JS was way slow because MSIE wasn't supposed to compete with desktop apps :p also, transpilation, JIT, virtualization and containers seem like a pretty big deal to me -- virtualization was academic in the 90's.
also, a lot of that "old" stuff like python and ruby and even C++ really weren't as mature and feature-full. memory safety/auto-management and concurrency language features are prevalent now, and i think people don't always appreciate (or remember?) when your computer couldn't walk and chew gum at the same time.
it seems to me like our tools have clearly improved -- i think a more useful conversation could investigate how to apply what we now have to improving productivity, safety and security.
Virtualization isn't that recent. It at least goes back to the 60's with the IBM 360 mainframe.
For micros, it has been available, in some form, on x86 since 1985 when the 386 processor was first released. Remember the vm86 mode that let people run DOS apps under Windows 2.x?
> Remember the vm86 mode that let people run DOS apps under Windows 2.x?
That's not really virtualization. In the x86 world, hardware virtualization extensions don't crop up until 2003. Efficient dynamic binary translation (a key component for efficient virtualization without hardware support) I generally reckon to start with DynamoRIO (~2001), with Intel's Pin tool coming out in 2004.
(Do note that hardware virtualization does predate x86; I believe IBM 360 was the first one to have support for it, but I'm really bad with dates for processor milestones).
Just a data point. VMware Workstation came out as a product in 1999, and did excellent x86 virtualisation without hardware support using dynamic translation and code scanning techniques.
I agree it is generally not what people consider virtualization today, but it was still a form of early virtualization. It was amazing for the time, letting people run most of their DOS apps under Windows 386.
(Note VMware Workstation, as another poster pointed out, and even earlier "emulation" solutions like Bochs existed before 2003.)
The great inventions do not look to be incremental because they are presented that way. Personally I find it fascinating to burst that bubble by looking into the rare histories of what lead up to what are considered the great tentpole developments.
I really think everything is incremental in progress. Where things are closer to us, we can see the incremental steps. Where we think of the great things of the past, we are completely ignorant of the incremental steps that came before.
They are nothing new. Just re-iterations and refinements. Incremental innovation is no real innovation. True innovation is destructive, removes whole fields from the map, while creating new ones.
I don't like being called a coward, even if the words wrapped in velvet, but in this case the truth sticks.
PS: Machine learning is old too, although application - again due to incremental hardware improvement, has finally arrived.
I totally agree with you. But, just as an anecdote on the other side, I recently did some Blender tutorials, the famous donut scene by Andrew Price. When I was done I was happy I learned Blender better but I was also disappointed that making 3D hasn't changed much since 1995. In 1995 I learned PowerAnimator (predecessor to Maya) and in 1996 I learned 3DSMax. The techniques used to build the scenes are exactly the same, still super tedious. What changed is better renderers, sculpting (z-brush), but not much else.
Devil's advocate here but I sort of agree. I think that all of the hard problems with computers will continue to be hard problems until some groundbreaking new computing is discovered (quantum?). All of these technologies are mere transformations with the same hard problems with computing still present underneath.
A lot of these are also fads that will pass. Are there any problems today that were unsolvable in 1980 given enough time?
Wow, smaller transistors, more clock cycles, big whoop. We have more now but it's not fundamentally different is it?
>If an engineer in 1996 fell into a coma and woke up today, they'd be greeted with an entirely different world.
I'd also be disappointed. Oh we are on DDR4, Windows 10, multiple cores, cpp 20? Ok. So we basically just extended the trendline 25 years. Boring.
Yeah, lots of progress being made left and right: huge improvements in image processing and recognition, SLAM in every cleaning robot (and we have cleaning robots!), much improved machine translation, much better voice recognition and transcription, ubiquitous video conferencing software, super complex virtual worlds accessible to anyone and also most of what was desktop only now also available on mobile devices, which was far from a small task to achieve.
My guess is that the author is comparing the rate of change from 1971-1996 to 1996-2021 (25 years each), but didn't do a good job with explaining that.
In which case software has "stalled" in terms of "invent anything fundamentally new " - and I'd agree.
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.
> 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.
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.
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.
> 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 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.
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.
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.
> 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.
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.
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.
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.
> 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.
I get that programming languages are designed by committee and every decision is thought out, but that still makes some things arbitrary to whatever they decided. It really is arbitrary that a for loops is done like this in python:
for val in sequence:
print(val)
and this in R:
for (val in sequence)
{
print(val)
}
and this in bash:
for val in sequence; do echo val; done
I mean there was no paper that I can find that found curly braces to be especially drawing to the human eye or anything like that. or that it's particularly intuitive to write "do" and "done" or not. For loops look like no linguistical sentence structure that I recognize, they are pretty much their own thing structurally imo. These are all arbitrary decisions decided by people, because it just happened to make arbitrary sense at the time for any number of reasons. Not because the R core team ran some psychological experiments to empirically determine the most intuitive for loop structure when they drafted their language; that data has never been collected, the R core team just followed what the S team had already done and that's that. Arbitrary.
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).
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"
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.
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.
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.
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.
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.
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.
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.
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.
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!
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.
Yeah. Sure, there were service-based architectures (SOA), some automated testing (so CI/CD I guess), containers have been around forever (BSD jails and then Solaris Zones), configuration management, etc., etc. But all of those things are vastly different than they were 25 years ago. [EDIT: Not 15. Can't do math this morning. Though even 15 is pre-iPhone/most mobile.]
This is an "Oh, the cloud is just timesharing" take.
Generally in agreement with most of this (and others takes that are similar).
Except that Linux containers are a huge regression on what BSD jails gave us 20 years ago. They’re catching up for sure, but it’s still just badly reinventing a wheel that already exists, for philosophical, political, or selfish reasons.
Yeah; but thats all so incremental. Better compiler error messages? Really? That makes the top 10 list from 25 years of work?
Async/await matters. But compared to inventions like threading, filesystems, java's write-once run anywhere, HTTP/HTML and the invention of the URL? I agree with the author. We've lost our mojo.
Computing is pretty unique in that we have near-complete freedom to define what a program even is. A sorting method implemented in haskell is a different sort of expression than the same idea implemented in C. The abstractions we all take for granted - processes, applications, RAM & disks, databases, etc - all this stuff has been invented. None of these ideas are inherent to computing. And yet apparently we only know how to make three kinds of software today: Web apps, electron apps and mobile apps.
Here's some hairbrained ideas that are only a good implementation away from working:
- HTML/React inspired UI library that works on all platforms, so we can do electron without wasting 99% of my CPU cycles.
- Opaque binary files replaced with shared objects (eg smalltalk, Twizzler[1]). Or files replaced with CRDT objects, which could be turned to support collaboratively editable global state.
- Probabilistic computing, merging ML and classical programming languages. (Eg if() statements in an otherwise normal program which embed ML models)
- SQL + realtime computed views (eg materialize). Or caching, but using an event stream for proactively updating cached contents. DB indexes as separate processes outside of a database, using an event stream to keep up to date. (Potentially with MVCC to support transactional reads from the index & DB.)
- Desktop apps that can be run without needing to be installed. (Like websites, but with native code.). And that can run without needing to trust the developer. (Using sandboxing, like web apps and phone apps).
- Git but for data. Git but realtime. Git, except with a good UI. Git for non-developers.
- Separate out the model and view layers in software. Then have the OS / network handle the models. (Eg SOLID.)
- An OS that can transparently move apps between my devices. (Like erlang but for desktop / phone / web applications)
- Docker's features on top of statically linked executables.
The entire possibility space of what computing is is open to us. Why settle for POSIX and javascript+HTML? Our platforms aren't even very good.
Sure; important and took a lot of work, but they’re still incremental improvements over what came before. I could name dozens of equally important improvements - typescript, css grids, llvm, http2, the M1 processor, WSL, C++ smart ptrs, io_uring, zfs, SeL4 and so on.
This is all important work, but none of it makes you think of computing in a new way. Not like the web did, or Haskell, or the idea of a compiler & high level language, a preemptive kernel, or TCP/IP. These were all invented by people, and a lot of the people who invented them are still around.
There are plenty of sibling ideas in the idea space. But for some reason computing cooled down and tectonic shifts of that scale don’t seem to happen anywhere near as frequently now. How long has it been since an interesting new OS appeared on the scene? Feels like a very long time. And even Haiku uses POSIX internally anyway.
Side comment: most new developers tend to ignore/not read compile or runtime error messages and ask for help before even realizing the cause of the problem they're trying to fix is right there in front of them. Better error messages for 'beginners' has questionable benefits for developers just getting started, until they get to the point where they realize error messages are actually useful
> - HTML/React inspired UI library that works on all platforms, so we can do electron without wasting 99% of my CPU cycles.
Unfortunately this won't ever happen, at least not something production ready that will be usable on all 5 major platforms (Android, Windows, iOS, MacOS and I'm generously including Linux desktop here :-) ).
It's a very costly super long term investment and the incentives are not there as every platform (including desktop Linux!) is fighting against it.
React Native is the closest thing we have and the development experience is awful, from what friends that are using it are telling me, plus I don't think it's well supported on desktops. I, for one, don't think I've ever seen a Windows React Native app, for example.
So the best we'll ever get is modified browser engines, ergo Electron.
I know about Flutter but I would be never build a product on top of Google tech unless I'd be confident I'm able to easily migrate away from it.
Flutter is also the kind of project Google seems worst at: it will require a lot of tedious work going forward, to support all the platforms. Thankless work that doesn't foster promotions.
I'm not counting Go, I consider it a community project now.
> Git, except with a good UI. Git for non-developers.
The reason we all suffer without this is not because we have failed to solve it. It's that Git itself is preventing any forward development in this space.
We had Mercurial 15 years ago, but Git is a massive usability dumpster fire that blocks all further progress (and GitHub continually pours gasoline on the fire so we can never escape).
Yes, the real problem is the perspective and not the actual development. New languages are of no value by themselves. It is like counting the tools in your toolbox instead of the things you built with them.
So looking at the number of projects that are hosted on the internet (e.g. Github, Sourceforge etc.) we are likely to see a different story.
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 :).
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.
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
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.
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.
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.
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.
If we start with CVS in the 90s (incidentally my first version control system as well) everything looks like great progress.
But if we actually look at what was around, both in theory and practice, CVS was a giant leap backwards.
Examples:
1. Smaltalk ENVY (1990s, I think?): Automatic class/method level versioning on save. Programmable, introspectable history to easily build CI type stuff. See user comments here: https://news.ycombinator.com/item?id=15206339.
> you could easily introspect every change to code and by combining introspection of classes and methods quickly determine which changes were happening where. We built a test framework that could list the changes since the last run, then compute dependencies and run an appropriate selection of test cases to check. This cut down test time by 90%
2. DOMAIN Software Engineering Environment (1980s): a distributed source control and config system where the provenance of built artifacts to source files was maintained. More than that:
> DSEE can create a shell in which all programs executed in that shell window transparently read the exact version of an element requested in the user's configuration thread. The History Manager, Configuration Manager, and extensible streams mechanism (described above) work together in this way to provide a "time machine" that can place a user back in a environment that corresponds to a previous release. In this environment, users can print the version of a file used for a prior release, and can display a readonly copy of it. In addition, the compilers can use the "include" files as they were, and the source line debugger can use old binaries and old sources during debug sessions. All of this is done without making copies of any of the elements.
(from Computer-Aided Software Engineering in a Distributed Workstation Environment, 1984, http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.575...)
Note again, the above is from 1984.
3. PIE reports (1981): Describes a model of "contexts" and "layers" (roughly analogous to branches and revisions) for nodes (not files) that version methods, classes, class categories and configurations. On merging work from multiple authors:
>Merging two designs is accomplished by creating a new layer into which are placed the desired values for attributes as selected from two or more competing contexts.
However: it's easy to build experimental systems with cool properties. It's really hard to make them appealing in practice when you have to give up simplifying assumptions.
In particular a lot of these systems were not well adapted to managing collections of text files in unknown formats, edited by unknown tools. That made sense for research purposes, since you can't have as many cool properties without understanding the file formats, but it made them substantially less useful in practice, which I think is partly why they didn't get adopted.
If you pick 1994/1995 as the cutoff, you then have Java, JavaScript and Ruby in the latter group. So I'm calling bullshit on an argument framed around one the biggest years in software language advancement.
Not to mention ignoring PHP, C# and the the whole .Net framework.
But that's what I find so dumb about this post - so what if the original JavaScript came out in 1995, as the current version is so vastly different (and improved) and used for such wildly different things than the original that it's barely the same language. I mean, heck, I was out of JS dev for just a couple years in the early 2010s and when I originally got back into it I could barely understand JS code: ES2015 added a ton of syntax changes, I was totally new to the Node/NPM ecosystem and the whole JS web app toolchain (babel, webpack, etc.)
>How on earth does this post have this many upvotes?
A silent majority? There may be more people than you think who generally agree with the author's thesis and this strikes you as perplexing because you hold a different view.
Highly doubtful as HN doesn't have downvotes on stories. Given the comment threads, I find it much more likely that a small minority of folks with a similarly curmudgeonly outlook as the author upvoted the story, and the majority is calling out the author on his BS.
>Highly doubtful as HN doesn't have downvotes on stories. Given the comment threads, I find it much more likely that a small minority of folks with a similarly curmudgeonly outlook as the author upvoted the story, and the majority is calling out the author on his BS.
Well that's just it, isn't it? The silent majority would be silent -- they would not be those commenting.
Lol, so your argument is the silent majority is doing the upvoting on the story but for some reason a different silent majority is upvoting the comments in these threads.
>Lol, so your argument is the silent majority is doing the upvoting on the story but for some reason a different silent majority is upvoting the comments in these threads.
No, that isn't my argument. My argument makes no mention of comment voting.
I, for one, totally agree with the author's thesis. Those of you like me who were building industrial and military software in that era know what I'm talking about. The web, and JavaScript, etc. and even windowing systems were a huge step backwards in terms of software productivity. Those of you who were programming nuclear power plants, battle ships, air traffic control systems, etc. please weight in and tell me if you disagree. Those who didn't - I'm honestly not interested in your opinion.
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
>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?
OK. Asking because we've started building https://iko.ai as an internal machine learning platform to solve actual problems we have faced delivering machine learning projects for our clients these past few years. So far, it has the following:
- No-setup Jupyter environments with the most popular libraries pre-installed
- Real-time collaboration on notebooks: see cursors and changes, etc.
- Multiple versions of your notebooks
- Long-running notebook scheduling with output that survives closed tabs and network disruptions. You can watch the notebook running live even on your phone without opening the JupyterLab interface.
- Automatic experiment tracking: automatically detects your models, parameters, and metrics and saves them without you remembering to do so or polluting your notebook with tracking code
- Easily deploy your model and get a "REST endpoint" so data scientists don't tap on anyone's shoulder to deploy their model, and developers don't need to worry about ML dependencies to use the models
- Build Docker images for your model and push it to a registry to user it wherever you want
- Monitor your models' performance on a live dashboard
- Publish notebooks as AppBooks: automatically parametrize a notebook to enable clients to interact with it without exporting PDFs or having to build an application or mutate the notebook. This is very useful when you want to expose some parameters that are very domain specific to a domain expert.
Much more on our roadmap. We're only focusing on actual problems we have faced serving our clients, and problems we are facing now. We always are on the lookout for problems people who work in the field have. What do you think?
I’m not agreeing with the author, however he accepts ML is an exception, and Jupyter notebooks are the same as mathematics notebooks except that they are open to languages other than wolf.
He does cover this.
Again, I don’t think you are necessarily wrong, but the author does cover Jupyter and ML.
The author specifically calls ML non-human computing and I believe is talking about the advances in ML from a theoretical standpoint. I don’t believe it is possible to lump the human written software used to train models, generate adversarial examples, and perform other tasks on GPUs, as purely non human computing. In fact, a lot of the advances in computing recently are specifically to enable this type of computing to be more efficient: easily parallelize training, analyze bigger datasets, graph databases, and other “big data” technologies.
In any case, software notebooks definitely existed before Jupyter like you say (I’m not familiar with Wolf but Mathematica has a similar idea), but I don’t believe they date back to 1996. I might be mistaken. I don’t see the author mention them in the text.
313 comments
[ 3.2 ms ] story [ 323 ms ] threadI guess Microsoft and the Lean theorem prover/programming language probably counts? I could see that becoming as big a thing as Mathematica.
https://alarmingdevelopment.org/?p=229
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.
We’re at the better horses stage of the cycle. What’s the next car?
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).
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://gilkalai.wordpress.com/2020/12/29/the-argument-again...
They know they are blind to potentially better products, but they no longer have the time to gather the experience and confidence in the new products.
Is it just the list of software tools they use?
He make logical leaps that aren't justified.
It is an very well designed piece of engineering and an extremely useful and tasteful set of tools, but it’s no paradigm shift.
> 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.
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
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.
Some people just want to find negativity in the world.
http://www.subtext-lang.org/
"This approach antagonizes both academics and professionals, but it is what I must do."
Are you kidding? The author has (clearly) been dedicating his entire career to trying to solve these problems. He's not some drive-by hipster reminiscing about the good old days. The problem is that in a lot of ways programming is stuck in the "good old days"
It's just a reaction to 'the kids' coming after him not being up to how good he (mis) remembers the past.
This negativity is a disappointing and growing trend among some grumpy old men in our field as that generation approach retirement. It disrespects people working today and I don't like it.
Your contributions thus far in this thread have been negative with no substantive rebuttal to any points made in the article.
> All of these latter technologies are useful incremental improvements on top of the foundational technologies that came before.
As if that wasn’t the case before. We’ve always built on what came before. What on earth does the author think was so revolutionary about Java? The language was an evolution of the C family. The VM was an evolution of Strongtalk.
The negative person says ‘all done before.’ The reasonable person says ‘step forward’ as we’ve been doing ever since.
And what’s the implication? That people have become stupid or lazy or ignorant? This is an attack on the work and integrity of a generation of people.
There is a consistent claim at the moment from CS men of a certain age that we don’t appreciate their genius enough. They bang on about how under appreciated their ideas are at their invited talks and on Twitter. I don’t think I’m the only one in the community thinking this. I think quite a lot of people feel this.
It’s not negative to call out someone else’s negativity.
That's not what I was referring to. I was referring to the actual negative statements you made about the author:
>Some people just want to find negativity in the world.
>I'm going to take a wiiiiild guess here that the author's personal peak was around 1996.
>It's just a reaction to 'the kids' coming after him not being up to how good he (mis) remembers the past.
>This negativity is a disappointing and growing trend among some grumpy old men in our field as that generation approach retirement.
That's not "calling out" negativity. That's a list of snark, broad insult, and generalizations with no supporting information. It's rude, discriminatory, and serves only to diminish the overall quality of discussion.
> Since 1996 almost everything has been cleverly repackaging and re-engineering prior inventions
seems like an ignorant attack on thousands of people’s professional competence and a veiled insinuation of deceit (the ‘clever repackaging and re-engineering’) and
> Suddenly, for the first time ever, programmers could get rich quick
sounds like a moral attack. All in all it’s a shitty thing to say to people. And there’s more and more grumpy people trying to tell young computer science researchers today that they’re useless and have no new ideas like this.
Have you been to a CS conference recently? You may be missing the context that these people are everywhere criticising everyone for not being as innovative as they remember they were.
It’s damaging and not true either. No thanks!
1996 was 24 years ago. You are totally correct that the progress and change in this period has been incredible on the historical scale. But 24 years on the timeline of a human life is quite a significant portion, and some may feel that their expectations of futuristic utopia have been subverted, making them cynical.
i know i do!
lot's of stuff about the future sucks, and i can't think of a way to fix anything important with faster garbage collection or better type systems... maybe that's the difference between makers and cynics. i guess i'll try harder :p
I can, I am very hopeful better type systems will help heal the absolutely dreadful state of software robustness.
Better types (and by extension, better type systems) help eliminate many costly tests, improves knowledge transfer from senior engineers to junior engineers, makes refactoring and adapting to changing requirements a much less error-prone process where the computer can guide you, provides a more rigid way of breaking down problems into chunks instead of a procedural approach where good boundaries are harder to intuitively determine.
While education is what enables people to write better code with them, we need better type systems and languages that make this process easier for the average programmer to learn and use. Already languages like TypeScript, Kotlin and Swift are slowly getting many people to take a gander over the brick wall by exposing them to constructs like sum types and specific patterns like optionals and either/result types, that should fuel a little bit of hope at least!
EDIT: That's some visceral reaction. Would be nice to see some disagreement stated in text, or if any particular point needs further explaining, or to see if just hope of things improving is what's angering people.
EDIT: actually, you kinda cheered me up :)
"3d-printification" or democratisation of manufacturing capabilities. When advanced manufacturing become cheap, generic and small scale you need less capital to create and design important hardware.
"UX-ification" of advanced programming practices or democratisation of software creation capabilities. When advanced software design, composition and implementation becomes cheap, generic and scalable you need less capital to create/design/implement software and to be in control of the software you want/need.
When those things come together the importance of capital will greatly diminish for some vital parts of life. It will not solve all problems but some. And maybe create other problems. But it should at the very least greatly impact "important" problems.
The "UX-ification" of software creation is the part where software engineers can be part of.
Disclaimer: Perhaps I have a naive assumption underlying all this - the idea that increased flexibility eventually "will lead" to apparent simplicity. But isn't living organisms kind of a proof of this? The amount of complexity that an animal needs to understand to continue living and reproduce is dwarfed by the complexity of the animal itself. Well, also cars and computers.
Something like that. Maybe. Goodnight.
Some of us could host 2005 YouTube out of pocket, but it’s 2020, and people with fast connections expect 1080p video now, so it remains impossible for individuals to compete with corporations.
Like, will it always make sense to add things to YouTube or will a more decentralised approach make more sense? Will single responsibility principle make sense at that scale? Can infrastructure costs be shifted around in flexible ways? Etc.
But yeah it's telling that Facebook was initially looking for a much more decentralised approach but gave up on it when adapting to reality and economics.
Instead we got social networking, ad tech, and surveillance capitalism.
The tech for flying cars already exists, just not the tech for protecting people on the ground from flying car crashes.
But these things were not driven by software innovations.
In 1996 a friend was dating an engineer with an electric car. She'd thrown a bunch of time and money into it. Had a range of about 80-90 miles and wasn't slow at all.
Around then there was skunks works a couple of buildings away from me. On the spectrum analyzer I could see spread spectrum signals showing up at 900 and 2.4GHZ.
Edit: Stay classy HN.
i was little and didn't know shit, but i was already learning to program, and i think about this all the time. like mind blown, every day. 8 threads and 2GB of ram in my cheap ass phone? crazy! and we got so good at writing compilers they give them away for free!
JS was way slow because MSIE wasn't supposed to compete with desktop apps :p also, transpilation, JIT, virtualization and containers seem like a pretty big deal to me -- virtualization was academic in the 90's.
also, a lot of that "old" stuff like python and ruby and even C++ really weren't as mature and feature-full. memory safety/auto-management and concurrency language features are prevalent now, and i think people don't always appreciate (or remember?) when your computer couldn't walk and chew gum at the same time.
it seems to me like our tools have clearly improved -- i think a more useful conversation could investigate how to apply what we now have to improving productivity, safety and security.
For micros, it has been available, in some form, on x86 since 1985 when the 386 processor was first released. Remember the vm86 mode that let people run DOS apps under Windows 2.x?
That's not really virtualization. In the x86 world, hardware virtualization extensions don't crop up until 2003. Efficient dynamic binary translation (a key component for efficient virtualization without hardware support) I generally reckon to start with DynamoRIO (~2001), with Intel's Pin tool coming out in 2004.
(Do note that hardware virtualization does predate x86; I believe IBM 360 was the first one to have support for it, but I'm really bad with dates for processor milestones).
(Note VMware Workstation, as another poster pointed out, and even earlier "emulation" solutions like Bochs existed before 2003.)
I really think everything is incremental in progress. Where things are closer to us, we can see the incremental steps. Where we think of the great things of the past, we are completely ignorant of the incremental steps that came before.
PS: Machine learning is old too, although application - again due to incremental hardware improvement, has finally arrived.
A lot of these are also fads that will pass. Are there any problems today that were unsolvable in 1980 given enough time?
Wow, smaller transistors, more clock cycles, big whoop. We have more now but it's not fundamentally different is it?
>If an engineer in 1996 fell into a coma and woke up today, they'd be greeted with an entirely different world.
I'd also be disappointed. Oh we are on DDR4, Windows 10, multiple cores, cpp 20? Ok. So we basically just extended the trendline 25 years. Boring.
In which case software has "stalled" in terms of "invent anything fundamentally new " - and I'd agree.
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.
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.
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 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.
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.
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.
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?
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.
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.
for val in sequence:
and this in R:for (val in sequence)
{
print(val)
}
and this in bash: for val in sequence; do echo val; done
I mean there was no paper that I can find that found curly braces to be especially drawing to the human eye or anything like that. or that it's particularly intuitive to write "do" and "done" or not. For loops look like no linguistical sentence structure that I recognize, they are pretty much their own thing structurally imo. These are all arbitrary decisions decided by people, because it just happened to make arbitrary sense at the time for any number of reasons. Not because the R core team ran some psychological experiments to empirically determine the most intuitive for loop structure when they drafted their language; that data has never been collected, the R core team just followed what the S team had already done and that's that. Arbitrary.
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.
This is hyperbole
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.
Most enterprise shops don't see any value in doing otherwise.
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.
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?
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?
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!
The only things that remain are those few which appeared seemingly out of nowhere and rose to prominence over a short period of time.
Thanks for doing it.
This is an "Oh, the cloud is just timesharing" take.
Except that Linux containers are a huge regression on what BSD jails gave us 20 years ago. They’re catching up for sure, but it’s still just badly reinventing a wheel that already exists, for philosophical, political, or selfish reasons.
[0] https://embed.cs.utah.edu/csmith/
I think this made it easier to firm up new language implementations. I feel like we started getting more of them because of this.
Async/await matters. But compared to inventions like threading, filesystems, java's write-once run anywhere, HTTP/HTML and the invention of the URL? I agree with the author. We've lost our mojo.
Computing is pretty unique in that we have near-complete freedom to define what a program even is. A sorting method implemented in haskell is a different sort of expression than the same idea implemented in C. The abstractions we all take for granted - processes, applications, RAM & disks, databases, etc - all this stuff has been invented. None of these ideas are inherent to computing. And yet apparently we only know how to make three kinds of software today: Web apps, electron apps and mobile apps.
Here's some hairbrained ideas that are only a good implementation away from working:
- HTML/React inspired UI library that works on all platforms, so we can do electron without wasting 99% of my CPU cycles.
- Opaque binary files replaced with shared objects (eg smalltalk, Twizzler[1]). Or files replaced with CRDT objects, which could be turned to support collaboratively editable global state.
- Probabilistic computing, merging ML and classical programming languages. (Eg if() statements in an otherwise normal program which embed ML models)
- SQL + realtime computed views (eg materialize). Or caching, but using an event stream for proactively updating cached contents. DB indexes as separate processes outside of a database, using an event stream to keep up to date. (Potentially with MVCC to support transactional reads from the index & DB.)
- Desktop apps that can be run without needing to be installed. (Like websites, but with native code.). And that can run without needing to trust the developer. (Using sandboxing, like web apps and phone apps).
- Git but for data. Git but realtime. Git, except with a good UI. Git for non-developers.
- Separate out the model and view layers in software. Then have the OS / network handle the models. (Eg SOLID.)
- An OS that can transparently move apps between my devices. (Like erlang but for desktop / phone / web applications)
- Docker's features on top of statically linked executables.
The entire possibility space of what computing is is open to us. Why settle for POSIX and javascript+HTML? Our platforms aren't even very good.
[1] https://www.usenix.org/conference/atc20/presentation/bittman
Aren't good error messages very hard to implement and also a _major_ productivity increase? They're also a boon to beginners.
Both are very important as the most powerful resource we have is people.
This is all important work, but none of it makes you think of computing in a new way. Not like the web did, or Haskell, or the idea of a compiler & high level language, a preemptive kernel, or TCP/IP. These were all invented by people, and a lot of the people who invented them are still around.
There are plenty of sibling ideas in the idea space. But for some reason computing cooled down and tectonic shifts of that scale don’t seem to happen anywhere near as frequently now. How long has it been since an interesting new OS appeared on the scene? Feels like a very long time. And even Haiku uses POSIX internally anyway.
a) new developers in general (totally new to programming)
b) developers new to this specific programming language
I'd be curious what the percentages are, but my personal hunch is that for any specific language there are more in category b) than a).
And for category b), those are definitely helped by error messages.
I was once amazed to learn that ClearCase was designed with the objective to be sold to lawyers, not developers.
Unfortunately this won't ever happen, at least not something production ready that will be usable on all 5 major platforms (Android, Windows, iOS, MacOS and I'm generously including Linux desktop here :-) ).
It's a very costly super long term investment and the incentives are not there as every platform (including desktop Linux!) is fighting against it.
React Native is the closest thing we have and the development experience is awful, from what friends that are using it are telling me, plus I don't think it's well supported on desktops. I, for one, don't think I've ever seen a Windows React Native app, for example.
So the best we'll ever get is modified browser engines, ergo Electron.
Flutter is also the kind of project Google seems worst at: it will require a lot of tedious work going forward, to support all the platforms. Thankless work that doesn't foster promotions.
I'm not counting Go, I consider it a community project now.
There are React Native forks for Windows, MacOS and Linux. I have no idea whether any of them is "good implementation" though.
> SQL + realtime computed views (eg materialize)
ClickHouse (OLAP DB) has materialized views (but only for inserts). Also Oracle and (I guess!) Materialize DB should have it too.
> Desktop apps that can be run without needing to be installed. (Like websites, but with native code.)
AppImage (and maybe Snap and Flatpak) is like this. Also technically, with Nix you can just run something like
(without root), but it feels like cheating.> Git but for data
https://github.com/dolthub/dolt (again, never tried it yet, but would like in future)
Java didn't invent that, it is only a new iteration on an old idea.
I remember that when they announced Java in 1994 I thought about the p code system from UCSD I used in 1986 on a Z8000 Unix machine from Onyx (sp?).
More info at https://en.wikipedia.org/wiki/P-code_machine
The reason we all suffer without this is not because we have failed to solve it. It's that Git itself is preventing any forward development in this space.
We had Mercurial 15 years ago, but Git is a massive usability dumpster fire that blocks all further progress (and GitHub continually pours gasoline on the fire so we can never escape).
Had that in the 90s:
https://www.digitalmars.com/ctg/trace.html
The idea dates back even earlier from a product called the Segmentor.
The Superoptimizer comes from a paper in the 1980s, and what it discovered was promptly integrated into several compilers.
So looking at the number of projects that are hosted on the internet (e.g. Github, Sourceforge etc.) we are likely to see a different story.
> 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-genea...
There is no such thing as fully independent innovation. Not just in tech, but every single piece of innovation in human history.
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.
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 :).
> 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.
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
The only thing that would shock a traveler from 70 years ago is the awful service and in flight entertainment system.
...and the cheapness
1950s - computers are so expensive that I can't even get one to myself and have to share it with a bunch of other people
now - I'm using so many computers that I can't even handle managing them all myself and instead pay Amazon to do it for me
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.
I think this is an example of "post something quite wrong and get lots of attention because it is so wrong".
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.
But if we actually look at what was around, both in theory and practice, CVS was a giant leap backwards.
Examples:
1. Smaltalk ENVY (1990s, I think?): Automatic class/method level versioning on save. Programmable, introspectable history to easily build CI type stuff. See user comments here: https://news.ycombinator.com/item?id=15206339.
> you could easily introspect every change to code and by combining introspection of classes and methods quickly determine which changes were happening where. We built a test framework that could list the changes since the last run, then compute dependencies and run an appropriate selection of test cases to check. This cut down test time by 90%
2. DOMAIN Software Engineering Environment (1980s): a distributed source control and config system where the provenance of built artifacts to source files was maintained. More than that:
> DSEE can create a shell in which all programs executed in that shell window transparently read the exact version of an element requested in the user's configuration thread. The History Manager, Configuration Manager, and extensible streams mechanism (described above) work together in this way to provide a "time machine" that can place a user back in a environment that corresponds to a previous release. In this environment, users can print the version of a file used for a prior release, and can display a readonly copy of it. In addition, the compilers can use the "include" files as they were, and the source line debugger can use old binaries and old sources during debug sessions. All of this is done without making copies of any of the elements. (from Computer-Aided Software Engineering in a Distributed Workstation Environment, 1984, http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.575...)
Note again, the above is from 1984.
3. PIE reports (1981): Describes a model of "contexts" and "layers" (roughly analogous to branches and revisions) for nodes (not files) that version methods, classes, class categories and configurations. On merging work from multiple authors:
>Merging two designs is accomplished by creating a new layer into which are placed the desired values for attributes as selected from two or more competing contexts.
(from An Experimental Description Based Programming Environment By Ira Goldstein and Daniel Bobrow, 1981, http://esug.org/data/HistoricalDocuments/PIE/PIE%20four%20re...)
However: it's easy to build experimental systems with cool properties. It's really hard to make them appealing in practice when you have to give up simplifying assumptions.
In particular a lot of these systems were not well adapted to managing collections of text files in unknown formats, edited by unknown tools. That made sense for research purposes, since you can't have as many cool properties without understanding the file formats, but it made them substantially less useful in practice, which I think is partly why they didn't get adopted.
How about the explosion of FLOSS?
Not to mention ignoring PHP, C# and the the whole .Net framework.
A silent majority? There may be more people than you think who generally agree with the author's thesis and this strikes you as perplexing because you hold a different view.
Highly doubtful as HN doesn't have downvotes on stories. Given the comment threads, I find it much more likely that a small minority of folks with a similarly curmudgeonly outlook as the author upvoted the story, and the majority is calling out the author on his BS.
Well that's just it, isn't it? The silent majority would be silent -- they would not be those commenting.
No, that isn't my argument. My argument makes no mention of comment voting.
- 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
>- 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?
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
- No-setup Jupyter environments with the most popular libraries pre-installed
- Real-time collaboration on notebooks: see cursors and changes, etc.
- Multiple versions of your notebooks
- Long-running notebook scheduling with output that survives closed tabs and network disruptions. You can watch the notebook running live even on your phone without opening the JupyterLab interface.
- Automatic experiment tracking: automatically detects your models, parameters, and metrics and saves them without you remembering to do so or polluting your notebook with tracking code
- Easily deploy your model and get a "REST endpoint" so data scientists don't tap on anyone's shoulder to deploy their model, and developers don't need to worry about ML dependencies to use the models
- Build Docker images for your model and push it to a registry to user it wherever you want
- Monitor your models' performance on a live dashboard
- Publish notebooks as AppBooks: automatically parametrize a notebook to enable clients to interact with it without exporting PDFs or having to build an application or mutate the notebook. This is very useful when you want to expose some parameters that are very domain specific to a domain expert.
Much more on our roadmap. We're only focusing on actual problems we have faced serving our clients, and problems we are facing now. We always are on the lookout for problems people who work in the field have. What do you think?
He does cover this.
Again, I don’t think you are necessarily wrong, but the author does cover Jupyter and ML.
In any case, software notebooks definitely existed before Jupyter like you say (I’m not familiar with Wolf but Mathematica has a similar idea), but I don’t believe they date back to 1996. I might be mistaken. I don’t see the author mention them in the text.
Also, I don’t see anything particularly new in how ML computing is organized.
We’ve had vectorization, and massively parallel processors since the 80s.
All that’s new is that those techniques are being used on desktop machines now because of Moore’s law.
I’m not saying there are no new discoveries in ML, just that the engineering isn’t new.