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

121–130 of 242 posts

Re: Haskell in Production

#121

Post by sullyj3 »

microtherion wrote: post #85
whateveracct wrote: post #80

Earlier quoted context omitted.

What exactly is wrong with it? I've never even used the Scotty library or monad being used and I can understand it.

1. I have a vague idea what the second "do" is for. I don't have the slightest idea what the first "do" does. 2. I have some idea what "$" is, but I have no idea what it does in this context. 3. param "uri" is presumably extracting a parameter, presumably from the result of an incoming HTTP request. How is that request passed into "app"? How is it passed into the "get"? How is it passed to "param"? 4. Why does "parse…

> I don't have the slightest idea what the first "do" does.

We know from the type signature that it returns a `ScottyM ()`, whatever that means. We don't know what that entails without having looked at the documentation. I don't think it's fair to criticize it on this basis, though, it seems basically the same as when you see an unfamiliar function in some python code and have to look up what it does.

However when we look at the docs: http://hackage.haskell.org/package/scotty-0.11.5/docs/Web-Sc...

There's literally no documentation for this type. Imo this is emblematic of a pretty dysfunctional culture in haskell of not bothering to document things properly.

By ctrl-f-ing "ScottyM" and looking around the page we can see that it's returned by the `get` and `post` functions, and get a vague idea that it's the type used to progressively build up a scotty web application. Then we see that the `scotty` function takes a `ScottyM ()` and returns an IO () that we can run as the main function of our program.

It can definitely be figured out, but the docs sure don't help much.

> this is an incomprehensible control and data flow, wrapped in an ugly syntax.

Parts of it are pretty bad, but I don't think the control flow being quite implicit here is actually much of a problem. Scotty is based heavily on Sinatra, a minimal ruby framework, and it kind of reminds me of Flask as well. In all of these, it falls to the programmer to decide what to return on a given route, and the sending back of the data is all handled implicitly and invisibly by the framework. So, I don't see this as an issue, and, if it is one, it isn't Haskell specific.

Re: Haskell in Production

#122

Post by kccqzy »

whateveracct wrote: post #77
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…

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

Re: Haskell in Production

#123

Post by kccqzy »

dmitriid wrote: post #42

How long does it take the “new programmers who have not worked with Haskell before” to learn and understand all the ASCII-art in the example code? How $ differs from On top of trying to remember that is string concatenation and >>= and <- have something to do with monads.

The exact same time it takes a programmer who has never seen Java or its close siblings like C++ to learn and understand all the keywords like "public" or "static" or "class" or "interface" or "extends" and how they work.

The only difference is that a random programmer you pick has probably already spent the time understanding Java and OOP, but not Haskell.

Re: Haskell in Production

#124

Post by whateveracct »

sullyj3 wrote: post #121
microtherion wrote: post #85

Earlier quoted context omitted.

1. I have a vague idea what the second "do" is for. I don't have the slightest idea what the first "do" does. 2. I have some idea what "$" is, but I have no idea what it does in this context. 3. param "uri" is presumably extracting a parameter, presumably from the result of an incoming HTTP request. How is that request passed into "app"? How is it passed into the "get"? How is it passed to "param"? 4. Why does "parse…

> I don't have the slightest idea what the first "do" does. We know from the type signature that it returns a `ScottyM ()`, whatever that means. We don't know what that entails without having looked at the documentation. I don't think it's fair to criticize it on this basis, though, it seems basically the same as when you see an unfamiliar function in some python code and have to look up what it does. However when we…

We can quickly find out that ScottyM is a Functor/Applicative/Monad though. And in this code (and using this library in general), that's all we need to know! FAM is a universal interface.

Re: Haskell in Production

#125

Post by dmitriid »

thesz wrote: post #73
dmitriid wrote: post #42

How long does it take the “new programmers who have not worked with Haskell before” to learn and understand all the ASCII-art in the example code? How $ differs from On top of trying to remember that is string concatenation and >>= and <- have something to do with monads.

Two weeks, Just as much as for any other new language. After two weeks new member can introduce simple features. After a month - relatively complex ones. Full development speed is achieved after half a year and is roughly equal to all languages because all this time people learn problem(s) domain(s) and its (their) mapping to the code. For example, if I ask you to optimize Kaldi's HCLG-based decoder, you won't get an…

> Two weeks, Just as much as for any other new language.

What?!! :) I was introducing new features within a day after switching from Java to C#.

New features within less than a week when switching to Erlang (having had little FP experience).

