3 ms·

Conversely, your approach has been used to justify the most abhorrent programming practices even perpetrated on mankind. What you get are not carefully chosen a

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.

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.