Live data from Hacker News

I tried Haskell for 5 years

metarabbit.wordpress.com

191–200 of 273 posts

Re: I tried Haskell for 5 years

#191

Earlier quoted context omitted.

I wish the problem was simply detecting and isolating space leaks. My experience is that actually fixing them can be incredibly difficult, hence my comment about needing to understand the gory details about how the runtime evaluates lazy expressions. Heck, that post even uses the phrase "Attempt to fix the space leak" as it's often not an obvious slam dunk. Sometimes it even devolves to peppering !'s around until the…

> My experience is that actually fixing them can be incredibly difficult My experience differs, FWIW. If you know where you're creating too many thunks, and you force them as you create them, they don't accumulate. Making sure you actually are forcing them, and not simply suspending a "force this", is probably the trickiest bit until you're used to the evaluation model.

If you know where you're creating too many thunks, and you force them as you create them, they don't accumulate.

Translation: if you've internalized the way Haskell code is compiled and executes, so that you can easily reason about how lazy evaluation is actually implemented, you can solve these problems.

If not, it devolves to throwing !'s in and praying.

Which is basically my point.

If I don't have a hope of solving common space leaks without deeply understanding how Haskell is evaluated, that's a real challenge for anyone trying to learn the language.

Re: I tried Haskell for 5 years

#192
post #82
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…

Haskell works really well for things revolving around languages. At SQream (www.sqream.com), Haskell is used for CLI, SQL parser, SQL language compiler, SQL optimizations and a variety of tools. We also use Haskell to generate Python code for testing (think: describing a testing scenario and sets of queries, translating into a runnable, predictable Python script that's easy to debug)

To me, this is Haskell's most appealing strength. The idea is, you can express your domain and logic in Haskell in pure functions which are highly testable, and then you can use that to generate code in any language you want. And the code you generate can have whatever zero-cost abstractions you choose to invent, all implemented in the nice, functional Haskell layer.

Haskell's strength at expressing and transforming AST's, in pure functional, understandable, testable code seems to be the key here.

Re: I tried Haskell for 5 years

#193
post #50

Earlier quoted context omitted.

> The line that if it compiles, it’s probably correct is often true. That is the meat of why Haskell is so great. I've never so reckless refactored code as much as I do in Haskell, I just wait for the compiler to tell me what I missed and go back and fix it up. I'd never do that in C, C++, Java, etc; it'd be suicide. And while that's still not a great fleshed out explanation, it's a great oversimplification of the sy…

"That is the meat of why Haskell is so great. I've never so reckless refactored code as much as I do in Haskell, I just wait for the compiler to tell me what I missed and go back and fix it up. I'd never do that in C, C++, Java, etc; it'd be suicide." That's interesting. I am pretty aggressive with C++ refactoring because the compiler will tell me what's wrong. Especially compared to JavaScript for example. In what w…

The semantics of the program can be more thoroughly encoded in Haskell's far more powerful type system. So if the program type checks you're far more likely to have a correct program than in a language like C++ or Java.

Re: I tried Haskell for 5 years

#194
post #61

Earlier quoted context omitted.

I've tried "Learn You A Haskell for Great Good" and "Real World Haskell".

That was my guess, but I didn't want to be presumptuous. I tried with them and as well it didn't really stick. In my opinion "Learn You A Haskell" is a great supplememental reference, but a terrible teaching tool. And I think It's done more disservice to enforcing the reputation of Haskell being difficult to learn. I highly recommend the lecture notes online from the "Upenn Spring 2013 Haskell" class. Search that phr…

[deleted]

Re: I tried Haskell for 5 years

#195

> If you read an article from 10 years ago about the best way to do something in the language, that article is probably outdated by two generations. Thank you, that is all I need to know about Haskell. I won't be learning Haskell then, in the same way that I won't have anything to do with C++. I don't have enough time to use these fashion-dominated and fad-obsessed programming languages.

Holy cow! Don't ever dream about getting into node.js then!

Re: I tried Haskell for 5 years

#196
post #50

> 1. There is a learning curve. Time and experience can cover up anything. So this does not say much about Haskell other than it is all negative without time and experience. > 2. Haskell has some very nice libraries So does NodeJS and (on an abstract level) Microsoft Word. Libraries are infrastructures and investments that (like time and experience) can cover up any shortcomings. > 3. Haskell libraries are sometimes…

> The line that if it compiles, it’s probably correct is often true. That is the meat of why Haskell is so great. I've never so reckless refactored code as much as I do in Haskell, I just wait for the compiler to tell me what I missed and go back and fix it up. I'd never do that in C, C++, Java, etc; it'd be suicide. And while that's still not a great fleshed out explanation, it's a great oversimplification of the sy…

> I've never so reckless refactored code as much as I do in Haskell, I just wait for the compiler to tell me what I missed and go back and fix it up. I'd never do that in C, C++, Java, etc; it'd be suicide.

That's precisely what I was doing at work today in a C# project. I was going particularly crazy today, doing some refactoring with project wide regex replaces rather than leaning on VS/Resharper for everything.

I think it depends a lot on how your project is structured. If you're passing around object everywhere and casting... you're gonna have a bad time, sure. But at that point you're practically using Python or something. If you're using generics and so on properly, then you can lean on the compiler and type system quite a lot.

Re: I tried Haskell for 5 years

#197
post #74

We have a code base of roughly 200,000 lines of Haskell code, dealing with high performance SQL query parsing, compilation and optimizations. I only remember one situation over the past 5 years that we had a performance issue with Haskell, that was solved by using the profiling capabilities of GHC. I disagree that performance is hard to figure out. It could be better, yes - but it's not that different than what you'd…

> but it's not that different than what you'd get with other programming languages

Does your list of other programming languages include C/C++/asm?

;)

Re: I tried Haskell for 5 years

#198

Earlier quoted context omitted.

Your experience may be biased. If I had a shop that depended on external consultants for development, I'd avoid any language that I'm not certain to be mainstream. It's just too risky.

I can name two Haskell consultancies off the top of my head :)

But what if those two are busy right now? What if geography is a problem?

Compare with how many Java consultancies do you think you can find on a quick search?

I don't think the Haskell development labor market is nearly liquid enough to rely on consultants. For full time jobs the picture is very different.

Re: I tried Haskell for 5 years

#199

Earlier quoted context omitted.

> My experience is that actually fixing them can be incredibly difficult My experience differs, FWIW. If you know where you're creating too many thunks, and you force them as you create them, they don't accumulate. Making sure you actually are forcing them, and not simply suspending a "force this", is probably the trickiest bit until you're used to the evaluation model.

If you know where you're creating too many thunks, and you force them as you create them, they don't accumulate. Translation: if you've internalized the way Haskell code is compiled and executes, so that you can easily reason about how lazy evaluation is actually implemented, you can solve these problems. If not, it devolves to throwing !'s in and praying. Which is basically my point. If I don't have a hope of solvin…

This sounds a bit FUD-ish. Programming in any language involves understanding the evaluation strategy. You seem to be advocating languages that can be used with a level of ignorance or innocence which in practice just isn't possible.

https://en.wikipedia.org/wiki/Evaluation_strategy

Re: I tried Haskell for 5 years

#200

Earlier quoted context omitted.

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/Redu…

I bought a few Haskell books but could never really grok it. In the last couple years I started learning f# and have found it's an incredible "intro to Haskell" language. I opened one of my Haskell books the other day and realized I understood everything much more quickly.

The same is true of OCaml.
Post reply on HN