3 ms·

It's also a counterpoint to "but it's doing a complicated job so the UI has to be complicated" nonsense defence that gets brought up in FreeCAD's defence a lot.

lelanthran 4y ago
> It's also a counterpoint to "but it's doing a complicated job so the UI has to be complicated" nonsense defence that gets brought up in FreeCAD's defence a lot. That defence is used for $SUPERIOR_LANGUAGE too. Look at the large numbers of devs who feel that the extra cognitive load needed to learn (for example) monads is worth it. Or the large number of posts explaining Rusts syntactical mess as "It's doing a complicated job so the interface has to be complicated." Hell, nevermind languages, that argument gets thrown across the entire tech stack - the submission yesterday about complexity had a number of posters who felt that there's no additional complexity in using Kubernetes even for an application that never needs to scale horizontally! Is it any surprise then that we see the same argument for different tech, even though it's a clearly invalid argument 99% of the time.
- regularfry 4y ago
  No, it's not surprising. It's a failure of abstraction design. But that's ok, designing a good abstraction that correctly hides things that can be hidden, in a composable, comprehensible way, is a really, really hard job. It's ok to fail at that. What's not ok is denying that failure and gaslighting users into self-blame while preventing trying something better.
  - lelanthran 4y ago
    > What's not ok is denying that failure and gaslighting users into self-blame while preventing trying something better. Forgive me, I wasn't attempting to imply that the practice is okay. I was just pointing out that the practice is normal, across the entire tech stack. It is common for people to reject high-cognitive load stuff, and at this point it is common to have others jump in with "they're dinosaurs resistant to change", "Every $TECH has a learning curve" or similar stuff.
    - regularfry 4y ago
      No worries, we're vigorously agreeing :-)

lelanthran 4y ago

> It's also a counterpoint to "but it's doing a complicated job so the UI has to be complicated" nonsense defence that gets brought up in FreeCAD's defence a lot. That defence is used for $SUPERIOR_LANGUAGE too. Look at the large numbers of devs who feel that the extra cognitive load needed to learn (for example) monads is worth it. Or the large number of posts explaining Rusts syntactical mess as "It's doing a complicated job so the interface has to be complicated." Hell, nevermind languages, that argument gets thrown across the entire tech stack - the submission yesterday about complexity had a number of posters who felt that there's no additional complexity in using Kubernetes even for an application that never needs to scale horizontally! Is it any surprise then that we see the same argument for different tech, even though it's a clearly invalid argument 99% of the time.

regularfry 4y ago
No, it's not surprising. It's a failure of abstraction design. But that's ok, designing a good abstraction that correctly hides things that can be hidden, in a composable, comprehensible way, is a really, really hard job. It's ok to fail at that. What's not ok is denying that failure and gaslighting users into self-blame while preventing trying something better.
- lelanthran 4y ago
  > What's not ok is denying that failure and gaslighting users into self-blame while preventing trying something better. Forgive me, I wasn't attempting to imply that the practice is okay. I was just pointing out that the practice is normal, across the entire tech stack. It is common for people to reject high-cognitive load stuff, and at this point it is common to have others jump in with "they're dinosaurs resistant to change", "Every $TECH has a learning curve" or similar stuff.
  - regularfry 4y ago
    No worries, we're vigorously agreeing :-)