Haskell in Production • Hacker News Board

Re: Haskell in Production

#71

Post by thesz » Thu, Oct 17, 2019, 9:52 PM UTC

ratww wrote: post #31

rifung wrote: post #13

Earlier quoted context omitted.

> It is extremely hard to learn, has an extremely confusing + needlessly complicated syntax and I agree with your other points but what's wrong with the syntax? I actually really like the syntax for the most part

I've been using Haskell on and off for almost ten years, and the "front end" of the language, including its syntax, is pretty much the only thing that I absolutely hate about it. The endless operators, all the language extensions required in 2019, the madness called Template Haskell, the absurdity of point free style, the multiple ways of achieving things by cleverly using . and $, the uncanny valley of do-notation (…

If you can have better solution to the problem at hand with the library, you will solve it faster. Turnaround time for library is much less than for a compiler.

So if language provides a way to solve something with a library instead of compiler, it provides a way for faster path to solution.

Re: Haskell in Production

#72

Post by microtherion » Thu, Oct 17, 2019, 10:02 PM UTC

brokencode wrote: post #15

MuffinFlavored wrote: post #9

> Haskell is great for business and great in production. Hot take: no it isn't. It is extremely hard to learn, has an extremely confusing + needlessly complicated syntax and I question the payoff immensely. I question the well-being of anybody who subjects themselves to the pain and torture that is Haskell. If I stood up in a corporate business boardroom meeting for tech analysis on a new project and said "I want to…

Are you speaking from experience? The article is about the author’s experience from a year of using Haskell. I don’t think it’s fair or constructive to disagree with his findings unless you also have experience using the language, and it doesn’t sound like that is the case.

So if somebody asserted that INTERCAL-72 is the proper language to use for production code, you would consider it unfair to contradict them until you've used INTERCAL in production code yourself?

Personally, I would not necessarily disbelieve somewhat propagating Haskell as a production ready language. However, I'm fairly confident that it would be thoroughly unsuited to any areas of work I regularly operate in.

I have tried a number of times to learn Haskell (from a variety of tutorials and text books). I find myself nodding along sympathetically at the fundamentals (functional purity, non-strict evaluation). I can follow the initial chapters. And somewhere between "Functor" and "Applicative", I tend to lose the plot.

Then I look at supposedly real world code like the URL shortener in Allen/Moronuki's "Haskell Programming from First Principles", and I just can't make heads or tails of it: https://github.com/bitemyapp/shawty-prime/blob/master/app/Ma...

   app :: R.Connection
       -> ScottyM ()
   app rConn = do
     get "/" $ do
       uri  do
           shawty  text (shortyAintUri uri)

If that's supposed to be the way to write production code in the future, count me out!

Re: Haskell in Production

#73

Post by thesz » Thu, Oct 17, 2019, 10:03 PM UTC

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 any interesting results even after two months EVEN if you known C++ well. Just to tip you with something: you can save off about 10% of execution time just by presorting HCLG graph by BFS - it is scale-free and there are nodes which decoder will visit more often than others. To do this, you have to look at the graph, you have to know about scale-free graphs and their properties. Which are way outside of programming language scope.

Re: Haskell in Production

#74

Post by PeCaN » Thu, Oct 17, 2019, 10:12 PM UTC

olah_1 wrote: post #26

rifung wrote: post #13

Earlier quoted context omitted.

> It is extremely hard to learn, has an extremely confusing + needlessly complicated syntax and I agree with your other points but what's wrong with the syntax? I actually really like the syntax for the most part

>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 the goal is to show snippets of cool Haskell code to other people this article is… fine I guess? But I don't think it's good for much more. Not even for teaching Haskell, since people should probably learn the language as it is used instead of some arbitrary "more readable to non-Haskell programmers" version. Using do-notation is probably even counterproductive for teaching since it obscures what's actually going on.

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.

―

¹ Lisp programmers aside, but even then in Lisp you're basically just drawing a tree and so the parenthesis kind of fade away, but in languages with infix syntax and operator precedence you can't ignore them.

Re: Haskell in Production

#75

Post by marcosdumay » Thu, Oct 17, 2019, 10:13 PM UTC

shantly wrote: post #54

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.

