3 ms·

Occasionally you come across languages that do and, at least to me, those languages feel extremely difficult to deal with. For instance, I found AppleScript an

by bborud 2y ago

Occasionally you come across languages that do and, at least to me, those languages feel extremely difficult to deal with. For instance, I found AppleScript and HyperTalk to be awful to work with. I also notice that some junior programmers I've worked with tend to argue for coding styles in mainstream languages that read almost like sentences. Not sure if this is a generational thing or an experience thing.

codeflo 2y ago
I’ve seen the same thing, it might be generational. Someone arguing that we need an isNotEqual(a, b) helper in addition to isEqual(a, b), because that’s supposedly “cleaner” and more readable than !isEqual(a, b). They were very vehement about it, but I don’t get that at any level. It’s more lines of code to write and maintain, more unit tests, more characters to type at the usage site and to me, reads exactly the same way.
- utensil4778 2y ago
  For me, reading isNotEqual() introduces an extra mental variable. I have to spend extra effort to keep track of the bar over the statement that doesn't exist in the text. But that said, I see no reason that someone couldn't learn to parse notX as fluently as I parse !X. I suppose it's one of those fashions that change with the times. Probably a big reason that I stick to good old C a lot of the time.
  - lambdaxyzw 2y ago
    One problem is that when refactoring it's easy to make a monster like "if (!notX()) ..."
- 8372049 2y ago
  My personal opinion is that 'not' (Python-style) should be the operator instead, simply because it's easier to miss a ! than a 'not'. With that said, I'm with you in the 'not isEqual(a, b)' camp. The exception, imo, is functions that take boolean arguments. Languages should make it easy to show what they mean, and devs should take care to explain them. sort(reverse=true, numeric=false) is much easier to read than sort(true, false). (Silly example, it's meant to illustrate the general point, not to say anything about the signature of a sort() function.)
jimmaswell 2y ago
What's old is new again - see SQL and COBOL. They certainly are easy to get the gist of from the words even if you don't know the language. (The business logic may be spaghetti in a COBOL program, but what's happening is clear.) I like it, and I remember SQL easier after disuse than the syntax of something else I've used equally sparsely like bash scripting. Then on the opposite end of the spectrum wrt new things, we have Rust, which comes off to me as pathologically terse and inscrutable - certainly much more difficult for a newbie to parse than SQL.

by bborud 2y ago

codeflo 2y ago

I’ve seen the same thing, it might be generational. Someone arguing that we need an isNotEqual(a, b) helper in addition to isEqual(a, b), because that’s supposedly “cleaner” and more readable than !isEqual(a, b). They were very vehement about it, but I don’t get that at any level. It’s more lines of code to write and maintain, more unit tests, more characters to type at the usage site and to me, reads exactly the same way.

utensil4778 2y ago
For me, reading isNotEqual() introduces an extra mental variable. I have to spend extra effort to keep track of the bar over the statement that doesn't exist in the text. But that said, I see no reason that someone couldn't learn to parse notX as fluently as I parse !X. I suppose it's one of those fashions that change with the times. Probably a big reason that I stick to good old C a lot of the time.
- lambdaxyzw 2y ago
  One problem is that when refactoring it's easy to make a monster like "if (!notX()) ..."
8372049 2y ago
My personal opinion is that 'not' (Python-style) should be the operator instead, simply because it's easier to miss a ! than a 'not'. With that said, I'm with you in the 'not isEqual(a, b)' camp. The exception, imo, is functions that take boolean arguments. Languages should make it easy to show what they mean, and devs should take care to explain them. sort(reverse=true, numeric=false) is much easier to read than sort(true, false). (Silly example, it's meant to illustrate the general point, not to say anything about the signature of a sort() function.)

jimmaswell 2y ago

What's old is new again - see SQL and COBOL. They certainly are easy to get the gist of from the words even if you don't know the language. (The business logic may be spaghetti in a COBOL program, but what's happening is clear.) I like it, and I remember SQL easier after disuse than the syntax of something else I've used equally sparsely like bash scripting. Then on the opposite end of the spectrum wrt new things, we have Rust, which comes off to me as pathologically terse and inscrutable - certainly much more difficult for a newbie to parse than SQL.