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

151–160 of 242 posts

Re: Haskell in Production

#151

Post by wellpast »

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.

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.

Re: Haskell in Production

#152

Post by wellpast »

verttii wrote: post #143
wellpast wrote: post #102

I will probably get stomped on for this but to me it's a giant elephant in the room. When that one purist on the team proposes mandating having 100%, 80%, or any hard number of unit test coverage, most sane people tend to disagree and understand its wild impracticality and counter-productivity. However - when one (ie, a Haskeller) says that the code must universally pass 100% strong static type verification coverage…

> SO MUCH worse cost/benefit than unit testing My experience is exactly the opposite. Using the type system is less effort, guides your development more and, in a way, provides more consistent guarantees than spending time on a wide unit test coverage. Obviously, these things are not totally mutually exclusive though.

If you are truly doing an apples to apples comparison here, I suspect you’re using a struct subset of your dynamic language. Otherwise I can’t see how the addition of a rule-based static-check pass filter gets you faster.

What are the two static & dynamic languages you’re comparing by the way?

Re: Haskell in Production

#153

Post by mbrodersen »

microtherion wrote: post #79
Mathnerd314 wrote: post #4

All the interesting code is in the next post, http://felixmulder.com/writing/2019/10/05/Designing-testable... . I'm not sure why they use a generic monad rather than ST, they don't need continuations for this. The Reader monad with a big record is standard Haskell, it's basically what GHC uses: https://github.com/ghc/ghc/blob/1219f8e8a3d1b58263bea7682232... data-has is less standard, it only seems to have been used s…

It's always good to see examples of how a language is actually used, rather than just assertions of its superiority. That said, if Haskell programmers truly consider this a superior and readable way to write code would tend to reinforce my preconception of them as an insular community elevating arcane jargon to a virtue (not unlike the APL programmers of yore).

> reinforce my preconception of them as an insular community elevating arcane jargon to a virtue

I highly recommend not assuming that all "Haskell programmers" agree on what is "superior and readable" code. I also recommend trying to explain "arcane jargon" such as "inheritance", "encapsulation", "method invocation", "recursion", "dependency injection" etc. to people who are not already familiar with such jargon. They might perhaps start believing that you are "an insular person elevating arcane jargon to a virtue"?

Re: Haskell in Production

#154

Post by mbrodersen »

microtherion wrote: post #100
jeremyjh wrote: post #95

Earlier quoted context omitted.

Its strange how code written in unfamiliar languages is ... unfamiliar? The Haskell in that post is bog-standard. The definition of "arcane" is not "I don't know it".

I've worked in a pretty wide range of languages. I think I know "unfamiliar" and I can tell it apart from "arcane". OP claims that "this article will emphasize writing easy to grok, maintainable code". The definition of "easy to grok" is not "once you've bought into the entire mindset, this will be obvious to you".

> I've worked in a pretty wide range of languages

Which languages are those? If the answer is "N flavours of imperative/OO languages" (like C/C++/Java/C#/Ruby/Javascript) then you really haven't worked in languages different enough for you to truly learn anything new. The rule is simple: if learning a new language is easy, then there isn't much new in the language for you to learn (except a different flavour of syntax or whatever).

Re: Haskell in Production

#155

Post by verttii »

wellpast wrote: post #152
verttii wrote: post #143

Earlier quoted context omitted.

> SO MUCH worse cost/benefit than unit testing My experience is exactly the opposite. Using the type system is less effort, guides your development more and, in a way, provides more consistent guarantees than spending time on a wide unit test coverage. Obviously, these things are not totally mutually exclusive though.

If you are truly doing an apples to apples comparison here, I suspect you’re using a struct subset of your dynamic language. Otherwise I can’t see how the addition of a rule-based static-check pass filter gets you faster. What are the two static & dynamic languages you’re comparing by the way?

For example now I'm building a Servant API on Haskell. It's basically a strongly typed API that you don't need to validate with tests. You only need to test the handlers that handle business logic.

In other languages with a less sophisticated type systems I would need to build validation functions manually and obviously test them. Hell, an interpreted language might even boot up with functions that have faulty code, ultimately producing runtime errors when invoked. Haskell generally would not (because of the type system). Adding type constraints basically limits the range of possible inputs/outputs, requiring you to write far less tests.

Re: Haskell in Production

#156

Post by mbrodersen »

gip wrote: post #11

> Haskell is great for business and great in production I disagree. It's a beautiful language but it lacks a lot of features to make it useable at scale. And in my experience Haskell engineers are extremely smart but the environment/culture they create makes it difficult to foster team spirit. I've been in 2 companies in the last 4 years who initially used Haskell in production. One has transitioned to Go and the oth…

> it lacks a lot of features to make it useable at scale

Facebook (and other companies) run Haskell in production, at scale. So I wonder what those "lots of missing features" you mention are? With "lots of them" I am sure you can mention at least 5+?

Re: Haskell in Production

#157

Post by mbrodersen »

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…

> Haskell gives one plenty of rope to hang himself on complexity.

Interesting. And C++/Java/Javascript doesn't?

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

Wow that sounds like there would be lots of examples you can mention. Care to mention any example we can verify?

> ou'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 never caught me using this thing that I just invented!"

I have never seen such articles. Please show us a few links?

Re: Haskell in Production

#158

Post by mbrodersen »

maximente wrote: post #32
gip wrote: post #11

> Haskell is great for business and great in production I disagree. It's a beautiful language but it lacks a lot of features to make it useable at scale. And in my experience Haskell engineers are extremely smart but the environment/culture they create makes it difficult to foster team spirit. I've been in 2 companies in the last 4 years who initially used Haskell in production. One has transitioned to Go and the oth…

in my (limited) experience, Haskell projects (and to a slightly lesser extent, functional programming projects) work best when thoroughly planned out in thorough whiteboard/spec sessions and are then implemented by a couple of gurus responsible for the code, who work almost exclusively in functional languages in their day to day. there seems to be a need for way more thought-per-line-of-code in Haskell/FP projects. m…

My experience is quite the opposite. I can throw together Haskell code and refactor it much quicker than equivalent C++/Java code. And I have a lot more experience with C++/Java than Haskell.

Re: Haskell in Production

#159

Post by mbrodersen »

wolco wrote: post #89
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.

What happens when you need to scale up or if one or more of the gurus quits? Do you think Haskell will still be primarily used when you grow?

Ask Facebook. They are running Haskell at massive scale.

Re: Haskell in Production

#160

Post by mbrodersen »

StreamBright wrote: post #96
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.

For the problem you are solving and at your scale. Things start to change when you need to hire n+1 teams or engineers quickly.

Yes indeed but not the way you think. There are many highly experienced developers out there who would love to use Haskell in their day job but currently can't. So your problem will be processing all the highly qualified CV's you will receive.
Post reply on HN