16 ms·
What will programming look like in 2020? (2012)
- daxfohl 5y agoNobody predicted GDPR or the need for multicloud. Wonder what the big new grunt work for 2030 will be.
- still_grokking 5y agoWell, GDPR is almost 1:1 identical to the regulations being in place "since forever" in Germany. 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.
- adenozine 5y agoLink seems busted for me...
- Turing_Machine 5y agoServer has apparently fallen over. Wayback Machine link: https://web.archive.org/web/20210925211554/http://lambda-the-ultimate.org/node/4655 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.
- Turing_Machine 5y agoNo good deed goes unpunished.
- Turing_Machine 5y agoI hope that made you feel good! 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?).
- mkl 5y agoComplaints about downvotes are boring, and are often made redundant when the comment is upvoted again, as happened here.
- tardibear 5y ago2012
- dang 5y agoAdded. Thanks!
- Micoloth 5y agoThe “ Some safe and some bold predictions” comment is almost exactly my view on how programming should evolve. (functional, reactive, going toward dependent types etc ) Interesting how in 2012 it was already so clear! 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?
- dgb23 5y agoThere are many different types of programming. For example there is an increasing amount of people who program but do not have programming related job titles. - 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.
- tapas73 5y agoMy take on this: 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.
- cortesoft 5y agoOne person predicted the AI IDE assistance. They were right that it is here, although I don’t think it is very accepted yet. No one mentioned containers or anything related.
- Macha 5y agoFor a mere 8 year timeframe, the predictions seem rather poor. It feels like there was such a push among people to have the forward thinking ideas that they overestimated how much would change. 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,
- Zababa 5y ago> Functional programming ideas became mainstream, except in Go, which is a sort of reactionary back to basics language. I feel like there is also a return to basic imperative programming, with OO and functional where it makes sense.
- RcouF1uZ4gsC 5y agoRust in 2021 is basically the functional programming language this commenter was predicting: > 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.
- neutronicus 5y agoRust is basically C++++ so I doubt it's what that commenter had in mind
- RcouF1uZ4gsC 5y agoOne of replies to the comment was that C++11 was what the commenter wanted, whereupon the commenter mentioned ways it did not meet the criteria. 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.
- zerr 5y agoMore like (C)++++ rather than (C++)++.
- tannhaeuser 5y agoC++-C
- neutronicus 5y agoEh 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++
- midwestemo 5y ago>What will programming look like in 2020? It will be a complete shit. http://lambda-the-ultimate.org/node/4655#comment-73750 http://lambda-the-ultimate.org/node/4655#comment-73750
- still_grokking 5y agoThe reply made me smile: So... Nothing changed, then. http://lambda-the-ultimate.org/node/4655#comment-73758 http://lambda-the-ultimate.org/node/4655#comment-73758
- dang 5y agoA couple small threads from back then: What will programming look like in 2020? - https://news.ycombinator.com/item?id=4962694 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 https://news.ycombinator.com/item?id=4931774 - Dec 2012 (12 comments)
- FnControlOption 5y ago> Unit testing will be built directly into languages as an intrinsic part, like compiler optimization or GC. Rust and Zig have this, right?
- kolme 5y agoAnd Clojure!
- junon 5y agohttp://lambda-the-ultimate.org/node/4655#comment-73772 http://lambda-the-ultimate.org/node/4655#comment-73772 > ... 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.
- chubot 5y ago> Leveraging the strengths of the computer and human will lead to an order of magnitude improvement in programmer productivity. Interactive testing will eliminate whole classes of logic bugs, making most non ui code correct by construction. 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.
- kaba0 5y agoMore like Brooks was the one being right (for like 3 decades now) with his ‘No silver bullets article’, in that we will not have another order of magnitude productivity change in programming after high level languages became a thing.
- kragen 5y agoBrooks wrote "No Silver Bullet" in 01987. The examples of high-level languages he mentions in his paper are Ada, Modula (not sure whether the 01975 version or Modula-2), Simula-67, APL, Pascal, Smalltalk, Fortran, COBOL, PL/I, and Algol, and of these he thinks Ada is the most promising. Does his thesis hold up in the face of modern programming language advances? 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 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 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.
- melling 5y ago“HCI-ware (and wear) 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: https://atap.google.com/soli/ https://atap.google.com/soli/
- Terr_ 5y agoPersonally I feel that Minority-Report-y predictions are foolish, because is ignores the human aspect in the name of glitz. Specifically, how tiring it is to hold your arms in the air all day. 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.
- hardwaregeek 5y agoThe App Servers prediction is actually a lot more accurate than I first thought: > 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.
- deleted 5y ago[deleted]
- zz865 5y agoThe reality is programming has taken a back seat while everyone spends all their time on containerization, k8s, cloud security and keeping up with what's hot right now.
- Spinnaker_ 5y agoOff topic, but is there a new site that replaced lambda-the-ultimate? It's such an amazing source of PL discussion... but mainly from 10 years ago.
- marcle 5y ago+1. I was about to post an almost identical comment.
- Cryptonic 5y agoI read a lot of comments there, basically the devs back then did not know it, but they hoped for Docker and it's applications, for Rust, some for Node =)
- quickthrower2 5y agoPredictably…’s prediction is basically Rust?
- Shoetp 5y ago> 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. This user casually predicted Rust.
- brabel 5y agoAccessible type system? Hm, I would think this would be more about TypeScript than Rust.
- still_grokking 5y agoI wouldn't call a "mutability first" language which relies mostly on side-effects "functional".
- FridgeSeal 5y agoRust’s type system is very close to Haskell’s and takes a lot of inspiration from functional programming. 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).
- still_grokking 5y ago> Rust’s type system is very close to Haskell’s and takes a lot of inspiration from functional programming. 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.
- FridgeSeal 5y ago> how the hardware will evolve: several (4-16) heterogeneous(not all with the same performance, some with specialized function unit) CPUs Isn’t this basically the architecture of the Apple M1 chips? They’ve got efficient cores and high-power cores.
- oflordal 5y agoARM big little (which the M1 is at least somewhat based on) was announced the year before the prediction.
- blippage 5y agoI had a play around with Logo the other day. In the end I decided to dive too deeply into it, but I came away thinking that there is basically nothing wrong with the language. It was invented in 1967. 1965! Yet it has everything "there". I think there's even a university professor who teaches Logo to undergraduates, too, claiming it is much better than Pascal. 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.
- pharmakom 5y agoProgramming changes at human speed because it requires programmers to learn. Maybe in 10 more years we will all be writing in ML-family languages!
- plastman 5y agoalmost excusively javascript frameworks
- CawCawCaw 5y agoIt is interesting to read some of these comments as an indication of what people actually hoped for, and then compare it to the reality of what they actually got.