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

121–130 of 151 posts

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

#121

Post by chakkepolja »

kaba0 wrote: post #53
chubot wrote: post #22

Earlier quoted context omitted.

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

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.

Availability of internet & resources like Stack Overflow can be considered a silver bullet, if you consider less proficient / junior programmers.

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

#122

Post by chakkepolja »

Shoetp wrote: post #73

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

> Strong tooling and libraries

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

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

#123

Post by jen20 »

meijer wrote: post #116
byteface wrote: post #87

Earlier quoted context omitted.

I do every day. I code 5 times faster on problems several times harder. 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 j…

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

Or trivial matters like “license compliance”.

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

#124

Post by jen20 »

chakkepolja wrote: post #122
Shoetp wrote: post #73

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

> Strong tooling and libraries * 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 complexit…

I find it pretty hilarious that “too much micro libraries” is a criticism, but then you recommend TypeScript - which runs on Node.is, the progenitor of “micro libraries” in the next sentence.

We’ll ignore every other bullet point containing fundamentally incorrect information also.

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

#125

Post by byteface »

meijer wrote: post #116
byteface wrote: post #87

Earlier quoted context omitted.

I do every day. I code 5 times faster on problems several times harder. 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 j…

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

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

#126

Post by chakkepolja »

jen20 wrote: post #124
chakkepolja wrote: post #122

Earlier quoted context omitted.

> Strong tooling and libraries * 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 complexit…

I find it pretty hilarious that “too much micro libraries” is a criticism, but then you recommend TypeScript - which runs on Node.is, the progenitor of “micro libraries” in the next sentence. We’ll ignore every other bullet point containing fundamentally incorrect information also.

Didn't really say typescript is perfect. In terms of type system its just more accessible than rust.

I think rust is the great language. But community is the worst thing about it.

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

#127

Post by still_grokking »

qsort wrote: post #97
still_grokking wrote: post #70

Earlier quoted context omitted.

> The “ 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! 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…

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

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

#128

Post by kaba0 »

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…

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

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

#129

Post by 37ef_ced3 »

bspammer wrote: post #114
37ef_ced3 wrote: post #59

Earlier quoted context omitted.

How close are you to being fully obsolete?

The correct response to becoming obsolete is to learn something new, not to fight the thing making you obsolete. Doing the latter is about as productive as yelling at the tide to not come in.

Yes, I guess it's like complaining about nuclear weapons. Best to embrace them.

If we can do it, we should do it. All technology is progress. All technology improves the human existence.

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

#130

Post by jhgb »

GuuD wrote: post #71
CardenB wrote: post #63

Earlier quoted context omitted.

Can you explain how this is worse than random chance?

It is, for people who think that the chance of meeting dinosaur on the street is 50% (you either do or don’t) /s

Does that account for multiverses?
Post reply on HN