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

Haskell in Production

felixmulder.com

Post reply on HN
Print view View original

181–190 of 242 posts

Re: Haskell in Production

#181

Post by mbrodersen »

wellpast wrote: post #148
tome wrote: post #134

Earlier quoted context omitted.

If it happens every time then it should be easy for you to give a small example. Please do! It’s very hard to understand what you mean otherwise.

Pattern matching for one. I can prove that 3 cases won’t be met but I have to ‘fill in’ them anyway. ADTs with non-Maybe fields. I can prove that all is fine if this ‘slot’ isn’t filled in. Trying to pass an opaque reference down a function call chain. There’s 3.

Right. And when another programmer changes the ADT so that this is no longer true your dynamic language will now crash in production instead of telling you right away before putting it into production? Or are you telling me that your code always have 100% code test coverage checking all possible execution paths for all pattern matches?

Re: Haskell in Production

#182

Post by mbrodersen »

wellpast wrote: post #150
wellpast wrote: post #148

Earlier quoted context omitted.

Pattern matching for one. I can prove that 3 cases won’t be met but I have to ‘fill in’ them anyway. ADTs with non-Maybe fields. I can prove that all is fine if this ‘slot’ isn’t filled in. Trying to pass an opaque reference down a function call chain. There’s 3.

And these are insanely expensive to deal with over time when you compare to the alternative.

> insanely expensive

Wow that sounds really expensive! How did you actually measure that in the real world?

Re: Haskell in Production

#184

Post by diffeomorphism »

pictur wrote: post #141
seddona wrote: post #63

We are a YC company doing very well, all our back end code is written in Haskell. We have produced a lot of functionality with a relatively small team. I would say we are existence proof that Haskell is good for business.

Who determines that you are a very good company?

Who claimed they are "a very good company"?

The post simply says they are "doing very well" (financially). That is fairly objective.

Re: Haskell in Production

#185

Post by TheCoelacanth »

chrisseaton wrote: post #145
james-mcelwain wrote: post #120

Earlier quoted context omitted.

I believe they mean static methods as part of the interface signature, e.g. to define constructor/factory methods. AFAIK there are issues with how Java handles dynamic dispatch that prevent this.

What would calling such a method look like?

Imagine that Collection had a static method `empty` that created an empty collection of the appropriate type depending on the type you are assigning it to, e.g. `List list = Collection.empty();` would create a list, `Set set = Collection.empty();` would create a set, and so on. This would be fairly similar to how things work in Haskell.

Re: Haskell in Production

#186

Post by lallysingh »

marcosdumay wrote: post #70
ljm wrote: post #28

Earlier quoted context omitted.

I’ve met some pretty damn solid engineers who started on Haskell and, even at a junior level in other languages, produce an elegant solution far more easily than a senior engineer in that language. You probably wouldn’t put the code in production verbatim but you can very easily see what’s going on and it isn’t haunted by spectre of early abstraction, which IMO is the biggest flaw of OOP at scale. People think you wa…

Haskell gives one plenty of rope to hang himself on complexity. So much that developers develop an aversion to it as deep as fear. It's unavoidable, the ones that didn't develop it are still buried at the working of their first Rube Goldberg machine and unavailable. You'll see plenty of blogs about a Haskell feature that end with "See? It's organized and safe. It works. Is it worth the complexity? No way! You'll neve…

Hi, I find that everything people here are complaining about (and they're valid complaints) has also been true of C++. C++ developed a lot of its complexity (particularly 15-20 yrs ago in the template space) after it got popular, so people were already wed to it.

I've used both quite a bit. Haskell's easier to learn to do well than C++ -- with the caveat that you can write java-style C++ productively without using the language very far. C++ in the "modern" style is more complex than Haskell. There are good reasons for that complexity, but it's still there.

I've seen plenty of projects where people have dug themselves into deep C++ holes -- everything is a template, all the files are headers, and the code is unreadable. These are business critical systems still in use in production worldwide.

The C++ community's really gotten good in the last 5 years or so about reigning in the bad impulses and getting people to write clean, clear, efficient code that has reasonable expressiveness.

Coming into Haskell from C++, I have the same instincts. Haskell's been a pure pleasure. The benefits are really there, and they're easy to get. You just have to think of the trade-offs.

Re: Haskell in Production

#187

Post by tome »

wellpast wrote: post #148
tome wrote: post #134

Earlier quoted context omitted.

If it happens every time then it should be easy for you to give a small example. Please do! It’s very hard to understand what you mean otherwise.

Pattern matching for one. I can prove that 3 cases won’t be met but I have to ‘fill in’ them anyway. ADTs with non-Maybe fields. I can prove that all is fine if this ‘slot’ isn’t filled in. Trying to pass an opaque reference down a function call chain. There’s 3.

Sure, thanks, I know where Haskell's type system will ask you to try again if you haven't provided all the information it wants. I'm asking for examples where it genuinely wasn't sensible to change your code to match what the compiler wants.

> Pattern matching for one. I can prove that 3 cases won’t be met but I have to ‘fill in’ them anyway.

This is a funny one because, no, GHC will not ask you to fill them in! You have to turn on a warning for it to complain. The fact that the warning is not on by default is one of my pet peeves with GHC!

> ADTs with non-Maybe fields. I can prove that all is fine if this ‘slot’ isn’t filled in.

Another funny one, because you can just use `undefined` or `error` and GHC won't complain! Personally I'd probably prefer that it did.

> Trying to pass an opaque reference down a function call chain.

I don't even know what you mean by that.

Re: Haskell in Production

#189

Post by tome »

wellpast wrote: post #151
wellpast wrote: post #148

Earlier quoted context omitted.

Pattern matching for one. I can prove that 3 cases won’t be met but I have to ‘fill in’ them anyway. ADTs with non-Maybe fields. I can prove that all is fine if this ‘slot’ isn’t filled in. Trying to pass an opaque reference down a function call chain. There’s 3.

Here’s another that kills me every time, I want to compose where I know types are mismatched and I am okay with a runtime fault downstrean . This is hugely powerful to move very fast in, eg, REPL-driven development environment where you build and verify pieces of code incrementally. Not being able to do this is a enormous productivity killer, relative to say a dynamic/Clojure.

> I want to compose where I know types are mismatched and I am okay with a runtime fault downstrean.

Sounds like another good candidate for `error` or `undefined`

Re: Haskell in Production

#190

Post by dllthomas »

StreamBright wrote: post #144
dllthomas wrote: post #137

Earlier quoted context omitted.

They... might? I worked at a Haskell start-up for a bit. Hiring wasn't easy. But it doesn't seem to be easier at the mostly-JS start-up I'm working at now.

I think so. https://insights.stackoverflow.com/survey/2019#technology

That doesn't speak to Haskell. You can say that's because there's not a lot of Haskell and that's likely at least partly true. But the difficulty hiring for a position depends on the number of people qualified and the number of other roles competing for those people. The fact that both of those numbers are smaller for Haskell than (say) Java doesn't tell us whether it'll be easier to hire for Haskell or Java.
Post reply on HN