Doubts about functional programming paradigm

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
42 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Doubts about functional programming paradigm

Abhishek Kumar
I am a beginner in haskell.I have heard a lot about haskell being great for parallel programming and concurrency but couldn't understand why?Aren't iterative algorithms like MapReduce more suitable to run parallely?Also how immutable data structures add to speed?I'm having trouble understanding very philosophy of functional programming, how do we gain by writing everything as functions and pure code(without side effects)?
Any links or references will be a great help.
Thanks 
Abhishek Kumar

_______________________________________________
Beginners mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
Reply | Threaded
Open this post in threaded view
|

Re: Doubts about functional programming paradigm

Sanatan Rai

I'd recommend writing out some code and then deciding. Functional programming is not a panacea, just the challenges are in different places. Proponents claim that the challenges are in the *right* place. Your mileage might vary.

I recommend working through 'Real World Haskell' as a good place to start.

--Sanatan

On 11 Dec 2015 15:07, "Abhishek Kumar" <[hidden email]> wrote:
I am a beginner in haskell.I have heard a lot about haskell being great for parallel programming and concurrency but couldn't understand why?Aren't iterative algorithms like MapReduce more suitable to run parallely?Also how immutable data structures add to speed?I'm having trouble understanding very philosophy of functional programming, how do we gain by writing everything as functions and pure code(without side effects)?
Any links or references will be a great help.
Thanks 
Abhishek Kumar

_______________________________________________
Beginners mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners


_______________________________________________
Beginners mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
Reply | Threaded
Open this post in threaded view
|

Re: Doubts about functional programming paradigm

Sumit Sahrawat, Maths & Computing,
 IIT (BHU)
If you're looking to start, I'll recommend the learnhaskell guide: https://github.com/bitemyapp/learnhaskell

On 11 December 2015 at 20:42, Sanatan Rai <[hidden email]> wrote:

I'd recommend writing out some code and then deciding. Functional programming is not a panacea, just the challenges are in different places. Proponents claim that the challenges are in the *right* place. Your mileage might vary.

I recommend working through 'Real World Haskell' as a good place to start.

--Sanatan

On 11 Dec 2015 15:07, "Abhishek Kumar" <[hidden email]> wrote:
I am a beginner in haskell.I have heard a lot about haskell being great for parallel programming and concurrency but couldn't understand why?Aren't iterative algorithms like MapReduce more suitable to run parallely?Also how immutable data structures add to speed?I'm having trouble understanding very philosophy of functional programming, how do we gain by writing everything as functions and pure code(without side effects)?
Any links or references will be a great help.
Thanks 
Abhishek Kumar

_______________________________________________
Beginners mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners


_______________________________________________
Beginners mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners




--
Sumit Sahrawat,

Junior - Mathematics and Computing,
Indian Institute of Technology - BHU,
Varanasi, India

_______________________________________________
Beginners mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
Reply | Threaded
Open this post in threaded view
|

Re: Doubts about functional programming paradigm

Imants Cekusins
In reply to this post by Abhishek Kumar
> parallel programming and concurrency but couldn't understand why?

Let's experiment: spread a programming task across large teams.

in project A each programmer work on their area but may also change
other's code. Programmers also depend on the progress their
colleagues' make.

in project B each programmer works on their own code with inputs and
putputs well defined. There is no dependency on other programmers.

Even if you did not work in both scenarios (project A & B), it is
probably easy to imagine how both projects could progress.


> how immutable data structures add to speed?

 immutable data structures add to reliability.


> what do we gain by writing everything as functions and pure code(without side effects)?

pure code gives consistency and allows to split larger programs into
parts without fear for end result.
_______________________________________________
Beginners mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
Reply | Threaded
Open this post in threaded view
|

Re: Doubts about functional programming paradigm

Daniel Bergey
In reply to this post by Abhishek Kumar
On 2015-12-11 at 10:07, Abhishek Kumar <[hidden email]> wrote:
> I am a beginner in haskell.I have heard a lot about haskell being great for
> parallel programming and concurrency but couldn't understand why?Aren't
> iterative algorithms like MapReduce more suitable to run parallely?Also how
> immutable data structures add to speed?I'm having trouble understanding
> very philosophy of functional programming, how do we gain by writing
> everything as functions and pure code(without side effects)?
> Any links or references will be a great help.

Functional languages make it easy to decompose problems in the way that
MapReduce frameworks require.  A few examples (fold is another name for
reduce):

sum :: [Double] -> Double
sum xs = foldr (+) 0 xs

sumSquares :: [Double] -> Double
sumSquares xs = foldr (+) 0 (map (**2) xs)

-- foldMap combines the map & fold steps
-- The Monoid instance for String specifies how to combine 2 Strings
-- Unlike numbers, there's only one consistent option
unlines :: [Text] -> Text
unlines xs = foldMap (`snoc` '\n') xs

We'd need a few changes[1] to make this parallel and distribute across many
computers, but expressing the part that changes for each new MapReduce
task should stay easy.

Immutable data by default helps with concurrency.  Speed may or may not be
the goal.  We want to be able to distribute tasks (eg, function calls)
across processor cores, and run them in different order, without
introducing race conditions.

Simon Marlow's book is great at explaining parallel & concurrent
concepts, and the particular tools for applying them in Haskell:
http://chimera.labs.oreilly.com/books/1230000000929

bergey

Footnotes:
[1]  OK, many changes.

_______________________________________________
Beginners mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
Reply | Threaded
Open this post in threaded view
|

Re: Doubts about functional programming paradigm

MJ Williams
A pure functional language enables you to reason about your code,
something you can't easily achieve with your average C or Java. And by
`reason' I am referring to mathematical proof. Haskell makes it very
simple, actually.  Why should you want to reason about your code?
Think the hassle you could avoid if you knew what your code really
meant and did when executed.

The absence of side effects is part of another concept in FP, namely,
`referential transparency'.  If your function `f' maps a value `x' to
a value `y' then `f x' will always equal `y' and no more. In other
words, your function `f' won't change anything e.g. assign to
variables, or other state changes as well as mapping `x' to `y', and
that's an absolute certainty, in theory, at any rate.

That's a very crude overview of at least part of what functional
programming is about.  I'm hoping it'll encourage others on this list
with far more in-depth knowledge of the subject matter to come in and
fill in the gaps and iron out the ambiguities.

Matthew


On 11/12/2015, Daniel Bergey <[hidden email]> wrote:

