Haskell is our first choice for building production software systems • Hacker News Board

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

#121

Post by IfOnlyYouKnew » Mon, Jan 11, 2021, 1:05 PM UTC

FlyingSnake wrote: post #70

IfOnlyYouKnew wrote: post #23

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…

> 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 fits. I think you're projecting too much on them. They found Haskell performant and are promoting it, I don't see any problem with it. How is any different from all the Rust evangelism HN sees all the time?

I really don't have a problem with their choice–I wasn't being ironic. It's perfectly acceptable to make "I like it" or "it works for us" choices.

I do believe, very very mildly, that there's a strain of thinking among the tech crowd that glorifies this Spock-like emotional detachment and I'm-so-rational mindset. Two issues, actually:

First, such a mindset is neither possible nor would do much good. There are stroke victims that survive with full mental capabilities with regards to logical reasoning but entirely devoid of emotions. These patients can still ace the SAT, but they fail spectacularly at daily life. As it turns out, you just cannot decide on a doctor's appointment without emotions. They'll spent hours vacillating between two good choices. Emotions are incredibly well-tuned heuristics that cut down your mental load to manageable levels. As any part of being human, they are sometimes ill-fitting for modern times: there's absolutely no reason to make me flinch when I spill hot coffee over my hand. But mostly they just work.

Second, it's slightly annoying when people deny that they are subject to emotions, and it gets up to Ryanair-levels of discomfort when they announce that it makes them superior to all those emotional social science majors, illogical politicians, women "throwing a fit", superficial designers etc. If I got a KDE theme every time someone accused Apple users of being blinded by eye candy, I'd still be left with only half of what Kubuntu ships.

But Rust is cool.

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

#122

Post by FpUser » Mon, Jan 11, 2021, 1:05 PM UTC

tome wrote: post #55

coldtea wrote: post #5

Why Haskell is our first choice for building production software systems: a rationalization of our excitement to get to write Haskell in production Here, I've fixed the title

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.

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

#123

Post by chriswarbo » Mon, Jan 11, 2021, 1:06 PM UTC

kensai wrote: 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…

I've played with it, using the kics2 implementation. I made a rough package for Nix, which might be useful if you have problems installing it:

http://chriswarbo.net/git/warbo-packages/git/branches/master...

You might like the Mercury language too: https://mercurylang.org/

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

#124

Post by sesm » Mon, Jan 11, 2021, 1:06 PM UTC

willtim wrote: post #77

IfOnlyYouKnew wrote: post #23

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…

> 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. It's about quality of life and picking the right tool for the job. There are some problems I can solve in Haskell, that I simply could not solve in Java, it would be too hard and too much work. Java is a simple language and therefore it's much easier to r…

Java is much easier to reason about the performance and space usage because it's a language with strict evaluation. Most programming languages use strict evaluation, including OCaml, F# and Scala.

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

#125

Post by Twisol » Mon, Jan 11, 2021, 1:08 PM UTC

dmitriid wrote: post #115

kreetx wrote: post #103

Earlier quoted context omitted.

It's the fact that it is `Int -> Int -> Bool` that ensures you that the function doesn't do any random thing (like doing something on the database). Combining non-IO capable functions is quite helpful in reasoning about programs. I.e if the function has `IO` in the result type then exactly - "who knows". But with the fact that it doesn't, you do know that it doesn't do anything other than return the bool.

I mean. Really. That's what people hang up on? The point for that particular gripe was this: "this allows a programmer reading Haskell code to look only at type signatures when getting a sense of what a certain piece of code does." Yes, IO tells that ... the function does some side effects. And that's it . If your type signature is `Int -> Int -> IO Bool`, it's just as useless as `Int -> Int -> Bool`, and requires yo…

You don't get any information from `IO _` functions, but that's the case with every mainstream language, where you have an implicit `IO` on every single function.

The benefit is not in `IO` -- its that its absence on a function tells you that it is heavily restricted in what it can do.

If you want to go the other way, you can concretely model the kinds of effects you need parts of your programs to do, and use that model instead of `IO`. Even if you end up implementing it using `IO`, you know it can't use more than what your model exposes.

Both of these possibilities, while not truly unique (see Agda, etc.), are absolutely rare-to-nonexistent in mainstream languages. Effect modeling is a real shift in perspective.

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

#126

Post by dan-robertson » Mon, Jan 11, 2021, 1:10 PM UTC

ernst_klim wrote: post #100

dan-robertson wrote: post #71

Earlier quoted context omitted.

What you have described is an anecdote rather than any study that attempts to be impartial which is what I really meant when I wrote ‘evidence.’ I’m sorry for not being clear enough. I don’t feel like this anecdote is evidence because I don’t think it’s inconsistent with the trend towards more static types over the last 5-10 years or so. For this anecdote to be convincing I would need to think that programming langua…

This is not an anecdote by definition, since these languages represents quite a huge marketshare (and most of the rest langs are already statically typed). Yes, this is not a sound rigid empirical proof, it's an observation (i.e. unlike the case of anecdotal, you can measure the marketshare of user, how many do use dialyzer or typescript, etc etc). We can't simply ignore any observations that are not scientifically r…

