9 ms·

"In spite of the topic of this blog, I think you should always aim to write code which is idiomatic to the language you’re using. If only so it’s accessible to

"In spite of the topic of this blog, I think you should always aim to write code which is idiomatic to the language you’re using. If only so it’s accessible to whoever has to maintain your code after you’re gone." Come on. This approach is almost always used to justify shitty practices just because they are idiomatic (read: the language has a severe limitation in the area) This is a really good example - if you can use a library with proper option types or other constructs which reduce bugs - go ahead! Similar with C# and libraries like language-ext - zero idiomacity but in some cases, can replace hundreds of lines of code while preventing obvious bugs. Whoever has to maintain it afterwards should be grateful about being exposed to different styles and language idioms instead of complaining that he's been taken out of his comfort zone, in my opinion.

cornholio 3y ago
Conversely, your approach has been used to justify the most abhorrent programming practices even perpetrated on mankind. What you get are not carefully chosen abstractions, but custom mini-languages with no specification masquerading as the original language by redefining basic primitives, a dependency hell to arbitrary and non maintained weekend projects someone dumped on github, which would have been easy to write in terms of the standard library - if only the original author knew its capabilities - but now they must be reverse-engineered from context etc. The maintainer is not ready for a paradigm shift because they will not own your program in perpetuity. Even you yourself ran away and abandoned it, so how can you expect someone else to love it more? No, the maintainer has a limited time and attention span to work on a specific bug or feature, and your code is either maintainable or it's not.
- Pannoniae 3y ago
  I think you assume that the choice is between "good, idiomatic code" and "non-idiomatic, horrible, abandoned mess". Most of what you said are problems with simply not documenting code and writing code well enough; being idiomatic slightly helps in that by making it more familiar, but that's just a masking of the fact that the program is written horribly with no documentation. Libraries like language-ext are absolutely not "badly chosen abstractions" or "dependency hell". Also, "your code is either maintainable or it's not." is heavily subjective. Maintainability is often also used to criticise stylistic choices like variable naming, tabs vs. spaces, brace placement and other things which might be non-standard but don't detract from readability at all. If it did, there wouldn't be so many different standards across languages.
  - cornholio 3y ago
    The basic idea is that, keeping all other things constant, the code with the least surprises and paradigm shifts is the more maintainable one, because almost all code innovations have a learning curve that pays back the more you use the concept. The maintainer is by definition on the losing end of that tradeoff, because they have to learn lots of things about your code and have limited opportunities to apply that learning. So poor code without surprises is much better than poor code that tries to take you outside of your comfort zone.
    - Pannoniae 3y ago
      But it also raises the average software quality by educating the maintainer. If all you do is write Python the same way your entire life, your code quality won't be that great. This is a fairly small sacrifice for a greater societal gain.
      - c_crank 3y ago
        Python itself was designed with the intent of pressuring programmers to write Python in one specific way. The problems that crop up in large Python codebases are probably the result of using Python outside of its intended scope of scripting and toy programs.
        Pannoniae 3y ago
        Yes. But people do use (or more like, misuse) Python for different things such as large systems. In cases like that, others still scream about "pythonicity" and "idiomaticness" just for the sake of language policing, even if those guidelines make zero sense. I had the misfortune of using Python for.... larger systems than it was intended for, and the code reviewer basically screamed at me for daring to use staticmethods instead of free-floating functions. Even though it was an internal implementation detail and it was exactly the point that the function itself shouldn't be discoverable if you import the file. But convention and being pythonic trumps everything... So yes, I think that people who criticise others for not writing "idiomatic" code just want to nitpick most of the time.

cornholio 3y ago

Conversely, your approach has been used to justify the most abhorrent programming practices even perpetrated on mankind. What you get are not carefully chosen abstractions, but custom mini-languages with no specification masquerading as the original language by redefining basic primitives, a dependency hell to arbitrary and non maintained weekend projects someone dumped on github, which would have been easy to write in terms of the standard library - if only the original author knew its capabilities - but now they must be reverse-engineered from context etc. The maintainer is not ready for a paradigm shift because they will not own your program in perpetuity. Even you yourself ran away and abandoned it, so how can you expect someone else to love it more? No, the maintainer has a limited time and attention span to work on a specific bug or feature, and your code is either maintainable or it's not.

Pannoniae 3y ago
I think you assume that the choice is between "good, idiomatic code" and "non-idiomatic, horrible, abandoned mess". Most of what you said are problems with simply not documenting code and writing code well enough; being idiomatic slightly helps in that by making it more familiar, but that's just a masking of the fact that the program is written horribly with no documentation. Libraries like language-ext are absolutely not "badly chosen abstractions" or "dependency hell". Also, "your code is either maintainable or it's not." is heavily subjective. Maintainability is often also used to criticise stylistic choices like variable naming, tabs vs. spaces, brace placement and other things which might be non-standard but don't detract from readability at all. If it did, there wouldn't be so many different standards across languages.
- cornholio 3y ago
  The basic idea is that, keeping all other things constant, the code with the least surprises and paradigm shifts is the more maintainable one, because almost all code innovations have a learning curve that pays back the more you use the concept. The maintainer is by definition on the losing end of that tradeoff, because they have to learn lots of things about your code and have limited opportunities to apply that learning. So poor code without surprises is much better than poor code that tries to take you outside of your comfort zone.
  - Pannoniae 3y ago
    But it also raises the average software quality by educating the maintainer. If all you do is write Python the same way your entire life, your code quality won't be that great. This is a fairly small sacrifice for a greater societal gain.
    - c_crank 3y ago
      Python itself was designed with the intent of pressuring programmers to write Python in one specific way. The problems that crop up in large Python codebases are probably the result of using Python outside of its intended scope of scripting and toy programs.
      - Pannoniae 3y ago
        Yes. But people do use (or more like, misuse) Python for different things such as large systems. In cases like that, others still scream about "pythonicity" and "idiomaticness" just for the sake of language policing, even if those guidelines make zero sense. I had the misfortune of using Python for.... larger systems than it was intended for, and the code reviewer basically screamed at me for daring to use staticmethods instead of free-floating functions. Even though it was an internal implementation detail and it was exactly the point that the function itself shouldn't be discoverable if you import the file. But convention and being pythonic trumps everything... So yes, I think that people who criticise others for not writing "idiomatic" code just want to nitpick most of the time.