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

191–200 of 242 posts

Re: Haskell in Production

#191

Post by whateveracct »

whalabi wrote: post #138

How is such an obscure language - with associated difficulty in finding talented engineers - ever going to be a better choice than a more mainstream language, which probably has many of the same features?

It's actually not that hard to find talented engineers, especially if you are a distributed/remote team. I've interviewed & given a thumbs up to a constant stream of Haskell candidates (either with Haskell experience or interest in learning).

That said, I've also seen a lot of Haskell engineers go through the interview pipeline & get thumbs up from all interviewers _except_ a single person in leadership who would later push to move away from Haskell for "hiring reasons" :eyeroll:

Re: Haskell in Production

#192

Post by runeks »

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.

Can you give an example or two?

Re: Haskell in Production

#193

Post by runeks »

KirinDave wrote: post #2

This is a great guide and sound advice. And hopefully in a year we'll see the community converge on Polysemy (or fused-effects for performance) to make this strategy even more natural.

Polysemy still appears mysterious to me.

I would absolutely love an article that translates the “Designing Testable Components”[1] part of this article into its Polysemy equivalent.

[1] http://felixmulder.com/writing/2019/10/05/Designing-testable...

Re: Haskell in Production

#194

Post by wellpast »

mbrodersen wrote: post #179
wellpast wrote: post #149

Earlier quoted context omitted.

This is not an opinion thing. If you’re saying that type checkers can reject code at no worse than the same rate as dynamic runtimes then you are just plain wrong. In any case the burden is on you to show this with the slightest sketch of a proof to how this is possible. And what is this magic type system that can do this, bc it sounds like some super AI. The reason I’m confident in my objections is because this is w…

> This is not an opinion thing. Of course it is an opinion thing. > never a concession as to its cons and costs. Pretty much what I get all the time from people who don't know how to use type systems productively, and then think that because they can't nobody else can. If types doesn't work for you, don't use them. They work for me so I use them.

I can use strong typing productively. I can use dynamic systems _way_ more productively.

When all things are equal, the impedance is not from lack of skill. It is staring at you straight in the face: it's a rules-based type prover that -- by definition -- significantly restricts the set of valid programs.

This is the definition of a type prover.

The argument should be that the value of this restriction outweighs the cost. But no one is yet making this claim. Which should make one wonder.

Re: Haskell in Production

#195

Post by wellpast »

mbrodersen wrote: post #180
wellpast wrote: post #149

Earlier quoted context omitted.

This is not an opinion thing. If you’re saying that type checkers can reject code at no worse than the same rate as dynamic runtimes then you are just plain wrong. In any case the burden is on you to show this with the slightest sketch of a proof to how this is possible. And what is this magic type system that can do this, bc it sounds like some super AI. The reason I’m confident in my objections is because this is w…

> the full power of dynamic languages? There is nothing you can do in a dynamic language you can't do in a typed language. There is no "special power" that only dynamic languages have. If you truly believe that dynamic languages have "special powers" that typed languages can't have then I recommend studying a bit of basic computer science. Starting with the Turing Machine or Lambda Calculus.

> There is nothing you can do in a dynamic language you can't do in a typed language.

There is nothing one can't do in assembly that you can't do it in a higher-level PL.

The argument is not what one can or can't do.

The argument is that one world (dynamism) allows for higher throughput than a static-checked environment. This can be discussed but the "can do" argument is of no interest.

You "can do" anything given enough time. One doesn't even need a programming language. You can manually execute instructions by hand. But this is not the discussion.

Re: Haskell in Production

#196

Post by wellpast »

mbrodersen wrote: post #182
wellpast wrote: post #150

Earlier quoted context omitted.

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?

I spent too many years programming in all kinds of dynamically typed and statically typed systems and I kept a clear head and didn't cling to a blind religious persuasion. I've also watched the performance of static type enthusiasts closely.

