__future__

What is /prog/'s opinion on the future of programming?
-Will functional languages really take over?
-Are there any other paradigms rising out of obscurity?
-Will the hardware we run on change drastically? Would this affect how we program? Think quantum computers and shit (/tech/esqe, but entirely related to what we do)

I think that in the future the use of multi-paradigm languages will become almost standard when it comes to writing anything. Concurrent programming is the way of the future; it is currently the only way Moore's Law will continue to be followed. However there are elements of functional languages that make them difficult for practical use, so switching between and combining paradigms where necessary may be the way to go. However we will end up with most languages looking like C++, or worse; a mess of different ways of achieving the same goal (I still love me some C++).

As such I don't see a massive shift to functional languages taking place just yet, however I do think we will see the incorporation of functional features into OO and procedural languages. However I feel that the need for functional languages is inevitable; we are moving closer and closer to a world where we are having to concurrently use data from different sources at once and functional languages simplify this situation greatly.

I actually haven't learned a functional language yet, but am probably going to try pick up Haskell and F# later in the year. Most of the information I've got on the functional style comes from http://www.defmacro.org/ramblings/fp.html

Given that all computers are Turing-complete, I don't think we'll make any changes to our actual programming style. High level languages will remain almost exactly the same, save maybe an idea or two. But I do think that the future of hardware could have a gigantic effect on cryptography. I haven't read much about this, but I am very interested in the effect it could have.

*virtual machines everywhere. all will support autothreading.
Autothreading? I know the last three points of yours are trolls, but the third one, I'm not so sure. Are you delusional?

There is no such thing as autothreading. There's not enough information in a programmer's written code to somehow automatically figure out how to efficiently parallelize it, in current languages and experimental language additions.

Concurrency isn't hard. The current trend has nothing to do with the compiler automating it. Rather, it is based around task-oriented parallelism, which does hide the details of threads and scheduling of tasks, but you still need to ensure that access to shared memory is synchronized, or better yet that no two tasks can touch the same region of memory.

There is no silver bullet for concurrency. There is no sweeping algorithm for concurrency that automates everything, like how garbage collection automated memory management.

Certain languages try push one or two idioms for concurrency, but it's forced as fuck, it's like trying to build a house with only a hammer but no saw.

The only way to approach concurrency effectively is to embrace a wide range of idioms and patterns and know which ones are best suited for your particular problems.