Live data from Hacker News

I tried Haskell for 5 years

metarabbit.wordpress.com

91–100 of 273 posts

Re: I tried Haskell for 5 years

#91
post #45
post #28

Earlier quoted context omitted.

I think I can safely say it isn't used heavily in many production environments but it is used heavily in some. For example, one of Facebook's abuse systems, dealing with 1M requests per second is written in Haskell: https://code.facebook.com/posts/745068642270222/fighting-spa... As for particular places where it shines, I don't know of any in particular. I remember when taking my Declarative Programming course in uni…

The article you're looking for is http://www.cs.yale.edu/publications/techreports/tr1049.pdf - Two of the top three (out of ten) solutions were made in Haskell, one by a beginner.

It would be interesting to see the full source code for the various entries - am I missing a place to acquire them?

Re: I tried Haskell for 5 years

#93
post #41

Haskell: where difficult problems are trivial, and where trivial problems are the subject of ongoing academic research

C'mon. Funny joke, but not fair when taken serious. Or what "trivial problems are the subject of ongoing academic research" in Haskell?

Re: I tried Haskell for 5 years

#94
post #12

> very hard to understand why a function could be useful in the first place So true. https://hackage.haskell.org/package/base-4.9.1.0/docs/Contro... > mfix :: (a -> m a) -> m a > The fixed point of a monadic computation. mfix f executes the action f only once, with the eventual output fed back as the input. Hence f should not be strict, for then mfix f would diverge. But why tho?

Reflex is a frontend library for haskell.

    -- create an input text widget with auto clean on return and return an event firing on return
    -- containing the string before clean
    inputW :: MonadWidget t m => m (Event t T.Text)
    inputW = do
        rec
          -- fire send event when pressing enter
          let send = textInputGetEnter input

          -- textInput with content reset on send
          input 
Ignoring the operator soup for a second (thanks lens) you might notice that the send event depends on the input field and the content of the input field depends on the send event. In, say, java you would first create the field and then mutate it separately. In haskell mutating wouldn't work so instead we usually tie the knot which means making the value dependent on itself and letting laziness figure it out.

However we are creating a text field here so if we make the value recursive on itself we are gonna be spawning text fields all over the place. MonadFix is variant of this that splices the effect out so it is only run once and then allows the value to be recursive.

Re: I tried Haskell for 5 years

#95
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 gets real work done' demographic. I know which of the two I'd rather be in. Haskellers are even worse than Lispers in this regard. For the amount of noise about Haskell, you'd expect to see high-quality operating system kernels, IDEs, or RDMBSs written in it by now. Instead its killer apps are a tiling window manager, a document converter, and a DVCS so slow and corruption-prone even they avoid it in favor of Git.

Re: I tried Haskell for 5 years

#96

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

> ... I am a bit lost Google "cognitive dissonance" and the "sunk cost fallacy."

The point of the article was focusing on things to fix. Having used Haskell, there's a great many things that were worth the cost of learning it. For one thing, it's made me a vastly better programmer in other languages. It lets me appreciate better styles of writing code and think outside the box when solving things. Using Haskell also gives me the tools for many projects to write code almost thoughtlessly -- you can just start writing in a declarative style and not worry about debugging, because everything is checked by the type system. Libraries exist for abstractions you wouldn't even think of in other languages that can cut down the code to 1/100th the length it would be and maintain expressiveness and type safety. At the same time, I don't find myself using Haskell all that often because I do think it's missing a lot of things I desire, but depending on what you're working on it can be very far from a sunk cost.

Re: I tried Haskell for 5 years

#97
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 has a preference for looking academic, and is one of the favorites on academic circles. But that does not mean it's not used within industry. I'd say that people mostly do not know what is running in industry. It could be any share of anything. We get a hint looking at job offers; Haskell is small there, but not unheard of. On the sweet spot, Haskell is great for modeling complex domains; it's great for long-…

>> I'd say that people mostly do not know what is running in industry

well if anyone does know what's out there then HN crowd would be a pretty good suspect in that regard.

I personally have done my fair share of consulting and prof services engagements - dozens of them across all kinds of industries - I've never seen a Haskell shop.

Java, Python, JS, Golang, Scala, Clojure, .Net, C, PHP - definitely out there in the field. Haskell - not so much.

Re: I tried Haskell for 5 years

#98
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

I've always disliked mapM_. Something about it just looks ugly and it doesn't really hint what its for. I would like to see mapM as mapMonad and mapM_ as eachMonad. Of course, once I knew what it meant the abbreviations became rather nice.

Re: I tried Haskell for 5 years

#99

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

> (#1) Time and experience can cover up anything. This is simply not true. Time and experience can never cover up for lack of expressiveness, and expressiveness is one of the biggest selling points of Haskell. In fact, experience can only cover for complexity, and lack of discoverability or intuitiveness. Haskell has all those three flaws, so you see, experience is really needed. > (#2) So does NodeJS and (on an abst…

> 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 the idea of taking browser screenshot (for example) or producing a publisher acceptable document with the same kind of ease(expressiveness in my dictionary) in Haskell?

Again, without specifics, the comparisons does not mean much -- which was all I was commenting.

> But the sheer amount of hard stuff that becomes easy is unsettling.

Another meaningless subjective word (sheer). I wasn't debasing Haskell. I was commenting on the meaningless of original post.

Re: I tried Haskell for 5 years

#100
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 in GHC https://ghc.haskell.org/trac/ghc/ticket/11783

Post reply on HN