I thought that when I updated a type that all of my running around fixing type errors had to do with me missing something but alas that was not the case. This is how the static enthusiasts do their work, all the while claiming that they are being more productive. When I call a static typer our on this the answer is always the same: "But you'd have to go update those case statements/maybe matches/type signatures anyway!" Meanwhile I'm over in a dynamic system not having to do any of that. Refactors are minimal not cross-the-entire-codebase.

Static type systems are training wheels. When a static type enthusiast takes his training wheels off, the bike falls over and s/he screams "See! I told you. I'm more productive with types!" And then they put the training wheels back on and think that they have proven that static verification is superior. What they don't know is that there is enormous missed opportunity once you learn how to ride a bike w/o training wheels.

The truth is you can produce much faster without a rules-based static type prover between you and your runtime environment if you know what you're doing. This should be obvious b/c in one world you have a filter/prover that you must past to ship. In the other world you do not. If the filter/prover was worth its weight then you should be able to clearly see the win. But in business systems the kinds of bugs found by filter/provers are of the "null pointer" variety -- the fastest and simplest bugs to fix when they are found; having a heavyweight filter/prover save me from these simplest of bugs to fix is simply not worth it.

Re: Haskell in Production

#197

Post by runeks »

nightski wrote: post #24
non-entity wrote: post #20

Earlier quoted context omitted.

> The syntax is quite similar to the rest of the ML family, which dates back to 1973. How close is it to say something Like F# then? I've toyed with F# a bit and was able to pick it up pretty decently, but a lot of Haskell still looks foreign to me

If you know F# you are going to feel a lot more comfortable than coming from say C/C++/C#. The largest difference imo between F#/Ocaml and Haskell is the evaluation model where Haskell is lazy by default.

IMHO the largest difference is purity.

Not being able to mix IO and non-IO functions like this

    print “Enter name:”
    print (“Hello “ ++ readStdinLine ++ “!”)
in Haskell means you have to learn a new way of writing IO code.

Re: Haskell in Production

#198

Post by nightski »

runeks wrote: post #197
nightski wrote: post #24

Earlier quoted context omitted.

If you know F# you are going to feel a lot more comfortable than coming from say C/C++/C#. The largest difference imo between F#/Ocaml and Haskell is the evaluation model where Haskell is lazy by default.

IMHO the largest difference is purity. Not being able to mix IO and non-IO functions like this print “Enter name:” print (“Hello “ ++ readStdinLine ++ “!”) in Haskell means you have to learn a new way of writing IO code.

Not really. You can mix them in Haskell too. Think of F# as Haskell except you are always working in the IO monad. Haskell doesn't require a "new way of writing IO code" at all. It just allows you to separate out the IO from the pure in a way that can be enforced by the compiler. But there is nothing preventing you from writing all Haskell code in the IO monad if you were so inclined - which is essentially OCaml/F#.

Re: Haskell in Production

#199

Post by chrisseaton »

TheCoelacanth wrote: post #185
chrisseaton wrote: post #145

Earlier quoted context omitted.

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.

If you know you’re creating a List (it’s there on the LHS) why not write List.empty()?

Re: Haskell in Production

#200

Post by tome »

nightski wrote: post #198
runeks wrote: post #197

Earlier quoted context omitted.

IMHO the largest difference is purity. Not being able to mix IO and non-IO functions like this print “Enter name:” print (“Hello “ ++ readStdinLine ++ “!”) in Haskell means you have to learn a new way of writing IO code.

Not really. You can mix them in Haskell too. Think of F# as Haskell except you are always working in the IO monad. Haskell doesn't require a "new way of writing IO code" at all. It just allows you to separate out the IO from the pure in a way that can be enforced by the compiler. But there is nothing preventing you from writing all Haskell code in the IO monad if you were so inclined - which is essentially OCaml/F#.

> Not really. You can mix them in Haskell too.

True, but it's not particularly syntactically convenient.

Post reply on HN