• 0 Posts
  • 6 Comments
Joined 2 years ago
cake
Cake day: August 14th, 2023

help-circle


  • For me, the more relevant adage here is “a bad abstraction is worse than no abstraction”.

    IMO many abstractions in Java are terrible in this regard, either via commonly proliferated patterns or via language design issues. Abstractions large and small are all forcibly locked into place very early on in the name of formalism and safety, ultimately leaving us with poor versions of the former and weakened versions of the latter. Where is “encapsulation” when certain classes only work when hooked up in very particular ways to other distant classes? Where is “type safety” when certain methods simply raise “not implemented for this sub/super-type”?

    These faults are often hand-waved as “all ecosystems have rough patches”, but my point is that Java’s bad abstractions in particular are supremely more stubborn and persistent in comparison with other ecosystems. I understand many consider this a strength aka stability, but IMO at the extreme being unable to shed the past means negatively hindering progress. I think modern Java versions show a budding shift in mentality, but I’ve already moved on – it’s just not for me.



  • IMO it’s time for a reckoning of what’s systematic/automated vs what’s not.

    For example, “no expectation of privacy in public” meant you should be okay with appearing in someone else’s (manual) photo while out in public. However, I don’t think that should extend to persistent systematic surveillance, e.g. suppose every Tesla’s camera captures were combined with person recognition systems and tracking.

    Just because something is theoretically okay at a small scale doesn’t mean the same applies at large scales.

    Another example: Society funds public roads via government taxes for personal use and for regulated commercial use. Uber systematically consumes public road space under the guise of personal use vehicles, for commercial use.


  • You’re getting a lot of conceptual definitions, but mechanically, it’s just:

    keeping state (data) and behavior (functions) that operate on that state, together

    At minimum, that’s it. All the other things (encapsulation, message passing, inheritance, etc) are for solidifying that concept further or for extending the paradigm with features.

    For example, you can express OOP semantics without OOP syntax:

    foo_dict.add(key, val)  # OOP syntax
    
    dict_add(foo_dict, key, val)  # OOP semantics