The 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 wa…
What will programming look like in 2020? (2012)
31–40 of 151 posts
Re: What will programming look like in 2020? (2012)
#32http://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…
Re: What will programming look like in 2020? (2012)
#33Server has apparently fallen over. Wayback Machine link: 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.
No good deed goes unpunished.
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?).
Re: What will programming look like in 2020? (2012)
#34One 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.
Re: What will programming look like in 2020? (2012)
#35http://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…
Does anyone actually use Copilot day to day? How much time does it actually save?
Re: What will programming look like in 2020? (2012)
#36Wonder what the big new grunt work for 2030 will be.
Re: What will programming look like in 2020? (2012)
#37http://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…
Does anyone actually use Copilot day to day? How much time does it actually save?
Re: What will programming look like in 2020? (2012)
#38http://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…
Its honestly not that hard to predict, with a bit of statistics and some insights into early deep learning, its obvious that alot of data with discernable patterns will produce good results.
Re: What will programming look like in 2020? (2012)
#39The “ 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…
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.