[tromp]

> The Haskell solution requires more steps and theory.

Really? The suggested Haskell solution is

    main = do  
        contents <- readFile "test.txt"
        print . map readInt . words $ contents

which is no more complex than the Python code. The entire file contents is read as a String into content. words breaks it into a list of words, and readInt parses each word into an Int. Finally the list of ints is printed.

[yodsanklai]

yes, it looks all good, until you want to change it. For instance, to make the file name a CLI parameter, you need to understand things like type classes, specifically Monad, Functor and Applicative. You may need a long time to be at ease with these things and a superficial understanding will not take you very far. In Python, it'll take you a few minutes to do the same thing.

[cess11]

What do you mean by "long time"? Why wouldn't it apply just the same to some Python file that defines a Maybe with a bit of unwrap and bind and orElse or whatever?

Instead of things going boom and spewing a stack sometimes they just go Nothing instead, you don't need much more understanding than that. There is a lot of syntax in Haskell that is somewhat hard to understand at first but you don't actually need it to write stuff yourself.

This idea that you need to talk a particular way and be able to teach CS theory at uni and whatnot to build stuff in Haskell is probably not very healthy.

[yodsanklai]

Long time, I mean possibly several weeks of full-time studying for an intermediate Python or C++ programmer.

I'm not saying you need any CS theory to write Haskell or that it's super hard. But I think the learning curve is pretty steep, and it's hard to write code without a good understanding of the concepts. Just tweaking until it type checks isn't going to cut it.

Consider this code. Generated from ChatGPT. This is supposed to be a simple command line option parsing. I don't think it's obvious what all the operators mean.

Sure, you can try to reuse this, and extend it. But I think sooner than later you'll be stuck with some undecipherable error messages and you'll have to sit down and understand what it all means.

  data Options = Options
    { optVerbose :: Bool
    , optInput   :: String
    } deriving Show

  optionsParser :: Parser Options
  optionsParser = Options
    <$> switch
        ( long "verbose"
       <> short 'v'
       <> help "Enable verbose mode" )
    <\*> strOption
        ( long "input"
       <> short 'i'
       <> metavar "FILENAME"
       <> help "Input file name" )

[7thaccount]

This is a really good point. I have coworkers that don't really code, but can use ChatGPT to help them put together a Python app that does what they need with some common sense changes. I don't think I could even do the same with Haskell with a fair amount of coding experience+ reading up a lot on Haskell over the years. It may be obvious to those select few who are drawn to Haskell, but I think they greatly underestimate the challenges for the average person. That's the essence of what I've been saying to the parent thread that believes a subset of Haskell will become popular some day. I could be wrong, but just can't see it.

[instig007]

It is obvious, as long as you know what Functors and Semigroups for custom data types are. If you don't know it, you can still use it freely without fully understanding the meaning of `<>` and `<$>`, because they are written almost as plain bullet points of components to treat as a single whole.

[7thaccount]

I'd say a lot more is going on there conceptually than the Python code. Imagine through the eyes of a beginner. You have some main do thing, then you appear to read it all into memory and assign a variable, then you do a bunch of composition to words and readInt and map it to print?

With the python version, you see the file handle as a variable and then for loop on that iterable and you can print each line or parse it however you want. Even when I was learning to program and had no clue what an iterable object was, there seemed to be an obvious three line idiom for processing text files that was easy to use.

[neonsunset]

I think the issue that many people have with Haskell is the order of expression evaluation is not structured left-to-right and top-to-bottom. At least it's what makes it difficult to read Haskell for me. Compare it with F# (and OCaml family in general):

    open System.IO

    (File.ReadAllText "text.txt").Split()
    |> Seq.map int
    |> Seq.iter (printfn "%d")

It doesn't really matter on simple expressions but as you keep chaining the operations the reverse order gets more difficult to follow.