Live data from Hacker News

Haskell is our first choice for building production software systems

foxhound.systems

151–160 of 297 posts

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

#151

Earlier quoted context omitted.

Thanks for sharing, but honestly, what does your comment add to a discussion of the post, which is about what works for them? You're making a rude comment that assumes they don't already know these things. Have you considered the possibility that the tiny slice of the world you've experienced is just that?

Because what works for one company may not work for another. It's useful to point to any potential cons of a particular approach. I didn't find the comment rude.

Their point is valid, though the comment reads condescending to me. Maybe it reads condescending to me because I don't agree with it, but I believe it could have been phrased in a less adversarial way:

«Haskell does not scale to organizations of 100+ engineers. There is a trade-off between writing and reading code, which Haskell does not fare well in. Also, given the realities of the dev hiring market, steep learning curves would be very detrimental to the success of the company»

What would have been your reaction if I had replied "look up the word condescension in the dictionary" to you? It would lead to bad discussion, regardless of whether my point about condescension was right or not.

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

#152

No, sorry, it has very little to do with technology. There's at least a dozen languages you could have chosen, and that others have chosen for any given use case. within some bounds, it makes very little difference.[0] The reason you've chosen Haskell and, by the way, also the TLD ".system", is that you've constructed your identity in such a way that "advanced language with a steep learning curve" is something that f…

Why don't you argue against the points made in favor of Haskell in the article? You can probably tell more about why they use Haskell that way. It's certainly a better indication than your ridiculous TLD divination.

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

#153

Earlier quoted context omitted.

That doesn't stop you having to type e.g. String foo = "bar"; String baz = foo; The `String`s can be completely avoided in languages with type inference because it's obvious that a string literal is a string.

And it's my experience that that is only a benefit to the person who wrote the code, and only for a short time. Generally, I prefer being able to read a line of code and understanding exactly what it does. If I need an IDE and have to repeatedly try to find the definition of something then, in my opinion, that's wasting my time. C++'s 'auto' is really useful but it's over-used IMO. I think that there's a belief that…

Code that specifies types instead of using auto is, barring compiler bugs, usually less correct. The compiler knows better than you what the type really is.

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

#154
I'm at a technology research company that is primarily using C++ as the main company tool. The development team is small, and the code is the result of 22 years of constant revision by PhDs. One of our Never To Be Violated Rules, simply because the number of hidden landmines is far to numerous, is template programming. When generic programming is required we use a web language like PHP where the type of something is contextual and one can be free and loose and sloppy if they want. Between the two extremes of our formal as fuck C++ base and the anything goes generic web languages we maintain surprisingly high levels of productivity, with very low bug counts. Having a tiny team helps, as we all know the code based inside out.

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

#155
This company looks to be a team of three (probably very smart) engineers who build cool custom software for likely relatively small clients. The software is likely only supported and modified by them. In that scenario something like Haskell makes sense - however once you need to scale your engineering footprint beyond 5-10 people it becomes virtually impossible to rationalize using a niche language like Haskell.

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

#156

Earlier quoted context omitted.

I've joined several companies, and getting into a Python code base was the most difficult one, because of the lack of typed method parameters. It was easier with Java and better still with Scala - same for Typescript vs. Javascript. I would be interested, is your Python experience green field or joining a large project? (just wanting to know, not implying anything on your part).

there are controlled studies supporting this idea the function parameters not having types slows down productivity

It would be helpful if you linked them ...

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

#157
post #79

Earlier quoted context omitted.

There's also the culture around the language to fold in. A culture of writing code assuming inference and structural typing is quite different than it merely being available.

So, OCaml or something? Or has Haskell added structural typing?

Haskell is structurally typed...

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

#158
post #69
post #26

Earlier quoted context omitted.

Annoyance about C++ errors isn't only about the error occuring. With me, it is predominantly about the utter unusability of the error messages. C++ has postprocessors you can use to get your 20 page STL errors down to a few lines just by reversing the expansion the compiler did to show you mere mortal something that you might recognize as your code instead of template-cthulhu. Haskell has such situations as well, but…

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

I'm always puzzled by people who see this as somehow a good thing.

If the Rust compiler can figure out what the type should be, why doesn't it just do the cross-function inference, and leave the complicated nested implications which only obscure the intent and effect out of it?

If having the programmer specify types is an important check on the correctness of the code that is written, how is blindly copying, without understanding some 60+ character type specification string from an error message going to help demonstrate correctness? All it does is make two sections "consistent". It isn't something the programmer understands or specifies as a type check.

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

#159

I dislike Haskell. But this article goes out of its way to make the worst possible case for Haskell imaginable. > 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 develo…

> So... Type signature `Int -> Int -> Bool` can be used for a function that does any of the following things: manipulates strings, decodes JSON, or queries a database? How does that make it easier to deduce what a function does by "looking only at type signature"?

From this quote, it's easy to see you've not spent any time actually using Haskell (others have explained what is actually going on), so why do you dislike it? I cannot fathom having an opinion either way on a language I don't know.

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

#160
post #79

Earlier quoted context omitted.

So, OCaml or something? Or has Haskell added structural typing?

Haskell is structurally typed...

Hmm, what do you mean? Haskell is generally considered nominally typed (or rather types introduced by its newtype and data declarations are ...). "Structural typing" typically refers to things like polymorphic row types and polymorphic variants.
Post reply on HN