magic_lobster_party

  • 0 Posts
  • 43 Comments
Joined 1 year ago
cake
Cake day: March 4th, 2024

help-circle







  • Haven’t properly watched the videos, but I don’t think OOP is that bad. I even think encapsulation is one of the core strengths of OOP.

    I’ve worked with systems where no thought was put into encapsulation, and those are often incredibly difficult to work with because everything is heavily interconnected. Can’t make a change in a small thing without risking breaking something else at the other side of the program.

    I like to see encapsulation as a workspace. It defines the tools we have direct access to. Changing one thing in a workspace shouldn’t affect anything on the other side of the program. Makes it much easier to collaborate in large teams. Minimizes the risk of interfering each other’s work.



  • I think applying design patterns blindly without understanding what problems they’re supposed to solve is often more harmful than not using them. It can lead to difficult to manage code bases because the program is over engineered for problems that don’t exist.

    My general rule of thumb is to write code that can be easily adapted to unexpected changes in requirements. Avoid writing code that paints yourself into a corner. Simple solutions are often easier to work with than complex solutions. If what you’re doing adds a lot of complexity, take a step back and seek other options. Maybe you’re overlooking an obviously simple solution to the problem?

    I think inheritance almost always has this “painting yourself into the corner” tendency. Once the design is set, it’s often difficult to break free from it. Composition along with interfaces is generally the better choice. Often not even interfaces are needed.

    This comes with experience. You learn what works, and what doesn’t. Often you do it the hard way.

    Databases are tricky. I have no good advice for that.







  • Even if a fix was discovered quickly it wouldn’t prevent the problem that it must be manually fixed on each computer. In this case a fix was discovered quickly even without access to source code.

    Just having more eyes on the source code won’t do much. To discover errors like these the program must be properly tested on actual devices. This part obviously went wrong on Crowdstrike’s side. Making the code open source won’t necessarily fix this. People aren’t going to voluntarily try every cutting edge patch on their devices before it goes live.

    I also doubt any of the forks would get much traction. IT departments aren’t going to jump to the next random fork, especially when the code has kernel access. If we can’t trust Crowdstrike, how can we trust new randos?



  • AFAIK, the documentation isn’t the main problem. I’m pretty sure PS3 is quite well understood.

    The problem is how to translate the code to a typical X86 architecture. PS3’s uses a very different architecture with a big focus on their own special way on doing parallelism. It’s not an easy translation, and it must be done at great speed.

    The work on RPCS3 incredible, but it took them more than a decade of optimizations to get where they are now. Wii U emulation got figured out relatively quickly in comparison, even if it uses similar specs to PS3.