Haskell in Production

Post by mbrodersen » Fri, Oct 18, 2019, 1:41 PM UTC

empath75 wrote: post #92

PeCaN wrote: post #74

Earlier quoted context omitted.

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 They’re not inventing that from thin air. I can understand Haskell with a great deal of effort, but it certainly requires a great deal of effort. My wife is a non-programmer. She knows nothing about code. I could explain what the go code I write does in a few minutes and she could follow it with a minimu…

Post by brianberns » Fri, Oct 18, 2019, 1:45 PM UTC

axilmar wrote: post #140

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…

I don't see the above better than print(even(4*2))

Post by mbrodersen » Fri, Oct 18, 2019, 1:49 PM UTC

wellpast wrote: post #152

verttii wrote: post #143

Earlier quoted context omitted.

> SO MUCH worse cost/benefit than unit testing My experience is exactly the opposite. Using the type system is less effort, guides your development more and, in a way, provides more consistent guarantees than spending time on a wide unit test coverage. Obviously, these things are not totally mutually exclusive though.

If you are truly doing an apples to apples comparison here, I suspect you’re using a struct subset of your dynamic language. Otherwise I can’t see how the addition of a rule-based static-check pass filter gets you faster. What are the two static & dynamic languages you’re comparing by the way?

Post by mbrodersen » Fri, Oct 18, 2019, 1:52 PM UTC

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…

Post by mbrodersen » Fri, Oct 18, 2019, 1:59 PM UTC

wellpast wrote: post #149

hderms wrote: post #130

Earlier quoted context omitted.

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

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…