Live data from Hacker News

Reflecting on Haskell in 2015

stephendiehl.com

41–50 of 106 posts

Re: Reflecting on Haskell in 2015

#41
post #27

Earlier quoted context omitted.

This [1] might help 'get it' with regards to monads. Very easy to digest. You mention LINQ and the List abstraction. Yes IEnumerable is a monad (LINQ isn't in itself - it [the grammar] is the equivalent of 'do' notation in Haskell). Monads are simply 'wrapper types' that follow a couple of rules: 1. You must be able to construct one from the un-wrapped value (return in Haskell, new List (...) in C#) 2. It must implem…

Thanks for taking the time to write all that up. I think (too early to say) that seeing all this expressed in C#/Java(script)/Ruby/Python syntax is key for someone like me. I learned LINQ/Select(Many) and later all the map/filter/reduce functional goodness by playing with Clojure and never had a problem and never heard the word "monad" and was fine, totally fine. Later watching a video on Rx (MS's reactive extensions…

My pleasure. I guess to help a bit more (because the list monad tends to be easier to comprehend) is to see how other types are implemented. So here's a very basic implementation of the Option/Maybe monad:

    public class Option
    {
        public readonly bool HasValue;
        public readonly T Value;

        internal Option(bool hasValue, T value)
        {
            HasValue = hasValue;
            Value = value;
        }

        public Option Select(Func map) =>
            HasValue
                ? Option.Some(map(Value))
                : Option.None();

        public Option SelectMany(Func> bind, Func project) =>
            HasValue
                ? bind(Value).Select(u => project(Value,u))
                : Option.None();
    }

    public static class Option
    {
        public static Option Some(T value) =>
            new Option(true, value);

        public static Option None() =>
            new Option(false, default(T));
    }
The SelectMany implementation is slightly more complicated than I showed before. This is an optimisation that C# does to group the bind and map together. So it may look slightly scary as a function. But hopefully you can see that if the Option has a value then it first invokes bind, then uses the result of the bind (an Option) to project the final result. Here's a more imperative version of it:

        public Option SelectMany(Func> bind, Func project)
        {
            if (HasValue)
            {
                var u = bind(Value);

                if (u.HasValue)
                {
                    return Option.Some(project(Value, u.Value));
                }
                else
                {
                    return Option.None();
                }
            }
            else
            {
                return Option.None();
            }
        }
You can see that with the IEnumerable version of Select and SelectMany it encapsulates list iteration. With the Option monad it doesn't do that. It instead checks the HasValue field, and if it's false then it doesn't run the map or bind functions.

The second static class: Option, contains the 'return' functions: Some or None. These wrap a value of type T in an Option.

Now if we use Option in a LINQ expression:

    var option1 = Option.Some(10);
    var option2 = Option.Some(10);
    var none    = Option.None();

    var res1 = from x in option1
               from y in option2
               select x + y;

    // res1.HasValue == true  res1.Value == 20 

    var res2 = from x in option1
               from y in none
               select x + y;

    // res2.HasValue == false

    var res3 = from x in none
               from y in option2
               select x + y;

    // res3.HasValue == false
This is the same as using do notation in Haskell:

    do x 
If we were to do that imperatively it would look like this:

    var res = Option.None();
    if( option1.HasValue )
    {
        if( option2.HasValue )
        {
            res = Option.Some(option1.Value + option2.Value);
        }
    }
Clearly more cluttered and error prone and importantly, not composable. This is where the notion of 'programmable semi-colons' comes from. It appears that the monad is running behaviour 'between the lines', and it is.

Hopefully that clears the fog. I'll keep an eye on this thread for a few days, so feel free to drop any questions in here or on my project page.

Re: Reflecting on Haskell in 2015

#42
post #30

I've learned haskell at the university level, and really enjoyed it(and found it very easy to pick up), but find it puzzling where I should use it. It's very easy to say this problem requires a scripting language, and this problem is better suited for an object oriented language, but I don't quite understand what problems would be easier with a functional language. At least in terms of problems that I want solved.

Traditionally speaking, one of the bigger arguments for functional languages is "embarrassingly high parallelism" because they tend to simplify many issues that writing imperative languages concurrently can bring about

Re: Reflecting on Haskell in 2015

#43

I consider myself a functional programmer, and I also have an interest in logic and type theory, and have learned enough Haskell to write some student-level projects in it. But when I try to dip my toe back into the Haskell community, a wave of despair washes over me. There's just too much. Haskell is changing too fast. There are too many language extensions, and more and more conceptually sophisticated features keep…

This matches my experience. At the company I work at, we use Haskell for HTTP services. The software stack we've grown is extremely opinionated about how to do things. We provide just one way to do things like report errors, run queries, do work asynchronously, and so forth. We get people up and running with about the same amount of effort as we spend getting people going on our PHP, and I think a big part of the rea…

Two questions - first, did you reply to the wrong comment? Seems like you might've meant to reply to thinkpad20's comment, which is about not needing to know everything to be productive.

Second - where do you work?

Re: Reflecting on Haskell in 2015

#44
post #14

Earlier quoted context omitted.

Talking about security: https://code.facebook.com/posts/745068642270222/fighting-spa...

I don't think "fighting spam" is really what the GP was talking about. A common "best practice" with cryptographic material is to hold it as short a time as possible (um, but garbage collection makes that hard), and zero it before releasing it (but immutability gets in the way). That means that, in a language like Haskell, you're going to leak crypto material into the free memory pool unless you break the language pa…

In non RT java this is nearly impossible. The best way is to use a specific allocated off memory byte buffer and zero it once done. But GC/deallocation and JIT compilation will fight your zeroing attempts, and it can easily break existing code :(

Re: Reflecting on Haskell in 2015

#45

I consider myself a functional programmer, and I also have an interest in logic and type theory, and have learned enough Haskell to write some student-level projects in it. But when I try to dip my toe back into the Haskell community, a wave of despair washes over me. There's just too much. Haskell is changing too fast. There are too many language extensions, and more and more conceptually sophisticated features keep…

I don't really feel that way. In fact, I think that there's just so much going on in Haskell that it kind of frees me from having to understand it all. Being comfortable with fundamentals of purely-functional programming (basically ADTs and use of first-class functions e.g. with maps/filters/folds), and the essential types and type classes (Functor, Applicative, Monad, State, etc) give one enough of a grounding as to…

Part of the problem is a 'relative' lack of material covering practical development in haskell, compared to material explaining/exploring fancy type featues ( i.e. Prosemicofunctor type classes ) , and those that do blog about more mundane issues dont get voted up or are as visible in the community since its not interesting to those that have already passed that level.

Re: Reflecting on Haskell in 2015

#46
post #19

Earlier quoted context omitted.

For learning functional programming I find Racket to be the best for teaching functional programming. I think I took 4 tries at teaching myself Haskell and then learning Racket really helped me to get over the learning curve of Haskell though i still consider myself a beginner.

I've tried Haskell 4 times. No joke. I have no problem with currying, higher-order functions, foldl, etc., but Monads. Get. Me. Every. Time. My brain just refuses to fully "grok" them. I still don't see why they're so awesome. I know I use them day-to-day - LINQ, the "List" abstraction (supposedly also a monad??) but I just don't see why it's important to understand them on this whole new fundamentally different leve…

> My brain just refuses to fully "grok" them. I still don't see why they're so awesome. I know I use them day-to-day - LINQ, the "List" abstraction (supposedly also a monad??) but I just don't see why it's important to understand them on this whole new fundamentally different level.

Why do you want to "grok" them? Just use them. In fact I'd say there isn't much more to grokking them than just using them.

Re: Reflecting on Haskell in 2015

#47

I consider myself a functional programmer, and I also have an interest in logic and type theory, and have learned enough Haskell to write some student-level projects in it. But when I try to dip my toe back into the Haskell community, a wave of despair washes over me. There's just too much. Haskell is changing too fast. There are too many language extensions, and more and more conceptually sophisticated features keep…

For me all the extensions and abstractions induce a kind of choice paralysis, and fear that my program isn't abstracted far enough. I don't feel that when working in C, Java or Ruby.

That captures my feelings really well. And then I think that if I'm going to stick to the "meat and potatoes" of functional programming, I might as well just use a language in the ML family.

Re: Reflecting on Haskell in 2015

#48
post #43

Earlier quoted context omitted.

This matches my experience. At the company I work at, we use Haskell for HTTP services. The software stack we've grown is extremely opinionated about how to do things. We provide just one way to do things like report errors, run queries, do work asynchronously, and so forth. We get people up and running with about the same amount of effort as we spend getting people going on our PHP, and I think a big part of the rea…

Two questions - first, did you reply to the wrong comment? Seems like you might've meant to reply to thinkpad20's comment, which is about not needing to know everything to be productive. Second - where do you work?

I'm at IMVU. We're hiring! :) http://www.imvu.com/jobs/index/

I intended to react to the comment "But when I try to dip my toe back into the Haskell community, a wave of despair washes over me. There's just too much. Haskell is changing too fast."

I think this is true. There are too many ways to do everything in Haskell and they're changing too often. If you don't get very specific guidance, you're going to be totally paralyzed with indecision. I have good evidence that you can do very well by confining the solution space.

Re: Reflecting on Haskell in 2015

#49

I consider myself a functional programmer, and I also have an interest in logic and type theory, and have learned enough Haskell to write some student-level projects in it. But when I try to dip my toe back into the Haskell community, a wave of despair washes over me. There's just too much. Haskell is changing too fast. There are too many language extensions, and more and more conceptually sophisticated features keep…

For me all the extensions and abstractions induce a kind of choice paralysis, and fear that my program isn't abstracted far enough. I don't feel that when working in C, Java or Ruby.

That's why Go succeeds too.

Re: Reflecting on Haskell in 2015

#50
post #43

Earlier quoted context omitted.

Two questions - first, did you reply to the wrong comment? Seems like you might've meant to reply to thinkpad20's comment, which is about not needing to know everything to be productive. Second - where do you work?

I'm at IMVU. We're hiring! :) http://www.imvu.com/jobs/index/ I intended to react to the comment "But when I try to dip my toe back into the Haskell community, a wave of despair washes over me. There's just too much. Haskell is changing too fast." I think this is true. There are too many ways to do everything in Haskell and they're changing too often. If you don't get very specific guidance, you're going to be totall…

Nice! How long have you been there? It'd be interesting to hear how things have gone running Haskell in prod (and hiring, and such) since your guys' blog post in March of 2014.

Gotcha. It also doesn't help that many of the canonical learning materials (e.g. LYAH, or Real World Haskell) are slowly drifting out of date.

Post reply on HN