Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Haskell is our first choice for building production software systems

foxhound.systems

Post reply on HN
Print view View original

131–140 of 297 posts

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

#131

Post by Twisol »

magicalhippo wrote: post #112
uryga wrote: post #82

Earlier quoted context omitted.

if it has side-effects, it has to be something like Int -> Int -> IO Bool otherwise the type checker won't let you perform any side-effecting operations (btw Haskell's `IO Bool` would be spelled `IO ` in C++/Java syntax)

And there's no way to get rid of the IO then, presumably (I mean otherwise I could have just used that as a wrapper). edit: So at work, just about every value depends directly or indirectly on stuff that comes from files or from the database. So would they all have to be wrapped by IO?

In Haskell, you often build pure transformations, and then lift them into an effectful context. If I have a function `String -> [String]`, say to parse a line of CSV into its elements, I can lift that to `IO String -> IO [String]` using the IO monad's `fmap`. And then I can compose it with something hypothetical like `readLine :: File -> IO String`, which actually reads the line.

The core logic of a program often doesn't need to care deeply about state or system resources. Pure functional programming is about writing as much as you can in this "functional core", and then lifting the assembled pieces of pipeline into the "imperative shell" (such as the IO monad).

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

#132

Post by dsign »

jcelerier wrote: post #2

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

Amen to that. I love dearly both C++ and Haskell, but I remember those times when I wanted to cry because the C++ error message broke the OS clipboard when I was trying to copy it to a text editor so that I could write a program to analyze it and find which "const" didn't match in the jungle of type names. I have never had that situation with Haskell.

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

#133

Post by chriswarbo »

wombat23 wrote: post #88

What I'd like to understand: When/why does one choose Haskell over other functional languages e.g. F# or OCaml? It looks to me like they would satisfy the same points that the article makes. Edit: just did a quick comparison of the last 2 SO developer surveys, and it looks like Haskell "replaced" F# in their popularity ranking last year.

Haskell's laziness and purity can make it a bit trickier to use constructs that are common in ML-like (or Scheme-like) languages, like mutable variables. This nudges Haskell libraries in a slightly different direction, e.g. making more use of control structures like monads, arrows, continuations, etc. which authors in other languages wouldn't reach for so readily. This has an effect on the ecosystem, since people want their systems and libraries to be compatible with each other's APIs.

The result is that "the Haskell way" can seem a little more intimidating than the more "pragmatic" approach of MLs.

(I write this as someone who writes a lot of Haskell, and dabbles in StandardML!)

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

#134

Post by secondcoming »

mehrdadn wrote: post #118
secondcoming wrote: post #114

Earlier quoted context omitted.

> If you want type inference you already have auto or auto&&. Did you really intend to make a copy?

You probably did intend it to be a copy if you're binding it to a variable and need it to be non-const (like in the example)!

Ah, but you knew that because that's how the code was written!

If it was instead

    String foo = "bar";
    auto baz = foo;
you don't know for sure. But the code compiles so it obviously ok!

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

#135

Post by mehrdadn »

secondcoming wrote: post #111
nicoburns wrote: post #89

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…

+1 for auto being overused. I always felt I was shouting into the void (hah) by saying the same thing... it's nice to see someone else agrees.

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

#136

Post by Twisol »

hardwaresofton wrote: post #107

Haskell is an excellent language, and you are free to choose not to drown yourself in the most complex uses of it. Haskell has the type system Java wishes it did, and half of the reason languages like Rust are interesting is because they've learned from Haskell (which is the point of Haskell, a research langage, though it happens to also be a pretty darn good language for building practical things). Simple basic data…

You dropped this:

[0] http://paulgraham.com/avg.html

(Scroll to "The Blub Paradox", about a third of the way down.)

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

#137

Post by mehrdadn »

secondcoming wrote: post #134
mehrdadn wrote: post #118

Earlier quoted context omitted.

You probably did intend it to be a copy if you're binding it to a variable and need it to be non-const (like in the example)!

Ah, but you knew that because that's how the code was written! If it was instead String foo = "bar"; auto baz = foo; you don't know for sure. But the code compiles so it obviously ok!

No, I'm saying even in that case you know it was intended to be a copy. If you wanted that to be a reference then you'd either (a) just do the obvious thing which is to just use the original variable name instead of creating a new variable out of the blue for no reason, (b) leave a comment explaining why you're not doing the aforementioned obvious thing, or (c) use a self-explanatory variable name to provide the explanation instead of a comment.

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

#138

Post by chriswarbo »

magicalhippo wrote: post #112
uryga wrote: post #82

Earlier quoted context omitted.

if it has side-effects, it has to be something like Int -> Int -> IO Bool otherwise the type checker won't let you perform any side-effecting operations (btw Haskell's `IO Bool` would be spelled `IO ` in C++/Java syntax)

And there's no way to get rid of the IO then, presumably (I mean otherwise I could have just used that as a wrapper). edit: So at work, just about every value depends directly or indirectly on stuff that comes from files or from the database. So would they all have to be wrapped by IO?

As a concrete example, there's a nice function in Haskell's standard library called `interact :: (String -> String) -> IO ()`: https://hackage.haskell.org/package/base-4.14.1.0/docs/Prelu...

Its argument is a function of type `String -> String` and it returns an `IO ()`, i.e. an i/o action with a trivial result. That action will call the given function on contents of stdin, and writes its result to stdout. Or, equivalently, we can think of `interact f` as transforming a pure string-processing function `f` into a stdio CLI.

Note that laziness (specifically "lazy IO") causes stdin to be read 'on demand', giving us a streaming computation without any extra work. Here's an example implementation of 'wc':

    module Main where
    import System.IO

    main :: IO ()
    main = interact count

    count :: String -> String
    count input = show (length (unwords input))
Bonus: if we want to show off, we could implement 'count' using function composition like this:

    count = show . length . unwords

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

#139

Post by mjburgess »

FpUser wrote: post #96
mjburgess wrote: post #25

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.

I have zero problems using type inference, tuples, etc in my code. Other developers I deal with and who do use C++ have no problems using those "novel" concepts either. So I am completely at loss about what type of culture you are talking about here. It looks like grasping at a straw type of argument to me.

I'm talking about all libraries and books written since it's development up until the early 10s; and of all those teams, libraries, and code which are legacy.

Haskell has never had a decades-long history of 'compiler-oriented programming', ie., excessive declarations, and so on.

The idea that C++ has a haskellish culture is patently absurd, even if the vanguard regard itself as presenting tending toward that direction.

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

#140

Post by 3836293648 »

emteycz wrote: post #99
Rompect wrote: 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.

Depends on the compiler. In my very limited experience I've found that Clang is far superior to GCC in this matter (but rustc is better still, apart from iterator errors)
Post reply on HN