etc. etc.

> For example, if I ask you to optimize Kaldi's HCLG-based decoder

Why would you ask me that? Is it such a common problem?

How about: if I ask you to implement a streaming Google Dataflow job getting data from a Google PubSub and writing data to BigQuery? It’s a much more common request.

Re: Haskell in Production

#126

Post by dmitriid »

lalaithion wrote: post #59
dmitriid wrote: post #57

Earlier quoted context omitted.

What would an error look like if I misused $ or &? And yes, compilers hold a user’s hand in most languages (including PHP with type hints :) ).

• Couldn't match expected type ‘([Integer] -> [Integer]) -> [b]’ with actual type ‘[Integer]’ • Possible cause: ‘map’ is applied to too many arguments In the second argument of ‘(&)’, namely ‘map (* 2) [1, 2, 3]’ In the second argument of ‘($)’, namely ‘map (+ 2) & map (* 2) [1, 2, 3]’ In the expression: map (+ 2) $ map (+ 2) & map (* 2) [1, 2, 3]

In my opinion this doesn’t help much.

Re: Haskell in Production

#127

Post by dang »

tempguy9999 wrote: post #45
MuffinFlavored wrote: post #41

Earlier quoted context omitted.

> Sounds like you've barely programmed in Haskell and don't know what you're talking about. You're right. I do not subject myself to Haskell because I can't fathom a world where JavaScript is less efficient than Haskell.

Then keep quiet. I agree completely with @foopdoopfoop.

You can't do this here. We've had to ask you several times to follow the site guidelines. Would you please review https://news.ycombinator.com/newsguidelines.html and take the spirit of this site more to heart? Note the most important one: "Be kind." That doesn't vary depending on how annoying or wrong other comments are.

Re: Haskell in Production

#128

Post by sullyj3 »

PeCaN wrote: post #74
olah_1 wrote: post #26

Earlier quoted context omitted.

>but what's wrong with the syntax? I'll just link to this blog about readable Haskell. If everyone followed his advise, it would be much better. http://www.haskellforall.com/2015/09/how-to-make-your-haskel...

Note that this is to make Haskell more readable to non-Haskell programmers (which is a bit of a weird goal IMO). It is not for readable Haskell in general. Advice like "not using $" just makes code less readable if you're familiar with Haskell and is quite frankly just bizarre. I do not think you'll find many programmers, Haskell or otherwise, who find lots of nested parenthesis to be the paragon of readability.¹ If…

> Honestly this sentiment from the Haskell community that Haskell is somehow bizarre and impenetrable to outsiders and needs to be somehow watered down so that normal people can understand it just feels extremely elitist and if anything only scares people away from Haskell.

What? The thread we're in is descended from a post about how terrible the syntax is!

Re: Haskell in Production

#129

Post by sullyj3 »

brokencode wrote: post #21
epsolos wrote: post #17

Earlier quoted context omitted.

Most people that have worked as developers/programmers/etc. that don't have a lot of exposure to or training in fp find it painfully hard to learn. This could be one of those cases.

To them, I would suggest that they remember back to when they learned their first imperative language like Java or C. For me, that was really difficult to wrap my mind around at the time, but now those languages are second nature to me. I kind of suspect that if everyone were exposed to a functional language first, there would be a lot fewer people who think they are extremely hard to learn.

There are many reasons Haskell is difficult to learn, and the functional programming aspects are only part of it. I'd venture a guess that it's vastly easier to go from say, python to clojure, than from python to haskell. Even neglecting clojure's impure escape hatches.

Re: Haskell in Production

#130

Post by hderms »

wellpast wrote: post #117
rawburt wrote: post #108

Earlier quoted context omitted.

This is opinion. Haskellers have opinions too. Whatever you like and whatever gets the job done: bravo

Nope. Not everything is "every way is just as good as the other". >Whatever you like and whatever gets the job done: bravo "The job" is this: it's an optimization problem of maximizing development throughput. That's the job in the business world, at least. There can and should be a conversation about doing this job well. Mandating strong static typing across the board is exactly what Haskell does. My claim is this is…

I believe you're exaggerating the frequency that the compiler rejects valid programs. It happens, but no more frequently than random runtime type errors occur in dynamic code.

In any case, one can just as easily argue that the value of static types come not just when the code is first written, but under the legion of modifications that need to occur. Not to mention how self documenting it is which also aids modification.

Some people just don't like static typing, which is fine, but making the statement that it's categorically worse is hard to defend.

Post reply on HN