• 0 Posts
  • 10 Comments
Joined 5 years ago
cake
Cake day: May 31st, 2020

help-circle
  • My pet theory is that our brain rewards us for interpreting clues correctly, because this is crucial for survival. And patterns make it easy to do this interpretation correctly, therefore triggering the reward system frequently.

    But if it is too easy to interpret a pattern correctly, the reward will be lessened, because the challenge you succeeded in was lesser. And it was also crucial to survival to fade out patterns which don’t change, so that e.g. the wind brushing through leaves doesn’t drown out the noises from a predator approaching.

    That’s why patterns which don’t change every so often stop triggering the reward system and therefore bore us.


  • Well, the writing-part isn’t the bad part about duplicated code. It’s the maintaining of it. In particular, if you duplicate logic, it happens all too quickly that you make modifications to one, but not the other, or you make differing modifications to both.

    Eventually, you’ll end up with two wildly different versions, where you won’t know why certain changes were made and not applied to the other version. Similarly, if you do need to make a similar change to both, you might now need to implement it two times.

    I guess, I do agree that it isn’t *always* worth it, but in my experience, it is far more often worth it than one might think.





  • You can check whether you’re clean with a toilet paper, if you’re unsure. But I did so a few times at the beginning and never had stained toilet paper (so long as I didn’t stick it inside, I guess), so I don’t bother anymore.

    In particular, you also feel cleaner when you regularly use a bidet (like you’re freshly showered), so that also makes it easier to feel when you aren’t clean…




  • The thing with OOP, particularly how it’s used in GCed languages, is that it’s all about handing references out to wherever and then dealing with the complexity of not knowing who has access to your fields via getters & setters, or by cloning memory whenever it’s modified in asynchronous code.

    Rust has quite the opposite mindset. It’s all about tracking where references go. It pushes your code to be very tree-shaped, i.e. references typically¹ only exist between a function and the functions it calls underneath. This is what allows asynchronous code to be safe in Rust, and I would also argue that the tree shape makes code easier to understand, too.

    But yeah, some of the patterns you might know from OOP will not work in Rust for that reason. You will likely need to get into a different mindset over time.

    Also just in case: We are talking OOP in the sense of the paradigm, i.e. object-oriented.
    Just using objects, i.e. data with associated functions/methods, that works completely normal in Rust.

    ¹) If you genuinely need references that reach outside the tree shape, which is mostly going to be the case, if you work with multiple threads, then you can do so by wrapping your data structures in Arc<Mutex<_>> or similar. But yeah, when learning, you should try to solve your problems without these. Most programs don’t need them.