__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

There's a big difference between solving hardware problems and solving people problems, and an abstraction can ALWAYS be built between the two. Of course the abstraction will leak and it won't be the most efficient thing possible. At that point you have to gauge how much patience you have for things like setting compiler flags. I have patience for that AFTER I've profiled, and not before, and I refuse to let it affect my design until after I've profiled.

 A language with semantics designed for THIS attitude is the one that should win

That's why ParrotVM is such a good idea.

Functional concepts

Parrot has rich support for several features of functional programming including closures and continuations, both of which can be particularly difficult to implement correctly and portably, especially in conjunction with exception handling and threading. Implementing solutions to these problems at the virtual machine level prevents repeated efforts to solve these problems in the individual client languages.

http://en.wikipedia.org/wiki/Parrot_virtual_machine#Functional_concepts