Ask HN: What big programming productivity gains you see happening in 5-10 yrs?

As I see it, the number one hurdle in software productivity is human understanding. The more understandable software is and the easier it is to make software understandable, the faster and more accurately it can be modified.<p>This is why functional models like React, DSL models like SQL, and constraint models are so widely used — they make what&#x27;s happening in the software more understandable (at a worthwhile performance cost).<p>A few of my own contributions:<p>* Legible Mathematics: <a href="http:&#x2F;&#x2F;glench.com&#x2F;LegibleMathematics&#x2F;" rel="nofollow">http:&#x2F;&#x2F;glench.com&#x2F;LegibleMathematics&#x2F;</a><p>* Flowsheets – showing data as you program: <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=y1Ca5czOY7Q" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=y1Ca5czOY7Q</a><p>* REPLugger – showing data as you program in large systems: <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=F8p5bj01UWk" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=F8p5bj01UWk</a><p>* FuzzySet interactive code documentation: <a href="http:&#x2F;&#x2F;glench.github.io&#x2F;fuzzyset.js&#x2F;ui&#x2F;" rel="nofollow">http:&#x2F;&#x2F;glench.github.io&#x2F;fuzzyset.js&#x2F;ui&#x2F;</a>

The cycle repeats over and over. Monolith becomes unmanageable and get chopped into loosely coupled, functionally independent replaceables: mainframes to containers, application servers to micro services, etc. Drag and drop coding hits the wall and gets overrun by old languages: 4GL to C++&#x2F;Java, HyperCard to Objective C, etc. The monoliths are currently numerous in the single page application realm, choose your framework. Eventually these will succumb to smaller more flexible and purposeful components.

&gt; Another productivity booster is Cross-Platform frameworks.<p>I would be so, so happy to see a UI framework that runs (well) on Windows, Mac, Linux, Android, and iOS. My druthers would be for it to have bondings to a JVM language (Kotlin is my happy place these days), but I would be okay writing in any similarly productive language.<p>Flutter is trying to get there, but it&#x27;s not a viable solution on the desktop yet, and somehow doesn&#x27;t even have a decent HTML widget. I do like Dart, however; it&#x27;s similar enough to Kotlin&#x2F;Swift that I&#x27;m comfortable writing it, even if I have to look up exact syntax now and then.<p>Electron wants to solve this problem, but we all know the arguments about its bloated runtime and egg-cooking power usage.<p>I suppose Progressive Web Apps and WebAssembly have the potential to solve this, too.

Not a lot of comments so far, but a few people are talking about stuff that is in the general vein of better tooling and code generation&#x2F;automation through deeper code understanding by our tooling.<p>I think that this sentiment is interesting, because the way I see it, this can only happen if we continue the trend of transitioning to static typing.<p>We can&#x27;t really do much more for dynamic language tooling today than we are already doing unless we solve the halting problem. The very nature of the problem (of providing smarter tooling) requires us to be able to gather metadata about our code, without having to execute it. This means static information.<p>We have invented all sorts of schemes circumvent this problem, like the plethora of documentation generation tools that exist. Of course, there is more to documentation than just information about the types of the arguments of functions and such, so documentation tools will always have their place. But I contend that a large part of the benefit a lot of the documentation provides for many languages is simply typing information. And I also believe that with well engineered type systems and API typings, the types themselves can provide enough information to use a lot of APIs without having to reach for external documentation.<p>Or to paraphrase: in any code documentation generation tool for a dynamic language, there is a half-finished implementation of a badly formalized, insufficiently powerful static type system.<p>Typescript&#x27;s huge rise in popularity seems to suggest that a lot of people used mostly to dynamic languages really wanted static typing all this time but just didn&#x27;t know.<p>I think if we could combine some of the concepts of typescript with Haskell&#x27;s type system, so that we can have both nominal and structural typing, we would have power to challenge the gods. If we are able to harness all the information in such a type system, we could provide very powerful tooling that will basically be able to write code for us, as long as the types are right (automatically filling typed holes).<p>I am obviously a proponent of static typing, but I&#x27;d be interested in hearing if there&#x27;s someone on the other side of the fence that has some ideas for how we can improve upon dynamic language productivity without solving the halting problem.

