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/

On Mon, 09 Apr 2012 22:28:01 +0200
Mirko Pilger <pilger@cymotec.de> wrote:

> i guess this might be of interest to some.

Yes, it is...and I wonder if D's FP features are good enough? Author mentions D, but says:"...This is all good, but not enough..."



Sincerely,
Gour


-- 
Everyone is forced to act helplessly according to the qualities he has acquired from the modes of material nature; therefore no one can refrain from doing something, not even for a moment.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810

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.

  I like functional languages, but the only one that seems to have much support is F#.


 I've used TBB Flow Graph in C++ and found it to be a major improvement over straight parallel algorithms/tasks/message passing etc which seem to be the norm(like in D).  Expressing dependencies between separate nodes was super easy.



  Do any other languages have support for flow based concurrency like C++/TBB?

* Sean Cavanaugh <WorksOnMyMachine@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

Am Tue, 10 Apr 2012 12:50:32 +1200
schrieb James Miller <james@aatch.net>:

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

Don't blame the library. EcmaScript was designed to be single-core. I imagine that web scripting language to be much more complex with multi-threading in user code. You are using the wrong tool for the job ;)

-- 
Marco

On Monday, 9 April 2012 at 20:22:30 UTC, Mirko Pilger wrote:
> http://fpcomplete.com/the-downfall-of-imperative-programming/
---
All data is immutable. All functions are pure. You might think this is crazy — how can you program with such stifling restrictions? It turns out that people have been doing just that for a long time. In fact the most popular language for parallel and distributed programming is Erlang — a functional language. An even better candidate for parallel programming is Haskell, which supports a large variety of parallel paradigms.
---
http://flyingfrogblog.blogspot.com/2008/08/haskells-virginity.html
Oookay.

* Marco Leise <Marco.Leise@gmx.de> [2012-04-10 05:57:52 +0200]:

> Am Tue, 10 Apr 2012 12:50:32 +1200
> schrieb James Miller <james@aatch.net>:
> 
> > Slightly OT: With the unstoppable march of parallel programming, does anybody else find node.js incredibly infuriating, since it is single-core.
> 
> Don't blame the library. EcmaScript was designed to be single-core. I imagine that web scripting language to be much more complex with multi-threading in user code. You are using the wrong tool for the job ;)
> 
> -- 
> Marco
> 

I meant that the fact that node.js is gaining popularity, despite the fact that we want to move away from single-threaded applications, is incredibly backwards.

I'm not using node, I have to use PHP at work, which at the very least gets help from the webserver in terms of parallel processing.

--
James Miller

On Tuesday, 10 April 2012 at 10:38:28 UTC, James Miller wrote:
> * Marco Leise <Marco.Leise@gmx.de> [2012-04-10 05:57:52 +0200]:
>
>> Am Tue, 10 Apr 2012 12:50:32 +1200
>> schrieb James Miller <james@aatch.net>:
>> 
>> > Slightly OT: With the unstoppable march of parallel programming, does
>> > anybody else find node.js incredibly infuriating, since it is
>> > single-core.
>> 
>> Don't blame the library. EcmaScript was designed to be single-core. I imagine that web scripting language to be much more complex with multi-threading in user code. You are using the wrong tool for the job ;)
>> 
>> --
>> Marco
>> 
>
> I meant that the fact that node.js is gaining popularity, despite the
> fact that we want to move away from single-threaded applications, is
> incredibly backwards.
>
> I'm not using node, I have to use PHP at work, which at the very least
> gets help from the webserver in terms of parallel processing.
>
> --
> James Miller

I haven't used it, but node.js has clusters
(http://nodejs.org/docs/v0.6.0/api/cluster.html) which often
should be just as good.

But performing I/O using single-threaded asynchronous I/O instead
of threaded blocking I/O is a huge win in terms of performance -
it would just be nice to have threading on top to do the number
crunching work.

No really.

Scala, Clojure and Ocaml also do have quite industry support already.
Actually on my job, any client would pick one of those over D, as they
are slowly being accepted in enterprise projects.

A curious fact is that the FP fans have much to thank to Microsoft, as
it is the company with more FP research on their paychecks. Many open
source fans are not aware that a few of the main developers in the Ocaml and Haskell communities, work for Microsoft Research labs.

--
Paulo

Am 10.04.2012 02:25, schrieb Froglegs:
> I like functional languages, but the only one that seems to have much
> support is F#.
>
>
> I've used TBB Flow Graph in C++ and found it to be a major improvement
> over straight parallel algorithms/tasks/message passing etc which seem
> to be the norm(like in D). Expressing dependencies between separate
> nodes was super easy.
>
>
>
> Do any other languages have support for flow based concurrency like
> C++/TBB?