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

221–230 of 242 posts

Re: Haskell in Production

#221

Post by tome »

microtherion wrote: post #205
mbrodersen wrote: post #153

Earlier quoted context omitted.

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

Let's compare how Wikipedia starts the definition of a "monad": "a monad [...] is an endofunctor (a functor mapping a category to itself), together with two natural transformations required to fulfill certain coherence conditions." vs. "encapsulation": "Encapsulation [...] is the bundling of data with the methods that operate on that data, or the restricting of direct access to some of an object's components." Are yo…

You looked up the wrong definition.

"In functional programming, a monad is a design pattern[1] that allows structuring programs generically while automating away boilerplate code needed by the program logic."

Re: Haskell in Production

#222

Post by tome »

nightski wrote: post #201
tome wrote: post #200

Earlier quoted context omitted.

> Not really. You can mix them in Haskell too. True, but it's not particularly syntactically convenient.

The entire point of monadic (do) syntax in Haskell is to make this convenient. I'm not following you exactly.

runeks mentioned

    print “Enter name:”
    print (“Hello “ ++ readStdinLine ++ “!”)
which can't be written like that with do notation. It's also pretty confusing code to write in any language, so maybe that's not a problem.

Re: Haskell in Production

#223

Post by tome »

wellpast wrote: post #207
tome wrote: post #187

Earlier quoted context omitted.

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…

> 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! Okay, so let's do the inverse then. I've got a pattern matched case that the type prover proves will never occur…

It's really interesting because I hear these kinds of claims a lot from Clojure programmers. How did they arise in the community? I find it hard to believe that so many Clojure programmers have actually tried Haskell and come to exactly the same conclusion.

Does Rich Hickey repeat these points somewhere? If so could you point me to where? I'd love to see them. I'm a big fan of Are We There Yet, Simple Made Easy etc. and find Haskell a great implementation of them.

> I have to add it to the type union. But it should be obvious at this point that the moves I am making are not driven by the outcome I want but by the rules of the type checker.

That's not how I see it at all. I wish I could understand why you do see it that way!

> But I don't want an error. I can prove that the absence of the field is OK/not-an-error.

You misunderstand. If you know that a field of a data type is going to be unused you can fill it in with an `error` call that you know will never be hit. You can even omit the field entirely! That's considered bad form but if you like it then knock yourself out.

    data Foo = Foo { bar  :: Int
                   , baz  :: String
                   , quux :: Bool
                   }
    
    doSomething :: Foo -> IO ()
    doSomething foo = do
      print (bar foo)
      print (baz foo)
    
    example1 = Foo { bar  = 42
                   , baz  = "Hello"
                   , quux = error "quux will never be inspected"
                   }
    
    -- > doSomething example1
    -- 42
    -- "Hello"
    
    example2 = Foo { bar  = 42
                   , baz  = "Hello"
                   }
    
    -- > doSomething example2
    -- 42
    -- "Hello"
> my value --(flows at runtime through)--> [some framework, say a web framework code to a, say, a Label that has no idea about my value's type domain] --(flows through pixels to)--> user's eyes

What's wrong with a polymorphic parameter?

Re: Haskell in Production

#224

Post by tome »

wellpast wrote: post #196
mbrodersen wrote: post #182

Earlier quoted context omitted.

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

If you have a place where you emit sum types, and you increase the set of possible cases you can emit then you do have to cross-the-entire-codebase to update all consumers of that sum type to handle the new case.

If you have a place where you consume product types, and you increase the set of fields that you inspect on that sum type, then you do have to cross-the-entire-codebase to update all producers of that product type to emit the new field.

I don't see how it could be any different. How would you handle this in Clojure?

Re: Haskell in Production

#225

Post by dllthomas »

StreamBright wrote: post #202
dllthomas wrote: post #190

Earlier quoted context omitted.

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.

True. Lets check the numbers. 90,000 developers took the survey. Java: 41.1% 36990 developers JavaScript: 67.8% 61020 developers Haskell: 0% 0 developers Jobs: Java: 73,447 jobs JavaScript: 59,647 jobs Haskell: 492 jobs https://www.indeed.com Given the numbers, as a hiring manager, I will never ever suggest to any company to try to use Haskell or hire Haskell devs. I know many developers who use it though. They suces…

Those are numbers. I'm not sure what they say, ultimately. If we believe them, then we can conclude: there are substantially more Java programmers, but substantially more unfilled Java positions, but a much bigger (... infinite) ratio of Haskell job to Haskell programmer, etc, etc. I'm not sure which of those wind up being most important.

I can say what I've said - that my experience of trying to hire the next couple Haskell programmers has not been harder than my experience of trying to hire the next couple JavaScript programmers.

There's also a big question of the quality of the survey, and how representative it's likely to be of your company's overall hiring pool - you say you have many Haskell programmers in your network, and your network is probably substantially fewer than 90k individuals, so something seems amiss.

I'm not interested in getting drawn into the rest of your ranting.

Re: Haskell in Production

#226

Post by smitty1e »

kccqzy wrote: post #122
whateveracct wrote: post #77

Earlier quoted context omitted.

My experience is upper management will scapegoat Haskell the moment they get the chance. Outside-hired leaders who doubt it from the start. It's a weird unpopular language - an easy target. If you just get over it & use Haskell, things will be fine. You'll get huge gains thanks to a lot of Haskell features & libraries, and you might have to write some more fundamental libraries yourself. Haskell makes that pleasant a…

I totally agree. When a project using Java fails, people would never think to blame the choice of Java as a contributing factor. When a project using Haskell fails, people will consider Haskell to be contributing to its failure even if the root cause lies elsewhere (bad management, bad culture, etc).

Maybe not Java proper, but I've heard copious abuse heaped upon Hibernate.

Now, we shouldn't blame the tool, but the performance was bad, and the induced race conditions were a dagger to the heart for the project.

Re: Haskell in Production

#227

Post by jonny383 »

mbrodersen wrote: post #163
jonny383 wrote: post #110

Advice for people using Haskell in "production": Don't. Save not only yourself the disappoint, but every other stakeholder around you. Use something tried and tested.

Let me guess: you have never programmed in Haskell?

I have programmed in Haskell. I have programmed in assembly. I have programmed in just about every language in-between. Haskell is at best, a sophisticated toy suited to a small subdomain of problems.

Have you ever tried to roll Haskell into production, when compared with something like C# or Java?

Re: Haskell in Production

#228

Post by TheCoelacanth »

chrisseaton wrote: post #199
TheCoelacanth wrote: post #185

Earlier quoted context omitted.

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

You know in this specific example, but not always. You could also do it in generic method where the collection type is parameterized.

Re: Haskell in Production

#229

Post by nightski »

tome wrote: post #222
nightski wrote: post #201

Earlier quoted context omitted.

The entire point of monadic (do) syntax in Haskell is to make this convenient. I'm not following you exactly.

runeks mentioned print “Enter name:” print (“Hello “ ++ readStdinLine ++ “!”) which can't be written like that with do notation. It's also pretty confusing code to write in any language, so maybe that's not a problem.

True, do notation does require you to add a line -

  main = do
      print "Enter name:"
      name
But I only said that it makes this convenient not that it allowed you to write any statement you want. It still makes it easy to intersperse pure and non-pure code.

Re: Haskell in Production

#230

Post by g_delgado14 »

mbrodersen wrote: post #159
wolco wrote: post #89

Earlier quoted context omitted.

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.

For what business units? For which use cases?

Also, they invest a lot into recruiting. My suspicion is that they give a considerable degree of freedom (often to the detriment of the organization in ways such as information silos) to engineering teams to help with recruiting.

Post reply on HN