Three things for the next 100 years of Computer Science
but-her-flies.bearblog.dev
but-her-flies.bearblog.dev
To me, if you're really look out even to the end of this century (which would double the amount of time humanity has been seriously evolving digital computing technology), the big change is likely to be that innovation in ideas, technology, and technique will shift from human minds to digital intelligences. I don't think that means a full-on Kurzweillian singularity, but I think we've basically just landed on the near shore of the generative intelligence continent, and there is way more to come.
Think about it this way: in 80 years, we've evolved raw computation power in a single installation from 500 or so FLOPS, to the petaFLOP range - a factor of over 10^12. So, let's be modest and scale down our expectations, and try to imagine what generative intelligence that is 100 times (not 1 trillion) as capable as, say, AlphaZero is, might do. I'm sure I can't actually imagine the results, but I do predict it will shift the balance of innovative "thinking" from human minds to digital intelligences.
In 100 years I expect there will be a fundamental shift in how computing is done. I don't know what that will look like, but it will be nothing like what we know today.
I'm not confident that will be the case. But its plausible from a technical standpoint. On a far shorter timeline than 100 years.
It seems I’m not alone and Noam Chomsky feels the same. https://www.inverse.com/article/32395-elon-musk-neuralink-no...
Such gaps sometimes get closed by monumental efforts, sometimes by small groups, and sometimes they take centuries.
EDIT: Now I can't shake the mental image of Alex from A Clockwork Orange strapped into his chair for his "treatment". And certain scenes toward the end of The Men Who Stare at Goats.
Arguably, we already did that (make an interface that our brain adapts to): programming languages, keyboards, are already man-made interfaces our brain adapted to.
For what its worth, I did (well, started) a PhD in this and you're bang on. We don't understand the brain at all, and trying to fudge this immense knowledge gap with Machine Learning is getting us nowhere. Doesn't stop the grant money from rolling in, though.
Brain implants + near-AGI would essentially make us superhuman
If you replace metalworking with the reward mechanism hacks Facebook et al use to optimize their success metrics, the threshold to a paperclip maximizer scenario gets considerably lower. Smartphones are bad enough, add MMI to the mix and all bets are off.
Reference: https://www.historynet.com/drones-hollywood-connection/?f
However, if we're talking 100 years, it's hard to estimate what potential paradigm shifts like true AI*, quantum computing, or something that hasn't been thought of will change.
* What we're now seeing with GPT 3.5 etc. No-one can really say with high confidence whether it's the start of an AI revolution or will plateau soon.
What your memory probably brought up was the fact that all the 52s flying today are 52H, the final iteration following A through G with considerable changes between them. But the H is the one built 1961 through 1963, from today's perspective they are not really much younger than their mothballed/disarmed siblings. The reason I suspect that this is what you are talking about is that the same thing happened to me, I roughly knew about the A through H thing but placed the H much closer to the present and was very surprised on a recent read-up.
[0] https://www.afmc.af.mil/News/Article-Display/Article/2789821...
Somehow no fundamental shifts in how rolling on the ground is done are foreseen, despite the time frame.
In 100 years, I expect programming languages will be mostly obsolete, since computers will be able to translate natural language into machine instructions with 100% effectiveness.
What we have done well is to quantitatively scale so that we're applying the classical debugging techniques to Big Balls of Mud, and not just a few lines of assembly.
(the record among my colleagues was writing, then fixing, 3 bugs in a single line of assembly)
Do you have a link? Searching only gave me irrelevant results.
Best I can do at the moment is to recommend searching from http://www.cs.tau.ac.il/~nachumd/term/EarlyProof.pdf which was one of the papers I passed on the way... (IIRC Goldstine and von Neumann has diagrams resembling Figure 2; I don't recall if Figure A had been anticipated or not — remember all these people had been attending the same conferences, so it's very likely)
Basically, back in the rosy-fingered dawn of electronic computation, they already had in mind "know what your state should look like at all points, so you can binary chop to find what control flow first made it go wonky".
(a question I have not investigated: how well developed were debugging techniques in the card computing era? I've read horror stories of Los Alamos computations being corrected on-the-fly, with "new code" cards on a different coloured stock being run at the same time through machines that were still busy processing "old code" cards on normal coloured stock.
And in terms of "know what your state should look like", card machines did have facilities to abort jobs if the input card deck should fail simple sanity check logic, implying that's been a thing since, probably, Hollerith ca. 1890.)
[Edit: I'll have to dig it out of my library, but an old book my spouse got me on Naval computation, from back when "computer" was a job title, not an object, talks about how to organise jobs that would take a week or two to run. I'm sure they had plenty of double-checking going on to make sure a slipup on Wednesday wouldn't result in complete garbage by the following Monday.]
Conversely, one of the problems I had in a previous place was the code being unclear because another developer kept all the obsolete code in the code base "for reference", and also put 1000 lines inside a single if clause, and duplicated class files because he didn't want to change some private: access modifiers to public:. Those kinds of problems weren't possible on such limited hardware and languages.
Over-complicating code has always been a thing, too. Admittedly, "Information Hiding" has only really been a thing since Parnas, but I think it's more true than not that most developers are making the same categories of mistakes developers have always made, and when new programming languages and paradigms are created specifically to avoid those errors, they bring with them new categories of errors.
Syntactically, the majority of code today looks completely different from 50-year-old code, of course. But I'm not sure things have really changed all that much on the human side.
So they will translate imprecise natural language to buggy business logic, great. :)
In my experience, between envisioning a new product/feature (at the product management level) and actually implementing it (at the engineering level) there's always the stage where the engineers discover that the PM's requirements and acceptance criteria are not precise enough and there are dozens of edge cases where additional input by the PM is needed in order to decide how the software should behave.
Sure, the AI could recognize those edge cases, ask the PM for what they want, and therefore help them spec out the entire application in natural language. That spec will then become the source of truth, i.e. the thing to version-control. I'm not sure this would be a very efficient process, though. At the end of the day, natural language will always be ambiguous and so, in the same way as the language of RFCs is regulated, one might need to restrict oneself to a more well-defined subset of natural language that avoids ambiguities as far as possible. But then you're essentially back to programming.
How is this a problem? This is already how PMs and engineering managers work: they tell individual contributors what to implement, hashing out any ambiguities or edge cases via natural language dialogs. They have no need to use version control on the code level; simply tracking changes to their high level spec works fine.
>one might need to restrict oneself to a more well-defined subset of natural language that avoids ambiguities as far as possible. But then you're essentially back to programming.
Again, PMs and engineering managers get by just fine with standard natural language.
I never said this was a problem.
> Again, PMs and engineering managers get by just fine with standard natural language.
I agree only to some extent. At least in my experience, edge cases are often hashed out between the PM and engineers in spontaneous meetings, Slack conversations, or <insert medium of choice>. If ticket descriptions / acceptance criteria then get adapted accordingly, great. (Most of the time they don't – since we're so fucking agile.) Though, even if the descriptions/criteria do get updated, they often still lack precision and require interpretation – which is no problem, since all engineers now know what is meant by the ticket description and how to handle the edge case. However, if your entire spec is natural-language-based and you want your AI to reliably generate the same code every single time without needing to provide additional context, you better make sure to remove any ambiguity from the spec. But removing ambiguity from natural language basically comes down to speaking like a mathematicion / programmer, so the natural language spec will end up being rather similar to (pseudo) code again. So you're essentially back to programming.
Actually, they often have lots of problems with “standard natural language”, which is why large projects tend to develop considerable volumes of specialized jargon (often multiple layers, such as project-specific, organization-specific, etc.), which is either subject to extensive documentation (which often becomes a maintenance issue) or which becomes a contributor itself to miscommunication as understanding gaps emerge as turnover and communications silos lead to differing understands among project team members and between the project team and other stakeholders.
In fact, there is a lot of specialized, formalized, controlled language that is standardized beyond the organizational level (including visual languages), which is designed to mitigate parts of this problem (though it often fails, in part because usage in practice doesn’t consistently follow the formal standard.)
...do they? Poorly defined requirements done through natural language could possibly be the most costly and wasteful aspect of any business.
There has been some progress in the last couple of decades, but not so much that you'd expect this to be completely solved in the next decade.
People have been saying this since 1960 at the very least.
In reality, it is vastly more likely that humans will finally learn to speak computer.
There is almost nothing about natural language use that ought to lead anyone to believe we are going to get computers to understand our requirements any better than we do, which often, is very poorly even when we try very hard.
Even if you could, you would not want to use natural language to instruct a computer. You don't want the AI, or the computer, to guess your intent.
Another branch that might eventually become something of a science might be massively parallel computing?
In 100 years, it's possible the only computing being done will be of the biological sort, by far smaller and more resilient life forms than humanity. Even if we survive, the seemingly inexorable progression of technology may take a back seat to survival, and we could easily be struggling just to maintain functionality of devices we no longer have the ability to manufacture.
I suppose I should temper the doom & gloom a bit by mentioning that I think we still have several chances to squeak out a pathway to avoid massive and violent die-offs, but that window is certainly narrowing and we aren't doing nearly enough. Hundreds of millions of climate refugees (or more) are going to disrupt pretty much everything if we don't start planning what to do with them now.
In the positive scenario tech becomes a significant enabler of sustaibility. I don't think we need major computer science breakthroughs for this to happen though. Its purely a human moral, behavioral, economic and political challenge.
I doubt that such things are really possible. I see two problems: 1. computers in general don't have domain knowledge, so they can't really say what "correct" means; 2. computers don't have a conceptual model of what it is a human is trying to do, so they can't determine if that way is correct.
I thought about this when I was playing with microcontrollers. There are all sorts of bizarre flags and ways and means of configuring and controlling a peripheral. If there was only one correct way of doing things, then it wouldn't make much sense to give such fine-grained control.
In one particular case I was writing to a peripheral. Normally one would block processing until the transfer was complete. However, I needed the operation to be done frequently, and blocking would have consumed much-needed computing cycles. My solution was to simply write to the peripheral. I knew that it would be complete by the time I made the next transfer.
Well, the thing is, a checker just can't reason in that way. It takes a human to do that. Humans can of course be wrong, and often are, but thems the breaks.
Formal checking may be able to establish a few things, but as a general exercise, there is no more chance of some kind of AI proving your program to be right as there is of solving the halting problem.
First, how 'bout 100 years ago, i.e., back to 1923?
Telephone: By 1915 in the US we had long distance telephone coast to coast.
Cars: The cars of 1923 were not so bad -- had tops, doors, glass windows, electric lights, rubber tires filled with air, a rear axle differential, ....
https://en.wikipedia.org/wiki/Category:Cars_introduced_in_19...
Airplanes: The Wright Brothers were at Kitty Hawk in 1915, and airplanes were important in WWI.
https://en.wikipedia.org/wiki/Kitty_Hawk
Physics: By 1923 we had explained the photoelectric effect (one of the foundations of quantum mechanics) and both special and general relativity (1915),
https://en.wikipedia.org/wiki/General_relativity
The Schrödinger equation was on the way, published in 1926,
https://en.wikipedia.org/wiki/Schr%C3%B6dinger_equation
From the past, one possible lesson is that progress is enabled or constrained by fundamentals.
So for the next 100 years, what are some of the likely important fundamentals?
It is probable, based solely on the rate of technological change, that the concepts of engineering, computing, programming, etc. will be historical by the middle of this century. Electronic engineering was the dominant technology trade in the late 80’s. Within 20 years, computer programming became the dominant technology trade. With AI advances, programming by humans will all but disappear and this field will be replaced by “cognitive architects” that build artificial intelligence systems and solutions. After that, who knows?
Once optical computing becomes a reality, we will look fondly upon our quaint silicon devices. Optical computers capable of measuring interactions of single photons will eventually lead to quantum computing in all things.
Likely, quantum computing will be a dedicated core/unit in a heterogeneous optical computing architecture, as linear operations are still need to manage I/O, memory and peripherals (displays and what not).
For example, photons don’t help if it’s theoretically impossible to dissipate heat any faster.
I think the primary motivation for using non-qwerty layouts is comfort, not speed. Though perhaps it only really becomes relevant once one actually learns the layout (touch typing, with all the fingers), and AFAICT not a large fraction of people does that, even with qwerty.
1. A visual programming language. In 2122 you'll be able to use 2D or 3D space for your program, not just a 1D character stream.
2. A natural language programming language. In 2122 you will no longer have to learn to program.
3. A simple parallel programming language. In 2122 a program for 1,000 cores is as easy as a single-threaded program.
4. A universal optimizing compiler. In 2122, all languages will be as fast as machine code.
5. A 1000x lossless compression algorithm. In 2122 diskspace and bandwidth are no longer constraints on anything.
6. A solution to the "Mythical Man Month" problem. In 2122, adding more programmers to a project will actually make it go faster.
We've been dreaming about these "breakthroughs" ever since the beginning. They are no more likely to happen in 2122 than perpetual motion or the philosopher's stone.
half joking I don't really know much about languages, I just don't see how a graphical programming model would be better than a text based one in expressiveness or compactness?
But yeah, i tend to doubt as well, but i still think its an interesting direction for programming language research.
And the only programming languages that nobody complains about are those that nobody uses.
I think the optimizing compiler one might actually work out.
However, I guess there might be some goalpost shifting around what compilers are expected to do.
This seems that it would violate a fundamental law of information theory in that a data stream can only be compressed to the minimum number of bits necessary to communicate non-random information present within it.
To state it another way, let us suppose that an excellent compression ratio in 2022 is ~70% (an oversimplification, as the ratio varies wildly based on the source data). 100Mb of data thus compresses down to 30Mb.
But with a 1000x compression ratio, that same 100Mb would compress down to just 100kb.
I am not aware of any data streams that carry so little information where such a ratio could be achievable.
We program in 2d character pages already.
Visual Basic and Delphi were mainstream GUI builders in 1997, a quarter century ago.
We have the Unity engine if you want 3D.
>2. A natural language programming language. In 2122 you will no longer have to learn to program.
VisiCalc, Lotus 123, then Excel made declarative programming usable by most people in the 1980s.
>3. A simple parallel programming language. In 2122 a program for 1,000 cores is as easy as a single-threaded program.
Multithreading is tricky, because it rewrites the physics of programming. Causality generally goes out the window, unless you use locks, which defeat the threading by bottlenecking it. Systems that refactor into immutable data don't have to use locks.
>4. A universal optimizing compiler. In 2122, all languages will be as fast as machine code.
LLVM, a universal backend to compilers, is being used on a wider basis almost every day.
>5. A 1000x lossless compression algorithm. In 2122 diskspace and bandwidth are no longer constraints on anything.
The laws of physics make this level of compression impossible. However, disk space and bandwidth are much, MUCH cheaper than they were in the days of 300 Baud dialup with acoustic couplers.
It's interesting to make such a list, but the 3 item seem to be a bit arbitrary - what about user interfaces, for example?
Right now Google, YouTube, StackOverflow, PornHub, Netflix perform search in the database.
But imagine, that you ask for something on Netflix and a whole movie will be generated for you.
We can see glimpses of this in ChatGPT vs Google, and I hope that this direction will grow to the mature phase.
I have always thought that mouse, keyboard, and screens are quite a tedious and uncomfortable way to interact with a computer, and god knows how many health problems sitting at a computer for decades contributes to.
I’d love to be programming laying in a park without being limited by not having a large monitor and quality keyboard/mouse.
Same for like a distributed system with message/event queues, it can start demonstrating various data flows that introduce possible race/concurrency conditions as I’m still in the design phase.
Now I realize 1. I don't want buggy hardware in my head 2. I don't want to go to the surgeon ("wetdoc" or whatever the Cyberpunk RPG called it) every time a new model comes out
I don’t think we’ll get there in 10 years.
This requires fundamental innovations all the way down.
I think the answer is quite simple: if something happens that contradicts the proof then a lot of resources will be used to doublecheck the proof and ensure its correctness and it will just be accepted that proofs are not always 100% valid.
Proof languages will be welcomed but we must apply discipline as we do today with type heavy languages.
The 4 colour theorem says hello from 1976.
Ultimately though proofs are not just about being confident something is true, its usually also about why something is true.
I hope that will translate in hardware standardization and stability, as this is probably the best thing that could happen to software engineering.
Is the total cost of learning Ada and SPARK greater than learning Rust or Frama-C?
https://learn.adacore.com/courses/intro-to-spark/index.html
>> Is the total cost of learning Ada and SPARK greater than learning Rust or Frama-C?
It is a comparable amount of effort.
The more fundamental limit is probably that you can't do lots of the tricks that make normal programs efficient. You can't exit early or have data dependent branches.
What happens when that trend reverses? Better yet, what happens when the number of people who are capable of writing software plummets quickly due to a mass extinction event?
What kinds of systems will the survivors design and implement? How will the relationship between development and maintenance change in this new world?
Save the planet with uBlock ome ad at a time. (I am not sarcastic here BTW).
https://www.destroyallsoftware.com/talks/the-birth-and-death...