4 ms·

There is something to be said for functional code which clearly shows the operations being performed in (reverse) order. In Haskell: (putStrLn . show . sum

There is something to be said for functional code which clearly shows the operations being performed in (reverse) order. In Haskell: (putStrLn . show . sum . map read . filter (not . null) . split '+') "28+32+++32++39" or, if you like list comprehensions, (putStrLn . show . sum) [read x | x <- (split '+' "28+32+++32++39"), not (null x)] But don't underestimate the power of syntax! It's much easier to see the structure of your (d0m's) first example than of the second at a glance. I won't comment on the readability of my Haskell code as I'm already far to conditioned. (Note that I had to define 'split' by hand; it is a gaping hole in the otherwise very comprehensive Data.List library.)

hcarvalhoalves 13y ago
I personally find Haskell's syntax a bad example in language syntax. It's super powerful, but with too many inconsistencies, idiosyncrasies and noise. That, on top of having to wrap your head around new or difficult concepts, makes it a chore. Most code I (try to) read is intractable.
- tome 13y ago
  > I personally find Haskell's syntax a bad example in language syntax. It's super powerful, but with too many inconsistencies, idiosyncrasies and noise. Interesting. Could you give an example? I find Haskell to have pretty much the most consistent, non-idiosyncratic and clean syntax of any language I know.
  - bjourne 13y ago
    The order of operations is incredibly haphazard. Here is GP:s example again decorated with in which order the expression is evaluated: {6}({9}putStrLn . {8}show . {7}sum) {5}[{2}read x | x <- ({1}splitOn "+" "3++4"), {4}not ({3} x)] Here is the same code expressed in Factor: "3++4++9" "+" split harvest [ string>number ] map sum present print Annotated with evaluation order: "3++4++9"{1} "+"{2} split{3} harvest{4} [ string>number{5} ]{6} map{7} sum{8} present{9} print{10}
    - hcarvalhoalves 13y ago
      Glad I'm not the only one bothered by that.
    - tome 13y ago
      And here's the GP's other example: (putStrLn{9} . show{8} . sum{7} . map{5} read{6} . filter{4} (not{3} . null{2}) . split '+'{1}) "28+32+++32++39" and here's ak217's Python version: expr{1} = '28+32+++32++39' print{8} sum{7}(int(i){6} for i in expr.split('+'){2} if{5} i is not ''{4}) Actually, I prefer your Factor example even more than the Haskell (even though I've never heard of the language) because the order of operations is more natural to me, but really I don't think the proposition "Haskell's syntax [is] a bad example in language syntax" has been demonstrated. Comprehensions in Python and in Haskell are an impediment to composability as I mentioned in another post on this story.
      - justinpombrio 13y ago
        Indeed, concatenative languages are written in a very natural way. I wonder if they wouldn't make good teaching languages: you have to learn about a stack, but the evaluation order is trivial (do the first thing, then the second, ...), and there are no variables to contend with. Haskell programs, on the other hand, are clearly written backwards :-)
- Dewie 13y ago
  I find Haskell's syntax to be very clean and with little noise. Much more clean than a multi-paradigm language like Scala.
  - hcarvalhoalves 13y ago
    By noise, I mean: =, =>, =>>, >>=, ->, |, <|>, ., :, ::, $, `...`, and such.
    - tome 13y ago
      That's not noise that's incredibly clear signal! (At least for some, I guess others have different taste).
    - Dewie 13y ago
      It seems that half of those are operators (functions), so in that case your beef seems to be with the names of many of the Prelude and other commonly used functions, not the syntax of the language. That might seem like a pedantic distinction, but I don't consider naming conventions to be part of the syntax of the language (even though they may influence the look and feel of much code). As for the rest, well, I guess I feel fine about their place in the syntax (for example the pipe (|) in the list comprehension: what else should be used? It's trying to look like set notation). What would be a less noisy alternative in your opionion? More English words/keywords instead of ASCII symbols?
gizmo686 13y ago
>(Note that I had to define 'split' by hand; it is a gaping hole in the otherwise very comprehensive Data.List library.) Have you looked at Data.List.Split (`cabal install split`)? splitOn from that package should do what you want. Admitadly, this should be part of Data.List in the standard library.

hcarvalhoalves 13y ago

I personally find Haskell's syntax a bad example in language syntax. It's super powerful, but with too many inconsistencies, idiosyncrasies and noise. That, on top of having to wrap your head around new or difficult concepts, makes it a chore. Most code I (try to) read is intractable.

tome 13y ago
> I personally find Haskell's syntax a bad example in language syntax. It's super powerful, but with too many inconsistencies, idiosyncrasies and noise. Interesting. Could you give an example? I find Haskell to have pretty much the most consistent, non-idiosyncratic and clean syntax of any language I know.
- bjourne 13y ago
  The order of operations is incredibly haphazard. Here is GP:s example again decorated with in which order the expression is evaluated: {6}({9}putStrLn . {8}show . {7}sum) {5}[{2}read x | x <- ({1}splitOn "+" "3++4"), {4}not ({3} x)] Here is the same code expressed in Factor: "3++4++9" "+" split harvest [ string>number ] map sum present print Annotated with evaluation order: "3++4++9"{1} "+"{2} split{3} harvest{4} [ string>number{5} ]{6} map{7} sum{8} present{9} print{10}
  - hcarvalhoalves 13y ago
    Glad I'm not the only one bothered by that.
  - tome 13y ago
    And here's the GP's other example: (putStrLn{9} . show{8} . sum{7} . map{5} read{6} . filter{4} (not{3} . null{2}) . split '+'{1}) "28+32+++32++39" and here's ak217's Python version: expr{1} = '28+32+++32++39' print{8} sum{7}(int(i){6} for i in expr.split('+'){2} if{5} i is not ''{4}) Actually, I prefer your Factor example even more than the Haskell (even though I've never heard of the language) because the order of operations is more natural to me, but really I don't think the proposition "Haskell's syntax [is] a bad example in language syntax" has been demonstrated. Comprehensions in Python and in Haskell are an impediment to composability as I mentioned in another post on this story.
    - justinpombrio 13y ago
      Indeed, concatenative languages are written in a very natural way. I wonder if they wouldn't make good teaching languages: you have to learn about a stack, but the evaluation order is trivial (do the first thing, then the second, ...), and there are no variables to contend with. Haskell programs, on the other hand, are clearly written backwards :-)
Dewie 13y ago
I find Haskell's syntax to be very clean and with little noise. Much more clean than a multi-paradigm language like Scala.
- hcarvalhoalves 13y ago
  By noise, I mean: =, =>, =>>, >>=, ->, |, <|>, ., :, ::, $, `...`, and such.
  - tome 13y ago
    That's not noise that's incredibly clear signal! (At least for some, I guess others have different taste).
  - Dewie 13y ago
    It seems that half of those are operators (functions), so in that case your beef seems to be with the names of many of the Prelude and other commonly used functions, not the syntax of the language. That might seem like a pedantic distinction, but I don't consider naming conventions to be part of the syntax of the language (even though they may influence the look and feel of much code). As for the rest, well, I guess I feel fine about their place in the syntax (for example the pipe (|) in the list comprehension: what else should be used? It's trying to look like set notation). What would be a less noisy alternative in your opionion? More English words/keywords instead of ASCII symbols?

gizmo686 13y ago

>(Note that I had to define 'split' by hand; it is a gaping hole in the otherwise very comprehensive Data.List library.) Have you looked at Data.List.Split (`cabal install split`)? splitOn from that package should do what you want. Admitadly, this should be part of Data.List in the standard library.