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

111–120 of 242 posts

Re: Haskell in Production

#111

Post by Mathnerd314 »

jeremyjh wrote: post #93
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…

The capability pattern that Data Has implements is definitely used in other projects[1], and notably is endorsed by RIO[2]. [1] https://github.com/input-output-hk/cardano-sl [2] https://github.com/commercialhaskell/rio#monads Elaboration: https://www.parsonsmatt.org/2018/03/22/three_layer_haskell_c...

The GitHub issue I linked is basically "switch from data-has to RIO"; the issues with data-has come from its use of multi-parameter type classes. RIO avoids the issues by using single-parameter classes. AFAICT multi-parameter type classes are the subject of numerous GHC bugs/misfeatures and are best avoided in production.

Re: Haskell in Production

#112

Post by sullyj3 »

ppseafield wrote: post #97
pyrale wrote: post #82

Earlier quoted context omitted.

What kind of error would you like to see here instead ?

Maybe just one extra line like this? Prelude> print 2 + 3 :3:1: error: • No instance for (Num (IO ())) arising from a use of ‘+’ • The expression `print 2` :: IO () • In the expression: print 2 + 3 In an equation for ‘it’: it = print 2 + 3 Just adding the one line telling telling you what was `IO ()` is helpful. ghci obviously knows what it was here.

This suggestion is a straightforward, easy to implement improvement. Many compilers have serious UX problems because their authors don't take UX seriously. Elm and Rust are two languages getting this right.

Re: Haskell in Production

#113

Post by sullyj3 »

wolco wrote: post #94
madhadron wrote: post #48

Earlier quoted context omitted.

> I can't fathom a world where JavaScript is less efficient than Haskell. You can't fathom a world where a compiler can more easily produce efficient machine code from a statically typed language with very few semantic corners than from a dynamically typed language with lots of sharp corners plus reflection? I think you may need to meditate on the task of compilation a for a bit. Unless you mean efficient for the pro…

Efficient use of time I think the parent poster was referring to. You could have the project finished quickier in Javascript. Would you disagree? Does choosing haskell increase development time (ignoring major rewrites)?

I'd say it depends heavily on what you're writing. If it involves graphics, Javascript is going to be substantially less annoying, at least initially. However, the version you write in Haskell will be much more reliable, and much easier to progressively refactor and scale up, whereas in JS, the weird edge cases and lack of static guarantees will gradually pile up and make the project a chore to maintain.

For something non graphics related that you're building by yourself, if you already know Haskell, it's a no brainer, due to the high expressivity ceiling. Once a team is involved, the right choice (as always) basically just depends on what people already know.

Re: Haskell in Production

#114

Post by phlakaton »

herbstein wrote: post #76
brianberns wrote: post #29

Earlier quoted context omitted.

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.

Haskell provides the (g . f) notation as the standard, and also has (f >>> g) notation buried in one of its more advanced libraries if anyone finds the right-to-left reading too disorienting.

Re: Haskell in Production

#115

Post by c3534l »

Everyone in the comments either doesn't like Haskell, because it's hard and different or niche or whatever, so they think Haskell is bad for production even though they don't code in it and haven't worked at a place that used it extensively.

The other group of people in the comments are people who love Haskell and are happy to have validation from the OP.

But I'm not really any wiser. I like Haskell, but I work in DevOps and the language simply isn't relevant there.

Re: Haskell in Production

#116

Post by phlakaton »

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…

I'd quibble with this, but that's probably largely because I used Hudak's "Haskell School of Expression" book as my road into Haskell, which seems to generally aim for readability at the expense of making everything into a monad. I gather it would be considered a bit of an outdated style now, but in retrospect I think it eased me into the pool.

Re: Haskell in Production

#117

Post by wellpast »

rawburt wrote: post #108
wellpast wrote: post #104

Earlier quoted context omitted.

> Just because an expressive static type system is available, doesn't mean you have to use all of its expressive power. There's nothing stopping you from writing your system using little more than String, Int, lists, IO etc. Of course, you probably have a higher chance of bugs, but that might be the right tradeoff for your usecase. This is not accurate or prove me wrong. Opting out of Haskell's type system may be "do…

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 death to productivity/throughput when you compare it to alternatives. The death part can be argued --the best leg Haskellers can stand on afaict is that overall throughput is increased due to decreased attention to the kinds of bugs prevented by strong typing. This needs to be proven by them.

Otherwise -- by definition -- strong type systems are asking you to take special care to meet a type proof that is not necessary to do to implement correctness in other PLs.

Every time I've implemented a solution in a strongly typed system I always run into the type prover complaining about something that Might be but that I can prove is not the case. Here is the limit of the type checker - it is simply not aware enough to understand what we're doing. So it puts needless requirements left & right. This is hostile to productivity.

Now you go.

Re: Haskell in Production

#118

Post by platinumrad »

c3534l wrote: post #115

Everyone in the comments either doesn't like Haskell, because it's hard and different or niche or whatever, so they think Haskell is bad for production even though they don't code in it and haven't worked at a place that used it extensively. The other group of people in the comments are people who love Haskell and are happy to have validation from the OP. But I'm not really any wiser. I like Haskell, but I work in De…

Everyone... except for the top comment?

Re: Haskell in Production

#119

Post by sullyj3 »

non-entity wrote: post #20
madhadron wrote: post #16

Earlier quoted context omitted.

> Hot take: no it isn't. Odd. I did some Haskell in prodution (hardware control and Unix daemons) and it was delightful. > It is extremely hard to learn, has an extremely confusing + needlessly complicated syntax and I question the payoff immensely. It is unfamiliar if you have only worked in the C family of languages. The syntax is quite similar to the rest of the ML family, which dates back to 1973. It's basically…

> 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

The surface similarities between haskell and F# are fairly clear - emphasis on pure functions, no parens and commas for function calls, etc.

Alexis King wrote an interesting comment on one reason haskell can be difficult to pick up, which might be one cause of the foreignness you've noticed: https://www.reddit.com/r/haskell/comments/ddsvbk/you_are_alr...

Re: Haskell in Production

#120

Post by james-mcelwain »

chrisseaton wrote: post #88
slaymaker1907 wrote: post #6

I really wish Java had associated types and static methods as parts of interfaces (i.e. constructors as part of the interface). Those two features make complex architectures much easier to design and use.

Interfaces can have static methods.

I believe they mean static methods as part of the interface signature, e.g. to define constructor/factory methods.

AFAIK there are issues with how Java handles dynamic dispatch that prevent this.

Post reply on HN