Live data from Hacker News

What will programming look like in 2020? (2012)

lambda-the-ultimate.org

51–60 of 151 posts

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

#51
post #8

For 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 great…

> * No-code tools are still no further along mainstream adoption than 2012 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…

This is true, and there are also coders today who's code does not run on computers, but in people's heads as the implementation of diagrams and schematics.

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

#52
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…

FYI, specialize is the American spelling.

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

#53
post #22
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…

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

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

#54
post #39
post #6

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! 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, sol…

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

Google moving away from Java has nothing to do with Oracle. That lawsuit was about an old Sun license of Java that was thought to be hurt by Google.

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.

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

#55
post #37

Earlier quoted context omitted.

Does anyone actually use Copilot day to day? How much time does it actually save?

Writing boring chores or repetitive code is amazing. Need to handle all cases in a case in pretty much the same way but changing only one thing? Write the first one, the rest is auto coded perfectly.

Sounds like a technical debt generator. I feel for the devs who will have to clean up the legacy from this in 10 years.

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

#56
post #37

Earlier quoted context omitted.

Writing boring chores or repetitive code is amazing. Need to handle all cases in a case in pretty much the same way but changing only one thing? Write the first one, the rest is auto coded perfectly.

But isn't much better to just manually code it into reusable function and use it repeatedly, instead of letting AI generates all the boilerplate code and causes maintenance headache down the road?

> boring chores or repetitive code

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

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

#57
post #27
post #10

Earlier quoted context omitted.

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

Imperative programming will always be a thing as long as computer processors work the way they do (mutating and incrementing things).

Due to all the out of order executions and pipelines, they are quite functional at the same time - so that is not a good way to look at it.

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

#58
post #37

Earlier quoted context omitted.

Does anyone actually use Copilot day to day? How much time does it actually save?

Writing boring chores or repetitive code is amazing. Need to handle all cases in a case in pretty much the same way but changing only one thing? Write the first one, the rest is auto coded perfectly.

> Need to handle all cases in a case in pretty much the same way but changing only one thing? Write the first one, the rest is auto coded perfectly.

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)

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

#59

Earlier quoted context omitted.

Does anyone actually use Copilot day to day? How much time does it actually save?

Writing scrapers with it is also amazing. All from the puppeteer code, response interface and casting to a local class model. Very time saving indeed.

How close are you to being fully obsolete?
Post reply on HN