The Downfall of Imperative Programming

James Miller james at aatch.net
Mon Apr 9 17:50:32 PDT 2012


* Sean Cavanaugh <WorksOnMyMachine at gmail.com> [2012-04-09 16:09:03 -0500]:
> On 4/9/2012 3:28 PM, Mirko Pilger wrote:
> >i guess this might be of interest to some.
> >
> >http://fpcomplete.com/the-downfall-of-imperative-programming/
> >
> >http://www.reddit.com/r/programming/comments/s112h/the_downfall_of_imperative_programming_functional/
> >
> 
> 
> I would counter a flow based programming approach solves a lot of
> the same concurrency problems and doesn't tie you to a programming
> style for the actual code (functional vs declarative) as each module
> can be made to do whatever it wants or needs to do.
> 

On top of that, while functional languages are cool, they tend to fall
down when you have to write more complex programs. I've seen Haskell
code that it incredibly verbose, simply because of it functional nature.
Pure functional is great, until you need a usable program, because
eventually you will want IO, and IO is unpure, you cannot predict it.

The better way is to have more of a sandbox model. IO and the like are
managed by a single thread (per object, so per file etc), that recieves
commands (I don't care how) to do things. Everything else is written
however you want, functional, imperative, declarative, whatever. You
then make all memory thread-local, no global memory at all, except
through a specific, controlled system that carefully controls access.
Ideally this system would only be used to pass around very large data
structures between threads.

This way, you get the advantages of pure functional, but don't miss the
advantages of mutable variables and being able to write in the
imperative style.

Slightly OT: With the unstoppable march of parallel programming, does
anybody else find node.js incredibly infuriating, since it is
single-core.

--
James Miller


More information about the Digitalmars-d mailing list