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

>>29
You're assuming that in C or C++ programmers have to manage threads and hardware cores. You are mistaken. Anyone who isn't an amateur has moved beyond working with threads. What do you think our concurrency frameworks are for? They provide adaptive work-stealing task schedulers, in fact, very similar to the exact same underlying task schedulers inside of a typical a Haskell runtime implementation.

If I lived in a world where 32 cores was the norm ( wait, what's this? 50 cores? http://en.wikipedia.org/wiki/Knight%27s_Corner ), I would just use TBB or MPL or OpenMP or Grand Central Dispatch and I'd let the library figure it out. The semantics of the library abstractions are such that the runtime CAN figure it out, to a pretty good extent, even going as far as to group tasks that access similar sets of data on threads assigned via affinity to run on the same NUMA nodes on hardware, to improve cache locality.

Again, I'll reiterate, this isn't a problem that can be solved only with a special language. Haskell doesn't even solve it all in the language, much of it is done via libraries supplied to the programmer.