[Haskell-beginners] Doubts about functional programming paradigm

Sat Dec 12 00:45:53 UTC 2015

What is a `race condition'?

On 11/12/2015, Christopher Allen <cma at bitemyapp.com> 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 <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
>