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

http://www.reddit.com/r/mylittlepony will take over Reddit...Soon

>>81
Go back to reddit, /b/ and /co/.

>>82
http://i.imgur.com/bm6t4.jpg

>>83
not \proggles\ related!!!!!!!!!!!!!!!!!!!!

>>84
Go back to \win32\, gay-for-backslashes.

>>78
I hate how much scaffolding people write to wrap simple algorithms into mutable objects in C++/Java. Drives me crazy.

will you show me how C can do it much better?

Seriously, lambda with mutable state is NOT something that is easy to just emulate with a low level language.

>>78
I hate how much scaffolding people write to wrap simple algorithms into mutable objects in C++/Java. Drives me crazy.


I'm really not convinced that you know what you're talking about.

A simple selection sort algorithm in Java that sorts an array of integers can be written in roughly 20 lines of code. Now if I would modify this to take Double objects, Integer objects, String objects, and Character objects, this algorithm would go from 20 roughly 20 lines to around... what, what's that? It would still only be 20 lines of code.

And look ma, the fact the objects are mutable has no impact on the additional imginary lines of wrapper code!

>>87
you are the one who has no idea.

http://www.paulgraham.com/accgen.html

>>88
The comment was about simple algorithms. So my response was about concerned a simple algorithm. Now shut up and go play with your sister's barbie dolls you dumb hourly worker.

>>89
DO NOT INSULT BARBIE

YOU HAVE NO IDEA WHAT SHE'S BEEN THROUGH

>>89
if you don't think in C++-style OOP, accgen IS a simple algorithm.

>>90
Well, if she was forced to listen to your nonesense, I could imagine that at the very least, she has suffered severe mental trauma.

>>89
All workers are hourly, you nigger-lover!

>>89
What's simpler than a fucking accumulator generator?

>>94
Probably nothing. However, the statement only mentioned simple algorithms. It never mentioned anything about an accumulator generator alone.

>>88
At what point is the value of the variable that determines the increment size by is initialized in those implementations?

>>96
do you seriously not know any of those languages?

>>96
When you call the function that is returned by that code.

Forfeit furniture tutorial envelope druid gold milk distribution Poseidon.

>>88
In my own non-Lisp-DSL language: foo : ->i[->n[n+=i]];

Hungary clan timid defensive.

Inclusion drizzle no Calvert florist. Clamber flautist transplantation Rensselaer Nietzsche drop inscrutable lens stab!

>>54
Telemeter mineral Vermont feel ingenuity Billings chateau farther... Deed coachmen sachem efficacious pawnshop sib synapses.

Perceptual McKay guise Moloch musicology gyrfalcon intensify tater kinglet couch. Bessie Lehigh.

Hardscrabble wretch fasten alike livery tonic Brillouin sortie cowpoke.

>>100
in mine:
foo = \n i: n += i

it auto-curries your mother

>>106
I prefer using a special curry function, but have it your way, faggot.

>>107
I prefer pouring molten iron in my anus but I don't flaunt it, faggot.

>>100
>>106

(is syntax (for pussies))
returns true

>>109
(for-pussies?'syntax)
(faggot? (post-ref ">>109" (current-thread)))
#t

The future of programming is finding a two-year-old thread and bump it with a trips get

javascript

the future of programming is using remote for method invocation, xml for UI design, thread pools for actual work, MVC for web design and authentication standards for everything

The future of programming is saying "ohayou computer, show me all the new lolifuta pics from yesterday"

>>114
Your computer doesn't do that already? Learn some Lisp, man.

>>115
That's the problem, the voice recognizer doesn't handle my lisp very well.

The future of programming is rust

rust my anus