[Haskell-beginners] Doubts about functional programming paradigm

Sat Dec 12 00:56:48 UTC 2015

+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 <dedgrant at gmail.com 
> <mailto: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
>     <mailto: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 <mailto:Beginners at haskell.org>
>         http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>
>
>     _______________________________________________
>     Beginners mailing list
>     Beginners at haskell.org <mailto:Beginners at haskell.org>
>     http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>
>
>
>
> -- 
> Chris Allen
> Currently working on http://haskellbook.com
>
>
> _______________________________________________
> Beginners mailing list
> Beginners at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/beginners/attachments/20151211/0a6465ff/attachment.html>