&gt; breakthrough innovation in programming which will enable programmers to deliver ambitious web&#x2F;mobile apps at a very high speed.<p>That&#x27;s a pretty narrow framing. 10 years from now, a lot of programming won&#x27;t look like traditional application development at all. For example, a self-driving car or other machine with a similar level of automation is a valuable product that requires a lot of programming but doesn&#x27;t fit into the category of &quot;web&#x2F;moble app.&quot; Or consider the development of natural language interfaces: right now this is at the level of Alexa skills, but over the next 10 years we will see frameworks that allow programmers to specify not just a few phrases, but mini-languages for entire domains: pilots talking to airplanes, doctors talking to EMRs, etc.<p>Use cases like this suggest that frameworks similar to PyTorch&#x2F;Tensorflow will become increasingly important. These frameworks have features (particularly automatic differentiation, very sophisticated yet easy-to-use SGD optimizers like Adam, and built-in GPU support), which hugely increase productivity and lower the barrier to entry compared to the tools of 10 years ago yet they still have tons of rough edges. Its easy to imagine that 10 years from now they&#x27;ll be even more powerful and easier to use; for example I&#x27;m pretty excited about the future possibilities of tools like [AutoGraph][AG].<p>[AG]: <a href="https:&#x2F;&#x2F;medium.com&#x2F;tensorflow&#x2F;autograph-converts-python-into-tensorflow-graphs-b2a871f87ec7" rel="nofollow">https:&#x2F;&#x2F;medium.com&#x2F;tensorflow&#x2F;autograph-converts-python-into...</a>

40 hour max work weeks enforced and 4 day work weeks. Shifts for people that need to monitor ops.<p>Offices for everyone on staff that like to work in a quiet place and pubic areas for people who like to work in those places .<p>Also, the minimization of time spent in meetings .

The gains from every developer having really good go-to-definition and find-references for all languages and code bases would be immense. The Language Server Protocol (LSP) from Microsoft has standardized a way for languages to provide these features, and more and more editor and language implementations are being built.

Some other reinvented wheel that makes one thing 10x easier but takes five years to build up an infrastructure from scratch for everything else that real programs need (an infrastructure that was already present in whatever the new thing replaced). Let a bit more time pass to forget a few other things, rinse and repeat. In other words, no net productivity gains, just churn.

The pendulum is now swinging back to types. Because it&#x27;s a pendulum, in 5-10 years the next hot productivity thing is going to be dynamic, type-free languages.<p>I still remember when people were excited by the productivity gains from Ruby. &quot;No time wasted wrestling with casts and typing&quot;.

WebAssembly as the prevailing cross-platform VM and used as the main distribution mechanism for most applications.

I don&#x27;t think programming productivity gains are coming.<p>I see webassembly terribly fragmenting the frontend skill distribution, not in a good way.<p>I see the next generation of programmers more populated by tech debt creators and less accepting of mentorship.<p>I see non-volatile storage gains dramatically changing how OSs think about RAM and storage, even to the point that we might see RAM mostly vanish (unless you need volatility, like crypto keys), and machine shutdown&#x2F;startup becoming instant. As non-volatile storage continues to approach RAM latency, we&#x27;ll need a new generation of operating systems and probably programming languages too.<p>I see people continuing to overpay for PaaS systems that can&#x27;t scale, creating software that&#x27;s ever more difficult to change and tightly coupled to proprietary cloud systems.

TypeScript revolutionized the act of writing JavaScript<p>React and JSX revolutionized the act of writing HTML<p>GraphQL revolutionized the act of connecting front end and back end<p>But for CSS... SASS, SCSS, LESS, and such are by comparison pretty pedestrian tweaks on vanilla CSS

The line between programmer and dev ops will be moved with more responsibilities on the developer. Cloud services will continue to decrease the barrier of entry while entering a price war, and every team or individual will have a set budget inside the cloud. Integration with IDEs and improved online UI and CLI tools will make these tasks very easy for everyone. We can also expect better&#x2F;easier&#x2F;cheaper support infrastructure for these applications. Imagine one click upload of a web app from IDEs with load balancing, monitoring, analytics, and profiling.<p>I&#x27;d also like to see some improvements on programming paradigms to take advantage of multicore CPUs. There are lots of ideas in this space, but no clear front runner ideology. I expect we&#x27;ll continue to see improvements in this space, and hopefully a winner will emerge.

