Live data from Hacker News

Haskell in Production

felixmulder.com

51–60 of 242 posts

Re: Haskell in Production

#51

This is a great guide and sound advice. And hopefully in a year we'll see the community converge on Polysemy (or fused-effects for performance) to make this strategy even more natural.

I've been out of the Haskell game for a while, so I hadn't seen Polysemy. Another thing on my reading list...

Re: Haskell in Production

#52

Earlier quoted context omitted.

To them, I would suggest that they remember back to when they learned their first imperative language like Java or C. For me, that was really difficult to wrap my mind around at the time, but now those languages are second nature to me. I kind of suspect that if everyone were exposed to a functional language first, there would be a lot fewer people who think they are extremely hard to learn.

I remember when I started with Java at University. Like, "hello, what is a method? What the hell is a class? Come on, stop kidding me, objects have methods???? How do I call them? Wait, how do I _write_ a method?"

What I kept bouncing off of was all the stupid as shit "sally sends a BUY message to Tommy's bagel shop" crap. I just needed about two to four pages worth of text & diagrams demonstrating how objects and structs are pretty much the same thing, and what the OO sugar inheritance and keywords and dynamic dispatch and such do under the hood, which ain't that complicated. Every single book I picked up (back in the '90s, when if you didn't know someone to personally recommend a book it was much harder to figure out which ones were decent and which sucked) wanted to use those awful, cutesy analogies to introduce OO and they just confused the hell out of me, and convinced me something dead-simple was hard.

Re: Haskell in Production

#53
post #11

> Haskell is great for business and great in production I disagree. It's a beautiful language but it lacks a lot of features to make it useable at scale. And in my experience Haskell engineers are extremely smart but the environment/culture they create makes it difficult to foster team spirit. I've been in 2 companies in the last 4 years who initially used Haskell in production. One has transitioned to Go and the oth…

in my (limited) experience, Haskell projects (and to a slightly lesser extent, functional programming projects) work best when thoroughly planned out in thorough whiteboard/spec sessions and are then implemented by a couple of gurus responsible for the code, who work almost exclusively in functional languages in their day to day. there seems to be a need for way more thought-per-line-of-code in Haskell/FP projects. m…

> in my (limited) experience, Haskell projects (and to a slightly lesser extent, functional programming projects) work best when thoroughly planned out in thorough whiteboard/spec sessions

I think you need more experience then! I'd rather prototype in Haskell than the other language that I use day-to-day, that people say is great for "exploratory coding" (Python).

Re: Haskell in Production

#54

How long does it take the “new programmers who have not worked with Haskell before” to learn and understand all the ASCII-art in the example code? How $ differs from On top of trying to remember that is string concatenation and >>= and <- have something to do with monads.

I still can't understand why Perl is easily dismissed as "LOL line noise" but Haskell's apparently fine. At least dipping into Perl you can take on the line noise slowly so you have time to absorb each new technique, and you can write it just fine with hardly any of that if you want, and it won't hurt a thing—Haskell seems to dump all that on you up front, and it seems to require it, idiomatically. It's very off-putting.

Re: Haskell in Production

#55

How long does it take the “new programmers who have not worked with Haskell before” to learn and understand all the ASCII-art in the example code? How $ differs from On top of trying to remember that is string concatenation and >>= and <- have something to do with monads.

A couple of weeks in my case. It's not any more difficult than remembering that the -> is the cache-miss operator in C++.

You also don't have to learn the entire universe of Haskell before being productive in it. I still have no idea what profunctors, comonads, and other things are and I'm shipping production Haskell code.

Re: Haskell in Production

#56
post #54

How long does it take the “new programmers who have not worked with Haskell before” to learn and understand all the ASCII-art in the example code? How $ differs from On top of trying to remember that is string concatenation and >>= and <- have something to do with monads.

I still can't understand why Perl is easily dismissed as "LOL line noise" but Haskell's apparently fine. At least dipping into Perl you can take on the line noise slowly so you have time to absorb each new technique, and you can write it just fine with hardly any of that if you want, and it won't hurt a thing—Haskell seems to dump all that on you up front, and it seems to require it, idiomatically. It's very off-putt…

It's because Haskell's type system at least helps you avoid getting the line noise wrong. If you have to refactor some complicated line noise then the compiler holds your hand.

Re: Haskell in Production

#57
post #56
post #54

Earlier quoted context omitted.

I still can't understand why Perl is easily dismissed as "LOL line noise" but Haskell's apparently fine. At least dipping into Perl you can take on the line noise slowly so you have time to absorb each new technique, and you can write it just fine with hardly any of that if you want, and it won't hurt a thing—Haskell seems to dump all that on you up front, and it seems to require it, idiomatically. It's very off-putt…

It's because Haskell's type system at least helps you avoid getting the line noise wrong . If you have to refactor some complicated line noise then the compiler holds your hand.

What would an error look like if I misused $ or &?

And yes, compilers hold a user’s hand in most languages (including PHP with type hints :) ).

Re: Haskell in Production

#58

How long does it take the “new programmers who have not worked with Haskell before” to learn and understand all the ASCII-art in the example code? How $ differs from On top of trying to remember that is string concatenation and >>= and <- have something to do with monads.

A couple of weeks in my case. It's not any more difficult than remembering that the -> is the cache-miss operator in C++. You also don't have to learn the entire universe of Haskell before being productive in it. I still have no idea what profunctors, comonads, and other things are and I'm shipping production Haskell code.

If you follow the link to the second article of the series, you’ll see that the author does dump all upfront, hence the question.

A couple of weeks to understand the terse operators (ab)used everywhere in Haskell code is horrendously long time, if you ask me.

Re: Haskell in Production

#59
post #56

Earlier quoted context omitted.

It's because Haskell's type system at least helps you avoid getting the line noise wrong . If you have to refactor some complicated line noise then the compiler holds your hand.

What would an error look like if I misused $ or &? And yes, compilers hold a user’s hand in most languages (including PHP with type hints :) ).

    • Couldn't match expected type ‘([Integer] -> [Integer]) -> [b]’
                  with actual type ‘[Integer]’
    • Possible cause: ‘map’ is applied to too many arguments
      In the second argument of ‘(&)’, namely ‘map (* 2) [1, 2, 3]’
      In the second argument of ‘($)’, namely
        ‘map (+ 2) & map (* 2) [1, 2, 3]’
      In the expression: map (+ 2) $ map (+ 2) & map (* 2) [1, 2, 3]

Re: Haskell in Production

#60
post #26

Earlier quoted context omitted.

>but what's wrong with the syntax? I'll just link to this blog about readable Haskell. If everyone followed his advise, it would be much better. http://www.haskellforall.com/2015/09/how-to-make-your-haskel...

Thanks. That's a good blog. The $ operator is definitely confusing in Haskell. F# uses print This means: Take the result of 4 * 2 and send it to `even`, then take that result and send it to `print`. Or you can write it with forward pipes to make it even clearer: 4 * 2 |> even |> print The thing about backward pipes is that they're often used to avoid parentheses, which is IMHO a good idea. It's just that thinking of…

> The $ operator is definitely confusing in Haskell

I generally think of it as a sort of open-ended parentheses that encloses the rest of the line. Instead of a backward pipe. It means "evaluate everything after this character first then apply the preceding function to it" just like parentheses would.

    print $ even $ 4 * 2
is equivalent to

    print ( even ( 4 * 2 ))
Post reply on HN