Live data from Hacker News

I tried Haskell for 5 years

metarabbit.wordpress.com

101–110 of 273 posts

Re: I tried Haskell for 5 years

#101
post #89
post #53

Earlier quoted context omitted.

> reasoning about the correctness of complex code, however the tradeoff is difficulty in reasoning about performance That's what drove me to languages like OCaml and Rust, which try to solve this tradeoff in a different way: Same thing about strictness and correctnes (despite slight differences in the type system), but lazy evaluation is only provided when explicitly asked for. The cool thing about OCaml is that you…

> The cool thing about OCaml is that you can actually reason about performance, as long as you ignore memory issues (memory usage, garbage collector runs, etc.). If you ignore mem issues you can also reason about the performance of Haskell :) If we want to reason about perf, I think Rust is currently leading in terms of a modern language that allows perf reasoning.

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

Re: I tried Haskell for 5 years

#102
post #37

Earlier quoted context omitted.

Ubiquitous single-letter symbols mapping to who-knows-what possible things, pnflly abvted fncn nms, and unclear motivations for code are what I've bounced off of with Haskell every time I've tried to dig in. The community seems to have adopted all the worst parts of mathematics culture, along with whichever good parts they've brought in.

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

[deleted]

Re: I tried Haskell for 5 years

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

We're using Haskell to produce an entire compute platform for building, composing, and running type-safe containerised micro-services for data science. This certainly touches on a lot of the areas that Haskell is traditionally known for being good at, e.g. building DSLs, type systems, interpreters, etc.

However, the work also includes a runtime platform that is more low-level, including building our own container system, talking to the Linux kernel, using cgroups/resource management, and distributed message passing - areas where languages such as Go have found a niche, and may be classified as Real World. However for us, Haskell's type-safety, runtime performance, and extensive ecosystem has been a boon even in this domain. We effectively use it as an (incredibly powerful) general-purpose language here, and it's worked more than fine.

We're currently at around 15,000 lines of code with a team of 5 Haskellers, and it hasn't really been a problem regarding performance, understanding the codebase, or with newcomers to the team.

(plug - we're at https://www.github.com/nstack/nstack and are hiring more Haskellers)

Re: I tried Haskell for 5 years

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

(OP here) I do say it's not that big of a deal in the end: it almost always is OK and at the end you optimize the inner loops by looking at profiles; like in any other project. But when using GHC, I have indeed sometimes ran into situations where I expect something to be fast when it is not (e.g., `ByteString.map (+ value)` is incredibly slow compared to a pseudo-C loop). I also did find a bona fides performance bug…

GHC isn't magical. It has bugs too.

We had an issue with the Data.Text package and OverloadedStrings in 7.10.2 which caused extremely slow compilation times and filed a bug report for that, which was solved for 7.10.3.

Re: I tried Haskell for 5 years

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

Hi can you tell us a bit more about this SQL-related project? I'm rather practically interested.

Re: I tried Haskell for 5 years

#106
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.

Until you have to solve a (maddeningly common) space leak issue. That's a problem unique to lazily evaluated languages (basically Haskell) and is godawful to debug.

It reminds me of solving git problems... you suddenly find yourself having to tear back the abstraction layer that is the language and compiler and start thinking about thunks and so forth.

It's jarring and incredibly frustrating.

Re: I tried Haskell for 5 years

#107
post #37

Earlier quoted context omitted.

Ubiquitous single-letter symbols mapping to who-knows-what possible things, pnflly abvted fncn nms, and unclear motivations for code are what I've bounced off of with Haskell every time I've tried to dig in. The community seems to have adopted all the worst parts of mathematics culture, along with whichever good parts they've brought in.

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.

Re: I tried Haskell for 5 years

#108
post #27

> The same is not true of Haskell. If you have never looked at Haskell code, you may have difficulty following even simple functions. Why is it that people talk about this almost as if it's done virtue of the language? As if the fact that's it's so inscrutable proves that it's valuable, different, and on a higher plane of computing.

The point is that it's not inherently inscrutable—it's different. And being different is a virtue: at the very least, you'll learn something from Haskell, and it's going to let you do things other languages won't. It's not just an Algol reskin.

If it had Algol syntax and Algol naming conventions it might actually have succeeded outside of academia. The decision not to go with an Algol-derived syntax was probably the biggest mistake ever done in Haskell's design.

Re: I tried Haskell for 5 years

#109

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

OP here. The point about a learning curve is that Haskell is different from most mainstream programming languages. > > 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. Javascript is one of the most widely used languages in the world and MS Word leverages t…

So you understand I was commenting that your post didn't really say much about Haskell (learning curve, libraries, tooling ). What you commented or implied is a bit of current Haskell culture.

> I actually like C++ a lot.

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). I simply find your comparisons odd. Given their deliberate design choice difference and it ended up feeling alike, how can that be positive?

Re: I tried Haskell for 5 years

#110
post #105
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…

Hi can you tell us a bit more about this SQL-related project? I'm rather practically interested.

I work for www.sqream.com, and our main product is SQream DB.

SQream DB is a GPU SQL database for analytics. Everything was written in-house - from the SQL parser all the way down to the storage layer. We're designed to deal with sizes from a few terabytes to hundreds of terabytes, and we use the GPU to do most of the work. It is the compiler (written in Haskell) however, that decides about specific optimizations and deals with generating the query plan.

Our SQL parser and typechecker is actually BSD3 licensed, if it's interesting: https://github.com/jakewheat/hssqlppp

Post reply on HN