4 ms·

Do not be fooled into thinking, "The language made me do it" when the culture that surrounds the language made you do it. Different technologies have cultures b

Do not be fooled into thinking, "The language made me do it" when the culture that surrounds the language made you do it. Different technologies have cultures brought on by often self-appointed leadership figures, even anonymous ones. Those leadership figures can popularize abuse by convincing others that it's a well-established cultural norm, simply because we tend to loathe non-conformity. Third-party frameworks are often used to establish one's self as a leader and establish abusive practices. Once the foothold is firm, it becomes literally "The framework made me do it." Cultural norms mandate the framework, and the framework forces the abuse. If anyone protests about the consequences of abuse, blame is redirected back at the language. To any onlooker, the consensus seems clear: Your language sucks! Those same onlookers are happy to reinforce this perception because they are busy trying to establish competing cultures & leaders of their own. "You should try my language!" Of course their primary goal is not to help, but to improve their own status by rising the tide and lifting their own boat. If they wanted to really help, they would work on establishing better culture instead of jockeying for popular culture.

Jtsummers 5y ago
Don't be fooled into thinking it's either one or the other. In reality, most of these kinds of things are a combination of social and "physical" systems. "physical" because while programming languages aren't technically physical entities, they still have their own kind of physics and paths of least resistance that people will tend to follow.
throwaway894345 5y ago
100%. Recently I've been frustrated with the Python ecosystem and how many "object oriented" libraries there are which can't easily be tested because of all of the weird shit their constructors do (most recently, the class I'd like to test just builds JSON documents and sends them to an API, but the constructor hard-codes the HTTP client so you have to use magic to swap the hard-coded client with a mock). Of course, someone will come riding in to defend OOP with "that's not true OOP" and another will come riding in to defend Python with "you can write bad code in any language!", both of which miss the point: this sort of thing is much more prevalent in the Python ecosystem than, say, the Go ecosystem or the Rust ecosystem precisely due to culture. And by the way, I'm sure there are lots of other languages that have a culture of poor programming practices--the intent here isn't to pick on Python (I've used it professionally for 15 years).
- deleted 5y ago
  [deleted]
- AmpsterMan 5y ago
  I wonder to what extent these problems have to do with OOP being poorly defined vs poorly understood vs poorly implemented.
- throwaway894345 5y ago
  By the way, if anyone is curious what a really terrible constructor looks like: https://github.com/jupyterhub/kubespawner/blob/81e6059a1481138d27d0d3c32f403ecd21d576d8/kubespawner/spawner.py#L157-L228 https://github.com/jupyterhub/kubespawner/blob/81e6059a14811... ^ I'm also curious to hear from people whether this kind of design is "OOP" or not, or if there are any good terms for talking about this particular antipattern.
  - blandflakes 5y ago
    I'm not really an OOP or Python defender, and generally agree that this type of constructor is inscrutable, frustrating, and quite common in the Python ecosystem. That said, I would not consider default mock values in a constructor to be good OOP. In general, "new"ing things in a constructor IMO is a no-go and makes for harder testing and confusing behavior. At the end of the day I'm not even sure why this class supports mock behavior. I'd expect two separate classes with divorced implementations, instead of an if statement on a boolean param.
- lamontcg 5y ago
  "Don't do work in the constructor" is an OOP principle that must be decades old. The problem with Python and Ruby is that being dynamic it makes them real easy to do highly lightweight OOP. There's just a cultural disconnect in the OO world where once you get past objects wrapping data the design patterns tend to come from the Java world and quickly descend into explaining dependency injection containers that nobody uses in Python or Ruby. There's a bit of a cultural middle ground which is not well defined due to the history of how it all evolved.
- 5y ago
marcosdumay 5y ago
What good is a good language if you can't learn anything from other people, use any common library, or collaborate with anybody without bad practices contaminating your work? They are different phenomena, but every practical consequence is the same. Including what you must do to avoid the problems.
- kerblang 5y ago
  Pragmatically speaking, yes, and this is the most important thing: The language eventually becomes a lost cause, regardless of where the finger of blame points. Worst of all, programming language evolution runs in circles as people invent & seek out regressive anti-languages in reaction to the misapprehension of blame.
l0b0 5y ago
Some examples of common cultural (that is, completely avoidable) antipatterns: - LISP dialect devs insisting on using incredibly obscure technical abbreviations for important names, like car/cadr/cdr instead of first/second/rest or something else human readable. - POSIX-ish shell standardizers and builders making it really difficult to deal with anything but ASCII alphanumeric filenames. Saying "You shouldn't put special characters in filenames!" isn't helpful if I'm trying to make a script to support other people's filenames. - C-style language makers' insistence on terminating statements with semicolon, so that a tiny fraction of multi-line statements can be shortened to one line. - Python devs treating time-zone-less datetimes as not an atrocity, for example in utcnow. - Nix, well, being generally incredibly hard to read and learn, even after about 20 other languages. I hope somebody goes ham on that language and creates a thoroughly backwards incompatible implementation of the fantastic ideas behind it. I guess I've pissed off the entire internet now, but remember that these are my gripes, not some absolute truths I'm trying to convince y'all of.
- spicybright 5y ago
  These are amazing points, #2 being one of the biggest peeves.
- TheMonarchist 5y ago
  > terminating statements with semicolon Line wrapping would be unacceptable without this.
ozfive 5y ago
This needs to stay the top comment here as there are many truths in this comment.

Jtsummers 5y ago

Don't be fooled into thinking it's either one or the other. In reality, most of these kinds of things are a combination of social and "physical" systems. "physical" because while programming languages aren't technically physical entities, they still have their own kind of physics and paths of least resistance that people will tend to follow.

throwaway894345 5y ago

100%. Recently I've been frustrated with the Python ecosystem and how many "object oriented" libraries there are which can't easily be tested because of all of the weird shit their constructors do (most recently, the class I'd like to test just builds JSON documents and sends them to an API, but the constructor hard-codes the HTTP client so you have to use magic to swap the hard-coded client with a mock). Of course, someone will come riding in to defend OOP with "that's not true OOP" and another will come riding in to defend Python with "you can write bad code in any language!", both of which miss the point: this sort of thing is much more prevalent in the Python ecosystem than, say, the Go ecosystem or the Rust ecosystem precisely due to culture. And by the way, I'm sure there are lots of other languages that have a culture of poor programming practices--the intent here isn't to pick on Python (I've used it professionally for 15 years).

deleted 5y ago
[deleted]
AmpsterMan 5y ago
I wonder to what extent these problems have to do with OOP being poorly defined vs poorly understood vs poorly implemented.
throwaway894345 5y ago
By the way, if anyone is curious what a really terrible constructor looks like: https://github.com/jupyterhub/kubespawner/blob/81e6059a1481138d27d0d3c32f403ecd21d576d8/kubespawner/spawner.py#L157-L228 https://github.com/jupyterhub/kubespawner/blob/81e6059a14811... ^ I'm also curious to hear from people whether this kind of design is "OOP" or not, or if there are any good terms for talking about this particular antipattern.
- blandflakes 5y ago
  I'm not really an OOP or Python defender, and generally agree that this type of constructor is inscrutable, frustrating, and quite common in the Python ecosystem. That said, I would not consider default mock values in a constructor to be good OOP. In general, "new"ing things in a constructor IMO is a no-go and makes for harder testing and confusing behavior. At the end of the day I'm not even sure why this class supports mock behavior. I'd expect two separate classes with divorced implementations, instead of an if statement on a boolean param.
lamontcg 5y ago
"Don't do work in the constructor" is an OOP principle that must be decades old. The problem with Python and Ruby is that being dynamic it makes them real easy to do highly lightweight OOP. There's just a cultural disconnect in the OO world where once you get past objects wrapping data the design patterns tend to come from the Java world and quickly descend into explaining dependency injection containers that nobody uses in Python or Ruby. There's a bit of a cultural middle ground which is not well defined due to the history of how it all evolved.
5y ago

marcosdumay 5y ago

What good is a good language if you can't learn anything from other people, use any common library, or collaborate with anybody without bad practices contaminating your work? They are different phenomena, but every practical consequence is the same. Including what you must do to avoid the problems.

kerblang 5y ago
Pragmatically speaking, yes, and this is the most important thing: The language eventually becomes a lost cause, regardless of where the finger of blame points. Worst of all, programming language evolution runs in circles as people invent & seek out regressive anti-languages in reaction to the misapprehension of blame.

l0b0 5y ago

Some examples of common cultural (that is, completely avoidable) antipatterns: - LISP dialect devs insisting on using incredibly obscure technical abbreviations for important names, like car/cadr/cdr instead of first/second/rest or something else human readable. - POSIX-ish shell standardizers and builders making it really difficult to deal with anything but ASCII alphanumeric filenames. Saying "You shouldn't put special characters in filenames!" isn't helpful if I'm trying to make a script to support other people's filenames. - C-style language makers' insistence on terminating statements with semicolon, so that a tiny fraction of multi-line statements can be shortened to one line. - Python devs treating time-zone-less datetimes as not an atrocity, for example in utcnow. - Nix, well, being generally incredibly hard to read and learn, even after about 20 other languages. I hope somebody goes ham on that language and creates a thoroughly backwards incompatible implementation of the fantastic ideas behind it. I guess I've pissed off the entire internet now, but remember that these are my gripes, not some absolute truths I'm trying to convince y'all of.

spicybright 5y ago
These are amazing points, #2 being one of the biggest peeves.
TheMonarchist 5y ago
> terminating statements with semicolon Line wrapping would be unacceptable without this.

ozfive 5y ago

This needs to stay the top comment here as there are many truths in this comment.