Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What will programming look like in 2020? (2012)

lambda-the-ultimate.org

Post reply on HN
Print view View original

131–140 of 151 posts

Re: What will programming look like in 2020? (2012)

#131

Post by jhgb »

zozbot234 wrote: post #113
lelanthran wrote: post #62

Earlier quoted context omitted.

Cherry picking only the accurate prediction makes it seem like the predictor is really good! 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…

> That hasn't happened and as far as I am aware, is not even close. Isn't that just the Rust borrow checker?

In terms of end result, yes, but not in terms of means.

Re: What will programming look like in 2020? (2012)

#132

Post by laurentlbm »

kragen wrote: post #117
kaba0 wrote: post #53

Earlier quoted context omitted.

More 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.

Brooks 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…

Why do you write years with a preceding zero?

Re: What will programming look like in 2020? (2012)

#133

Post by rak1507 »

byteface wrote: post #125
meijer wrote: post #116

Earlier quoted context omitted.

> There's literally no point coding without it. Except maybe that it is still not generally available.

True. My son is on the waiting list several week now. But honestly traditional coding is the past. Soon they might be asking for someone with 12 months copilot experience. I don't mind the negative downvotes from luddites. Copilot is smarter and faster than you. Accept it and learn to use it.

If copilot is smarter and faster than you, that says more about you than it does about copilot :)

Re: What will programming look like in 2020? (2012)

#134

Post by qsort »

still_grokking wrote: post #127
qsort wrote: post #97

Earlier quoted context omitted.

> Given that languages used broadly in the industry are lacking behind research 20+ years 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…

> 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. 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.…

> But the elephant in the room? What about LISP?

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.

Re: What will programming look like in 2020? (2012)

#135

Post by kragen »

kaba0 wrote: post #128
kragen wrote: post #117

Earlier quoted context omitted.

Brooks 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…

I may not really get your point: are you trying to prove or disprove the original article? 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 produ…

Well, I was hoping to disprove it, and then I looked at things I'd written recently in high-level languages, for which I had logs of how long it took me, and came to the opposite conclusion: Python might be more productive than Ada, but not by an order of magnitude. Of course someone else might be a much better programmer than I am in Python, but in all likelihood their improvement over me in lower-level languages would be even bigger.

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.)

Re: What will programming look like in 2020? (2012)

#136

Post by moogly »

junon wrote: post #15

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 the…

People only seem to have heard about GitHub Copilot. But Microsoft has a similar solution (that is not as... invasive) that was first released in preview in 2018. It's called IntelliCode, available for multiple languages both for Visual Studio Code[1] and regular Visual Studio[2] (but not enabled by default last time I checked -- which was a while ago, granted).

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...

Re: What will programming look like in 2020? (2012)

#137

Post by kazinator »

qsort wrote: post #134
still_grokking wrote: post #127

Earlier quoted context omitted.

> 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. 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.…

> But the elephant in the room? What about LISP? 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 softw…

Your analysis is quite astute. Lisp systems became big and resource-hungry ahead of newer, more affordable, less powerful machines being able to keep up.

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.

Re: What will programming look like in 2020? (2012)

#138

Post by nomdep »

cortesoft wrote: post #7

One 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.

One comment does:

“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”

Re: What will programming look like in 2020? (2012)

#139

Post by byteface »

rak1507 wrote: post #133
byteface wrote: post #125

Earlier quoted context omitted.

True. My son is on the waiting list several week now. But honestly traditional coding is the past. Soon they might be asking for someone with 12 months copilot experience. I don't mind the negative downvotes from luddites. Copilot is smarter and faster than you. Accept it and learn to use it.

If copilot is smarter and faster than you, that says more about you than it does about copilot :)

If you don't think it is. It says a great deal about you too :)

Re: What will programming look like in 2020? (2012)

#140

Post by rak1507 »

byteface wrote: post #139
rak1507 wrote: post #133

Earlier quoted context omitted.

If copilot is smarter and faster than you, that says more about you than it does about copilot :)

If you don't think it is. It says a great deal about you too :)

I don't just think it isn't, I know it isn't. I've tried it, and watched friends try it too.

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.

Post reply on HN