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.
Haskell in Production
51–60 of 242 posts
Re: Haskell in Production
#52Earlier 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?"
Re: Haskell in Production
#53> 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…
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
#54How 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.
Re: Haskell in Production
#55How 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.
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
#56How 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…
Re: Haskell in Production
#57Earlier 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.
And yes, compilers hold a user’s hand in most languages (including PHP with type hints :) ).
Re: Haskell in Production
#58How 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.
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
#59Earlier 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
#60Earlier 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…
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 ))