4 ms·

But then it is reduced to simply saying "I don't like it", which is not useful or meaningful. A discussion is not useful if it is just people going "I don't li

But then it is reduced to simply saying "I don't like it", which is not useful or meaningful. A discussion is not useful if it is just people going "I don't like X", "well I do like X". Yes, haskell programmers tend to prefer short names. If you want to argue that this causes it to be unreadable then feel free, but you are just saying it rather than making an argument for it.

sanderjd 12y ago
Recognizing that an opinion is not objective fact does not preclude making an argument for it. (If it did, there would be very little discussion in general.) My argument is that I believe using descriptive words, even if they are longer, usually makes concepts easier to understand while reading than using either terser words that are less descriptive or symbols that are not in common use. That's not fact, but it's different than just saying "I don't like X".
- imanaccount247 12y ago
  Ok, but that isn't what you said. You said haskell has way too many operators, and operators are fundamentally unreadable. Neither are true. The problem with your new argument is that it is just rephrasing "if I don't learn X, I don't understand X". The operators commonly used in haskell are in common use, by definition. Haskell is not unreadable just because you didn't learn how to read it. No, basic_arithmetic_addition_function is not clearer than +. So why would needlessly_long_name_that_conveys_no_extra_information be clearer than >>=?
  - sanderjd 12y ago
    You know what, you're right. Operators aren't at all "fundamentally unreadable", that was a dumb thing to say. Operators in common usage, like ">>=", are not at all a problem, because as you suggest, they only need to be learned once and aren't easily forgotten. Operators that are never used are also not a problem, because they are never used. But I do see a problem in the middle, where I see an operator, figure out what it does, and then don't see it again for some time. Re-learning less frequently used operators constantly is not very efficient. Your fake names are a false choice. The trick is to find good descriptive names, and using a name that is annoyingly long is probably worse than using one that is frustratingly terse. The trick is to pick a good one.
    - codygman 12y ago
      > Re-learning less frequently used operators constantly is not very efficient. You could also say: > Re-learning less frequently used command line programs constantly is not very efficient. However in my experience re-learning is much easier than learning the first time. For instance if I've used a command line program before I can glance at the manual and figure out what I need very quickly.
      - sanderjd 12y ago
        Sure. But my point is that good names make it even easier because they act like a refresher. Unix command line programs could also use to be better-named. "cat" and "ls" are example of fairly poor names (but again, common enough to not be a big problem!), whereas "head", "tail", and "echo" are much better because even if you forget what they do, the names themselves refresh your memory! Naming things well is definitely hard, but it's worthwhile.
        kbenson 12y ago
        I generally hold that it's simply a matter of whether the language is optimizing for beginners, intermediate level users, or experts. Terse code is useful for domain experts, it allows them to quickly assess what's happening without having to read a lot, and have more of the program logic in the field of view at a time. Unfortunately it's hard for beginners to understand because a lot is implied through idiomatic usage. Verbose code is easier for beginners, but domain experts may find it cumbersome and a chore to both read and write. Perl has found an interesting spot on this spectrum, as through TIMTOWTDI it has the capacity for verbose code, as well as terse, idiomatic code. I'm not sure if that means it's optimized for intermediate level users, or if it's just schizophrenic.
    - imanaccount247 12y ago
      >Your fake names are a false choice Yes, they are certainly hyperbolic. But the idea was to make the point that longer is not better. If a variable has a short scope, you do not need to constantly be reminded what it is. If a variable is very general, a very general name is fine. Generally haskellers consider names like 's' and 'x' and 'i' to be very good names. Code is generally optimized for being read by people who know the language, not by people who are unfamiliar with it.

sanderjd 12y ago

Recognizing that an opinion is not objective fact does not preclude making an argument for it. (If it did, there would be very little discussion in general.) My argument is that I believe using descriptive words, even if they are longer, usually makes concepts easier to understand while reading than using either terser words that are less descriptive or symbols that are not in common use. That's not fact, but it's different than just saying "I don't like X".

imanaccount247 12y ago
Ok, but that isn't what you said. You said haskell has way too many operators, and operators are fundamentally unreadable. Neither are true. The problem with your new argument is that it is just rephrasing "if I don't learn X, I don't understand X". The operators commonly used in haskell are in common use, by definition. Haskell is not unreadable just because you didn't learn how to read it. No, basic_arithmetic_addition_function is not clearer than +. So why would needlessly_long_name_that_conveys_no_extra_information be clearer than >>=?
- sanderjd 12y ago
  You know what, you're right. Operators aren't at all "fundamentally unreadable", that was a dumb thing to say. Operators in common usage, like ">>=", are not at all a problem, because as you suggest, they only need to be learned once and aren't easily forgotten. Operators that are never used are also not a problem, because they are never used. But I do see a problem in the middle, where I see an operator, figure out what it does, and then don't see it again for some time. Re-learning less frequently used operators constantly is not very efficient. Your fake names are a false choice. The trick is to find good descriptive names, and using a name that is annoyingly long is probably worse than using one that is frustratingly terse. The trick is to pick a good one.
  - codygman 12y ago
    > Re-learning less frequently used operators constantly is not very efficient. You could also say: > Re-learning less frequently used command line programs constantly is not very efficient. However in my experience re-learning is much easier than learning the first time. For instance if I've used a command line program before I can glance at the manual and figure out what I need very quickly.
    - sanderjd 12y ago
      Sure. But my point is that good names make it even easier because they act like a refresher. Unix command line programs could also use to be better-named. "cat" and "ls" are example of fairly poor names (but again, common enough to not be a big problem!), whereas "head", "tail", and "echo" are much better because even if you forget what they do, the names themselves refresh your memory! Naming things well is definitely hard, but it's worthwhile.
      - kbenson 12y ago
        I generally hold that it's simply a matter of whether the language is optimizing for beginners, intermediate level users, or experts. Terse code is useful for domain experts, it allows them to quickly assess what's happening without having to read a lot, and have more of the program logic in the field of view at a time. Unfortunately it's hard for beginners to understand because a lot is implied through idiomatic usage. Verbose code is easier for beginners, but domain experts may find it cumbersome and a chore to both read and write. Perl has found an interesting spot on this spectrum, as through TIMTOWTDI it has the capacity for verbose code, as well as terse, idiomatic code. I'm not sure if that means it's optimized for intermediate level users, or if it's just schizophrenic.
  - imanaccount247 12y ago
    >Your fake names are a false choice Yes, they are certainly hyperbolic. But the idea was to make the point that longer is not better. If a variable has a short scope, you do not need to constantly be reminded what it is. If a variable is very general, a very general name is fine. Generally haskellers consider names like 's' and 'x' and 'i' to be very good names. Code is generally optimized for being read by people who know the language, not by people who are unfamiliar with it.