Live data from Hacker News

Haskell is our first choice for building production software systems

foxhound.systems

221–230 of 297 posts

Re: Haskell is our first choice for building production software systems

#221

Okay, so this is admittedly snarky but we've seen this sort of blog post so much that it has practically become an Onion article: Why Haskell Is Our Secret Weapon, by Startup You've Never Heard Of. And then when someone points out that nobody knows who they are or what they've built, we get commenters talking about how company X, Y, and Z are also using Haskell. And those claims also come up short...most of them can'…

I'm not really a haskell fan, but the lion's share of that effect more that likely comes from the small sample size of companies using haskell. Even if it were somehow superior, there just are enough people trying it to be coming up with a unicorn startup or two.

Now, the lack of skilled haskell programmers on the other hand, that's a pretty scary proposition if you're starting a company and may find yourself riding on a rocket, needing as many able hands as you can possibly find.

Re: Haskell is our first choice for building production software systems

#222

Earlier quoted context omitted.

They don't, but, at least in object-oriented languages, much of overall experience is easy enough to replicate with formal interfaces and coding standards.

I thought the nice thing about Modula-2 was that you could browse through interface files to understand some code and then go into implementations.

It's true, but there are so many ways to skin that cat. Smalltalk, for example, gives an even more fluid way to browse at a high level and then drill in, and it doesn't (necessarily) have source code files in the first place.

Re: Haskell is our first choice for building production software systems

#223
post #122
post #55

Earlier quoted context omitted.

Would you say that you've engaged in good faith with the point the author was trying to make?

I've found article arguments incorrect - what they describe as Haskell's features and more are easily available in other languages as well. Strictly enforcing function style on the other hand looks to me as un-feature. From my long experience strictly enforcing any particular paradigm/style in programming is amounts to plugging round holes with the square pegs.

I'm a partisan, of course, but I always found ocaml to be the practical choice for ML-style functional languages. All the functional type-y goodness without being shackled to it, you can let yourself off the hook if you need to, you can just write a dang loop if that's what needs doing, compiles down to native, just a good practical mix.

Other than Jane Street, nobody much uses it though, so that's that.

Re: Haskell is our first choice for building production software systems

#224
I simply don't get the hate this article is getting, are some HN readers really that bad at reading comprehension? The authors clearly mention it is "our first choice" and then they go on to present their findings with great clarity. Nowhere do they evangelize Haskell like other language like Rust for example. I never see such comments on threads on other languages, even though some of articles posted are of subpar quality.

In the end the insecurities and failures of snarky commentators don't matter to others who are in the arena solving real problems in production with an unsexy language.

Re: Haskell is our first choice for building production software systems

#225
post #61

Has anyone had a look or knows of production systems made with a Haskell-like language named Curry? ( https://curry-lang.org/ ) Sounds a lot like Haskell with Prolog... “ Curry is a declarative multi-paradigm programming language which combines in a seamless way features from functional programming (nested expressions, higher-order functions, strong typing, lazy evaluation) and logic programming (non-determinism, bui…

You can already have Prolog embedded in Haskell, using LogicT.

Here is the paper by Kiselyov: http://okmij.org/ftp/papers/LogicT.pdf

Re: Haskell is our first choice for building production software systems

#226

Haskell does not actually get rid of side effects in practice. I find that tons of Haskell code involves do notation which is basically code that embraces monadic side effects which sort of defeats the purpose that this article says of pushing side effects to the edge. Really in order to “push side effect to the edge” people need to avoid using monadic composition as much as possible which I see Haskell programmers r…

Monadic composition is used everywhere from simple failure (Maybe or Either) through to genuine side effects such as IO. The presence of monads does not necessarily mean side effects.

Haskell never claimed to "get rid of side effects", the idea is make them explicit in the types and to be able to reason about them.

Re: Haskell is our first choice for building production software systems

#227

Haskell does not actually get rid of side effects in practice. I find that tons of Haskell code involves do notation which is basically code that embraces monadic side effects which sort of defeats the purpose that this article says of pushing side effects to the edge. Really in order to “push side effect to the edge” people need to avoid using monadic composition as much as possible which I see Haskell programmers r…

Monadic composition is used everywhere from simple failure (Maybe or Either) through to genuine side effects such as IO. The presence of monads does not necessarily mean side effects. Haskell never claimed to "get rid of side effects", the idea is make them explicit in the types and to be able to reason about them.

Right, but the article says that Haskell pushes these side effects to the edge. I am not saying haskell claims this, I'm saying the article claims this. Haskell actually doesn't do this in practice as tons of people use do notation and state monads. The more people use do notation, the more they are embracing side effects. Literally I've seen haskell code where all function definitions had some form of do notation which is basically against the claim made by this article.

To push side effects to the edge you have to only use do notation and monads when you absolutely have no choice, which is not done in practice with haskell.

>The presence of monads does not necessarily mean side effects

The presence of a functor does not mean side effects. The presence of a monad implies composition and binding which does imply a side effect. Even maybe monads composed have side effects that can produce output that the function itself can never produce on it's own.

For example let's say I have a maybe monad that will never produce "Nothing."

   b :: int -> Maybe Int
   b x = Just x
but I can produce a side effect by binding it with Nothing.

  Nothing >>= b
The above yields "Nothing," even though it is not part of the definition of b. It is a contextual side effect passed on through monadic composition. Normal composition outside of monadic composition usually does not have this property.

Re: Haskell is our first choice for building production software systems

#228

> Many programmers encounter statically typed languages like Java or C++ and find that the compiler feels like an annoyance. By contrast, Haskell’s static type system, in conjunction with compile-type time checking, acts as an invaluable pair-programming buddy that gives instantaneous feedback during development. the reason they "find that the compiler feels like an annoyance" is because their first exposure to Java…

I run into the same thing with Java.

Code that always upsets me is something like `Map` where a concrete type would work so much better (and faster).

Using a statically typed language, the most important thing you can do is USE IT. Let the type system save you from problems. Encode whatever you can in the types.

Bypassing it by casting always causes headaches.

Re: Haskell is our first choice for building production software systems

#229
post #99
post #69

Earlier quoted context omitted.

In contrast, Rust's compiler sometimes gives suggestions for changes which can often just be copied.

That's not entirely true. It gives suggestions in the cases where the C++ compiler does too. There are more than a few very cryptic errors you can encounter with Rust. I like it though, just needs more work.

It's been a while since I used C++ but I have never seen suggestions of the same quality that the rust compiler produces. Do you have a link that shows the error messages you're talking about?

For sure though, not every error has a great message and some can be cryptic. But those cases are relatively rare these days IMO

Re: Haskell is our first choice for building production software systems

#230

Haskell does not actually get rid of side effects in practice. I find that tons of Haskell code involves do notation which is basically code that embraces monadic side effects which sort of defeats the purpose that this article says of pushing side effects to the edge. Really in order to “push side effect to the edge” people need to avoid using monadic composition as much as possible which I see Haskell programmers r…

Monadic composition is used everywhere from simple failure (Maybe or Either) through to genuine side effects such as IO. The presence of monads does not necessarily mean side effects. Haskell never claimed to "get rid of side effects", the idea is make them explicit in the types and to be able to reason about them.

Well, I don’t know why but this submission has attracted particularly misinformed, blatant wrong or hyper emotive responses. Maybe Haskell killed people’s pets or something.
Post reply on HN