Javascript performance on mobile continues to get better every year.<p>For many of the informational based apps, it&#x27;s totally overkill to create a native experience. One app, responsive views, and your small team is suddenly incredibly productive.

&gt; what do you think will be a breakthrough innovation in programming which will enable programmers to deliver ambitious web&#x2F;mobile apps at a very high speed<p>I&#x27;m not sure that speed-to-market will be where the breakthroughs are. But constraining myself to that conditional...<p>The best one I can think of is a library of curated, easily embeddable snippets. Like Helm charts for code. We already have package managers, but as the industry grows more and more with a larger number (not necessarily percentage) of developers churning out sub-par code, companies are going to want to leverage reuse sans fear. You already see this curation with some languages&#x2F;ecosystems having sets of blessed libraries, but a library is too high of an abstraction and it is language specific. Some group one day will offer embeddable, curated snippets (or entire libraries) that follow a certain set of rules to give confidence to their users and they will apply those rules (with language specifics) across runtimes. In both good and bad ways, some systems may end up being a walled garden of code where they only accept this curated code which, as walled gardens can be, are good for the users (i.e. devs referencing the code) and bad for the devs (i.e. devs writing new components being forced into others&#x27; rules).<p>Would you feel better with a &quot;Guaranteed by StringentCodeTrust(tm)&quot; seal on a library&#x2F;repository you reference? A non-pragmatic middle manager at Big Corp might.

Web application deployment got way easier than it was 10 years ago. Now now there are plenty of alternatives for CI and testing tools that can automate the process of releasing and verifying code at scale. By scale I mean lots of developers collaborating on the same code base and handling massive loads at the same time.<p>It&#x27;s also the field that I think will see lots of improvements and maybe some fundamental disruptions. Maybe it will be GitHub actions and it&#x27;s right around the corner :)

&gt; Considering this background, what do you think will be a breakthrough innovation in programming which will enable programmers to deliver ambitious web&#x2F;mobile apps at a very high speed.<p>Quality, Speed, Price. Pick two.<p>What is the driving force to &quot;...deliver ... at a very high speed?&quot; It&#x27;s easy to assume that from the list above quality would be the one to suffer. Doesn&#x27;t anyone here on HN ever get tired of being everyone&#x27;s beta bitch?

Kubernetes and other container systems are so widely adopted and accepted that most common system services are solved and require only minutes to integrate. As a result people move back to their monoliths because it is easy and productive

AWS has lots of tools which have made me feel like a super developer. For example, using Lambdas and S3 to build massively parallel processing systems in just a few days.

I think just finally getting rid of unsafe languages, particularly at the bottom. This will I think increase &quot;productivity&quot; of the world at large, by reducing the number of crashes and security holes they have to contend with every day.<p>I feel like we have finally arrived at the time when more people accept no-one (or at least, no-one outside a tiny set of people) should be using languages with undefined behaviour, or unsafe memory accesses by default (looking at you C and C++).<p>If &quot;we&quot; want to be taken seriously, and as more of the world relies on computing, we can&#x27;t be building on a foundation of sand and saying &quot;Oh, as well as every programmer is clever enough, all the time, we&#x27;ll probably be OK&quot;.

