Wasted 10 years programming because of OOP.
Better late than never. Just use function and what you need is really just Data structure + Algorithm.
DDD, Design patterns,.. or complicated things just born to fix the OOP methodology.
Better late than never. Just use function and what you need is really just Data structure + Algorithm.
DDD, Design patterns,.. or complicated things just born to fix the OOP methodology.
DDD is not inherently tied to OOP: the whole strategical part isn’t about code at all, and the tactical part is applicable to FP as much as to OOP.
WRT design patterns, they exist in functional programming as well, they’re just different.
Nowadays there are even resources about DDD specific to the FP world, such as Domain Modeling Made Functional by Scott Wlaschin [0].
[0] https://pragprog.com/titles/swdddf/domain-modeling-made-func...
And Context (at least in my humble experience). Lately I got rid of OOP too and now all my functions accept `params` as a first argument which contains settings and the state of an object/subserver/etc. I find the ability to group functions into different files useful though (it’s js so I cannot do that like one does in c++).
Lets hope your not in charge of building that new complex air traffic control system, bank lending system, or large inventory management system.
Did you learn nothing of over a decade of large projects using data-flow modeling (structured analysis)?
When in fact you can have architecturally separated modules without objects just fine, and all objects bring is the complexity of finite state machines talking to each other via complex message protocols.
Sometimes you indeed need some virtual dispatching, but most of the time procedure is a better abstraction, and function is even better. Instead of making complex parts of the system simpler, OOP usually makes simple parts complex.
Hence the need for frameworks. In functional or procedural worlds people just take libraries and glue them together. In OOP world it's nearly impossible because of how complicated object protocols are, so if you have objects from different libraries, you'll most likely need to write lots and lots of facades. Hence OOP evolved towards megalibraries which have it all.
> Lets hope your not in charge of building that new complex air traffic control system, bank lending system, or large inventory management system.
Many of these are doing fine being written in procedural style though.
That's not a direct result of OOP. Languages can have extension functions or type classes or delegation to address this. And it's not like the problem magically goes away for procedural code.
It's actually the core definition of objects. Objects are entities supporting open recursion, self-polymorphism and late binding.
There is a difference between "having type-classes" and "having object as a core formalism of computation"
> Languages can have
Languages can have objects, or actors, or other entities alike. This doesn't mean it's prudent to design your code around the idea of message-exchanging FSMs. Sometimes at some scale objects or actors are useful.
> And it's not like the problem magically goes away for procedural code.
This is empirically not true, and the frameworks example is the best proof of it. In languages like (functional) Scala, Go, OCaml, libraries do compose well enough, and gluing them is cheap.
Any hardcore OOP language eventually brings frameworks like Spring, Rails, etc, because gluing objects is expensive, and for no reason, if functional/procedural alternative is so much cheaper. Even natural transformations between monads are very cheap compared to objects' composition.
This Kay-esque focus on _messages_ has fudded the OO space for too long now. The so called "magical view" of OO - "it's all about messages".
The actual original inventors saw an object as a representation of a phenomena, real or imagined. They (particularly Kristen Nygaard) sought a way to model phenomena, concepts and the interactions between them. Consider that this is the design viewpoint that Bjarne Stroustrup actually sought to add to the C language. Step back from a focus on state machines, message protocols and a technical plumbing viewpoint.
FP has its place, particularly where the focus is on the transformation of data. But don't extrapolate that as applicable to all types of computing application.
As I mentioned elsewhere, the predominant design paradigm for large complex projects outside of computing and the data sciences for over a decade was Structured Analysis. That involved data modeling and typically separately modeling the functional processes that modified that data. Did we learn anything?
Sure, people nowadays tend to prefer writing procedural/functional code in OO languages, using objects as mere modules.
> But don't extrapolate that as applicable to all types of computing application.
Any formalism can be used for any kind of computation. Actors, objects or lambda calculus/simple referentially transparent FP lang are interchangeable. The only difference is the latter is the simplest, hence easier to reason about and compose. But any kind of system can be built on top of any of these.
> As I mentioned elsewhere, the predominant design paradigm for large complex projects outside of computing and the data sciences for over a decade was Structured Analysis.
This is not a paradigm, that's a methodology, and it's totally unrelated to what kind of language paradigm is used, or to original take about "programs = algorithms + data structures". Besides, most modern reactive systems are built on top of something like RX or Akka streams anyways, and functional in principle.
Functional programming in aviation: https://m.youtube.com/watch?v=0x3EIqBrZxw
Functional programming in banking: https://www.finextra.com/newsarticle/36297/nubank-buys-firm-...
Except for things like React which are more or less functional reactive programming, but in case of react its stateful. Functional reactive programming exist, and GUI is not obliged to be OO
Another big Clojure UI/graphics framework is Quil, which is based on Processing and does an even worse job of hiding it’s imperative/stateful core.
If you are really interesting in this topic, check out the following pages: https://clojure.org/community/success_stories