[Haskell-cafe] Haskell Weekly News: Issue 330

Thu May 21 23:49:52 UTC 2015

New Releases

  inline-c

    Francesco Mazzoli and Mathieu Boespflug release a library that
    allows to freely mix Haskell and C in the same source file and
    pass data from one language to the other with minimal overhead.

    http://hackage.haskell.org/package/inline-c

    https://github.com/fpco/inline-c/

    https://www.fpcomplete.com/blog/2015/05/inline-c

Books

  The Little Prover by Daniel P. Friedman and Carl Eastlund

    This book will come out in July 2015 and teaches how to use
    inductive proofs to determine facts about computer programs.

    http://mitpress.mit.edu/books/little-prover

  Haskell Programming by Christopher Allen and Julie Moronuki

    Half of the book is written and is available for early access.

    http://haskellbook.com/

    https://gumroad.com/l/haskellbook?getthebook=Get+Haskell+Programming+now+from+Gumroad

    https://news.ycombinator.com/item?id=9580746

    http://haskellbook.com/images/sample_pdf_v1.pdf

Talks

  Workshop on Type Inference and Automated Proving

    Videos and slides are now available.

    http://staff.computing.dundee.ac.uk/frantisekfarka/tiap/

Discussion

  Against the definition of types

    Tomas Petricek argues that definition of what is a type does not
    exist and we should look for innovative ways of working with types
    without formal definition.

    http://tomasp.net/blog/2015/against-types/

    http://www.reddit.com/r/haskell/comments/35zzvu/against_the_definition_of_types_by_tomas_petricek/

  Effects encoded in types break encapsulation

    Yuras Shumovich notes that being too fine-grained in specification
    of side effects is in some ways equivalent to leaking
    implementation detail.

    http://blog.haskell-exists.com/yuras/posts/effects-encoded-in-types-break-encapsulation.html

    http://www.reddit.com/r/haskell/comments/36agmf/effects_encoded_in_types_break_encapsulation/

Quotes of the Week

    klaxion> "… My impression is that haskellers tend to be seen as
             head-in-the-clouds-impractical, purists to the point of
             fanaticism, and annoyingly prone to proselytizing. I'd
             like to change that and honestly I haven't met anyone who
             fits that (then again, I've yet to meet another haskeller
             IRL). Maybe this is a holdover from the earlier days when
             Haskell was a very marginalized community."
    kqr> "I wouldn't be too hopeful. Despite the fact that I'm one of
         the most practical, pragmatic members of one little social
         group I belong to (and this is clearly obvious quite often
         when others get into arguments over insignificant things) I'm
         still seen as a puristic, impractical hipster because I like
         Haskell. :( They don't seem to understand that a desire for
         good type systems and immutability come from a practical
         perspective. They equate things like Node.js with
         productivity and practicality. It's hard to change that image
         as long as that is the case."

    http://www.reddit.com/r/haskell/comments/36j3au/how_haskellers_are_seen_and_see_themselves/

    "Everyone knows that the awesome Iron Man suit is actually
    dependent types." (psygnisfive)

    http://www.reddit.com/r/haskell/comments/36j3au/how_haskellers_are_seen_and_see_themselves/cremooe

    "The haskell applicative, alternative, monoidal and monadic
    combinators when applied to a monad that manage asynchronous IO
    permits multithreaded programming with little plumbing that is
    close to the specification level with great composability. No
    inversion of control means no need to deconstruct the
    specifications and no state machines. This, together with the
    uniform and composable thread management, narrow the design space
    and makes the application more understandable from the
    requirements, and thus the technical documentation and maintenance
    costs are reduced to a minimum." (Alberto Gómez Corona)

    "OOP is like creating custom hardware everytime for every problem.
    since there is no composability, everything must be done from
    scratch. there are no reusable objects beyond basic containers
    encapsulated in objects." (Alberto Gómez Corona)

    https://www.fpcomplete.com/user/agocorona/EDSL-for-hard-working-IT-programmers#the-oop-non-solution-half-solution

    http://haskell.1045720.n5.nabble.com/NoOO-languages-td5809663.html

    "if it's abstract (say, map) then x is as informative as element:
    a thing you know nothing further about" (cameleon)

    http://www.reddit.com/r/haskell/comments/36j3au/how_haskellers_are_seen_and_see_themselves/crf47tg

    "Add `terror`, a Text version of `error`" (Jonathan Lange)

    https://github.com/jml/basic-prelude/commit/11e936d6484ddbe9d403d40aa2bfbd3594b3a2b1

    "If you take away my laziness, your language better bloody well be
    total and have a good accounting of codata." (kamatsu)

    http://www.reddit.com/r/haskell/comments/36s0ii/how_do_we_all_feel_about_laziness/crgm71x

    "Turing completeness is entirely compatible with totality. It is
    only bullshit completeness that totality excludes." (pigworker)

    http://www.reddit.com/r/haskell/comments/36s0ii/how_do_we_all_feel_about_laziness/crgqbah

    "The best way to encapsulate effects is not to restrict
    them." (Yuras Shumovich)

    http://blog.haskell-exists.com/yuras/posts/effects-encoded-in-types-break-encapsulation.html

    "I wouldn't use Haskell if I felt bad about laziness. It'd be like
    eating an apple pie while complaining that it contains
    apples..." (hagda)

    http://www.reddit.com/r/haskell/comments/36s0ii/how_do_we_all_feel_about_laziness/crgmcbl

    "Lazy evaluation gives the compiler more leverage in the optimiser
    than in a strict language. There are more equalities that apply
    (e.g. beta reduction, and let x = E in y ==> y, if y /= x) and
    therefore the compiler can do more code
    transformations." (simonmar)

    http://www.reddit.com/r/haskell/comments/36s0ii/how_do_we_all_feel_about_laziness/crgntwq

    "Seeing arguments from both sides, it's obvious to me that
    laziness-by-default is not better or worse than
    strictness-by-default; it's just a matter of taste and thinking
    habits. You can't please everyone: some people like looking at
    code more equationally and mathy, while some like it more
    down-to-earthy and predictable. … The bottom line, however, is
    that, as SPJ said, laziness was good for Haskell because it helped
    them keep it pure." (SkoomaMudcrab)

    http://www.reddit.com/r/haskell/comments/36s0ii/how_do_we_all_feel_about_laziness/crgn2q5

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150522/39fc950f/attachment.sig>