2012-01-04

My prediction for the software industry for 2012 and beyond


My prediction for 2012 and beyond:

* The software industry realizes we're fast heading towards a massive train wreck, because as everybody jumps on the bandwagon of "Ohnoes, the multicore era is actually here now, per-core speeds have plateaued, and my code isn't getting any faster, I'd better parallelize it", we start seeing a massive uptick in segfaults and deadlocks as an army of programmers that should never be writing multithreaded code start trying to do so.

* There is a sudden, frantic search for frameworks, toolkits, libraries and languages that provide a more natural expression of concurrency. Much time is wasted while people learn esoteric concurrency frameworks and languages and try to reimplement some of their core logic in these newer technologies, only to learn that they aren't the right tool for the job.

* 2012 comes to an end and from that point on, for the next 10 years, around December 15th every year, everybody starts asking if the following year might be the "year of implicit parallelization" -- the year we manage to get proper safe implicit parallelization into all mainstream language toolchains.

* In 2022, the software industry realizes that they were asking the wrong question during those 10 years, and that they shouldn't have been figuring out how to retrofit implicit parallelization into mainstream languages (which is impossible in the general case), or how to more safely abstract notions and patterns of concurrency, but rather they should have been trying to figure out what the underlying reason is for our human inability to write good multithreaded code, and what the reason is for the impossibility of adding generalized implicit parallelization to imperative languages. The software industry furthermore comes to the collective realization that a new language should have been developed long ago that is as utile as any mainstream language but has the correct theoretical underpinnings to guarantee its code can be safely, maximally and directly implicitly parallelized. Everybody aligns and this new language is created in 6 months through a massive outpouring of online collective creativity.

* In 2032, despite the emergence of a solution to the multicore dilemma 10 years earlier, the majority of code is still written single-threaded in imperative languages, including in linguistic atrocities such as Fortran and C++.

* In 2042, Perl 6 is released.

2 comments:

  1. What would a language "that has the correct theoretical underpinnings to guarantee its code can be safely, maximally and directly implicitly parallelized" look like?

    My view is that in parellelizing code, problems arise when you have shared memory and so careful understanding of architecture and synchronization is required. How can a language make that safer?

    ReplyDelete
  2. Scott: this was a loaded post, because I'm working on designing and building just such a system for implicit parallelization myself, which I'm calling the "Flow Programming Language": http://www.flowlang.net/p/flow-manifesto.html Proper language support, with zero programmer effort (basically, enabling optimal implicit parallelization and preventing programmers from shooting themselves in the foot with manual multithreading) is absolutely the right (and the only) way to solve the multicore dilemma properly.

    ReplyDelete