3 ms·

Structural inspection is sometimes a very good test idea, especially in a dynamically typed language like Python. For example, a certain class might get dynami

by mlthoughts2018 8y ago

Structural inspection is sometimes a very good test idea, especially in a dynamically typed language like Python. For example, a certain class might get dynamically enhanced with extra methods or extra structure at run time, depending on some config or something. I’ve found many examples like this where needing to conform the design to a static typing compiler would be a huge waste of time and involve some stupid pile of abstraction that is totally inappropriate for the problem. Instead, there may be 3 or 4 highly controlled “mix-in” options (where the choice of mix-in happens at run time and is dynamically modified or configurable), and it’s perfectly safe to write it with monkey-patching or dynamically defining a class with type(...). In the unit tests, you may sincerely want to verify that if the system is fed config that should cause some new data members or functions to be monkeypatched into some instances, that it does in fact cause this to happen. I think the point is that in some languages, the structure of the program is itself customizeable or modifiable and so there are functions whose unit of work is to effect that modification, and those functions need to be tested too. Some examples might be checking that a certain class instance gets endowed with a specialized context manager implementation or special data model overrides or special iteration behavior. I’ve experienced many cases where statically typed languages inherently disallow this as a possibility, and you end up having to engineer huge multiple-dispatch structures and highly genericized interfaces to get a similar effect of dynamically selecting structure at run time, and often that big pile of abstraction is hugely limiting and disallows you from efficiently making big changes to it, even in cases when the programmer really can guarantee safety and limits on complexity for their special use case.

mistrial9 8y ago
extensive OO gymnastics is an acquired taste, and best practiced by someone who is willing to deal with the dynamic mess that will inevitably result in a mature code base. Nothing you say is wrong, yet none of this is necessary to solve the vast majority of actual problems.
- mlthoughts2018 8y ago
  I’d say the static typing analogue to the workflow I described is perhaps the canonical OO gymnastics and leads to much worse messes, thoughtless regurgitation of “design patterns” and wasted hours getting some tower of abstraction in place for something that you can just do in dynamic languages and make it perfectly safe and move on. “The dynamic mess” is mostly a myth we tell ourselves because many dominant languages are predicated on there needing to be actual material benefit to type safety. In reality, bad use of abstraction will cause a mess no matter which paradigm you use, but dynamic languages at least give you the option to eschew the bullshit and just solve the problem, while many mainstream statically typed languages, even functional languages, just give you pattern recipes that gaurantee you’ll get lost in a sea of value-destructive abstraction and end up using a bazooka for every nail.
  - clhodapp 8y ago
    That hasn't been my experience at all. Indeed, I have gone found static typing to give me superpowers by letting me quickly see what kinds of data and transformations I have access to, constraining out possibilities that I'd otherwise need to test for, and codegenning away boilerplate.
    - mlthoughts2018 8y ago
      A good example of why your experience doesn’t generalize is to compare the severe limitations of breeze linear algebra for Scala with numpy in Python. Breeze’s type safety creates this utterly needless hierarchy of abstraction that severely handicaps you from doing advanced elementwise operations, particularly with automatic broadcasting. With ndarrays in numpy, you can pretty do whatever crazy beoadcasted operations you want with no restriction on manually promoting things to “the right” shape or type. Breeze gives you “safety” at the cost of not being able to do anything with it, and requiring huge pains to refactor generic code to add functionality. I find this is exactly have it plays out with most large statically typed systems, even with fancy type class patterns in FP.

mistrial9 8y ago

extensive OO gymnastics is an acquired taste, and best practiced by someone who is willing to deal with the dynamic mess that will inevitably result in a mature code base. Nothing you say is wrong, yet none of this is necessary to solve the vast majority of actual problems.

mlthoughts2018 8y ago
I’d say the static typing analogue to the workflow I described is perhaps the canonical OO gymnastics and leads to much worse messes, thoughtless regurgitation of “design patterns” and wasted hours getting some tower of abstraction in place for something that you can just do in dynamic languages and make it perfectly safe and move on. “The dynamic mess” is mostly a myth we tell ourselves because many dominant languages are predicated on there needing to be actual material benefit to type safety. In reality, bad use of abstraction will cause a mess no matter which paradigm you use, but dynamic languages at least give you the option to eschew the bullshit and just solve the problem, while many mainstream statically typed languages, even functional languages, just give you pattern recipes that gaurantee you’ll get lost in a sea of value-destructive abstraction and end up using a bazooka for every nail.
- clhodapp 8y ago
  That hasn't been my experience at all. Indeed, I have gone found static typing to give me superpowers by letting me quickly see what kinds of data and transformations I have access to, constraining out possibilities that I'd otherwise need to test for, and codegenning away boilerplate.
  - mlthoughts2018 8y ago
    A good example of why your experience doesn’t generalize is to compare the severe limitations of breeze linear algebra for Scala with numpy in Python. Breeze’s type safety creates this utterly needless hierarchy of abstraction that severely handicaps you from doing advanced elementwise operations, particularly with automatic broadcasting. With ndarrays in numpy, you can pretty do whatever crazy beoadcasted operations you want with no restriction on manually promoting things to “the right” shape or type. Breeze gives you “safety” at the cost of not being able to do anything with it, and requiring huge pains to refactor generic code to add functionality. I find this is exactly have it plays out with most large statically typed systems, even with fancy type class patterns in FP.