> On 2015-12-11 at 10:07, Abhishek Kumar <[hidden email]> wrote:
>> I am a beginner in haskell.I have heard a lot about haskell being great
>> for
>> parallel programming and concurrency but couldn't understand why?Aren't
>> iterative algorithms like MapReduce more suitable to run parallely?Also
>> how
>> immutable data structures add to speed?I'm having trouble understanding
>> very philosophy of functional programming, how do we gain by writing
>> everything as functions and pure code(without side effects)?
>> Any links or references will be a great help.
>
> Functional languages make it easy to decompose problems in the way that
> MapReduce frameworks require.  A few examples (fold is another name for
> reduce):
>
> sum :: [Double] -> Double
> sum xs = foldr (+) 0 xs
>
> sumSquares :: [Double] -> Double
> sumSquares xs = foldr (+) 0 (map (**2) xs)
>
> -- foldMap combines the map & fold steps
> -- The Monoid instance for String specifies how to combine 2 Strings
> -- Unlike numbers, there's only one consistent option
> unlines :: [Text] -> Text
> unlines xs = foldMap (`snoc` '\n') xs
>
> We'd need a few changes[1] to make this parallel and distribute across many
> computers, but expressing the part that changes for each new MapReduce
> task should stay easy.
>
> Immutable data by default helps with concurrency.  Speed may or may not be
> the goal.  We want to be able to distribute tasks (eg, function calls)
> across processor cores, and run them in different order, without
> introducing race conditions.
>
> Simon Marlow's book is great at explaining parallel & concurrent
> concepts, and the particular tools for applying them in Haskell:
> http://chimera.labs.oreilly.com/books/1230000000929
>
> bergey
>
> Footnotes:
> [1]  OK, many changes.
>
> _______________________________________________
> Beginners mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>
_______________________________________________
Beginners mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
Reply | Threaded
Open this post in threaded view
|

Re: Doubts about functional programming paradigm

Thomas Jakway
Building on that, I think coming to Haskell with a very specific goal in mind (like swap Haskell for Java in my map reduce problem) kind of misses the point.  Haskell may or may not be faster/better suited to map reduce vs Java, but the real reason to use/learn Haskell is elegance and correctness.  The lack of side effects and referential transparency means you're far more likely to prevent bugs.  And there's a pretty substantial learning curve coming from imperative languages so if you need to speed up map reduce on a deadline you will be more productive in the imperative language of your choice (for now).

Dont take this as discouragement, I think Haskell (and FP in general) is very well suited to that kind of problem.  I'm a beginner in Haskell and it's already had a huge impact on how I think about all the code I write, not just the occasional toy Haskell project.

On Dec 11, 2015 1:08 PM, MJ Williams <[hidden email]> wrote:

>
> A pure functional language enables you to reason about your code,
> something you can't easily achieve with your average C or Java. And by
> `reason' I am referring to mathematical proof. Haskell makes it very
> simple, actually.  Why should you want to reason about your code?
> Think the hassle you could avoid if you knew what your code really
> meant and did when executed.
>
> The absence of side effects is part of another concept in FP, namely,
> `referential transparency'.  If your function `f' maps a value `x' to
> a value `y' then `f x' will always equal `y' and no more. In other
> words, your function `f' won't change anything e.g. assign to
> variables, or other state changes as well as mapping `x' to `y', and
> that's an absolute certainty, in theory, at any rate.
>
> That's a very crude overview of at least part of what functional
> programming is about.  I'm hoping it'll encourage others on this list
> with far more in-depth knowledge of the subject matter to come in and
> fill in the gaps and iron out the ambiguities.
>
> Matthew
>
>
> On 11/12/2015, Daniel Bergey <[hidden email]> wrote:
> > On 2015-12-11 at 10:07, Abhishek Kumar <[hidden email]> wrote:
> >> I am a beginner in haskell.I have heard a lot about haskell being great
> >> for
> >> parallel programming and concurrency but couldn't understand why?Aren't
> >> iterative algorithms like MapReduce more suitable to run parallely?Also
> >> how
> >> immutable data structures add to speed?I'm having trouble understanding
> >> very philosophy of functional programming, how do we gain by writing
> >> everything as functions and pure code(without side effects)?
> >> Any links or references will be a great help.
> >
> > Functional languages make it easy to decompose problems in the way that
> > MapReduce frameworks require.  A few examples (fold is another name for
> > reduce):
> >
> > sum :: [Double] -> Double
> > sum xs = foldr (+) 0 xs
> >
> > sumSquares :: [Double] -> Double
> > sumSquares xs = foldr (+) 0 (map (**2) xs)
> >
> > -- foldMap combines the map & fold steps
> > -- The Monoid instance for String specifies how to combine 2 Strings
> > -- Unlike numbers, there's only one consistent option
> > unlines :: [Text] -> Text
> > unlines xs = foldMap (`snoc` '\n') xs
> >
> > We'd need a few changes[1] to make this parallel and distribute across many
> > computers, but expressing the part that changes for each new MapReduce
> > task should stay easy.
> >
> > Immutable data by default helps with concurrency.  Speed may or may not be
> > the goal.  We want to be able to distribute tasks (eg, function calls)
> > across processor cores, and run them in different order, without
> > introducing race conditions.
> >
> > Simon Marlow's book is great at explaining parallel & concurrent
> > concepts, and the particular tools for applying them in Haskell:
> > http://chimera.labs.oreilly.com/books/1230000000929 
> >
> > bergey
> >
> > Footnotes:
> > [1]  OK, many changes.
> >
> > _______________________________________________
> > Beginners mailing list
> > [hidden email]
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners 
> >
> _______________________________________________
> Beginners mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners 
_______________________________________________
Beginners mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
Reply | Threaded
Open this post in threaded view
|

Re: Doubts about functional programming paradigm

Darren Grant-2
In reply to this post by Abhishek Kumar

Regarding concurrency+immutability with respect to both reliability and performance:

One way to think about synchronizing concurrent programs is by sharing memory. If the content of that memory changes, then there is a risk of race conditions arising in the affected programs. (A common source of vexing bugs, and complications for compilers.) But if the contents are somehow guaranteed not to change (ie. a specific definition of immutability), then no race conditions are possible for the lifetime of access to that memory.

Although this is a greatly simplified illustrative explanation, it is generally at the heart of arguments for immutability aiding performance. Unchanging regions of memory tend to permit simpler sorts of models since limitations are lifted on synchronization. This in turn allows both more freedom to pursue many otherwise tricky optimizations, such as ex. deciding when to duplicate based on cache geometry, trivially remembering old results, etc.

Regarding the discourse on purely functional programs not having side effects:

Writing pure programs without side effects is a little tricky to talk about, since this has some very precise technical meanings depending on whom you talk to. (What constitutes an effect? Where is the line between intentional and unintentional drawn?)

Maybe think of this statement as part of the continuum of arguments about languages that allow us to write simpler programs that more precisely state the intended effects.

Cheers,
Darren

On Dec 11, 2015 07:07, "Abhishek Kumar" <[hidden email]> wrote:
I am a beginner in haskell.I have heard a lot about haskell being great for parallel programming and concurrency but couldn't understand why?Aren't iterative algorithms like MapReduce more suitable to run parallely?Also how immutable data structures add to speed?I'm having trouble understanding very philosophy of functional programming, how do we gain by writing everything as functions and pure code(without side effects)?
Any links or references will be a great help.
Thanks 
Abhishek Kumar

