[Haskell-beginners] Doubts about functional programming paradigm

Christopher Allen cma at bitemyapp.com
Fri Dec 11 21:36:26 UTC 2015


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 <dedgrant at gmail.com> 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" <abhishekkmr18 at gmail.com> 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
>> Beginners at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>>
>>
> _______________________________________________
> Beginners mailing list
> Beginners at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>
>


-- 
Chris Allen
Currently working on http://haskellbook.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/beginners/attachments/20151211/d2cd9ae7/attachment.html>


More information about the Beginners mailing list