Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I tried Haskell for 5 years

metarabbit.wordpress.com

Post reply on HN
Print view View original

251–260 of 273 posts

Re: I tried Haskell for 5 years

#251

Post by platz »

harry8 wrote: post #250
platz wrote: post #52

Earlier quoted context omitted.

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

The state of the Haskell ecosystem is that it is amazing at encouraging people to write libraries, especially libraries to assist in writing haskell code but amazingly bad at encouraging people to write actual programs, especially actual programs useful for something that isn't writing code. Take out the programs that are for writing code, ghc, shellcheck, darcs etc. And what are you actually left with? git-annexe, p…

I believe a similar dynamic exists with many of the expressive high-level languages; this is probably not an issue unique to the Haskell community.

For example, I think many would struggle to name many open source user application written in Clojure as well.

Re: I tried Haskell for 5 years

#252

Post by adrianN »

Veedrac wrote: post #242
eximius wrote: post #234

Earlier quoted context omitted.

I find this response a little ironic because we don't really see complaints about knowing the C runtime and C compiler when performance becomes a problem, which is also jarring and frustrating. But, ultimately, sometimes languages have failings and we need to peek under the hood to figure out how to address it - we're just more comfortable with the relatively common and direct mapping of the C runtime. I am not exper…

When have you ever had the C runtime be the cause of a performance problem?

Writing a custom replacement for malloc is relatively common. Does that count?

Re: I tried Haskell for 5 years

#253

Post by Tarean »

zzalpha wrote: post #191
dllthomas wrote: post #183

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…

I think there are different types of space leaks:

- Reference is kept alive so that a computation can't be streamed. Easy to figure out with profiling but fixing them might make the code more complex. Also, if you have a giant static local variable ghc might decide to share it between calls so it won't be garbage collected when you'd expect it.

- Program lacks strictness so you build a giant thunk on the heap. This is probably what you think of when talking about dropping !'s everywhere. I don't find it that difficult to fix once the location is known but figuring that much out can be seriously annoying.

- Lazy pattern matching means the whole data has to be kept in memory even if you only use parts of it. I don't think I have ever really run into this but it is worth keeping in mind.

- I have seen code like `loop = doStuff >> loop >> return ()` several times from people learning haskell, including me. Super easy to track down but still worth noting I guess.

Building giant thunks is the only one where you really need some understanding of the execution model to fix it. 99% of the time it is enough to switch to a strict library function like foldl', though.

Re: I tried Haskell for 5 years

#254

Post by zzalpha »

adrianN wrote: post #252
Veedrac wrote: post #242

Earlier quoted context omitted.

When have you ever had the C runtime be the cause of a performance problem?

Writing a custom replacement for malloc is relatively common. Does that count?

Writing a custom replacement for malloc is relatively common.

You... can't be serious. That's common to you?

Re: I tried Haskell for 5 years

#255

Post by adrianN »

zzalpha wrote: post #254
adrianN wrote: post #252

Earlier quoted context omitted.

Writing a custom replacement for malloc is relatively common. Does that count?

Writing a custom replacement for malloc is relatively common. You... can't be serious. That's common to you?

Yes? From the Wikipedia:

"Because malloc and its relatives can have a strong impact on the performance of a program, it is not uncommon to override the functions for a specific application by custom implementations that are optimized for application's allocation patterns."

Re: I tried Haskell for 5 years

#256

Post by zzalpha »

adrianN wrote: post #255
zzalpha wrote: post #254

Earlier quoted context omitted.

Writing a custom replacement for malloc is relatively common. You... can't be serious. That's common to you?

Yes? From the Wikipedia: "Because malloc and its relatives can have a strong impact on the performance of a program, it is not uncommon to override the functions for a specific application by custom implementations that are optimized for application's allocation patterns."

"not uncommon" is far far from "common". If you're writing your own malloc replacement you're pretty deep into the weeds of high performance computing. Heck even just deciding to replace the stock implementation with an off-the-shelf replacement puts you in fairly rarified company. I'd wager the vast majority of software written for Linux makes use of the standard glibc allocator.

I expect high performance games are the most common exception, but they represent a fraction of the C/C++ in the wild.

Space leaks in Haskell, on the other hand, are unfortunately relatively easy to introduce.

Re: I tried Haskell for 5 years

#257

Post by eximius »

Veedrac wrote: post #242
eximius wrote: post #234

Earlier quoted context omitted.

I find this response a little ironic because we don't really see complaints about knowing the C runtime and C compiler when performance becomes a problem, which is also jarring and frustrating. But, ultimately, sometimes languages have failings and we need to peek under the hood to figure out how to address it - we're just more comfortable with the relatively common and direct mapping of the C runtime. I am not exper…

When have you ever had the C runtime be the cause of a performance problem?

I have not because I don't write C professionally. We generally have things that require algorithmic improvements due to the scale - language doesn't matter.

C's model requires you to understand the machine model. Haskell presumably requires you to understand the machine model (but less thoroughly) but understand the compiler's model also. It's a little more but comparable. So complaining only about the Haskell runtime just seems ironic to me.

Re: I tried Haskell for 5 years

#258

Post by eximius »

user5994461 wrote: post #241
eximius wrote: post #234

Earlier quoted context omitted.

I find this response a little ironic because we don't really see complaints about knowing the C runtime and C compiler when performance becomes a problem, which is also jarring and frustrating. But, ultimately, sometimes languages have failings and we need to peek under the hood to figure out how to address it - we're just more comfortable with the relatively common and direct mapping of the C runtime. I am not exper…

The C is very straightforward. Maybe you meant C++? You see no complaint because noone use that anymore. Anything that can be done with an easier language is done with an easier language. The hardcore C++ performance critical code is left to a few veterans, who don't complain.

I don't consider the combination of the C runtime + the machine model straightforward - just less arcane than C++. Consider pipelines and branch prediction and cache lines and it quickly becomes difficult. Granted, those typically become relevant later in the optimization stage than other things.

Re: I tried Haskell for 5 years

#259

Post by insulanian »

nickpeterson wrote: post #180
pivotal wrote: post #132

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.

F# is a beautiful, pragmatic, functional programming language. It's a shame some people dismiss it due its Microsoft origins.

Re: I tried Haskell for 5 years

#260

Post by Veedrac »

adrianN wrote: post #252
Veedrac wrote: post #242

Earlier quoted context omitted.

When have you ever had the C runtime be the cause of a performance problem?

Writing a custom replacement for malloc is relatively common. Does that count?

I don't see why not, though I wouldn't consider that to be an example of a difficult to diagnose problem in the same vein as lazy evaluation.
Post reply on HN