5 ms·

Concatenating all the functions flat into one file can work for quick prototypes, but when you reach 1-2k LOC, you need to start abstracting things to keep it m

• beaconstudios 6y ago
  That's very true, but OOP just isn't a very good method of abstraction. Keeping data and code separate permits much more flexibility.
  • snovv_crash 6y ago
    It all depends how much state you need to manage, and how persistent it needs to be. What works in an image processing pipeline doesn't work in a web server, and what works there doesn't work in an autopilot.
    • beaconstudios 6y ago
      I'm usually not one to talk in absolutes, but I'm near certain that procedural or functional programming beat OOP every time. The idea of hidden/encapsulated state just hurts flexibility - where OOP shines is when you have an army of junior developers and you want to encapsulate state and provide rigid interfaces so that mistakes are harder to make.
      • snovv_crash 6y ago
        Some amount of hiding state makes APIs easier to use though. Keeping data structures coherent, for example, means you need to only interact with them through the provided interfaces. This also means that you could internally change the data structures (eg. from deque to ring buffer) and not expose the implementation details to the outside world, causing downstream breakages. What you describe makes sense for small components built by a small, tightly knit and highly skilled team. The issue is that at some point the software grows enough that you can't hold the whole thing in your head at once, or you need to make it reusable to external developers.