> I think it's a better evidence exactly because it's what language users are asking about, and what large chunk of language users choose to use when they got a choice. This shows that quite a big share if not majority of programmers value type annotations.

To be clear, this is where I disagree. I don’t want to claim that people don’t think hard about language design or that users aren’t asking for these features as I think both of those statements are true. But I strongly disagree that languages doing things (and those languages being popular) is good evidence that those things are good.

I think a lot of language design is driven by fashion (ie keeping up with what similar languages are doing) and I claim that this is a more convincing reason for python having some gradual typing.

I think large number of people is moving to/from from python for gradual typing in aggregate, and I don’t think it’s happening on the margin either. I think any wise decisions about languages are more likely to be driven by practical considerations (what do people know, what are they used to, what can people be hired for, what libraries are available, what platforms are supported, what performance is required, and so on).

Just because python has a large market share, it doesn’t mean it’s users are supporters of gradual typing, it just means that they thought python was a good idea when they first started using it and they haven’t justified the cost of changing to something else. The users didn’t choose gradual typing they just chose “upgrade the language to the next version”

Even if I agreed with your claim that many users asked for gradual typing, I don’t agree that in aggregate users ask for things that will be good for them or good in general. Maybe users are just trying to figure out a way to say “we want our programs to be less buggy” and think this might help. I think there are better examples in programming language design of what can happen if you keep giving users what they are asking for.

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

#127

Post by secondcoming » Mon, Jan 11, 2021, 1:12 PM UTC

bachmeier wrote: post #66

unicornmama wrote: post #3

Good luck scaling this to organization of 100+ engineers. You will soon learn the tradeoff between writing and reading code. And the stark realities of the dev hiring markets and the thing called a learning curve.

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.

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

#128

Post by mehrdadn » Mon, Jan 11, 2021, 1:12 PM UTC

msla wrote: post #117

mehrdadn wrote: post #78

Earlier quoted context omitted.

> You have to repeat the type information, a lot. Nope you don't, that's what typedefs are for. They're underrated for sure though. People don't use them nearly as much as they should. They're incredibly valuable for avoiding precisely this problem.

Shifting topics a bit, typedefs don't allow me to write generic code. Templates do, but templates bring in their own problems, in addition to not being expressive in the right ways: I can have an array of T, but I can't specify that T is Numeric? The fact C++ doesn't have Numeric but instead has int and long and unsigned and long long and float and double all off on their own is another problem: The compiler knows en…

You're asking for the impossible. What you want is precisely what templates are, but you also want them to not be "templates" for... some bizarre reason.

> I can have an array of T, but I can't specify that T is Numeric?

Sure you can. If you have C++20 concepts:

  template
  concept Numeric = std::integral || std::floating_point;
  
  template
  T twice(T x)
  { return x + x; }

Or if you're on a C++11 compiler:

  template
  typename std::enable_if::value,
    T>::type twice(T x)
  { return x + x; }

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

#129

Post by MaxBarraclough » Mon, Jan 11, 2021, 1:14 PM UTC

msla wrote: post #117

mehrdadn wrote: post #78

Earlier quoted context omitted.

> You have to repeat the type information, a lot. Nope you don't, that's what typedefs are for. They're underrated for sure though. People don't use them nearly as much as they should. They're incredibly valuable for avoiding precisely this problem.

Shifting topics a bit, typedefs don't allow me to write generic code. Templates do, but templates bring in their own problems, in addition to not being expressive in the right ways: I can have an array of T, but I can't specify that T is Numeric? The fact C++ doesn't have Numeric but instead has int and long and unsigned and long long and float and double all off on their own is another problem: The compiler knows en…

edit: I see dataflow beat me to it. I'll leave this here anyway.

> I can have an array of T, but I can't specify that T is Numeric?

This is what type-traits and 'concepts' are for, right?

> The compiler knows enough about them to have complex promotion rules but doesn't know enough to allow me to refer to all of them under one name in my code.

This is what std::is_integral gives you.

https://en.cppreference.com/w/cpp/types/is_integral

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

#130

Post by kreetx » Mon, Jan 11, 2021, 1:14 PM UTC

dmitriid wrote: post #115

kreetx wrote: post #103

Earlier quoted context omitted.

It's the fact that it is `Int -> Int -> Bool` that ensures you that the function doesn't do any random thing (like doing something on the database). Combining non-IO capable functions is quite helpful in reasoning about programs. I.e if the function has `IO` in the result type then exactly - "who knows". But with the fact that it doesn't, you do know that it doesn't do anything other than return the bool.

I mean. Really. That's what people hang up on? The point for that particular gripe was this: "this allows a programmer reading Haskell code to look only at type signatures when getting a sense of what a certain piece of code does." Yes, IO tells that ... the function does some side effects. And that's it . If your type signature is `Int -> Int -> IO Bool`, it's just as useless as `Int -> Int -> Bool`, and requires yo…

Having a distinction of if something does IO or not is quite important, and the fact that haskell has the ability to encode it in types is what other languages don't have.

Secondly, IO is just one monad. You can build a more granular one where you can separate filesystem, network etc, and encode this into types (so you know at a glance). You can't do this in most other languages.

What are the types of things that are worth being hung up on for a language for you?