_______________________________________________
Beginners mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners


_______________________________________________
Beginners mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
Reply | Threaded
Open this post in threaded view
|

Re: Doubts about functional programming paradigm

Christopher Allen
Having the option of communicating by sharing memory, message-passing style (copying), or copy-on-write semantics in Haskell programs is why I've found Haskell to be a real pleasure for performance (latency, mostly) sensitive services I frequently work on. I get a superset of options in Haskell for which I don't have any one choice that can really match it in concurrency problems or single-machine parallelism. There's some work to be done to catch up to OTP, but the community is inching its way a few directions (Cloud Haskell/distributed haskell, courier, streaming lib + networking, etc.)

Generally I prefer to build out services in a conventional style (breaking out capacities like message backends or persistence into separate machines), but the workers/app servers are all in Haskell. That is, I don't try to replicate the style of cluster you'd see with Erlang services in Haskell, but I know people that have done so and were happy with the result. Being able to have composable concurrency via STM without compromising correctness is _no small thing_ and the cheap threads along with other features of Haskell have served to make it so that concurrency and parallelization of Haskell programs can be a much more modular process than I've experienced in many other programming languages. It makes it so that I can write programs totally oblivious to concurrency or parallelism and then layer different strategies of parallelization or synchronization after the fact, changing them out at runtime if I so desire! This is only possible for me in Haskell because of the non-strict semantics and incredible kit we have at our disposal thanks to the efforts of Simon Marlow and others. Much of this is ably covered in Marlow's book at: http://chimera.labs.oreilly.com/books/1230000000929 

Side bar: although using "pure" with respect to effects is the common usage now, I'd urge you to consider finding a different wording since the original (and IMHO more meaningful) denotation of pure functional programming was about semantics and not the presence or absence of effects. The meaning was that you had a programming language whose semantics were lambda-calculus-and-nothing-more. This can be contrasted with ML where the lambda calculus is augmented with an imperative language that isn't functional or a lambda calculus. Part of the problem with making purity about effects rather than semantics is the terrible imprecision confuses new people. They'll often misunderstand it as, "Haskell programs can't perform effects" or they'll think it means stuff in "IO" isn't pure - which is false. We benefit from having a pure functionalal programming language _especially_ in programs that emit effects. Gabriel Gonzalez has a nice article demonstrating some of this: http://www.haskellforall.com/2015/03/algebraic-side-effects.html

When I want to talk about effects, I say "effect". When I want to say something that doesn't emit effects, I say "effect-free" and when it does, "effectful". Sometimes I'll say "in IO" for the latter as well, where "in IO" can be any type that has IO in the outermost position of the final return type.

But, in the end, I'm not really here to convince anybody to use Haskell. I'm working on http://haskellbook.com/ with my coauthor Julie because I thought it was unreasonably difficult and time-consuming to learn a language that is quite pleasant and productive to use in my day to day work. If Haskell picks up in popularity, cool - more libraries! If not, then it remains an uncommon and not well-understood competitive advantage in my work. I'm not sure I mind either outcome as long as the community doesn't contract and it seems to be doing the opposite of that lately.

I use Haskell because I'm lazy and impatient. I do not tolerate tedious, preventable work well. Haskell lets me break down my problems into digestible units, it forces the APIs I consume to declare what chicanery they're up to, it gives me the nicest kit for my work I've ever had at my disposal. It's not perfect - it's best if you're comfortable with a unix-y toolkit, but there's Haskellers on Windows keeping the lights on too.

Best of luck to Abhishek whatever they decide to do from here. I won't pretend Haskell is "easy" - you have to learn more before you can write the typical software project, but it's an upfront cliff sorta thing that converts into a long-term advantage if you're willing to do the work. This is more the case than what I found with Clojure, Erlang, Java, C++, Go, etc. They all have a gentler upfront productivity cliff, but don't pay off nearly as well long-term in my experience. YMMV.

On Fri, Dec 11, 2015 at 3:13 PM, Darren Grant <[hidden email]> wrote:

Regarding concurrency+immutability with respect to both reliability and performance:

One way to think about synchronizing concurrent programs is by sharing memory. If the content of that memory changes, then there is a risk of race conditions arising in the affected programs. (A common source of vexing bugs, and complications for compilers.) But if the contents are somehow guaranteed not to change (ie. a specific definition of immutability), then no race conditions are possible for the lifetime of access to that memory.

Although this is a greatly simplified illustrative explanation, it is generally at the heart of arguments for immutability aiding performance. Unchanging regions of memory tend to permit simpler sorts of models since limitations are lifted on synchronization. This in turn allows both more freedom to pursue many otherwise tricky optimizations, such as ex. deciding when to duplicate based on cache geometry, trivially remembering old results, etc.

Regarding the discourse on purely functional programs not having side effects:

Writing pure programs without side effects is a little tricky to talk about, since this has some very precise technical meanings depending on whom you talk to. (What constitutes an effect? Where is the line between intentional and unintentional drawn?)

Maybe think of this statement as part of the continuum of arguments about languages that allow us to write simpler programs that more precisely state the intended effects.

Cheers,
Darren

On Dec 11, 2015 07:07, "Abhishek Kumar" <[hidden email]> wrote:
I am a beginner in haskell.I have heard a lot about haskell being great for parallel programming and concurrency but couldn't understand why?Aren't iterative algorithms like MapReduce more suitable to run parallely?Also how immutable data structures add to speed?I'm having trouble understanding very philosophy of functional programming, how do we gain by writing everything as functions and pure code(without side effects)?
Any links or references will be a great help.
Thanks 
Abhishek Kumar

_______________________________________________
Beginners mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners


_______________________________________________
Beginners mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners




--
Chris Allen
Currently working on http://haskellbook.com

_______________________________________________
Beginners mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
Reply | Threaded
Open this post in threaded view
|

Re: Doubts about functional programming paradigm

