• 0 Posts
  • 250 Comments
Joined 1 year ago
cake
Cake day: July 18th, 2023

help-circle
  • No, boycotts are not a corporate death knell. No one is saying that. LITERALLY no one is saying their personal decision or reasoning is the cause of this news.

    EVERYONE ks pkinting at shitty things Ubisoft does, says, it caused them to not bjy it and likely is impacting others’ decisions… then you come along going, “NUHUH NUHUH, Ubisoft isn’t losing money because YOU didn’t buy it!”

    My dude… we FUCKING KNOW THAT!! We’re saying UBISOFT shot themselves in the foot with shitty behavior. This article is literally about the effects of people not buying en masse, and you’re saying that the NEWS WE ARE READING is not possible…

    Just stop. Just stop. Boycotts most often do not work, but THIS IS NOT A BOYCOTT!! This is people explaining why they stopped giving Ubisoft money. Holy fuck, you are good at doubling down on a bad idea.





  • MotoAsh@lemmy.worldtoCasual UK@feddit.uk*Sigh*
    link
    fedilink
    English
    arrow-up
    2
    arrow-down
    3
    ·
    edit-2
    24 days ago

    No, a dove is not ‘a’ pigeon. A dove is in the pigeon family. Your cousin is NOT your brother … because they’re not your brother.

    They may have been condescending (quoting a mildly modified copypasta they linked), but the explanation is very clear until the end. Do not insult knowledge with obstinance simply because you were called wrong. That is beyond pathetic and insults knowledge itself.








  • IMO, “One app/library/etc does one thing only” is a rather ignorant form of wisdom about encapsulation, anyways.

    Encapsulation is important regardless of how many disparate tasks a library handles. Doing one thing with one thing is a pretty good rule of thumb to get close to good results, but it is FAR from a golden standard, and serves to drag people away from the finer nuances of encapsulation.

    The ONLY time it is a hard and fast rule is at the individual function level. A single function ideally should have one task to accomplish, even if that task has side effects.

    I’m sure there are cross-dependency issues on an OS level that makes it a bit wiser to do for wide, cross-cutting system tasks, but to make it an absolute rule smacks of wisdom gone awry.









  • IMO, the most important parts are to document the actual intent of the code. The contract of what is being documented. Sure, it’s only so useful in perfectly written code, but NO code is perfect, and few will come through later with full context already learned.

    It makes it sooo mich easier to know what is intended behavior and what is an unchecked edge case or an unexpected problem. If it’s a complicated thing with a lot of fallout, good documentation can save hours of manually lining up consequences and checking through them for sanity.

    You might say, “but that’s indication of bad code!”. No. Not really. Consequences easily extend past immediate code doing things as trivial as saving data to the database without filtering, or having a publicly available service. Even perfectly coded things come up with vulnerabilities all the time due to underlying security issues. It’s always great to have an immediate confirmation of what’s supposed to happen whether it’s immediate code or some library with a new quirk in a new version.