<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
+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".<br>
<br>
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<br>
<br>
<font face="arial, helvetica, sans-serif">Couldn't match expected
type ‘r’ with actual type ‘COParseResult’</font>
<div><font face="arial, helvetica, sans-serif"> ‘r’ is a rigid
type variable bound by</font></div>
<div><font face="arial, helvetica, sans-serif"> the type
signature for</font></div>
<div><font face="arial, helvetica, sans-serif">
getParseResult :: ParseResult r => String -> IO r</font></div>
<font face="arial, helvetica, sans-serif"> ...<br>
<br>
</font>I have a PhD in computer science, but never really liked
programming languages back then and somehow I never learned what a "<font
face="arial, helvetica, sans-serif">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 </font><font
face="arial, helvetica, sans-serif">
<meta http-equiv="content-type" content="text/html;
charset=windows-1252">
foldl (+) 0 [1..10^9] </font>may take 10 Gigs of RAM to
calculate?<br>
<br>
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.<br>
<br>
Summarizing,<br>
<br>
Learning Haskell: It will be a bumpy ride, but there *is* a happy
ending.<br>
<br>
<br>
<br>
Cheers,<br>
<br>
<br>
Dimitri<br>
<br>
<br>
<div class="moz-cite-prefix">On 12/11/15 7:36 PM, Christopher Allen
wrote:<br>
</div>
<blockquote
cite="mid:CADnndOoyuxuJVpeO42wsB1VR+4ziZ2ynQGQA73Ry79+iFqY7_g@mail.gmail.com"
type="cite">
<div dir="ltr">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.)
<div><br>
</div>
<div>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: <a moz-do-not-send="true"
href="http://chimera.labs.oreilly.com/books/1230000000929">http://chimera.labs.oreilly.com/books/1230000000929</a> </div>
<div><br>
</div>
<div>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: <a moz-do-not-send="true"
href="http://www.haskellforall.com/2015/03/algebraic-side-effects.html">http://www.haskellforall.com/2015/03/algebraic-side-effects.html</a></div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>But, in the end, I'm not really here to convince anybody to
use Haskell. I'm working on <a moz-do-not-send="true"
href="http://haskellbook.com/">http://haskellbook.com/</a>
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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
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.</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Fri, Dec 11, 2015 at 3:13 PM, Darren
Grant <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:dedgrant@gmail.com" target="_blank">dedgrant@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<p dir="ltr">Regarding concurrency+immutability with respect
to both reliability and performance:</p>
<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">Regarding the discourse on purely functional
programs not having side effects:</p>
<p dir="ltr">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?)</p>
<p dir="ltr">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.<br>
</p>
<p dir="ltr">Cheers,<br>
Darren<br>
</p>
<div class="gmail_quote">
<div>
<div class="h5">On Dec 11, 2015 07:07, "Abhishek Kumar"
<<a moz-do-not-send="true"
href="mailto:abhishekkmr18@gmail.com"
target="_blank">abhishekkmr18@gmail.com</a>>
wrote:<br type="attribution">
</div>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div class="h5">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)?
<div>Any links or references will be a great help.</div>
<div>Thanks </div>
<div>Abhishek Kumar</div>
<br>
</div>
</div>
<span class="">_______________________________________________<br>
Beginners mailing list<br>
<a moz-do-not-send="true"
href="mailto:Beginners@haskell.org" target="_blank">Beginners@haskell.org</a><br>
<a moz-do-not-send="true"
href="http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners"
rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners</a><br>
<br>
</span></blockquote>
</div>
<br>
_______________________________________________<br>
Beginners mailing list<br>
<a moz-do-not-send="true"
href="mailto:Beginners@haskell.org">Beginners@haskell.org</a><br>
<a moz-do-not-send="true"
href="http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners"
rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners</a><br>
<br>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<div class="gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">
<div dir="ltr">Chris Allen<br>
<div><span style="font-size:12.8000001907349px">Currently
working on </span><a moz-do-not-send="true"
href="http://haskellbook.com" target="_blank">http://haskellbook.com</a></div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Beginners mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Beginners@haskell.org">Beginners@haskell.org</a>
<a class="moz-txt-link-freetext" href="http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners">http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners</a>
</pre>
</blockquote>
<br>
</body>
</html>