MJ Williams
What is a `race condition'?

On 11/12/2015, Christopher Allen <[hidden email]> wrote:

> Having the option of communicating by sharing memory, message-passing style
> (copying), or copy-on-write semantics in Haskell programs is why I've found
> Haskell to be a real pleasure for performance (latency, mostly) sensitive
> services I frequently work on. I get a superset of options in Haskell for
> which I don't have any one choice that can really match it in concurrency
> problems or single-machine parallelism. There's some work to be done to
> catch up to OTP, but the community is inching its way a few directions
> (Cloud Haskell/distributed haskell, courier, streaming lib + networking,
> etc.)
>
> Generally I prefer to build out services in a conventional style (breaking
> out capacities like message backends or persistence into separate
> machines), but the workers/app servers are all in Haskell. That is, I don't
> try to replicate the style of cluster you'd see with Erlang services in
> Haskell, but I know people that have done so and were happy with the
> result. Being able to have composable concurrency via STM without
> compromising correctness is _no small thing_ and the cheap threads along
> with other features of Haskell have served to make it so that concurrency
> and parallelization of Haskell programs can be a much more modular process
> than I've experienced in many other programming languages. It makes it so
> that I can write programs totally oblivious to concurrency or parallelism
> and then layer different strategies of parallelization or synchronization
> after the fact, changing them out at runtime if I so desire! This is only
> possible for me in Haskell because of the non-strict semantics and
> incredible kit we have at our disposal thanks to the efforts of Simon
> Marlow and others. Much of this is ably covered in Marlow's book at:
> http://chimera.labs.oreilly.com/books/1230000000929
>
> Side bar: although using "pure" with respect to effects is the common usage
> now, I'd urge you to consider finding a different wording since the
> original (and IMHO more meaningful) denotation of pure functional
> programming was about semantics and not the presence or absence of effects.
> The meaning was that you had a programming language whose semantics were
> lambda-calculus-and-nothing-more. This can be contrasted with ML where the
> lambda calculus is augmented with an imperative language that isn't
> functional or a lambda calculus. Part of the problem with making purity
> about effects rather than semantics is the terrible imprecision confuses
> new people. They'll often misunderstand it as, "Haskell programs can't
> perform effects" or they'll think it means stuff in "IO" isn't pure - which
> is false. We benefit from having a pure functionalal programming language
> _especially_ in programs that emit effects. Gabriel Gonzalez has a nice
> article demonstrating some of this:
> http://www.haskellforall.com/2015/03/algebraic-side-effects.html
>
> When I want to talk about effects, I say "effect". When I want to say
> something that doesn't emit effects, I say "effect-free" and when it does,
> "effectful". Sometimes I'll say "in IO" for the latter as well, where "in
> IO" can be any type that has IO in the outermost position of the final
> return type.
>
> But, in the end, I'm not really here to convince anybody to use Haskell.
> I'm working on http://haskellbook.com/ with my coauthor Julie because I
> thought it was unreasonably difficult and time-consuming to learn a
> language that is quite pleasant and productive to use in my day to day
> work. If Haskell picks up in popularity, cool - more libraries! If not,
> then it remains an uncommon and not well-understood competitive advantage
> in my work. I'm not sure I mind either outcome as long as the community
> doesn't contract and it seems to be doing the opposite of that lately.
>
> I use Haskell because I'm lazy and impatient. I do not tolerate tedious,
> preventable work well. Haskell lets me break down my problems into
> digestible units, it forces the APIs I consume to declare what chicanery
> they're up to, it gives me the nicest kit for my work I've ever had at my
> disposal. It's not perfect - it's best if you're comfortable with a unix-y
> toolkit, but there's Haskellers on Windows keeping the lights on too.
>
> Best of luck to Abhishek whatever they decide to do from here. I won't
> pretend Haskell is "easy" - you have to learn more before you can write the
> typical software project, but it's an upfront cliff sorta thing that
> converts into a long-term advantage if you're willing to do the work. This
> is more the case than what I found with Clojure, Erlang, Java, C++, Go,
> etc. They all have a gentler upfront productivity cliff, but don't pay off
> nearly as well long-term in my experience. YMMV.
>
> On Fri, Dec 11, 2015 at 3:13 PM, Darren Grant <[hidden email]> wrote:
>
>> Regarding concurrency+immutability with respect to both reliability and
>> performance:
>>
>> One way to think about synchronizing concurrent programs is by sharing
>> memory. If the content of that memory changes, then there is a risk of
>> race
>> conditions arising in the affected programs. (A common source of vexing
>> bugs, and complications for compilers.) But if the contents are somehow
>> guaranteed not to change (ie. a specific definition of immutability),
>> then
>> no race conditions are possible for the lifetime of access to that
>> memory.
>>
>> Although this is a greatly simplified illustrative explanation, it is
>> generally at the heart of arguments for immutability aiding performance.
>> Unchanging regions of memory tend to permit simpler sorts of models since
>> limitations are lifted on synchronization. This in turn allows both more
>> freedom to pursue many otherwise tricky optimizations, such as ex.
>> deciding
>> when to duplicate based on cache geometry, trivially remembering old
>> results, etc.
>>
>> Regarding the discourse on purely functional programs not having side
>> effects:
>>
>> Writing pure programs without side effects is a little tricky to talk
>> about, since this has some very precise technical meanings depending on
>> whom you talk to. (What constitutes an effect? Where is the line between
>> intentional and unintentional drawn?)
>>
>> Maybe think of this statement as part of the continuum of arguments about
>> languages that allow us to write simpler programs that more precisely
>> state
>> the intended effects.
>>
>> Cheers,
>> Darren
>> On Dec 11, 2015 07:07, "Abhishek Kumar" <[hidden email]> wrote:
>>
>>> I am a beginner in haskell.I have heard a lot about haskell being great
>>> for parallel programming and concurrency but couldn't understand
>>> why?Aren't
>>> iterative algorithms like MapReduce more suitable to run parallely?Also
>>> how
>>> immutable data structures add to speed?I'm having trouble understanding
>>> very philosophy of functional programming, how do we gain by writing
>>> everything as functions and pure code(without side effects)?
>>> Any links or references will be a great help.
>>> Thanks
>>> Abhishek Kumar
>>>
>>> _______________________________________________
>>> Beginners mailing list
>>> [hidden email]
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>>>
>>>
>> _______________________________________________
>> Beginners mailing list
>> [hidden email]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>>
>>
>
>
> --
> Chris Allen
> Currently working on http://haskellbook.com
>
_______________________________________________
Beginners mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
Reply | Threaded
Open this post in threaded view
|

Re: Doubts about functional programming paradigm

Dimitri DeFigueiredo
In reply to this post by Christopher Allen
+1 for composable concurrency through STM. It multiplies programmer effectiveness many times when doing concurrent programming. I now consider threads, condition variables and locks "cruel and unusual punishment".

However, the learning curve in Haskell is not a small problem. It is *the* crucial problem with the language. I believe it is exactly what will prevent the language for becoming mainstream in the foreseeable future (e.g. 10 years). Consider a snippet of an error message from GHC that previously appeared in this list

Couldn't match expected type ‘r’ with actual type ‘COParseResult’
      ‘r’ is a rigid type variable bound by
          the type signature for
            getParseResult :: ParseResult r => String -> IO r
            ...

I have a PhD in computer science, but never really liked programming languages back then and somehow I never learned what a "rigid type variable" is. I was happily chugging along until I came to haskell and was confronted with this error message. Does one have to be a type theorist to make sense of this error message? Strictly speaking, I am complaining about GHC not haskell. But would anyone care to explain to a novice in a couple paragraphs why  foldl (+) 0 [1..10^9] may take 10 Gigs of RAM to calculate?

My advice to anyone who wants to learn haskell is to join social groups as we are not yet ready to teach it through books. I frequently have to go read academic papers to learn new topics. That shows me that the knowledge used to build the language simply has not been digested enough to be easily accessible to the average programmer.

Summarizing,

Learning Haskell: It will be a bumpy ride, but there *is* a happy ending.



Cheers,


Dimitri


On 12/11/15 7:36 PM, Christopher Allen wrote:
Having the option of communicating by sharing memory, message-passing style (copying), or copy-on-write semantics in Haskell programs is why I've found Haskell to be a real pleasure for performance (latency, mostly) sensitive services I frequently work on. I get a superset of options in Haskell for which I don't have any one choice that can really match it in concurrency problems or single-machine parallelism. There's some work to be done to catch up to OTP, but the community is inching its way a few directions (Cloud Haskell/distributed haskell, courier, streaming lib + networking, etc.)

Generally I prefer to build out services in a conventional style (breaking out capacities like message backends or persistence into separate machines), but the workers/app servers are all in Haskell. That is, I don't try to replicate the style of cluster you'd see with Erlang services in Haskell, but I know people that have done so and were happy with the result. Being able to have composable concurrency via STM without compromising correctness is _no small thing_ and the cheap threads along with other features of Haskell have served to make it so that concurrency and parallelization of Haskell programs can be a much more modular process than I've experienced in many other programming languages. It makes it so that I can write programs totally oblivious to concurrency or parallelism and then layer different strategies of parallelization or synchronization after the fact, changing them out at runtime if I so desire! This is only possible for me in Haskell because of the non-strict semantics and incredible kit we have at our disposal thanks to the efforts of Simon Marlow and others. Much of this is ably covered in Marlow's book at: http://chimera.labs.oreilly.com/books/1230000000929 

Side bar: although using "pure" with respect to effects is the common usage now, I'd urge you to consider finding a different wording since the original (and IMHO more meaningful) denotation of pure functional programming was about semantics and not the presence or absence of effects. The meaning was that you had a programming language whose semantics were lambda-calculus-and-nothing-more. This can be contrasted with ML where the lambda calculus is augmented with an imperative language that isn't functional or a lambda calculus. Part of the problem with making purity about effects rather than semantics is the terrible imprecision confuses new people. They'll often misunderstand it as, "Haskell programs can't perform effects" or they'll think it means stuff in "IO" isn't pure - which is false. We benefit from having a pure functionalal programming language _especially_ in programs that emit effects. Gabriel Gonzalez has a nice article demonstrating some of this: http://www.haskellforall.com/2015/03/algebraic-side-effects.html

When I want to talk about effects, I say "effect". When I want to say something that doesn't emit effects, I say "effect-free" and when it does, "effectful". Sometimes I'll say "in IO" for the latter as well, where "in IO" can be any type that has IO in the outermost position of the final return type.

But, in the end, I'm not really here to convince anybody to use Haskell. I'm working on http://haskellbook.com/ with my coauthor Julie because I thought it was unreasonably difficult and time-consuming to learn a language that is quite pleasant and productive to use in my day to day work. If Haskell picks up in popularity, cool - more libraries! If not, then it remains an uncommon and not well-understood competitive advantage in my work. I'm not sure I mind either outcome as long as the community doesn't contract and it seems to be doing the opposite of that lately.

I use Haskell because I'm lazy and impatient. I do not tolerate tedious, preventable work well. Haskell lets me break down my problems into digestible units, it forces the APIs I consume to declare what chicanery they're up to, it gives me the nicest kit for my work I've ever had at my disposal. It's not perfect - it's best if you're comfortable with a unix-y toolkit, but there's Haskellers on Windows keeping the lights on too.

Best of luck to Abhishek whatever they decide to do from here. I won't pretend Haskell is "easy" - you have to learn more before you can write the typical software project, but it's an upfront cliff sorta thing that converts into a long-term advantage if you're willing to do the work. This is more the case than what I found with Clojure, Erlang, Java, C++, Go, etc. They all have a gentler upfront productivity cliff, but don't pay off nearly as well long-term in my experience. YMMV.

On Fri, Dec 11, 2015 at 3:13 PM, Darren Grant <[hidden email]> wrote:

Regarding concurrency+immutability with respect to both reliability and performance:

One way to think about synchronizing concurrent programs is by sharing memory. If the content of that memory changes, then there is a risk of race conditions arising in the affected programs. (A common source of vexing bugs, and complications for compilers.) But if the contents are somehow guaranteed not to change (ie. a specific definition of immutability), then no race conditions are possible for the lifetime of access to that memory.

Although this is a greatly simplified illustrative explanation, it is generally at the heart of arguments for immutability aiding performance. Unchanging regions of memory tend to permit simpler sorts of models since limitations are lifted on synchronization. This in turn allows both more freedom to pursue many otherwise tricky optimizations, such as ex. deciding when to duplicate based on cache geometry, trivially remembering old results, etc.

Regarding the discourse on purely functional programs not having side effects:

Writing pure programs without side effects is a little tricky to talk about, since this has some very precise technical meanings depending on whom you talk to. (What constitutes an effect? Where is the line between intentional and unintentional drawn?)

Maybe think of this statement as part of the continuum of arguments about languages that allow us to write simpler programs that more precisely state the intended effects.

Cheers,
Darren

On Dec 11, 2015 07:07, "Abhishek Kumar" <[hidden email]> wrote:
I am a beginner in haskell.I have heard a lot about haskell being great for parallel programming and concurrency but couldn't understand why?Aren't iterative algorithms like MapReduce more suitable to run parallely?Also how immutable data structures add to speed?I'm having trouble understanding very philosophy of functional programming, how do we gain by writing everything as functions and pure code(without side effects)?
Any links or references will be a great help.
Thanks 
Abhishek Kumar

_______________________________________________
Beginners mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners


_______________________________________________
Beginners mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners




--
Chris Allen
Currently working on http://haskellbook.com


_______________________________________________
Beginners mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners


_______________________________________________
Beginners mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
Reply | Threaded
Open this post in threaded view
|

Re: Doubts about functional programming paradigm

Dan Stromberg
In reply to this post by MJ Williams

Two or more code units want to do basically the same thing at almost the same moment.  Whichever one does the thing first (or sometimes, second) wins, and the other loses.

EG, imagine two processes communicating over shared memory. If they both want to write to variable x in shared memory at almost the same moment, whichever one writes second "wins", because the write of the first is wiped out by the write of the second.

Some race conditions aren't much of a problem, but some of them can be a source of really hard-to-track-down bugs.

On Fri, Dec 11, 2015 at 4:45 PM, MJ Williams <[hidden email]> wrote:
What is a `race condition'?

