Live data from Hacker News

I tried Haskell for 5 years

metarabbit.wordpress.com

131–140 of 273 posts

Re: I tried Haskell for 5 years

#131

Earlier quoted context omitted.

> Haskell is an example of academic carefully crafted language, while C++ is rather a practically driven continuous patchwork (and they are extremities to both ends). Haskell is also a continuous patchwork, just look at the number of deprecated GHC extensions.

... which is the opposite of its pure vision, which is why I can't help think it is a negative.

>>> Haskell is an example of academic carefully crafted language

>> Haskell is also a continuous patchwork

> which is the opposite of its pure vision, which is why I can't help think it is a negative

I'm very confused. One second, you're literally saying Haskell was "carefully crafted", and the next, you're saying it's "the opposite of its pure vision"

It's almost as if you're just trying as hard as you can to argue, not caring what stance you're arguing, just so long as you can act like the author is wrong

Re: I tried Haskell for 5 years

#132
post #8

If anyone's curious to try out functional programming, I would highly recommend Elm. I haven't been so excited about a language since I went from C to Ruby ten years ago, and Pragmatic Studios has a great course on it (I have no affiliation): https://pragmaticstudio.com/courses/elm

I spent some time working through various Haskell books with varying success, then decided to do a code challenge (adventofcode.com) using Elm. I didn't finish, but after writing Elm for many days on end, suddenly Haskell clicked a lot more. The Elm compiler is far more friendly than Haskell's and will walk you through a lot of rookie mistakes and oversights.

I find Elm exciting, and with the prevalence of React/Redux these days, a lot of front end developers would be wise to familiarize themselves with the origin of many of the concepts borrowed from Elm.

Re: I tried Haskell for 5 years

#133

Earlier quoted context omitted.

> Time and experience can never cover up for lack of expressiveness Expressiveness is subjective. Experience can alter one's perception. In fact, time and experience alter the basis of comparisons, from objective comparisons to subjective comparisons. > No, they don't. Javascript and macro Basic do not even have enough expressiveness for supporting the kind of library you'll find in Haskell. You mean you can express…

haskell is objectively expressive. (where expressive means amount of logic per character) there are multiple reasons for this, kind've tied together. Whitespace is function application (no parenthesis to keep track of like lisp, or even e.g. c, java, or javascript, when programming in a functional style). Immutability forces you to compartmentalize and compose everything. when everything is a function, function and v…

By objective, you mean succinctness (which can be simply measured by program character counts)? In this regard, APL must be the most objectively expressive language. What if we run deflation over APL?

It happens that I measure expressiveness by the amount of the time the author takes to express an idea and/or the amount of the time the reviewer takes to comprehend an idea. That, unfortunately, is very subjective.

APL programmers write very short programs, but they express it at one character a minute (or less) pace.

Re: I tried Haskell for 5 years

#134

Earlier quoted context omitted.

> If you ignore mem issues you can also reason about the performance of Haskell :) Really? My guess (based on close to complete ignorance) would be that laziness would make reasoning about performance hard. Can you ELI5 why my guess is wrong?

All performance issues caused by laziness are memory issues. Something isn't evaluated promptly, so large amounts of memory are consumed storing unevaluated expressions. This causes drag on the garbage collector and excess cache thrashing when it finally is evaluated. But all of that is just because data stays in memory longer than expected. If you ignore that, laziness has a small performance impact, but it's less t…

Both you and cies said that "All performance issues caused by laziness are memory issues." My intuitive sense was more like: You've got a lazy calculation that has several stages. At some point in the pipeline, you're doing something slow, but it's not obvious. When you get to the end and start using the data, the whole calculation is slow. But it's not clear where it's slow, because of the laziness.

That may not be "a performance issue caused by laziness", in your terms, because the laziness isn't causing performance issues. But it's laziness making a performance issue hard to find.

Does my scenario happen? Is it common? Is it easy to analyze/find/fix when it does happen?

Most generally, does laziness make it harder to reason about performance?

Re: I tried Haskell for 5 years

#135
post #126
post #8

If anyone's curious to try out functional programming, I would highly recommend Elm. I haven't been so excited about a language since I went from C to Ruby ten years ago, and Pragmatic Studios has a great course on it (I have no affiliation): https://pragmaticstudio.com/courses/elm

I think a lot of Haskeller's will find Elm's type system to be limited and frustrating. Even for simple things the solution in Elm is that you have to write a bunch of boilerplate.

I had this experience. However, starting out I think it'd be a much more gentle introduction.

For other haskellers, Purescript seems to solve this problem.

Re: I tried Haskell for 5 years

#136
post #8

If anyone's curious to try out functional programming, I would highly recommend Elm. I haven't been so excited about a language since I went from C to Ruby ten years ago, and Pragmatic Studios has a great course on it (I have no affiliation): https://pragmaticstudio.com/courses/elm

I concur with your suggestion. As a longtime functional programmer (Lisp, Clojure, Erlang), Elm is one of my favorite languages of all time. I'm hoping to jump into Haskell next, and I feel like it's a great transition in that direction.

Re: I tried Haskell for 5 years

#137

I will never, ever use Haskell in production because of its default evaluation strategy, the wrongness of which was tacitly conceded not long ago with the addition of the strictness pragma (which only works per-module) to GHC. I think it's especially telling that its community skews so heavily towards this blogger/monad tutorial writer dilettante demographic rather than the D. Richard Hipp/Walter Bright 'actually get…

My impression on the consensus was that laziness was good for the tree (computation) but bad for the leaves (datatypes); hence the good practice of using strictness annotations on datatypes.

Re: I tried Haskell for 5 years

#139
post #107

Earlier quoted context omitted.

Serious question. In the following code, what would be better function / type names? (or you can pick another bit of Haskell code that you know and/or have particular trouble understanding). class Foldable t where foldl :: (b -> a -> b) -> b -> t a -> b

Maybe something like: class Foldable myFoldable where foldl :: (summary -> element -> summary) -> summary -> myFoldable element -> summary This is the translation I do in my head when I read that type signature, at least.

Wow. That's much better.

Apparently-idiomatic Haskell reads (or, rather, doesn't) about like line-noise/code-golf style Perl to me.

Re: I tried Haskell for 5 years

#140
post #52
post #16

Question to the Haskell experts here. Is Haskell more academic in nature or used heavily in Production environments? Is there an application sweet spot/domain (say Artificial Intelligence/Machine Learning, etc) where it shines over using other languages (I am not talking about software/language architectural issues like type systems or such)? I have no experience with Haskell but do use functional languages such as E…

> Is there an application sweet spot/domain State of the Haskell ecosystem: https://github.com/Gabriel439/post-rfc/blob/master/sotu.md The topics are roughly sorted from greatest strengths to greatest weaknesses. Each programming area will also be summarized by a single rating of either: Best in class: the best experience in any language Mature: suitable for most programmers Immature: only acceptable for early-adopte…

This is an excellent Haskell resource. Grades are given by both application domain (e.g., "web development") and development task (e.g., "testing" or "IDE Support"). Each of the categories has not only a grade but also list of relevant libraries and example projects.
Post reply on HN