4 ms·

Or... gulp... Haskell, which has your line noise and in addition significant white space syntax.

by nutate 12y ago

imanaccount247 12y ago
When people complain about "line noise" they do not mean "this language has operators".
- sanderjd 12y ago
  Representing "this language has operators" as the complaint about haskell is a bit disingenuous. It is that haskell has way too many operators. Operators are fundamentally unreadable, even if they are nicely writable.
  - imanaccount247 12y ago
    >Operators are fundamentally unreadable I would suggest that is obviously false. Most languages have operators. Is 4+5 really less readable than plus(4,5)? Haskell does not have very many operators. The fact that people see 3 operators they are not familiar with and decide "this is unreadable because of so many operators" speaks rather poorly of people's desire to learn.
    - michaelcampbell 12y ago
      Or, to quote Rich Hickey; "I can't read German; that doesn't make it unreadable." NB: I know a little German, and almost no Haskell.
    - sanderjd 12y ago
      I think "4+5" is readable because I read it as "four plus five", and that operators become un-readable when you can no longer insert a common descriptive word in their place. The problem in haskell is not the few operators in the prelude that are unfamiliar, but the multitude defined in libraries. In fairness, there are good ways to search the documentation for those operators so at least you aren't stuck googling for line noise.
      - imanaccount247 12y ago
        But you can insert a common descriptive word in their place. Choosing not to learn what >>= means doesn't make it unreadable or line noise. That is like saying C++ is unreadable line noise because it has all these -> all over the place.
      - codygman 12y ago
        getDirectoryContents "/home/cody" >>= print Bind a function which gets the contents of my system tmp directory to a function which takes anything and returns a monad, then return the evaluated monadic result.
  - dragonwriter 12y ago
    > It is that haskell has way too many operators. Haskell doesn't really have that many operators built-in (that is, in the standard Prelude). Haskell is completely open to user-defined operators (whose names can either be alphanumeric or symbolic), which, combined with the fact that symbolic operators often are attempt to approximate symbols from the application domain in ASCII while avoiding duplication of symbols used in the prelude even if those in the application domain are the same as those used in the prelude often results in less-than-intuitive choices. Whether this is more or less readable than alternatives, though, is pretty subjective -- operators are generally used to reduce visual complexity in a way which is (given the constraints discussed above) as familiar as practical given the notation used in the domain, so even with the problems introduced by those constraints I think it often results in code that is at least as readable, and often more, than the cumbersome structures that are the alternative in languages that don't support user-defined operators.
    - sanderjd 12y ago
      I don't think I've ever seen code (in any language) that restricted itself to the Prelude (or its equivalent). What matters is what typical code looks like, and while I like haskell, I believe it's a major weakness of the language that, whether by design or idiom, typical code appears to prefer terseness over good names, and operators over descriptive function names are the most noticeable aspect of the problem. I think mathematicians could use to learn the lesson that descriptive names are nice, rather than programmers learn the lesson that terse domain-specific operators are better.
      - imanaccount247 12y ago
        >typical code appears to prefer terseness over good names Or to phrase it another way, typical code prefers good names over lengthy names. See, having a preference is fine. But acting like your preference is objectively correct is not.
        sanderjd 12y ago
        I don't think I'm objectively correct, and I struggle with the balance between peppering around a bunch of "I think"s and "in my opinion"s and just writing what I think directly and hoping people can tell that it's just my opinion. Since that didn't work, I'll be more explicit: in my opinion, an unfamiliar operator is usually both a terse and a bad name.

Or... gulp... Haskell, which has your line noise and in addition significant white space syntax.

by nutate 12y ago

Or... gulp... Haskell, which has your line noise and in addition significant white space syntax.

imanaccount247 12y ago

When people complain about "line noise" they do not mean "this language has operators".

sanderjd 12y ago
Representing "this language has operators" as the complaint about haskell is a bit disingenuous. It is that haskell has way too many operators. Operators are fundamentally unreadable, even if they are nicely writable.
- imanaccount247 12y ago
  >Operators are fundamentally unreadable I would suggest that is obviously false. Most languages have operators. Is 4+5 really less readable than plus(4,5)? Haskell does not have very many operators. The fact that people see 3 operators they are not familiar with and decide "this is unreadable because of so many operators" speaks rather poorly of people's desire to learn.
  - michaelcampbell 12y ago
    Or, to quote Rich Hickey; "I can't read German; that doesn't make it unreadable." NB: I know a little German, and almost no Haskell.
  - sanderjd 12y ago
    I think "4+5" is readable because I read it as "four plus five", and that operators become un-readable when you can no longer insert a common descriptive word in their place. The problem in haskell is not the few operators in the prelude that are unfamiliar, but the multitude defined in libraries. In fairness, there are good ways to search the documentation for those operators so at least you aren't stuck googling for line noise.
    - imanaccount247 12y ago
      But you can insert a common descriptive word in their place. Choosing not to learn what >>= means doesn't make it unreadable or line noise. That is like saying C++ is unreadable line noise because it has all these -> all over the place.
    - codygman 12y ago
      getDirectoryContents "/home/cody" >>= print Bind a function which gets the contents of my system tmp directory to a function which takes anything and returns a monad, then return the evaluated monadic result.
- dragonwriter 12y ago
  > It is that haskell has way too many operators. Haskell doesn't really have that many operators built-in (that is, in the standard Prelude). Haskell is completely open to user-defined operators (whose names can either be alphanumeric or symbolic), which, combined with the fact that symbolic operators often are attempt to approximate symbols from the application domain in ASCII while avoiding duplication of symbols used in the prelude even if those in the application domain are the same as those used in the prelude often results in less-than-intuitive choices. Whether this is more or less readable than alternatives, though, is pretty subjective -- operators are generally used to reduce visual complexity in a way which is (given the constraints discussed above) as familiar as practical given the notation used in the domain, so even with the problems introduced by those constraints I think it often results in code that is at least as readable, and often more, than the cumbersome structures that are the alternative in languages that don't support user-defined operators.
  - sanderjd 12y ago
    I don't think I've ever seen code (in any language) that restricted itself to the Prelude (or its equivalent). What matters is what typical code looks like, and while I like haskell, I believe it's a major weakness of the language that, whether by design or idiom, typical code appears to prefer terseness over good names, and operators over descriptive function names are the most noticeable aspect of the problem. I think mathematicians could use to learn the lesson that descriptive names are nice, rather than programmers learn the lesson that terse domain-specific operators are better.
    - imanaccount247 12y ago
      >typical code appears to prefer terseness over good names Or to phrase it another way, typical code prefers good names over lengthy names. See, having a preference is fine. But acting like your preference is objectively correct is not.
      - sanderjd 12y ago
        I don't think I'm objectively correct, and I struggle with the balance between peppering around a bunch of "I think"s and "in my opinion"s and just writing what I think directly and hoping people can tell that it's just my opinion. Since that didn't work, I'll be more explicit: in my opinion, an unfamiliar operator is usually both a terse and a bad name.