On 11/12/2015, Christopher Allen <[hidden email]> wrote:
> Having the option of communicating by sharing memory, message-passing style
> (copying), or copy-on-write semantics in Haskell programs is why I've found
> Haskell to be a real pleasure for performance (latency, mostly) sensitive
> services I frequently work on. I get a superset of options in Haskell for
> which I don't have any one choice that can really match it in concurrency
> problems or single-machine parallelism. There's some work to be done to
> catch up to OTP, but the community is inching its way a few directions
> (Cloud Haskell/distributed haskell, courier, streaming lib + networking,
> etc.)
>
> Generally I prefer to build out services in a conventional style (breaking
> out capacities like message backends or persistence into separate
> machines), but the workers/app servers are all in Haskell. That is, I don't
> try to replicate the style of cluster you'd see with Erlang services in
> Haskell, but I know people that have done so and were happy with the
> result. Being able to have composable concurrency via STM without
> compromising correctness is _no small thing_ and the cheap threads along
> with other features of Haskell have served to make it so that concurrency
> and parallelization of Haskell programs can be a much more modular process
> than I've experienced in many other programming languages. It makes it so
> that I can write programs totally oblivious to concurrency or parallelism
> and then layer different strategies of parallelization or synchronization
> after the fact, changing them out at runtime if I so desire! This is only
> possible for me in Haskell because of the non-strict semantics and
> incredible kit we have at our disposal thanks to the efforts of Simon
> Marlow and others. Much of this is ably covered in Marlow's book at:
> http://chimera.labs.oreilly.com/books/1230000000929
>
> Side bar: although using "pure" with respect to effects is the common usage
> now, I'd urge you to consider finding a different wording since the
> original (and IMHO more meaningful) denotation of pure functional
> programming was about semantics and not the presence or absence of effects.
> The meaning was that you had a programming language whose semantics were
> lambda-calculus-and-nothing-more. This can be contrasted with ML where the
> lambda calculus is augmented with an imperative language that isn't
> functional or a lambda calculus. Part of the problem with making purity
> about effects rather than semantics is the terrible imprecision confuses
> new people. They'll often misunderstand it as, "Haskell programs can't
> perform effects" or they'll think it means stuff in "IO" isn't pure - which
> is false. We benefit from having a pure functionalal programming language
> _especially_ in programs that emit effects. Gabriel Gonzalez has a nice
> article demonstrating some of this:
> http://www.haskellforall.com/2015/03/algebraic-side-effects.html
>
> When I want to talk about effects, I say "effect". When I want to say
> something that doesn't emit effects, I say "effect-free" and when it does,
> "effectful". Sometimes I'll say "in IO" for the latter as well, where "in
> IO" can be any type that has IO in the outermost position of the final
> return type.
>
> But, in the end, I'm not really here to convince anybody to use Haskell.
> I'm working on http://haskellbook.com/ with my coauthor Julie because I
> thought it was unreasonably difficult and time-consuming to learn a
> language that is quite pleasant and productive to use in my day to day
> work. If Haskell picks up in popularity, cool - more libraries! If not,
> then it remains an uncommon and not well-understood competitive advantage
> in my work. I'm not sure I mind either outcome as long as the community
> doesn't contract and it seems to be doing the opposite of that lately.
>
> I use Haskell because I'm lazy and impatient. I do not tolerate tedious,
> preventable work well. Haskell lets me break down my problems into
> digestible units, it forces the APIs I consume to declare what chicanery
> they're up to, it gives me the nicest kit for my work I've ever had at my
> disposal. It's not perfect - it's best if you're comfortable with a unix-y
> toolkit, but there's Haskellers on Windows keeping the lights on too.
>
> Best of luck to Abhishek whatever they decide to do from here. I won't
> pretend Haskell is "easy" - you have to learn more before you can write the
> typical software project, but it's an upfront cliff sorta thing that
> converts into a long-term advantage if you're willing to do the work. This
> is more the case than what I found with Clojure, Erlang, Java, C++, Go,
> etc. They all have a gentler upfront productivity cliff, but don't pay off
> nearly as well long-term in my experience. YMMV.
>
> On Fri, Dec 11, 2015 at 3:13 PM, Darren Grant <[hidden email]> wrote:
>
>> Regarding concurrency+immutability with respect to both reliability and
>> performance:
>>
>> One way to think about synchronizing concurrent programs is by sharing
>> memory. If the content of that memory changes, then there is a risk of
>> race
>> conditions arising in the affected programs. (A common source of vexing
>> bugs, and complications for compilers.) But if the contents are somehow
>> guaranteed not to change (ie. a specific definition of immutability),
>> then
>> no race conditions are possible for the lifetime of access to that
>> memory.
>>
>> Although this is a greatly simplified illustrative explanation, it is
>> generally at the heart of arguments for immutability aiding performance.
>> Unchanging regions of memory tend to permit simpler sorts of models since
>> limitations are lifted on synchronization. This in turn allows both more
>> freedom to pursue many otherwise tricky optimizations, such as ex.
>> deciding
>> when to duplicate based on cache geometry, trivially remembering old
>> results, etc.
>>
>> Regarding the discourse on purely functional programs not having side
>> effects:
>>
>> Writing pure programs without side effects is a little tricky to talk
>> about, since this has some very precise technical meanings depending on
>> whom you talk to. (What constitutes an effect? Where is the line between
>> intentional and unintentional drawn?)
>>
>> Maybe think of this statement as part of the continuum of arguments about
>> languages that allow us to write simpler programs that more precisely
>> state
>> the intended effects.
>>
>> Cheers,
>> Darren
>> On Dec 11, 2015 07:07, "Abhishek Kumar" <[hidden email]> wrote:
>>
>>> I am a beginner in haskell.I have heard a lot about haskell being great
>>> for parallel programming and concurrency but couldn't understand
>>> why?Aren't
>>> iterative algorithms like MapReduce more suitable to run parallely?Also
>>> how
>>> immutable data structures add to speed?I'm having trouble understanding
>>> very philosophy of functional programming, how do we gain by writing
>>> everything as functions and pure code(without side effects)?
>>> Any links or references will be a great help.
>>> Thanks
>>> Abhishek Kumar
>>>
>>> _______________________________________________
>>> Beginners mailing list
>>> [hidden email]
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>>>
>>>
>> _______________________________________________
>> Beginners mailing list
>> [hidden email]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>>
>>
>
>
> --
> Chris Allen
> Currently working on http://haskellbook.com
>
_______________________________________________
Beginners mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners



