3 ms·

They are biased to new readers of a codebase, not of a language, which is really just another way of saying that the code is very readable.

laumars 6y ago
I don’t think it’s fair to say what’s readable to new developers is the same as what’s readable to experienced developers nor even every developer. For example the terse style of Sexpressions or C-style braces are off putting to some but after a short while they become second nature to visually parse (not saying all code should follow Those idioms, just using that as an example of how readability changes with experience). On the other hand I never found it as straightforward visually parsing the “word soup” of named arguments when using languages that favoured it. While those languages were easier to learn the basics, they quickly became tiresome to write larger code bases with. But I guess this just boils down to personal preference.
- enricozb 6y ago
  I'm talking specifically about the function calls, which are effectively the same in C, Rust, Python, Lisp, Haskell, and many others. No matter how terse, it's always some form of <name of function> <value1> <value2> <value3> ... The absence/presence of parenthesis and commas don't add anything of semantic value here, so that's not really what I'm referring to. The problem is, is that the values often don't have any meaning attached to them, especially when they are literals. C++ codebases are pretty bad about this with boolean parameters, just having a random `true` at the end of the function call. Variable names at the call-site are good hints, but we often pass the same variable to different functions, and the name doesn't exactly fit the meaning of each function. This is why I think requiring named parameters, at least by default, is better.
  - laumars 6y ago
    I agree random boolean arguments are unhelpful. Good software development standards would say any uses of boolean values should be substituted with well named constants if the same value. However the advantage of having that baked into the language rather than forcing developers to via code reviews isn’t lost on me

laumars 6y ago

I don’t think it’s fair to say what’s readable to new developers is the same as what’s readable to experienced developers nor even every developer. For example the terse style of Sexpressions or C-style braces are off putting to some but after a short while they become second nature to visually parse (not saying all code should follow Those idioms, just using that as an example of how readability changes with experience). On the other hand I never found it as straightforward visually parsing the “word soup” of named arguments when using languages that favoured it. While those languages were easier to learn the basics, they quickly became tiresome to write larger code bases with. But I guess this just boils down to personal preference.

enricozb 6y ago
I'm talking specifically about the function calls, which are effectively the same in C, Rust, Python, Lisp, Haskell, and many others. No matter how terse, it's always some form of <name of function> <value1> <value2> <value3> ... The absence/presence of parenthesis and commas don't add anything of semantic value here, so that's not really what I'm referring to. The problem is, is that the values often don't have any meaning attached to them, especially when they are literals. C++ codebases are pretty bad about this with boolean parameters, just having a random `true` at the end of the function call. Variable names at the call-site are good hints, but we often pass the same variable to different functions, and the name doesn't exactly fit the meaning of each function. This is why I think requiring named parameters, at least by default, is better.
- laumars 6y ago
  I agree random boolean arguments are unhelpful. Good software development standards would say any uses of boolean values should be substituted with well named constants if the same value. However the advantage of having that baked into the language rather than forcing developers to via code reviews isn’t lost on me