As languages with more interesting type systems come along, more powerful IDE tooling will be possible (e.g. idris 2&#x2F;blodwen code completion <a href="https:&#x2F;&#x2F;twitter.com&#x2F;edwinbrady&#x2F;status&#x2F;1050528305743622147" rel="nofollow">https:&#x2F;&#x2F;twitter.com&#x2F;edwinbrady&#x2F;status&#x2F;1050528305743622147</a>)<p>More hopefully, maybe new language developers will put more work into easier and easier FFIs? How often have you thought &quot;I wish language X could catch on, but all the useful libraries are in language Y?&quot;

I expect to have a visual dataflow programming environment similar to node-red, Yahoo! Pipes etc. that is touchscreen-friendly, has plenty of community-maintained building blocks and converts to a variety of low-level languages for easy deployment to many platforms. Hopefully, we&#x27;ll get rid of clunky IDEs&#x2F;text editors with lots of boilerplate, whole file hierarchies to maintain and all that other ancient stuff invented for 1960&#x27;s teletypes.

The cost of using and teaching formal methods will continue to come down and program synthesis will become the practical means of automating a lot of lower-level code.

Have there been any major productivity gains in the past 5-10 years? Not really. So I see no reason to expect any in the next 5-10 years.

I could definitely see some type of declarative language + constraints being driven by a voice AI system.<p>This would let you rapidly prototype ideas

AI powered intellisense and code generation.

JavaScript precompiler techniques (like <a href="https:&#x2F;&#x2F;svelte.technology&#x2F;" rel="nofollow">https:&#x2F;&#x2F;svelte.technology&#x2F;</a>) should find their way down to everyday use cases, like abstracting away Canvas DOM programming and GPL and other programming difficulties.

&gt; Frameworks like React &amp; Angular give you decent building blocks to create SPAs, but the learning curve &amp; effort required to create ambitious applications is very high.<p>Any ambitious application is going to require a high learning curve and lots of effort. Otherwise it wouldn&#x27;t be ambitious.

- Context-aware IDEs with significantly more powerful versions of today&#x27;s intellisense tools.<p>- Compilers with even more powerful implicit behavior- forget automatically creating Get() and Set(), we&#x27;ll be creating entire inheritance structures with one function definition.

I think people will see that type safety and functional programming don’t impact productivity much in a business setting, and we’ll see a flight from these languages as examples of horrible legacy code reveal themselves to show that the problem is behavioral &#x2F; sociological, and has nothing to do at all with enforcement on the code or compilation vs testing.<p>I also think more job candidates will reject interviews that waste time with unrealistic homework assignments, marathon on-site interviews, etc.<p>Finally, I think productivity losses and health issues related to open-plan offices will soar, but companies will continue to be disingenuous and act like it improves collaboration or saves money when it’s uncotroversially flat false.

Continued increase in network speeds.

Runtime code analysis: instead of analyzing code at rest, we need to have better tools to tell us what the code actually <i>does</i>. Static typing doesn&#x27;t help you trace back from an interface to the code that generated that interface. Runtime analysis can potentially be applied across systems, so we can analyze not just one program, but how a whole myriad of systems work together, which is the way most complex systems work.

The decline of JavaScript. Web Assembly will soon have DOM access. It will be game-on for other languages in the browser.<p>Let&#x27;s be honest, is JavaScript the winner because it is amazing, or the winner because it was the <i>only</i> choice in the browser. I know my opinion. The other ecosystems, with different strengths, will soon be able to achieve single-language stacks when the playing field is leveled. This will be a boon to productivity.

A quick scan through the comments and I was surprised that no one referenced the No Silver Bullet essay[0].<p>From where I sit I find that the Cambrian explosion of frameworks, systems and methodologies is causing us to regress in terms of productivity.<p>[0] <a href="http:&#x2F;&#x2F;worrydream.com&#x2F;refs&#x2F;Brooks-NoSilverBullet.pdf" rel="nofollow">http:&#x2F;&#x2F;worrydream.com&#x2F;refs&#x2F;Brooks-NoSilverBullet.pdf</a>

Maybe the software industry will discover constraint programming the way that it discovered functional programming over the past decade. If it did, that would almost immediately increase programmer productivity for non-performance-critical tasks (since the compiler could supply the implementation), while making formal methods more easily applicable to production code &amp; supplying the prerequisites for more clever automatic code generation methods.<p>(In general, software engineers becoming vaguely aware of tech invented in the 1960s and 1970s is a huge productivity boon. If you, as a developer, want to impress your peers, you should take a couple hours to read what software engineers thought was obvious prior to 1980, when software engineers had a strong background in software engineering.)

Slimmer frameworks. I went from jQuery to React to Angular to Vue and they keep getting simpler and more user-friendly. I still think the templating system in Vue is a bit clunky but better than alternatives. Expect responsive frameworks to become even more scalable.

Search, i.e. lower activation threshold for accessing intelligence from strangers elsewhere in the world.

Smarter people, perhaps?

None.<p>There is no silver bullet:<p><a href="http:&#x2F;&#x2F;faculty.salisbury.edu&#x2F;~xswang&#x2F;Research&#x2F;Papers&#x2F;SERelated&#x2F;no-silver-bullet.pdf" rel="nofollow">http:&#x2F;&#x2F;faculty.salisbury.edu&#x2F;~xswang&#x2F;Research&#x2F;Papers&#x2F;SERelat...</a>