--
Dan Stromberg

_______________________________________________
Beginners mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
Reply | Threaded
Open this post in threaded view
|

Re: Doubts about functional programming paradigm

Imants Cekusins
In reply to this post by MJ Williams

> What is a `race condition'?

Multiple threads accessing and modifying shared resource (value) in  uncontrolled order, which may differ each time code runs.


_______________________________________________
Beginners mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
Reply | Threaded
Open this post in threaded view
|

Re: Doubts about functional programming paradigm

MJ Williams
Just out of interest, what was your PHD in?

On 12/12/2015, Imants Cekusins <[hidden email]> wrote:
>> What is a `race condition'?
>
> Multiple threads accessing and modifying shared resource (value) in
> uncontrolled order, which may differ each time code runs.
>
_______________________________________________
Beginners mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
Reply | Threaded
Open this post in threaded view
|

explaining effects (was: Doubts about functional programming paradigm)

Daniel Bergey
In reply to this post by Christopher Allen
I have pedagogical questions.  Why do you prefer "effect" to "side
effect"?  I know that "pure" is misleading to programmers new to
Haskell, but I have thought that "side effect" was more likely to be
self-explanatory.

I also reach for longer phrases like "free from side effects" if I'm
talking to my students.

cheers,
bergey

On 2015-12-11 at 16:36, Christopher Allen <[hidden email]> wrote:

