💾 Archived View for soviet.circumlunar.space › zwatotem › diff › dependencies.gmi captured on 2023-07-10 at 13:44:02. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-06-14)
-=-=-=-=-=-=-
It's been a while since I last showed my thoughts on system design. And since then - I had many - to the point that I don't know, if I'll be able to recall and express then all in one sitting. First - I took a peek into the design of various programming languages, notably F# is the one that I learned in deep, but looked at a few others as well. I've also listened to many talks that compare functional languages and functional design to object orientation and procedural paradigm. The main difference that is being pointed out is immutability, which I feel is very weird. While immutability is the quality that you will inadvertly see in functional programs it's by no means the most important. Things like pureness of functions and separation of data and operations are in my opinion some of the more meaningful qualities of functional design.
For a while, it now seems, object oriented programming has been criticised for binding data models with behaviour. The reasoning given for this is two in big systems data can be involved in a very big amount of operations across different unrelated areas of the application. Additionally it's often brought that if you create a library with some kind of data in it, the set of operations that can be conducted on that data is pretty much sealed for anyone who'd want to extend its functionality. Except it's not. Object oriented programming went in a strange direction. Not being able to extend operations on data through first party member functions, people started packing the functionality to external classes, creating my most hated kind of design which is manager classes. At this point classes become merely sacks for functions, with no internal state.
This is the point, where functional people are coming in very often, saying: "See? You have to create a class, and give it a method to do anything. In the meantime I just create a function". But "OOP" invented also some things that I like. Polymorphism is a very powerful mechanism. It's the first step to generic programming. Having an abstraction over a number of data types greatly increases productivity of the programmer and clearness of the code. In my work, where I use C#, I don't actually get to see that much of it though. Glorious inheritance hierarchies that I learned to love in my early education are gone missing, never to be found again. I think, that the capabilities of multiinheritance that Java and C# given up on so easily have just too much potential. The fact that both of them later added default implementations for interfaces shows that very well.
But anyway, that design still stuck, and now every Java/C# programmer will tell you to not use inheritance at all, but create interfaces and implement them. This mantra had so hard influence (along with testability excuses) that it is common practise to create a pair of class and interface even if that class will forever be the lone implementation, and of course the class has no state and only one method. In the meantime functional people are laughing, having to write only one function to get the same result.
That's why I consider what I call "modern OOP" unnecessarily complicated. I say "modern OOP", because allegedly the original object-oriented programming in smalltalk is something completely different and it's reportedly significantly better, but that's still for me to check out.