magic_lobster_party

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

help-circle

  • It’s generally considered a fact that Linux, along with many other open-source software projects, are more efficient than their propriety closed-source counterparts

    This is not necessarily true. Linux had trouble with Nvidia Optimus, which is a GPU technology that seamlessly switches between power modes. Well, that is if it works properly, which it didn’t for Linux. I haven’t heard it in a while, so I assume it’s not a problem now anymore.

    But it was a big problem where Linux laptops drained batteries much faster because they were using the GPUs at max capacity at all times.

    What I’m saying is that the efficiency of Linux depends on access to hardware features, and that might depend on the vendors of the drivers.

    Also, like it or not, if there’s one thing I envy about Mac is its power efficiency. They usually last really long on one charge.








  • 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.







  • Hate is a strong word.

    I have a dislike for them. Especially in recent years. There was a time I thought they were the cool hip company with lots of cool innovations. When Google docs launched it was so revolutionary that two people could work with the same document at the same time.

    Now I see them more for what they are: an advertisement provider. They’re only after our data. Once I realized that my dislike for them grew.

    But my dislike for them hasn’t been enough to stop using their products. I’ve tried DDG a few times, but I’ve always been dissatisfied with their results.