> I'm sorry, but it's not at all obvious that code is parsing a CSV file.

What, exactly, is your complaint?

Could this fellow have written cleaner code? Sure, we agree. Are you saying this is some fundamental problem for Haskell? Because I'm trying to tell you it's not the case. For example, on that line a better practice would be to do exactly what your Python script did; label the reader with csvs with "qualified" in the import.

So let's refresh the comparison with the proper style and without the decision to convert to lists from vectors:

    -- Haskell, cleaner but longer. 
    -- Many people prefer this style when dealing in IO.
    -- Please note that 'readFile' here sucks nearly as
    -- badly as your Python version's readfile does. 
    -- They are terrible.
    f <- BS.readFile "somefile.csv"
    case CSV.decode True f of
      Left  error  -> putStrLn error
      Right tuples -> do 
         -- ...

    # Python
    with open("nukes-list.csv", 'rb') as f:
      try: 
        csvfile = csv.reader(f)
        # ...
      except csv.Error as e:
        print e
      

Huh. Similar linecount, similar line density.

You might argue, "Why were all the extra fmaps there?" Well, ostensibly they're there to do what your code doesn't do, namely deal with exception conditions (your code just ignores errors). But of course the author's poor style throws that benefit away on the same line with the pattern match on "Right _", but we've already conceded the author's code could be cleaner.

My point: You're blaming Haskell for the author's decisions. You're also crediting Python with your own personal familiarity. It is not Python that is natural and obvious, your many hours of hard work with Python have made that language's solution easy for you to perceive. Give yourself some credit, and stop pretending Python is somehow "naturally' clearer.

If you'd like to see examples of good, clean, fast Haskell code then they're easy to provide. I have a funny feeling that's not your goal here, though.