61–70 of 242 posts
Is there any books or long form articles digging into these different approaches? I know basic Haskell and heard of these different patterns a few times. I'm curious how it looks in a larger Haskell project and what the pros/cons are of each, and general popularity.
Edit: I see the next article in the series has more real code examples
Earlier quoted context omitted.
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 ))
If I remember correctly, Co-Star, the horoscope app, runs Haskell on the backend.
> Haskell is great for business and great in production. Hot take: no it isn't. It is extremely hard to learn, has an extremely confusing + needlessly complicated syntax and I question the payoff immensely. I question the well-being of anybody who subjects themselves to the pain and torture that is Haskell. If I stood up in a corporate business boardroom meeting for tech analysis on a new project and said "I want to…
Sounds like you've barely programmed in Haskell and don't know what you're talking about. > It is extremely hard to learn Haskell was the first language I learned. I didn't think this at all and I still don't. It doesn't strike me as any more difficult than learning Java or something. You may think this because Haskell is a different paradigm than what you're used to, so while you may be able to get quickly started w…
Haskell on the other hand creates crazy errors which confuse students, and often require extensive teaching to understand what is going on.
I'm happy to accept the possibility expert Haskell programs will be more productive in the longer term, but the learning is MUCH harder.
For example, here's one "simple" haskell error:
Prelude> print 2 + 3
:9:1: error: • No instance for (Num (IO ())) arising from a use of ‘+’
Now, it's not too hard to figure out what's gone wrong, but when doing beginning learning, explaining what (Num (IO ()))) is isn't something I want to be doing. No Java error gets that complicated.
Earlier quoted context omitted.
> all in all i think it requires a lot of discipline that can easily break down, whereas some of the popular imperative languages you can still sort of plug along (=> punt the technical debt) despite that. Interestingly I have the exact opposite perspective. Writing imperative or OOP code requires me to be excessively disciplined. It is extremely easy to build un-maintainable spaghetti. There is a whole cottage indus…
> There is a whole cottage industry of methods for your discipline of choice: Clean, SOLID, TDD, etc. I'm not a big OOP fan, but I'm pretty sure Clean and SOLID are principles (or sets of principles), while TDD alone is a practice. I'm also not very familiar with Clean or SOLID, but I'm pretty sure they apply to Haskell as well, and I would expect that Haskell enthusiasts would ordinarily boast that Haskell allows (o…
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.
> Haskell is great for business and great in production. Hot take: no it isn't. It is extremely hard to learn, has an extremely confusing + needlessly complicated syntax and I question the payoff immensely. I question the well-being of anybody who subjects themselves to the pain and torture that is Haskell. If I stood up in a corporate business boardroom meeting for tech analysis on a new project and said "I want to…
Cooleague was not familiar with Haskell before, barely touched it. He also was recovering from hard divorce and, as he has said later, was not willing to work at all.
After a month he delivered changes needed, with tests and ready to use.
So my experiences (there are several others anecdotes) directly contradict what you say.
Now about RTS and language itself.
Haskell has threads greener than Erlang and/or Go. Go's thread stack size is 4K-8K, in Haskell it is about 1K-1.5K. It is possible in Haskell to have scheduler as a library http://hackage.haskell.org/package/meta-par for finer scheduling which is not possible with Erlang and Go.
So I question the well-being of anybody who subjects themselves to the pain and torture that is not Haskell.
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…
> 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…
I’ve met some pretty damn solid engineers who started on Haskell and, even at a junior level in other languages, produce an elegant solution far more easily than a senior engineer in that language. You probably wouldn’t put the code in production verbatim but you can very easily see what’s going on and it isn’t haunted by spectre of early abstraction, which IMO is the biggest flaw of OOP at scale. People think you wa…
So much that developers develop an aversion to it as deep as fear. It's unavoidable, the ones that didn't develop it are still buried at the working of their first Rube Goldberg machine and unavailable.
You'll see plenty of blogs about a Haskell feature that end with "See? It's organized and safe. It works. Is it worth the complexity? No way! You'll never caught me using this thing that I just invented!"