> Side bar: although using "pure" with respect to effects is the common usage
> now, I'd urge you to consider finding a different wording since the
> original (and IMHO more meaningful) denotation of pure functional
> programming was about semantics and not the presence or absence of effects.
> The meaning was that you had a programming language whose semantics were
> lambda-calculus-and-nothing-more. This can be contrasted with ML where the
> lambda calculus is augmented with an imperative language that isn't
> functional or a lambda calculus. Part of the problem with making purity
> about effects rather than semantics is the terrible imprecision confuses
> new people. They'll often misunderstand it as, "Haskell programs can't
> perform effects" or they'll think it means stuff in "IO" isn't pure - which
> is false. We benefit from having a pure functionalal programming language
> _especially_ in programs that emit effects. Gabriel Gonzalez has a nice
> article demonstrating some of this:
> http://www.haskellforall.com/2015/03/algebraic-side-effects.html
>
> When I want to talk about effects, I say "effect". When I want to say
> something that doesn't emit effects, I say "effect-free" and when it does,
> "effectful". Sometimes I'll say "in IO" for the latter as well, where "in
> IO" can be any type that has IO in the outermost position of the final
> return type.
_______________________________________________
Beginners mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
Reply | Threaded
Open this post in threaded view
|

Re: Doubts about functional programming paradigm

Henk-Jan van Tuyl
In reply to this post by Dimitri DeFigueiredo
On Sat, 12 Dec 2015 01:56:48 +0100, Dimitri DeFigueiredo  
<[hidden email]> wrote:

:
> Couldn't match expected type ‘r’ with actual type ‘COParseResult’
>        ‘r’ is a rigid type variable bound by
>            the type signature for
> getParseResult :: ParseResult r => String -> IO r
>              ...
>
> I have a PhD in computer science, but never really liked programming
> languages back then and somehow I never learned what a "rigid type
> variable" is.

See
   [Haskell-cafe] What is a rigid type variable?
   https://mail.haskell.org/pipermail/haskell-cafe/2008-June/044622.html

:
> But would anyone care to explain to a
> novice in a couple paragraphs why foldl (+) 0 [1..10^9] may take 10 Gigs
> of RAM to calculate?

The foldl builds up a very long expression and evaluates it after the last  
element of the list is reached (the evaluation is non-strict, or lazy). If  
you use foldl' (from Data.List) instead, the calculation is done per  
element (the evaluation is strict).

For more details, see
   Foldr Foldl Foldl'
   https://wiki.haskell.org/Foldr_Foldl_Foldl'

   Lazy vs. non-strict
   https://wiki.haskell.org/Lazy_vs._non-strict

Regards,
Henk-Jan van Tuyl


--
Folding@home
What if you could share your unused computer power to help find a cure? In  
just 5 minutes you can join the world's biggest networked computer and get  
us closer sooner. Watch the video.
http://folding.stanford.edu/


http://Van.Tuyl.eu/
http://members.chello.nl/hjgtuyl/tourdemonad.html
Haskell programming
--
_______________________________________________
Beginners mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
Reply | Threaded
Open this post in threaded view
|

Re: Doubts about functional programming paradigm

Imants Cekusins

> The foldl builds up a very long expression and evaluates it after the last element of the list is reached (the evaluation is non-strict, or lazy). If you use foldl' (from Data.List) instead, the calculation is done per element (the evaluation is strict).

Is it possible to write a wrapping function (if it does not already exist) which would analyze inputs and apply appropriate fold (foldl, foldl', foldr, foldr') or safeguard (return Left warning) against following the 10Gb ram route - if this can be avoided?


_______________________________________________
Beginners mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
Reply | Threaded
Open this post in threaded view
|

Re: Doubts about functional programming paradigm

Dimitri DeFigueiredo
In reply to this post by Henk-Jan van Tuyl
Oops! Sorry, I think I wasn't clear. I know the answers to all the
questions I asked. They were rhetorical questions.

I just wanted to make a point that learning haskell is *much* harder
than learning most other programming languages and the (multitude of)
learning aids that are available are not yet cohesive enough to present
a clear path ahead for the average programmer. I also think this is the
main reason haskell will NOT be more widely used any time soon, despite
its many other advantages.

I think newcomers to the language should know this before they start to
evaluate their reasons and seek help from others (as in this list) to
guide them in the process.

Thank you very much for the pointers in any case, they look very good.

Dimitri

On 12/13/15 9:51 PM, Henk-Jan van Tuyl wrote:

> On Sat, 12 Dec 2015 01:56:48 +0100, Dimitri DeFigueiredo
> <[hidden email]> wrote:
>
> :
>> Couldn't match expected type ‘r’ with actual type ‘COParseResult’
>>        ‘r’ is a rigid type variable bound by
>>            the type signature for
>> getParseResult :: ParseResult r => String -> IO r
>>              ...
>>
>> I have a PhD in computer science, but never really liked programming
>> languages back then and somehow I never learned what a "rigid type
>> variable" is.
>
> See
>   [Haskell-cafe] What is a rigid type variable?
> https://mail.haskell.org/pipermail/haskell-cafe/2008-June/044622.html
>
> :
>> But would anyone care to explain to a
>> novice in a couple paragraphs why foldl (+) 0 [1..10^9] may take 10 Gigs
>> of RAM to calculate?
>
> The foldl builds up a very long expression and evaluates it after the
> last element of the list is reached (the evaluation is non-strict, or
> lazy). If you use foldl' (from Data.List) instead, the calculation is
> done per element (the evaluation is strict).
>
> For more details, see
>   Foldr Foldl Foldl'
>   https://wiki.haskell.org/Foldr_Foldl_Foldl'
>
>   Lazy vs. non-strict
>   https://wiki.haskell.org/Lazy_vs._non-strict
>
> Regards,
> Henk-Jan van Tuyl
>
>

_______________________________________________
Beginners mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
Reply | Threaded
Open this post in threaded view
|

Re: Doubts about functional programming paradigm