I still can't understand why Perl is easily dismissed as "LOL line noise" but Haskell's apparently fine. At least dipping into Perl you can take on the line noise slowly so you have time to absorb each new technique, and you can write it just fine with hardly any of that if you want, and it won't hurt a thing—Haskell seems to dump all that on you up front, and it seems to require it, idiomatically. It's very off-putt…

Well, I had no idea what (&), but you just place the cursor on it in emacs and it will say `(&) :: a -> (a -> b) -> b` that, after you learn this language is enough to understand that `v & f` runs the function `f` with the parameter `v`.

If I was trying to discover what function does that, I'd type the `a -> (a -> b) -> b` (yes, it's that obvious) string on Hoogle, and it would show me the operator.

I have never got that experience with Perl. Every new symbol requires a query into perldoc in a new window, every time you don't know what symbol to use, you keep not knowing, because it's impossible to discover.

Besides, Haskell has a consistent value + operator + value structure, while Perl has a mess.

Re: Haskell in Production

#76

Post by herbstein » Thu, Oct 17, 2019, 10:22 PM UTC

brianberns wrote: post #29

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

Thanks. That's a good blog. The $ operator is definitely confusing in Haskell. F# uses print This means: Take the result of 4 * 2 and send it to `even`, then take that result and send it to `print`. Or you can write it with forward pipes to make it even clearer: 4 * 2 |> even |> print The thing about backward pipes is that they're often used to avoid parentheses, which is IMHO a good idea. It's just that thinking of…

> Does (g ∘ f)(x) mean g(f(x)) or f(g(x))?

The function composition operator can be vocalized as, in this case, "g after f". That is, apply the f and then g. Translating '∘' into 'after' is the easiest way to understand it.

Re: Haskell in Production

#77

Post by whateveracct » Thu, Oct 17, 2019, 10:23 PM UTC

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 anyways. Worst-case, using Haskell could end up being a wash vs other languages.

Rewrites aren't always indicative of failures of language or the engineers writing it. They're also a useful mechanism for solidifying control for a VPE-type at a nascent but quickly-growing startup. Especially if said VPE-type wants to push out personnel that were there before them.

Re: Haskell in Production

#78

Post by whateveracct » Thu, Oct 17, 2019, 10:29 PM UTC

MuffinFlavored wrote: post #9

> Haskell is great for business and great in production. Hot take: no it isn't. It is extremely hard to learn, has an extremely confusing + needlessly complicated syntax and I question the payoff immensely. I question the well-being of anybody who subjects themselves to the pain and torture that is Haskell. If I stood up in a corporate business boardroom meeting for tech analysis on a new project and said "I want to…

> It is extremely hard to learn

I picked up Haskell while still getting my degree on my own. My only training was in C. Payoff was huge within a couple months of starting (didn't even finish LYAH), especially when writing concurrent programs.

> I question the well-being of anybody who subjects themselves to the pain and torture that is Haskell.

Haskell is so effortless once you get over the learning curve though. I've used less effort & focus programming professionally in Haskell than I ever did in other languages. The types & way programs are structured make so many tasks 100% mechanical, with your only thought being where to direct the mechanics.

> If I stood up in a corporate business boardroom meeting for tech analysis on a new project and said "I want to write it in Haskell", I'd get laughed + kicked out.

Don't care about those people's opinions in the first place. Never will :) Should be viable for me to write professional software for years to come in Haskell.

Re: Haskell in Production

#79

Post by microtherion » Thu, Oct 17, 2019, 10:33 PM UTC

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

Re: Haskell in Production

#80

Post by whateveracct » Thu, Oct 17, 2019, 10:34 PM UTC

microtherion wrote: post #72

brokencode wrote: post #15

Earlier quoted context omitted.

Are you speaking from experience? The article is about the author’s experience from a year of using Haskell. I don’t think it’s fair or constructive to disagree with his findings unless you also have experience using the language, and it doesn’t sound like that is the case.

So if somebody asserted that INTERCAL-72 is the proper language to use for production code, you would consider it unfair to contradict them until you've used INTERCAL in production code yourself? Personally, I would not necessarily disbelieve somewhat propagating Haskell as a production ready language. However, I'm fairly confident that it would be thoroughly unsuited to any areas of work I regularly operate in. I ha…

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