What will programming look like in 2020? (2012)
lambda-the-ultimate.org
lambda-the-ultimate.org
> ... the beginnings of intelligent ... assistants in our IDEs ... specialize (sic) in ... C/C++, Java, Mobile. They will have intimate knowledge of common APIs ... trained on tens of thousands of code projects pulled from the open repositories across the web (google code, github, bitbucket,...). In addition to having 'read' more orders of magnitude more code then any human could in a lifetime, they will also have rudimentary ability to extract programmer intent, and organizational patterns from code. ... The computer automatically bringing up example code snippets, suggesting references to existing functionality that could be reused.
This person (Marc DeRosa) predicted Github Copilot within a margin of one year. Incredible.
I'd like to see evidence / experience reports backing up this part. Certainly Copilot exists, but what I've read about it is pretty mixed.
I am not confident that there are programs I can write in Python, JS, or OCaml in one hour that nobody can write in Ada in ten hours, and programs in those languages in ten hours that nobody can write in Ada in 100 hours. I'm even less confident that they beat Smalltalk by as much. The exception is for very small programs: you can write things in Python in 5 minutes that nobody can write in Ada in an hour.
http://canonical.org/~kragen/sw/dev3/rpneact.py is maybe one example, which I wrote over the course of about 12 hours on January 2. It's a simple interactive calculator app that includes a general-purpose numerical equation solver; from the Python standard library it gets floating-point and complex arithmetic, regular expressions, and command-line editing. I don't think it would take me even as long as 120 hours to write it in C, which is roughly the same level as Ada but more painful to debug.
Similarly, http://canonical.org/~kragen/sw/dev3/lmu.py is a very limited MUD, where multiple users can connect, interact, and collaboratively build a textual world by creating rooms and other objects and setting their descriptions: sort of like a Wiki for interactive fiction, though without much richness of interaction. I wrote this between July 18 and July 24 last year, probably taking more than 20 hours in total. Writing it in C would have been slower but surely would not have taken 200 hours.
The main thing that's happened since 01987 is that computers have gotten a lot faster and bigger, so we can get by without as much attention to efficiency, and software libraries are also enormously more powerful. It's not that much easier now to write a SQL database than it was in 01987, but it's a hell of a lot easier to link in SQLite. It's not that much easier to write a regular expression matcher, but every modern language has one in the standard library already. Rendering Telugu text properly still involves a lot of hairy cases, but whether you're in a terminal or a browser, generally all you need to do is emit some UTF-8 bytes and you're golden.
In my opinion it does hold up, since indeed we can hardly even be 2x more productive in a barebone project with different programming languages, let alone an order of magnitude.
And what you are getting at is as far as I remember was the escape hatch mentioned by Brooks himself, that is the only significant improvement in productivity will come from the ecosystem. And I think we are behind even at that, in that we unfortunately have many NIH projects doing the exact same thing across language ecosystems, with not much interoperability. Eg. the JVM, Python, JS ecosystem has barely any shareable elements. Hopefully something like Graal’s polyglot might change it in the future.
The library ecosystem is a great bright spot: the cost of modularity has fallen to such a point that leftPad is its own NPM module. The fact that Python has a separate leftPad as the .rjust method on strings seems less significant than the reduction of duplication within each ecosystem. Historically if you wanted your library to be usable from anywhere, like D-BUS, you wrote it in C, and that's still a viable option; but Rust is shaping up to be a better alternative there.
I do think we can be more than 2× more productive in a barebones project with better programming languages, because I've been programming in assembly language this week, and it is pretty slow going. But I reluctantly came to the conclusion that Brooks was right: the big leap in raw productivity was from assembly to Algol 60, not Algol 60 to JS. (And, separately, from batch mode to interactive programming.)
If we can do it, we should do it. All technology is progress. All technology improves the human existence.
I profit from your obsolescence. I'm making you obsolete. I know what I'm doing. I'm making you worthless. The fact that you can fail to do even a basic check into me speaks volumes.
> manually code it into reusable function and use it repeatedly
Refactoring every place where you do x into a reusable function that does x is a boring repetitive chore.
As someone who has suffered though inheriting a code base of excessive copy/paste with things done "pretty much the same way but changing only one thing" it's a nightmare to take it to diff and try and refactor out the common code. In my case I had to fix a bug in their copy/paste mess and found six separate copies of a whole functions worth of code duplicated.
I suspect part of the reason is for the initial developer it's a great feeling to churn out tons of code and it all kind of works without having to think how you make a block of code generic (avoiding temptation to just pass in a global state struct and dealing with function pointers in the worst cases etc) but having suffered the after effects, I implore you, PLEASE don't repeat yourself (DRY)
You also get good at 'using copilot' just like you can be 'good at googling'. So if you not already doing it. Start now.
IMO. There's literally no point coding without it. You are completely wasting your time. However it has limits. It only helps you write code. Architecture is still down to you. If it could read your whole codebase rather than just the page you are on. And if you could supply it prompts via urls. i.e. preloads it with hints from other code bases. Then it will really become something else.
Except maybe that it is still not generally available.
Copilot is decent at speeding up some commonly occurring boilerplate in a common language, and pretty bad at anything else.
FWIW, there was also this https://challenge.openai.com/codex/leaderboard, and Copilot's 'time' was laughably bad compared to any decent human.
Does this mean that it couldn't potentially be a useful tool? No. I think it could be, and for some projects I would probably use it myself to speed up some laborious tasks. But currently, claiming it can help with anything remotely more complex is just untrue.
If you have evidence to the contrary, I'd like to see it.
edit.
- ok so you conceded in your sentence that it's faster and you would use it for that reason.
so your only disagreement is it can't help you solve harder problems?.
- the average dev is hitting stackoverflow 10x a day for that very reason. And that data is embedded in copilot. I've literally typed the name of functions I was going to have to spend 20 minutes googling to figure out how to achieve. typed the pseudo code comments and boom. copilot has done it before I even had to think. If not I just have to change how i prompt it by feeding it a few variable names or changing my comments. As I said. You can get good at using it. If copilot is crap it's because of the person using it. I.e. if you are looking for a bike and you google 'chicken sandwich' well. You aint gonna get a bike.
To me 'smarter and faster' means being able to solve harder problems + accurately reason about things, etc. (And not introduce security issues, which is a whole other thing...)
If it is just a replacement for stackoverflow, it's probably useful and it could save time, but I'm not sure it's 'smarter and faster' any more than any other feature in an IDE (you could also create a hotkey or something to search SO which would probably be just as fast too).
It's nice to reason about your actual problem and not the features of code.
EDIT. regarding these situations when it doesn't predict what I wanted, I feel that my brain is getting better at not focusing at that and moving on. At first it was distracting, now I subconsciously know that the provided solution might be wrong and I'm deciding faster if it's something I should choose or skip. Your tool is adapting to you and you're adapting to your tool to find the right balance :)
Of course, getting a new language to wide spread adoption is far from trivial, but that's a separate problem.
Look at the rest of that quote:
> The human, computer pair, will also interactively suggest, confirm and fine tune specifications of mathematical properties and invariants at points in the the program.
That hasn't happened and as far as I am aware, is not even close.
> This will help the computer assistant to not only better understand the program but also to to generate real time, verification test runs using SAT technology,
Ditto.
> Interactive testing will eliminate whole classes of logic bugs, making most non ui code correct by construction.
Ditto..
So, 1 out of 4 predictions correct, which makes it worse than random chance?
/s
Short summary of linked video: when your type system is powerful enough you can restrict the set of possible implementations to the point that the compiler can make a decent guess as to what the program should be to satisfy the type signature.
Isn't that just the Rust borrow checker?
I was just pointing out something fun.
JetBrains has their own experimental thing that is not enabled per default.
And there's also Codota and Tabnine.
Copilot is actually fairly late to the party here.
[1]: https://marketplace.visualstudio.com/items?itemName=VisualSt...
[2]: https://github.com/MicrosoftDocs/intellicode/blob/master/doc...
I think mostly we do have gone in that direction, even if probably even slower than the (already cautious) commenter predicted.
Honest question: why are we as a community so slow at evolving a good, solid programming environment?
I get that each time a new language is introduced, porting over all the existing code + training the people is an immense task. But this is _exactly the problem_, right?
Why aren’t we able to stop for a while and sort out once and for all a solid framework for coding?
It’s not a theoretical ideal: I’m very convinced that the dumb piling up of technologies/languages/frameworks that we use now is significantly slowing down the _actual daily work_ we do of producing software. Definitely >>50% of my time as a programmer is spent on accidental complexity, that i know for sure.
It’s very practical: at this point this whole thing simply feels like very bad engineering, tbh?
- A designer might use HTML/CSS/JS directly or with "low code" tools (AKA graphical IDEs, they are still essentially programming) to implement frontends or a bit of scripting to automate stuff in their Adobe tools.
- An analyst might use Excel (a programming environment) or SQL or some hybrid tool.
- Mathematicians and scientists are increasingly programming.
- An electrical technician or engineer programs their installations.
- And so on...
There isn't one paradigm or even a set of paradigms that fits them all. Some languages are deliberately straight forward and provide minimal abstractions, other languages have strong runtime guarantees, others enable flexible, composable abstractions.
I think programming will become even more diverse in the future.
1. Societal issues. Microsoft wanted Java they could control and change. C# it is then. Google is moving away from java to kotlin, because of disagreements with Oracle.
2. Wish of different trade offs. fast-to-learn vs feature-full vs ease-of-use vs configurability vs portability vs speed vs safety vs developer friendly vs user friendly vs admin friendly vs development-speed vs program corectness.
3. Low proof-of-concept cost. If some lib involves lot of boilerplate for my usecase, it is easy to create my own improved version and feel the sense of achievement (my version might be just a wrapper at first, but the gate have opened)
4. Reduction-of-programing-worlds-complexity is at the bottom of everybodies priority lists.
Since then, Java was completely open-sourced, having the same license as the Linux kernel, so there is nothing stopping android from using it. The preference for kotlin comes from the fact that Android’s Java is barely at OpenJDK’s Java 8 versions, making syntactic sugars all that much more important there.
Java and it's VM are OpenSource. So that argument doesn't make any sense.
Also I don't think Google would, or even could, move away form one of their primary languages.
Kotlin on the other hand is only a significant trend in Android development, and it will get dropped like a hot potato in favor of Dart as soon as Fuchsia arrives as Android successor, I guess.
Kotlin has a problem: It tries to be "the better Java", but Java is picking up (slowly) all the features. The space for a significantly more powerful JVM language is already taken by Scala. So in the long run there won't be much space for Kotlin left: As soon as Java will get "more modern Features" Kotlin will have a hard time to compete. As likely mostly only syntax differences will remain.
Do you have any idea just how much there's Android/Java/Kotlin code now?
> Kotlin has a problem: It tries to be "the better Java", but Java is picking up (slowly) all the features.
2016 called. Wants your opinion back. Kotlin is sooo much more now than "better Java", it is a Multiplatform, efficient and pragmatic language that is just pleasant to work with, unlike even modern Java.
It has first party support for iOS, Android, desktop and JS. It has modern Multiplatform GUI framework that rivals React and Flutter.
It has countless syntactic features and built-in null safety.
Java will be forever stuck in server and niche products like Intellij.
Does Google care? Ever had a look at their graveyard?
The rest sounds just like the usual marketing yada-yada and doesn't stand reality…
Please, Google graveyard meme here?
Name at least one DEVELOPMENT project that was killed by them. Even the infamous GWT is still alive on life support.
In case you're serious, it seems you don't understand or know the scale of Android project. Android is one of the most important projects of Google, it rivals Chrome and YouTube.
> The rest sound just like the usual marketing yada-yada and doesn't stand reality…
Please, launch your Java application on Node.js or in a browser, or on iOS, on Android for that matter. Or create modern client-side application that runs on all major platforms.
And no, Codename One/Gluon/JavaFX don't count. Even worst of the worst Ionic runs better than those.
Codename One works as well as Ionic when used by the right developer.
Oh I'm sure it is. Both of them are awfully terrible compared to even React Native/Flutter, let alone native.
It's not. Last time I used it, everything was super janky, the look of app from 90s also didn't impress me.
The DX is awful, compared to neat single binary of Flutter.
> React native isn't a write once run anywhere tool. As a result it has a lot of different problems which imo make it way worse than all of the above.
I only care about result, not semantics.
Google code. Google code search.
Given that languages used broadly in the industry are lacking behind research 20+ years that's not a good prediction. It's just the way things are going.
BTW: There's still no mainstream language with full dependent typing… (I count Haskell as mainstream; Scala seems closest¹ but still a long way to go).
Actually people are already so overwhelmed by all that really old stuff coming now to languages that some of them resort to even much more basic approaches on the level of the 70'ies, like Go, thinking programming is otherwise "too complicated". To add on that: I don't think "the average dude" will ever use for example depended types even they would appear in some broader used language.
My guess for the future is more that we will see a kind of split between a big group of people using advanced low-code like tools for programming day to day things and data exploration, and some much smaller group of "experts" doing the "hard things" needed to make those tools work. On the one hand side this will bring programming further "to the masses". But on the other hand side the hard parts will not only remain, they will get even harder and much less approachable by arbitrary people.
This is obviously true in abstract, but the real breakthrough happens when you make those concepts ergonomic for the working developer. The theory behind dependent types is well established, but I can't really write my next project in Idris, can I?
Similarly, there was a time when C was the only sensible choice to write anything non-academic, non-toy. It's not like people didn't know about OOP or functional programming back then, but it wasn't a realistic possibility.
Or parametric subtype polymorphism, also known by its common name "generics". The concept has been around at least since the 70s, C++ templates weren't widely used before what, 1990?
> My guess for the future is more that we will see a kind of split between a big group of people using advanced low-code like tools for programming day to day things
This has arguably already happened, we call them data scientists. Many of them are technical and have some light scripting skills but they couldn't be put to work on, say, your average backend project. Obviously this is a gross generalization, titles mean literally nothing, I'm pretty sure there exist data scientists that kick ass at coding.
> This is obviously true in abstract, but the real breakthrough happens when you make those concepts ergonomic for the working developer.
That's of course correct. That's actually why we're lacking behind research by such a long distance. It's not only type-systems. The "20 year lack to research" seems to be a quite general phenomena in IT. I'm not judging. It's an observation.
> This has arguably already happened, we call them data scientists.
I think this is only a facet of what I had in mind. I guess it will become more ubiquitous to use some "coding related" tools in a lot of places! But it won't be for sure software engineering what those people will do. I was thinking more in the direction of e.g. MS PowerApps. Or something on the spectrum between such thing and Jupyter notebooks.
But the elephant in the room? What about LISP?
To try to answer that by myself:
My guess is that (too?) "advanced" technology (at some point in time) doesn't get any traction on the mass market. That's another reason mainstream languages and tools lack significantly behind academia in my opinion. If something is called "academic" that implies "not pragmatic enough for use" for a lot of people, I suspect. (The LISP story has more to it but this would be largely off-topic so not going into that).
My input on lisp:
I think as far as "practical" programming is concerned, lisp kind of missed the critical window. There have been three phenomena occuring simultaneously:
- Computers become so powerful that it's now justifiable to use inefficient languages. Ecosystem develops around said languages (perl, ruby, python...)
- The web becomes the primary way to ship software. The OS C API isn't something you necessarily have to keep in mind at all times.
- Mainstream languages incorporate 'academic' features.
The combination of 1 and 2 made it so that up until the turn of the century (and realistically well into the 00s) C and to an extent C++ were first class citizens, and everything else was at most ancillary. The most efficient Lisp compilers out there produce code that's within a factor of 3 of C++. That's amazing by today's standards, but if you're programming Pentiums (and earlier 486s, 386s) you don't really have a factor of 3 to spare.
As for the capabilites of the language itself, even around 2000, lisp really was secret alien technology. But by the time you could actually either afford the performance penalty on the desktop or to be web-based, the "inefficient" bunch is now also an option, offering more expressivity than C/C++ and better libraries/batteries than lisps.
> My guess is that (too?) "advanced" technology (at some point in time) doesn't get any traction on the mass market.
The point here is, IMO, that IT in general and programming languages in particular are very hard to innovate. PL innovations by definition don't offer more features than the status quo ante. Once you have a programming language that's sufficiently high level and with a sufficiently efficient compiler (in our timeline that was C), programming languages are effectively "feature-complete", there's never going to be a language with a feature that can't be replicated in C. In other words, the leap from ASM to C (or Fortran, Cobol, whatever, I'm using C for the sake of argument) is a 10x improvement, but everything after that has significantly diminishing returns.
What you're really doing is improving developer productivity: not every project needs C, so maybe write Python and be done in a tenth of the time, with a tenth of the bugs and without buffer overruns.
However what the market is after is "total" productivity: if my codebase is already in C, it's a huge productivity loss if we move to $NEW_LANGUAGE, regardless of the new features, and because language innovations has diminishing returns, it becomes increasingly difficult to justify switching.
> If something is called "academic" that implies "not pragmatic enough for use" for a lot of people, I suspect.
With that said, you are correct that there is sometimes a knee-jerk reaction. See for example the unreasonable pretense that "monad" is some kind of black magic.
Lisps were developed on departmental and corporate "big iron" computers from the beginning. Initially out of necessity, because those were the only viable computers that existed. Then later out of necessity because it was the only computers on which it would run well.
Very few languages (or other software!) that were popular on expensive big iron in the 1960-1985 era transitioned into the microcomputer era with their popularity intact, or at all.
For a window of time, microcomputer enthusiasts were simply not able to make any use of the big iron software at all. Those who programmed big iron at work and micros on the side did not pass on the knowledge from the big iron side to the newcomers who only knew consumer microcomputers. They just passed on stories and folklore. You can't pass on the actual knowledge without giving people the hands-on experience. And so the microcomputer culture came up with its own now iconic software.
Today we run descendants of Unix because Unix was actually developed pretty late into that big iron era, on smaller iron hardware; like a clumsy but workable ballerina, Unix readily made the hops to workstations having a few megabytes of memory like early Suns, to microcomputers like better-equipped 386 boxes.
There are stories from the 1980's of people developing some technology using Lisp, but then crystalizing it and rewriting it in something else, like C, to actually make it run on inexpensive hardware so they could market it. CLIPS is one example of this; there are others.
I don't think that people had no cycle to spare on 286 and 386 boxes. This is not true because even some much slower languages than Lisp were used for real programming. People used programs written in BASIC on 1 MHz 8 bit micros for doing real work. By and large, most of those people had no exposure to Lisp. BASIC was slow, but it fit resource-wise. Not fitting well into the memory is the deal breaker. Performance is not always a deal-breaker.
The Ashton-Tate dBase languages were another example of slow languages, yet widely used. They ran well on business microcomputers, and carried the selling story of being domain specific languages for database programming, something tremendously useful to a business.
All that said, our thinking today shouldn't be shackled today by some historical events 1980 to 1990.
> Why aren’t we able to stop for a while and sort out once and for all a solid framework for coding?
There's never going to be one "solution" here. There will always be tradeoffs depending on the constraints of a given domain or problem space. One-size-fits-all solutions end up not being great for anything, since they have to make so many compromises.
Also great tools are made through solving real problems. If we just went to plato's heaven and dreamed up a "perfect" programming environment, we would end up with something which solves our problems in theory. But the issue with this is that our problems don't exist in theory, they exist in reality.
Looking back, the biggest changes between now and 2012 are:
* Git (and github) took over the world in the version control. Git was already the leader in 2012, but mercurial was doing ok and svn was still around to a much greater extent.
* Docker/Kubernetes and the container ecosystem. There was a guess here about app servers, but the poster seemed to thinking of PaaS platforms and Java app servers like Jetty more so. I guess you could say "serverless" is sort of in that vein, but it's far from the majority of use cases as the poster predicted.
* Functional programming ideas became mainstream, except in Go, which is a sort of reactionary back to basics language.
Overall though:
Good predictions:
* The IDE/editor space gets a shake up, though maybe not in the way any of the specific predictions guessed (the rise of VS code)
* Machine learning gets bigger
* Apple introduces a new language to replace Objective-C
* Some sort of middle ground to the dynamic/static divide (static languages have got local type inference, dynamic languages have got optional typing)
Bad predictions:
* No-code tools are still no further along mainstream adoption than 2012
* Various predictions that Lisp/ML/Haskell get more mainstream rather than just having their most accessible ideas cherry picked.
* A new development in version control displaces git
* DSLs, DSLs everywhere. DSLs for app development, DSLs for standard cross database NoSQL access,
I feel like there is also a return to basic imperative programming, with OO and functional where it makes sense.
In 200 years, people will still be predicting the rise of no code solutions.
If you are executing diagrams and schematics, you still have code. And the people maintaining that code are still coding. That is, they are coders. They're just working in a whole new stack that doesn't have git, diff, a variety of editors, open standards for encoding, etc.
Except for the perpetual no-code and DSL memes, whether git would dominate as much as it did was pretty much up in the air in 2012. Same with functional languages. In 2012 the mainstream was what, Java 1.6? ML/Haskell was like a breath of fresh air, it's hard to understate how pure OOP a la early Java sucks. The fact that some functional features would become mainstream wasn't a given back then, if anything, that is the surprising turn of events.
What will programming look like in 2020? - https://news.ycombinator.com/item?id=4962694 - Dec 2012 (3 comments)
Ask HN: What will programming look like in 2020? - https://news.ycombinator.com/item?id=4931774 - Dec 2012 (12 comments)
Rust and Zig have this, right?
> You'll abstract most applications with a DSL, structured of applets or formlets operating on an abstract client API. The same app can then be 'compiled' and served to multiple mediums - as a web-page, an android app, a Chrome app, or even a desktop app.
This is effectively React with Electron, React Native, etc. Of course the author was overly optimistic about how polished and effective cross platform apps would be, but it's still the same idea. React is a UI DSL with a reactive runtime that can run on many different platforms.
This user casually predicted Rust.
I’m not sure I’d call Rust mutable-first either. As for side-effects, I suspect the next leap in PL development will be an efficient algebraic-effects system with a good dev experience (or at least a trade-off so appealing it overcomes the necessary friction).
Well… No.
It misses some landmark features like HKTs, and it likely never won't get them.
Inspiration? Sure. But what lang today doesn't take that?
> I’m not sure I’d call Rust mutable-first either.
So what do the affine types track? ;-)
> As for side-effects, I suspect the next leap in PL development will be an efficient algebraic-effects system with a good dev experience (or at least a trade-off so appealing it overcomes the necessary friction).
Let's make "some effect system" out of it and I'm with you.
But it likely won't be Rust getting such features in the near or midterm future (no clue about such a possibility in the far future, though).
Other languages are almost there on the other hand side. Scala for example will get "ability tracking" real soon™ now.
Rust may seem a little bit like a FP lang at frist if you're coming form one. But after writing some code you going to realize that Rust's philosophy is quite different form a FP lang: Rust embraces mutability and side-effects at its core! It "just" tries to make that more safe.
Referential transparency is the one feature that makes reasoning about a program easy. You can think about referential transparent programs purely in the substitution model. You can move referential transparent expressions freely around as you please.
You can't think of a Rust program this way. It's inherently procedural.
Rust gets a lot of things quite right! But it's not a FP language. It's a better C. It's about shoveling bits and bytes around, as safely and efficient as possible.
* Long compile times * Too much micro libraries
> An accessible type system
As a sibling comment mentioned, typescript covers this more appropriately.
> - Deterministic memory behaviour - By-default strict evaluation
For most practical purposes, Golang and Java cover this. Rust / C++ is great is systems stuff, I am not going to use it for some application layer stuff, with all complexities that come with it.
> Commercial backing
Not much, really.
We’ll ignore every other bullet point containing fundamentally incorrect information also.
I think rust is the great language. But community is the worst thing about it.
https://web.archive.org/web/20210925211554/http://lambda-the...
P.S. these are predictions made in 2012 of what 2020 was going to be like.
Seriously, someone goes to the trouble of finding the archive link because the server is having trouble (note that someone else had mentioned it too, not just me), and it gets modded down. Why? What possible justification is there for that?
Then even mentioning the ridiculous modding down gets modded down further. Why? (and no, "because those are the rules" isn't a reason... did it ever occur to you that sometimes rules are wrong?).
It will be a complete shit.
So...
Nothing changed, then.
While increasing heterogeneous and concurrent architectures will certainly impact languages and frameworks (and there is much progress there already, e.g. to leverage clouds or GPUs), I'm more interested in how things like Project Glass, LEAP motion, Emotiv, and Touché might impact programming. Project Glass could provide pervasive access to eye-cams, voice, and HUD feedback. Something like that would be a suitable basis for pen and paper programming, or card-based programming, or various alternatives that involve laying out objects in the real world and clarifying with voice (perhaps non-speech voice).”
still no progress on this. Keyboard and mouse.
Minority Report is almost 20 years old.
i had high hopes for Project Soli:
I think the example of mail is instructive. Contrary to some "zeerust"-y predictions, we don't buy virtual stamps from the virtual store to virtually lick them before virtually walking to the virtual mailbox. Even with the vastly improved capabilities of 30-40 years in 3D technology, the concept is immediately bizarre.
In practice, we instead boiled away most of the extra bits and ended up with e-mail, which tries to minimize even the body-movement needed.
No one mentioned containers or anything related.
“I think you're right about virtualization, too. By 2020, hardware virtualization will be ubiquitous to the point that it's done for each application”
Isn’t this basically the architecture of the Apple M1 chips? They’ve got efficient cores and high-power cores.
Maybe in 10 more years we will all be writing in ML-family languages!
> I predict that functional programming will continue to gain ground as people discover the benefits of immutability and easy parallelism—but the functional language will not be Haskell, nor Scala, nor Clojure. At a guess, people will use something with:
>Strong tooling and libraries
>An accessible type system
>Deterministic memory behaviour
>By-default strict evaluation
>Commercial backing
>Every mainstream functional language is lacking in at least one of these areas.
If you follow the C++ development, you can see a huge effort to make it support more funcational paradigms (see for example the efforts for structural pattern matching). However, its backward compatibility requirements have limited it a lot. So even if Rust was C++++ without the backward compatibility baggage it could easily reach these ideals.
To me that's C++ snobbery talking. Long compile times, confusing type system, RAII as guiding design light
Just admit that it's basically C++
Wonder what the big new grunt work for 2030 will be.
What actually changed is that it's now more enforceable. Before GDPR there where all those laws but nobody cared really as there weren't proper punishments in place.
My idea for 2030: We're going to tackle all that web-development legacy as we're going to leave the time-sharing mainframe model again (actually for the same reasons as last time… ;-)). But maybe I'm to optimistic, and it'll be 2040 by than.
Pascal. That could be used as a systems programming language. Maybe it's not perfect - C++ wins when it comes to resource management - but that doesn't mean it's unfixable. Just fix the bits you don't like. Sorted.
I could go on: Dylan, Ada, even Basic. They all "work". We've been inventing language after language after language, and yet all the key ideas were already there.
Now, it's true, many are lacking the kinds of libraries we want. And most of these languages don't receive the love they need to smooth over the rough edges that have programmers reaching for the more popular languages.
Let us now consider programming languages that can be programmed graphically. These kinds of tools get announced with great hype, only to be ignored when everyone realises that it's more fuss that it's worth.
And yet, it's maybe not a complete wash. NodeRed looked practical, and Scratch seemed to have a place. In principle, the whole idea that a program can be viewed as a schematic has appeal.
Then there's the "MX" tool for STM32 MCUs (microcontrollers). It can used to configure the pins and peripherals of your MCU. I hated it at first, but now I'm seeing its advantage at simplifying configuration, even if it does spew out a ton of stuff.
One thing about MX is that it "understands" the chip, so it knows about conflicts of pins and the limitations of the chip. The key thing here is that it's a metatool, a kind of Domain Specific "Language" (although it's actually graphical). It can achieve something that general-purpose languages can't. There's no magic here, of course, the MX only understands the chips because it has been programmed to.
MX is completely useless for making things like database applications, for example.
So DSLs /can/ work - maybe - but they tend to suffer from the same problems as graphical programming tools. They are also niche products, so they don't tend to get much interest. They also tend to suffer from the problem of "walled gardens" - whereby anticipated things are trivial, but unanticipated things are impossible.
One of my own ideas is a kind of "compilation language". It would be a language, possibly a subset of a larger language, in which you could give developers something that "understands" their problem domain. I'm thinking something along the lines of C++'s notion of "constexpr all the things". Perhaps we could push this idea so far that we could build a set of libraries that the compiler itself executes and can validate other developer code.