Dan Stromberg
In reply to this post by Imants Cekusins

On Sun, Dec 13, 2015 at 4:02 PM, Imants Cekusins <[hidden email]> wrote:

> The foldl builds up a very long expression and evaluates it after the last element of the list is reached (the evaluation is non-strict, or lazy). If you use foldl' (from Data.List) instead, the calculation is done per element (the evaluation is strict).

Is it possible to write a wrapping function (if it does not already exist) which would analyze inputs and apply appropriate fold (foldl, foldl', foldr, foldr') or safeguard (return Left warning) against following the 10Gb ram route - if this can be avoided?

I know next to nothing about Haskell, but I suspect this would require knowing whether a list is finite or infinite, which may be equivalent to "the halting problem" - IOW, not possible in general in a finite amount of time. 

--
Dan Stromberg

_______________________________________________
Beginners mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
Reply | Threaded
Open this post in threaded view
|

Re: Doubts about functional programming paradigm

John Lusk-2
In reply to this post by Christopher Allen
Dude... it's the Haskell *Beginners* List.

STM, I guess, is Shared Transactional Memory.

But OTP?  Wazzat?

On Fri, Dec 11, 2015 at 4:36 PM, Christopher Allen <[hidden email]> wrote:
Having the option of communicating by sharing memory, message-passing style (copying), or copy-on-write semantics in Haskell programs is why I've found Haskell to be a real pleasure for performance (latency, mostly) sensitive services I frequently work on. I get a superset of options in Haskell for which I don't have any one choice that can really match it in concurrency problems or single-machine parallelism. There's some work to be done to catch up to OTP, but the community is inching its way a few directions (Cloud Haskell/distributed haskell, courier, streaming lib + networking, etc.)

Generally I prefer to build out services in a conventional style (breaking out capacities like message backends or persistence into separate machines), but the workers/app servers are all in Haskell. That is, I don't try to replicate the style of cluster you'd see with Erlang services in Haskell, but I know people that have done so and were happy with the result. Being able to have composable concurrency via STM without compromising correctness is _no small thing_ and the cheap threads along with other features of Haskell have served to make it so that concurrency and parallelization of Haskell programs can be a much more modular process than I've experienced in many other programming languages. It makes it so that I can write programs totally oblivious to concurrency or parallelism and then layer different strategies of parallelization or synchronization after the fact, changing them out at runtime if I so desire! This is only possible for me in Haskell because of the non-strict semantics and incredible kit we have at our disposal thanks to the efforts of Simon Marlow and others. Much of this is ably covered in Marlow's book at: http://chimera.labs.oreilly.com/books/1230000000929 

Side bar: although using "pure" with respect to effects is the common usage now, I'd urge you to consider finding a different wording since the original (and IMHO more meaningful) denotation of pure functional programming was about semantics and not the presence or absence of effects. The meaning was that you had a programming language whose semantics were lambda-calculus-and-nothing-more. This can be contrasted with ML where the lambda calculus is augmented with an imperative language that isn't functional or a lambda calculus. Part of the problem with making purity about effects rather than semantics is the terrible imprecision confuses new people. They'll often misunderstand it as, "Haskell programs can't perform effects" or they'll think it means stuff in "IO" isn't pure - which is false. We benefit from having a pure functionalal programming language _especially_ in programs that emit effects. Gabriel Gonzalez has a nice article demonstrating some of this: http://www.haskellforall.com/2015/03/algebraic-side-effects.html

When I want to talk about effects, I say "effect". When I want to say something that doesn't emit effects, I say "effect-free" and when it does, "effectful". Sometimes I'll say "in IO" for the latter as well, where "in IO" can be any type that has IO in the outermost position of the final return type.

But, in the end, I'm not really here to convince anybody to use Haskell. I'm working on http://haskellbook.com/ with my coauthor Julie because I thought it was unreasonably difficult and time-consuming to learn a language that is quite pleasant and productive to use in my day to day work. If Haskell picks up in popularity, cool - more libraries! If not, then it remains an uncommon and not well-understood competitive advantage in my work. I'm not sure I mind either outcome as long as the community doesn't contract and it seems to be doing the opposite of that lately.

I use Haskell because I'm lazy and impatient. I do not tolerate tedious, preventable work well. Haskell lets me break down my problems into digestible units, it forces the APIs I consume to declare what chicanery they're up to, it gives me the nicest kit for my work I've ever had at my disposal. It's not perfect - it's best if you're comfortable with a unix-y toolkit, but there's Haskellers on Windows keeping the lights on too.

Best of luck to Abhishek whatever they decide to do from here. I won't pretend Haskell is "easy" - you have to learn more before you can write the typical software project, but it's an upfront cliff sorta thing that converts into a long-term advantage if you're willing to do the work. This is more the case than what I found with Clojure, Erlang, Java, C++, Go, etc. They all have a gentler upfront productivity cliff, but don't pay off nearly as well long-term in my experience. YMMV.

On Fri, Dec 11, 2015 at 3:13 PM, Darren Grant <[hidden email]> wrote:

Regarding concurrency+immutability with respect to both reliability and performance:

One way to think about synchronizing concurrent programs is by sharing memory. If the content of that memory changes, then there is a risk of race conditions arising in the affected programs. (A common source of vexing bugs, and complications for compilers.) But if the contents are somehow guaranteed not to change (ie. a specific definition of immutability), then no race conditions are possible for the lifetime of access to that memory.

Although this is a greatly simplified illustrative explanation, it is generally at the heart of arguments for immutability aiding performance. Unchanging regions of memory tend to permit simpler sorts of models since limitations are lifted on synchronization. This in turn allows both more freedom to pursue many otherwise tricky optimizations, such as ex. deciding when to duplicate based on cache geometry, trivially remembering old results, etc.

Regarding the discourse on purely functional programs not having side effects:

Writing pure programs without side effects is a little tricky to talk about, since this has some very precise technical meanings depending on whom you talk to. (What constitutes an effect? Where is the line between intentional and unintentional drawn?)

Maybe think of this statement as part of the continuum of arguments about languages that allow us to write simpler programs that more precisely state the intended effects.

Cheers,
Darren

On Dec 11, 2015 07:07, "Abhishek Kumar" <[hidden email]> wrote:
I am a beginner in haskell.I have heard a lot about haskell being great for parallel programming and concurrency but couldn't understand why?Aren't iterative algorithms like MapReduce more suitable to run parallely?Also how immutable data structures add to speed?I'm having trouble understanding very philosophy of functional programming, how do we gain by writing everything as functions and pure code(without side effects)?
Any links or references will be a great help.
Thanks 
Abhishek Kumar

_______________________________________________
Beginners mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners


_______________________________________________
Beginners mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners




--
Chris Allen
Currently working on http://haskellbook.com

_______________________________________________
Beginners mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners



_______________________________________________
Beginners mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
123