A broad layman's definition of a psychosis is roughly; "The belief in something that has been proven to be wrong". The definition of a mass psychos...
For further actions, you may consider blocking this person and/or reporting abuse
Very nice article. I think you argue in a really good way but I disagree with you in almost all points. You said that OOP is not the unique solution and this is totally right. Depending on the problem you should apply the right solution. I mean, OOP is a way of structuring code and can be a solution for some problems. However, people not always apply OOP in the proper way and not always apply other solutions in the right way. That's why OOP seems to be a bad solution but could happen the same with other approaches.
A broomstick is perfect because it doesn't need an instruction manual. Everything that's brilliant is intuitively understood without requiring further explanation. When I started coding (40 years ago), my very first creation was as follows.
Reproducing the above easily understood program in (correct) OO would probably require an
OutputFactoryclass, anOutputFactoryMarshalerclass, aMainclass, anotherOutputFactoryMarshalerFactory, with a couple of interface implementations to make sure it's adequately abstracted, anotherDoWorkclass, definitely inheriting from (at least) 2 or 3 distinct interfaces to apply by the rules of "SOLID", separating the implementation from the interface, allowing maintainers to implement alternatives through their IoC container, to prepare for scenarios that would highly unlikely never occur - And at the end of the day, I would have increased the requirements for cognitive energy by several orders of magnitudes to maintain it, effectively created "unmaintainable code", impossible to understand, debug, or extend in any ways what so ever - Paradoxically, because I wanted something that was extendible, easily maintained, and easily understood, with proper encapsulation.I'm not sure who said this, I think it was attributed to Leonardo DaVinci though, and it goes as follows ...
You can use OO to create great code, but the paradigm is implicitly making it much, much harder - Because the paradigm is fundamentally wrong. With OO, assuming you obey by SOLID, with the aim of creating "great code", it is fundamentally impossible to create even the simplest of "Hello World", without ending up with a "class hierarchy from the depths of Mordor" ...
Don't believe me? Port my above BASIC program (2 lines of code) to any OO language of your choice, and in the process make sure you obey by all the OO design principles, such as SOLID, clean architecture, etc, applying the adequate design patterns in the process where they make sense ... :/
Computing is a process of transformation. A process of transformation takes input, applies a verb to your input, and produces a result. The nature of our brains, and the natural laws of the universe you might argue, is much better geared towards using "verbs" as the mechanism to transform such data. Verbs are fundamentally better described with "functions", and not "subjects" (classes and types) ...
When that's said, I do a lot of work in OOP, simply for no other reason than the fact of that most other produce OOP code - I just try to avoid it every time I can avoid it ...
Notice, I liked your comment ;)
Reality:
Anti OOPs Ranting:
Even if that was true, the above is 7 lines of code. That is 3.5 times as many LOC as my 2 liner. Science shows us that the amount of resources required to maintain code is proportional to the LOC count. Your example is hence 3.5 times more demanding in both initial resources to create it and resources required to maintain it. One of OOP's sales pitches was "that it makes it easier to maintain your code". You just scientifically proved it wrong ...
The ranting you did was , as I told none of them was required:
@polterguy you're repeating a very common fallacy - less code is better. In fact, the amount of code is much less important (and in most cases just irrelevant). Also, this example does not show nor prove anything because it has zero useful functionality.
LOC is always proportional to resource requirements for maintaining the code. Resource requirements is "the price". The goal is to reduce the price, without reducing quality or deliverability ...
The very first statement is the root of the issue. Because it just plain wrong. The "mechanical" metric like LOC does not consider the business (task) context. Simple counter-example for this statement: there are "write-only" code (for example, regular expressions), which is very concise, but very hard to support and maintain.
In fact, reduction of the LOC makes sense only as long as business context is preserved. Once reduction is done by dropping part of context (for example, by relying on "implicit" knowledge or "defaults"), reduction of LOC causes more harm than good.
Well, my statement is still accurate. Don't like it, blame the scientists. It's been proven over and over again, already as far back as in the 1960s. I even think Brooks wrote about it in his "Mythical Man Month" from the late 60s. I first saw it in the book called "The art of CISC x86 Assembly Programming". The author used it as an argument for that assembly was only 25% "slower" in Time2Market compared to C.
Whether or not it causes harm or does good of course, is another subject, but the amount of resources required to maintain a snippet of code, is directly proportional to the LOC count, regardless of language ...
Since the 60s there are many things changed, including tools we're using to read, write and manage code. That assessment is not accurate anymore. You might be interested to take a look: dev.to/siy/we-should-write-java-co...
It's very Java-oriented, but you might find similarities in other languages as well.
This math is written at information theory. The more complex are encoder and decoder, the smaller is the code. However, it's possible to transmit very simple code with lot of repeatitions and it can be produced/understood by same simple encoder/decoder. However, we consider less-entropy code to be better because in general we are reducing local entropy, thats is the progammers' job and i believe life in general.
You expressed a general view, but, as it often happens, the devil is buried in the details.
Information which need to be stored in the code consists of three main components:
Let's assume that incoming business logic is fixed (it is defined by the task in hands). So, if the total amount of information is fixed and preserved during encoding/decoding, then we can reduce the amount of the code only by shifting the balance between syntax and implicit information. The implicit information must be present in both, encoder and decoder to enable them to perform their functions and to avoid information loss.
Since this is the developer, who actually handles "encoder/decoder" task, reduction of the syntax by increasing amount of implicit information results in the growth of mental overhead. This, in turn, means that a smaller amount of code is enough to hit "complexity barrier" of the project. You can see this effect in the real life observation, for example it is well-known fact that strongly typed languages (i.e. ones which are inherently more verbose) far better suited for large, complex, long-living projects.
As I've assumed above, information is preserved during encoding. But for many languages this is not the case. This results in different "impedance" of writing and reading code. Perhaps the best illustration of this loss are regular expressions. They are rather easy to write, but very hard to read because information which exists during encoding is lost. Worse is that get lost most valuable part of the information - business logic/requirements.
With all of the above, it is easy to see that "less code is better" idea is too simplistic and does not consider real-life implications like loss of the information during encoding or need to keep in mind huge amounts of defaults/implicit information.
If "more code" was better, nobody would purchase off the shelf products, such as iOS, ClickUp, use GitHub for that matter, etc - Facts are; Less code is always a blessing ...
I see no reason why my point of view should be screwed and pushed to absurd, like you're trying to do.
I reiterate my real point of view: less code is better only if there is no loss of context (in the term of my previous answer - business logic/requirements remain preserved during encoding). The "fact" you're pushing, does not work in real life. Otherwise, APL would be one of the most widely used languages, but it collects dust somewhere in the IT history closet.
Code is the very definition of technical debt. Pinpointing that out isn't pushing it to the extreme in any ways. If one million LOC requires 3 people to maintain it, then two million LOC requires (at least) 6 people. The resource requirements probably also grows exponentially and not linearly too. The less LOC, the less technical debt. Whether the company is able to operate with zero LOC or not, is of course questionable - However if it can, without compromising business functions, zero LOC is the goal ...
OK, I reiterate: your argumentation is applicable only if we're talking about same language and same code base. It does not provide any basis for comparison of different languages or different code bases.
"complexity barrier" - is not property of a project. It's property of a developer.
If we can't handle decoding that does not mean the code is bad.
"Complexity barrier" is the property of the combination of the developer AND the language.
If we can't handle decoding, that does mean that code is unmaintainable. Of course, this does not mean that code is bad. It's not good nor bad. It's useless.
Actually, the language is literally irrelevant, something demonstrated by several peer reviewed scientific reports about the subject, many times too in fact.
If the code cannot be easily understood in 20 minutes by an experienced software developer it's garbage, and the only hope that exists is to initiate a "SHIFT+DELETE" refactoring project ... :/
I've maintained dozens, if not hundreds of "complex projects" in my 20+ years of experience. They've all got a lot of common traits; They're unmaintainable, there's 10x as many developers working on the project(s) as you'd need if the project was easily understood, they've had to obtain 100x as much HW to run the thing on, because it leaks like Titanic, and the software runs like freakin' syrup and consumes 10x as much resources, time and bandwidth as would be necessary if they were nicely architected. The most fascinating part of these projects, is that the CEO having paid millions of EUROs having assembled this garbage literally believes that "the thing is worth a lot of money". I wouldn't have accepted any of these codebases today if I was paid money to be given them for free.
Typically, they're millions of LOCs, outdated, impossible to update or fix bugs in, and performance is so degrading that the company as a consequence is bleeding money.
A FinTech company I was working for had a payment API that would literally reject 25% of all attempts to pay, because their API backend was so slow the payment provider gave up sending us notifications, resulting in timeouts from the payment provider, resulting in that we literally lost 25% of all payments. The exception log in this thing was accumulating 2,000 unhandled exceptions on a daily basis. We had roughly 700 users on a daily basis. 3 unhandled exceptions for each user. Today the company no longer exists.
Facts are, literally every single project I've worked on during my professional life resembles this junkyard of software ... :/
Or software developer is not as experienced, as it thinks about itself.
P.S. Your story does prove literally nothing. I saw different projects in my career, and not all of them were like ones described by you.
This is how modern application works, in .NET for example. Developers just wrap everything to try{}catch(exception){_logger.LogException(exception);} and run the code until someone complains. Then trying to investigate logs)
This is how some modern applications are working. Not all of them.
I have worked as a professional software developer for 22 years, in the US, in Norway, in Cyprus, and remotely for companies all over the world - In addition, I've worked as a consultant due to my experience as an architect and advisor. I have never seen anything not resembling garbage.
I have worked on software that was installed in some of the largest hospitals in the world. I have worked on software licensed by all major banks in (unnamed) country in EU. I have worked on software used by hundreds of thousands of traders on a daily basis. I have worked on software used by some of the largest streaming service providers in the world. I can guarantee you with 100% certainty that it's all garbage, and for the same reasons too. Overcomplicated, over engineered, astronaut architecture, created by a bunch of autistics, capable of describing DDD and SOLID until normal people "cracks", and simply leaves the room from cognitive overload, resulting in a complexity resembling some creature from John's Revelations, with configuration files (Pulsar?) with tens of thousands of lines of YAML code, to create a "bare bones" (basic) installation.
I swear to (unnamed deity) if somebody suggests DDD, SOLID, or Micro Service architecture for me once more, based upon message brokers, event sourcing, sagas and CQRS, I'll end up having to go to prison for manslaughter ... :/
My favourite system was a partner administration system using Guids as "authentication tokens", automatically injecting these as GET QUERY parameters upon invocations to the backend. The Guids was the primary key for the user records in the database BTW. That thing was built in a frontend framework that was literally abandoned by its (only) developer 15 years earlier, scattered with jQuery all over the place, 15 years after jQuery was arguably obsolete may I add. It was creating 15 different "queues" in Solace, required 4 weeks of configuration to simply get it up running, and consisted of a monster codebase, with 25+ "micro services" dependencies, to simply get a single 200 OK HTTP response from its backend. I practically begged my manager to do the big rewrite. His response was "it works". The system has since been replaced and tossed in the garbage as far as I know ...
The above system was using Durandal as an "MVC framework" to "increase code quality". One of my views had 6,000 LOC. One single JavaScript file. I was going mental over having "project team lead" responsibilities over the thing, and suffered a 2 year long non-stop headache because of "all the attempts to increase code quality" ... :/
If you see things "differently", then either I'm the one with "a problem", or maybe something else is wrong here ...
Just sayin' ... :/
My condolences. Perhaps I'm more lucky or just working in the industry little bit longer (about 35 years), but I saw projects which didn't look like ones you're describing. By the way, I share your skepsis regarding microservices (you can find many related articles in my blog).
Could you, please, show a project which you like or you think it's nearly fine?
The vast majority of the projects I was working on are enterprise ones. Obviously, they are not available publicly. Nevertheless, my current project is open source, and you can take a look here. It's definitely far from perfect, but it not even close to the tragedy mentioned above in a comment I've replied to.
Of course, there are also my personal projects, but they are too small to serve as an example.
You are obviously highly skilled, and know what you're doing, but you're also (kind of) proving the point with things such as this - Where we're 9 folders in, having a class name consisting of 5 words and 30+ characters. But as I started out with, you're highly skilled, and I don't mean to put you down as a person, but you're still arguably proving the initial statement of my article ... :/
The number of words in the class name does not matter, it's a "mechanical" metric, just like LOC. The purpose of the name is to provide as much of the business context as necessary, and this particular name does exactly that. You might notice that it does not contain any design pattern names or any other useless stuff. The importance of preserving business context I've already stressed.
Good point. However, if it was written in a functional context its name would be a single verb, such as "Create", "Run", "Transfer", etc ...
The whole point with my OP was how FP results in more readable code. More readable code translates to more maintainable code. More maintainable code again, results in less costs and less technical debt ...
If there's only one person maintaining the code, of course the above is irrelevant. The problem doesn't become a problem before somebody else needs to understand the code ...
Yet again, I want to emphasise I don't intend to pick on you in particular - You're obviously highly skilled, and a pride to your employer ...
If you take a look into my blog, you'll discover that I'm a big proponent of FP. I also believe that there is no point to confront OOP and FP. In fact, they perfectly fine complement each other and quite often trying to achieve same goal, just using slightly different (complementary) views on same things.
The class which you've pointed, actually demonstrates this approach in action: the class serves as a holder of the "context" (hashing algorithm) and its methods basically nothing else than partially applied functions in FP. This class utilizes OOP to achieve additional goals:
Would like to see one.
Just in case if anyone is looking for something relevant: the study, which proves quite low relevance of LOC as a metric across different languages. I was really impressed to find, that LOC is most relevant for COBOL :) (but relevance is still too low to be useful).
"Quite low" is not the same as "irrelevant" - However, the interesting question isn't productivity, the interesting question is "how much technical debt will I be taking on". As in the cost to maintain the thing ...
Measuring developer's productivity according to LOC is (of course) madness! Measuring a software project's complexity and amount of technical debt according to the same metric, is probably a quite good metric ...
Hence, paying developers according to LOC (which was Bill Gates' joke) becomes absurd, because you're paying them for (technical) debt ...
Which was the famous IBM quote where Bill did the Jumbo Jet analogy paying for the weight of the plane as a metric ...
Should we consider all factors? For example, amount of caffeine in the developers' coffee? Or display diagonal and resolution? All these also impacts technical debt and cost to maintain.
Recently did a huge refactoring, which increased amount of the code (for refactored part) by about ~25%. At the same time, refactored code now is readable by every team member, not just by the author of the code. And no, this is not the first time I observe such an effect. Yet another illustration that technical debt and LOC are not related to each other.
Segregating related parts into separate components is a good idea, for different reasons, since it allows the developers to focus on one problem at the time. However, even though you increased the LOC count by 25%, you probably separated the thing into multiple (smaller) components and modules. Whether or not you increased the LOC or decreased the LOC is actually "debatable", regardless of the hard core numbers you provide ... ;)
Over exaggeration to prove once point. LOC is important, but so is common sense.
A developer who finds 2 extra lines of code difficult to understand, and is ready to sacrifice modularity and every other aspect of programming, is definitely not making a strong point.
You're right, but so is (still) the science about LOC. LOC is the factor determining resources required to achieve maintainability according to science. Sometimes it helps to add some few additional lines of code to increase readability or modularity, but the science is still sound, and proclaims that there is a one to one proportional resource requirement towards maintainability and LOC ...
Notice, I don't disagree with you ...
LOC metric as a factor determining resources makes sense only under identical circumstances. Once you change language, code style or even formatting, comparison of LOC gets meaningless.
Simple example: make a license header mandatory in each source file and LOC will immediately grow, but maintenance efforts will barely change because processing is automated and folding in IDE will preserve user experience.
Actually, this was Randy's exact point, that it doesn't matter, and he used it as an argument to prove how "assembly programming is only 25% more resource intensive than C", so not it doesn't matter actually ...
I didn't say it doesn't matter. I did say that comparison makes sense only in same conditions.
And are you cool Thomas?
I think so
Hahaha :D
I was 8 years old ...
Did you get the code from a magazine, I was told that's how most kids got to write basic
Oric 1 User was the magazine's name. This was in 1982 though ...
Let's try in one of the original object-oriented languages. :)
Hehe, Simula ...?
Smalltalk :D
Smalltalk is one of those languages I in general respect, although I've never really dived into it ...
Alan was a smart guy ;)
"The above system was using Durandal as an "MVC framework" to "increase code quality"."
Actually, enforcing MVC in a framework is bad architecture. It applies to any MVC framework. Frameworks should focus on core business tasks like user handling, authentication, and authorization. Assigning the responsibility of handling views to a framework may cause modularization and componentization efforts to fail, potentially resulting in spaghetti code, regardless of whether OOP or FP is used.
A more effective approach involves a modular framework implementing the hexagonal pattern, complemented by a separate module responsible for input and output. In the context of web applications, this can appear as a CMS module, but this principle can apply broadly across various application types.
Routing handled by a framework can be a warning sign, and plain wrong in applications where different UI themes or outputs might necessitate rendering different components for the same URL or input.
When considering maintainability, the coding approach (OOP or FP) or the number of lines of code (LOC) aren't the main focus. The key lies in the application of best practices and adherence to proper principles."
I hope this revision is more to your satisfaction. Please let me know if there are other aspects you'd like to modify.
I really enjoyed reading this article but I can't help feeling that someone has beaten you with a broomstick far too many times... Then blamed it on OOP.
If you see code that looks like that, it doesn't matter what paradigm you claim to be following, you are doing it wrong!
Thank you, and yes, you’re probably right. The problem is COMPLEXITY. But I’d still argue that the solution is NOT OOP 😉
I'm joining this thread because the rest got flattened and is difficult to read.
I think that's a non-sequitur which doesn't do anything for your argument.
I'd say more like 4. You can see it's more verbose, you don't need to start counting braces to add to the argument!
Probably why Tetrus and games like angry birds made millions
Any paradigm can be pushed to extreme (absurd). OOP is not an exception. FP either.
P.S. you're mixing into OOP all things, which basically not an OOP: patterns, SOLID, clean architecture and other stuff.
No, I am using design patterns and SOLID as the proof of that OOP is sub-optimal.
Try to apply the same approach to FP, and you'll see the same issues. Because there is no optimal solution.
While(true) Console.WriteLine("Thomas is wrong");
I guess you forgot one of the most important principles: KISS.
Your article about OO being overcomplicated can be ported to anything, really.
If we would follow every FP principles, would also be very hard to maintain stuff, e.g: if you need to STDOUT something, you would have to create a monad or something like it to avoid the log side effect, since it's an I/O.
Just keep the code simple and get the best parts of OOP and FP.
You're right, and obviously that was my point. History has taught me that the statistical probability of that an OO project turns into an "astronaut architecture project from the depths of Mordor" is 10x orders of magnitudes more likely than that the equivalent FP project ending in the same result ...
Psst, here's a functional example of a code snippet taken from our website (Hyperlambda code). Try implementing the same in C#, Java or (sigh!) C++ ... :/
I assume everyone reading the above code can instantly understand what it does ...
The above is 5 lines of code. Its C# or Java equivalent would probably require hundreds of lines of code, and at least half a dozen classes, in addition to (consuming) some 25 to 50 different existing classes ... :/
Actually, your code does nothing useful beside generation of useless traffic (result of the operation are ignored) :)
In the Java framework I'm working on, your code will look like this:
Wish I have more time to work on this framework...
Beautiful, but of course creating libraries that simplifies things is possible in all languages. When I was doing my LOC count, I considered the bare bones implementation using
HttpClientfrom .Net ...Najs code though :)
Edit;
I didn't see this one before now, but no, my example does not ignore the result of the operation. That's the purpose of the [join] keyword in Hyperlambda. It waits for the [fork] invocations to finish, and returns the result of the invocations to the caller. To access the content of the first for instance would be as easy as follows.
strcpyis a bunch of lines if you don't have it in your standard library. Everything in this example is hiding complexity somewhere, just like all code ever written.I like "less code" as a principle, but I'll add more SLOC if I think it makes what I'm trying to do clearer:
Every one can undertand what it does. Try implementing it in Hyperlambda, which will atleast require 100s of lines of code to implements this Awesome functionality. And hence by your logic it can be deduced Hyperlambda is psychosis.
No, I showed three of the fundamental building blocks in Hyperlambda (3 slots), which are similar to "functions" in structure, and how these 3 fundamentals solves an actual problem, being retrieving 2 HTML documents in parallel, and waiting for both documents to download.
I have demonstrated a better example of how to run any app with just one line of code. It does all you say and do in just one line.
If reducing number of line is yard stick.
Reducing the LOC is always a "yard stick" yes.
One of the yard stick yes, but definitely not the most important of all. A sane programmer would and should choose modularity, for a non trivial programm, always over LOC. A few extra lines which gives better extensibility and readability is instead good and promoted as a good programming atticate.
Not in C#
Simply wiring up your
HttpClient, ensuring you're disposing yourContentResponseobject, and correctly parametrise it would require 10x as many lines of code as the Hyperlambda 5 liner above. Then do it twice (two invocations), add the required boiler plate code for threading, and ensure you wait for the code to return before you move beyond thejoininvocation, and you're probably looking at a lot more code, at least 10x as much code as the Hyperlambda example, probably even more than that. If you disagree, feel free to prove me wrong. You've got the Hyperlambda code up there - By all means, port it to C# and let's see what produces most code and complexity ...I'm not sure what the point of this article is besides being inflammatory. I am both a heavy user of functional programming and more traditional OOP languages.
My definition of OOP
There are many paradigms that get grouped under the name "OOP".
I think of OOP as:
None of these are inherently bad, and they surface in different forms in functional programming languages too.
Task join/fork example in C++
You give the example of
In a C++ framework I wrote (and I tend to be on the heavy-handed verbose side of the spectrum), I would write:
If I wanted to push it, I could easily boil it down to
which compiles to the exact same memory layout and binary code.
Because my HTTP factory implements an abstract virtual class, I can easily swap out different factories, say if I am running unit tests or decide to replace HTTP calls with some local IPC. I also get a concrete task object that I can pass around and introspect / monitor / listen to / cancel.
You might say that
http.get : fun string -> bytesis more elegant thanbut it is missing the point.
The value is that I get a clearly documented, easily extendable data structure that encapsulate what is needed to create thunks that ultimately return bytes. I can look at the class of my HTTPFactory instance and easily see that it contains say, a TLS certificate. I can also add a
POSTmethod, and make it obvious that both GET and POST belong together and reuse some of the same code and data.These things are more opaque in a functional context.
Which is the best? None, they both work just fine.
OOP the strawman
Since you don't provide a concrete OOP API other than bringing up the strawman of needed an OutputFactoryMarshalerFactory to print out a single line of output, it is hard not to assume that you are arguing in bad faith. I can write
just as well. Bringing up LISP (all caps?), while Common Lisp has probably the most expansive approach to OOP of all the languages I know, strikes me as a bit odd as well.
Using C++ as an example, which is probably the language that I most often use to write what could be called "traditional OO", a class without virtual methods is arguably just a shortcut for a series of functions that take the same data structure as first argument. Once you introduce virtual dispatch, a class is just a way to combine a virtual dispatch mechanism with a data structure, give that group of dispatched functions a name, and make reuse easier. That's very similar to what many languages call "traits", arguably less flexible, but flexibility can often be a bad thing (say, if working in a big team with different skill-levels).
Data+Code centric patterns are useful
There's value in taking a data centric approach, especially in more resource constrained environments. I wouldn't know easily how much memory is allocated, when, where, by whom, and who owns it. In my C++, I know that I have 1 instance of Task_Join, 2 instances of Task_HTTPGet, and I can go look up the class to see that Task_Join keeps two pointers, and Task_HTTPGet a byte buffer, a state variable and a file descriptor. I know when they are created, I know when they are freed.
That data-centric OOP style might be less flexible than function-centric code when composing functions, but it's much simpler in many other regards. As with all code, it's about tradeoffs.
Thx for the snippet. It took me a couple of days to realise I don't need to prove anything at all, since your C++ example basically is all the proof I needed ...
Interestingly, the following code snippet you provided ...
... is arguably more in the style of FP than in the style of OO. However, you didn't provide the creation of your
m_Factoriesinstance, you didn't provide the wiring of your IoC container (assuming it was somehow dependency injected), etc. But nice code - You're obviously skilled :)You can write heinously bad code in any language and with any design pattern. There is no approach or pattern that saves you from bad code.
Yes, but the general rule of thumb that seems to be valid "all over the place" is KISS, as in Keep It Stupid Simple - And if you follow KISS, it's much less likely going to produce bad code. OO is fundamentally incompatible with KISS. You're writing code for human beings, the fact that it compiles is just "a lucky side effect" one could argue. The simpler your code is, the more easily understood it is. OO results in complex code, FP results in simple code ...
Every word in this reply is wrong and I am embarrassed I didn’t catch it sooner.
But I’ll reiterate, FP isn’t going to save you from bad code by being inherently simple. For every statement that says it does, you can probably find 10 repos that use FP with hilariously bad results.
It’s never the language or the style, it’s always the person using it.
Then why did even React use inheritance?
The entire .Net framework is OOP as is Java. None of those failed.
This is just a Javascript centric OOP Flame article. Problem is even Javascript supports OOP now.
NPM has messy Javascript code everywhere. It's a virtual garbage dump brought about by what Javascript allows and what people think are best practices.
It didn't
React.createClass(): "Create a component given a specification."Component Specifications: "When creating a component class by invoking
React.createClass(), you should provide a specification object that contains a render method and can optionally contain other lifecycle methods described here."Clearly the React team wasn't immune to fashion influences as that factory function would have been more appropriately called
React.createComponent()especially as for all intents and purposes the component instance'sthis.propsandthis.statewere owned and managed by React - not the object instance itself as one would expect with standard class-based object orientation.This style was advocated by Douglas Crockford as class-free object orientation at least as far back as 2008 (JavaScript the Good Parts).
The component specification simply contained what was unique about that particular component.
It was the later alignment with the ES2015
classtemplate for creating objects that brought inextends React.Component.For years this was common dude or are you too new?
class Car extends React.Component {
render() {
return
Hi, I am a Car!
;}
}
JavaScript has always had OOP, as long back as to the 1990s. It just didn't have class based OOP, but rather prototype OOP.
Which I even prefer over class based oop just to feel great by attaching my standalone function to a class' proto to stay dry but don't mess with inheritance.
And npm itself has no influence on Js as a language. Same issues can happen in other language registries too.
Very good point about dynamic features yes ... :)
It's prototype OOP was sucky, still is.
All OOP is bad, but the ability to dynamically attach functions to an object has its use cases.
True. All OOP Is not bad, just your opinion
There is no silver bullet... OOP and FP are no exclusive. I love FPing on my application code and agree with you on many points, but when I design library or use a 3rd party one I prefer to have well oop-organized packages/modules, class and methods rather than a bunch of functions.
Very interesting article, but it is unforgivably wrong. The problem is not in OOP itself, but in the fact that all OO languages(and developers using them) come from imperative programming in the form of C. OOP is just as declarative as FP is. A lot of good concepts like immutability are not specific for FP only and they do not appear in its definition. The correct statement is "OOP is done wrong", not "OOP is wrong".
OK, I agree with that - It's still a problem ...
However, even though I blame OOP languages themselves in the header, I'm not really doing that in my arguments. Interestingly, most languages, including C#, is easily used in a "FP style" ...
It might be interesting for you to look at EOLANG, an experimental OO language which is pure OO: everything is lazy, no flow-control statements(if and for), no classes, no METHODS, only objects and their composition. It feels very similar to FP because every object has a specific method "@", which is considered its primary method.
Interesting ...
It would be great to have some real examples, or some side-by-side comparisons, instead of hyperbole like "virtually impossible to understand code", and "arguably the very definition of madness" which are not quantifiable, and "results in 1,000+ classes for something that could have been done with 5 functions in FP", which is not even true.
This article seems to be written for people who have already decided that they prefer FP. By writing stuff like the above, you don't win over any OO programmers, you just allow them to dismiss your whole article because you lead with things that are demonstrably false.
Thx Aidan, and yes, I have thought that exact same thought myself, as in provide for instance the "textbook example" from C# doing the same thing as my 5 lines of Hyperlambda code (in another comment), etc, then compare these side by side, to illustrate the difference.
Thx for the tip though, I'll definitely do that at some point in time when I've got the time ...
Patterns like OOP can be applied to any problem, regardless if they are a good fit.
Patterns can shape your design decisions for the better or the worse. Use them wisely. Thinking of them as silver bullets is a recipe to shoot your own kneecaps.
Just to construct an example where OOP is a good fit: you have items with a lot of methods. Without OOP, you either need to externalize the methods or create them for every instance, which is bad for performance. With OOP, you can have the methods inherited and can even change them for instances that are already created.
Thomas, it looks like your recommendation of programming languages is based on the lack of OOP rather than the functional features. Would you recommend against mixing both paradigms? I actually don't see a problem in it as long as one keeps the OOP very lightweight.
I guess I'm just trying to balance the debate here. I'm not "against" OO, I just believe one should be a bit cautious with it. The principles of SOLID, DDD and (overusing) design patterns, rapidly results in a code base nightmare, impossible to navigate or maintain ...
Incorrect information in this article starts from the "30+" years. OOP is about as old as procedural programming (i.e. 50+ years). And it is just a logical next step: while procedural programming focuses on encapsulation of the code, OOP adds encapsulation of the data. All these are necessary steps to reduce software complexity.
I really like FP (and use it every day), but I'm pretty certain that real working approach is the hybrid of OOP and FP.
P.S. there are very little efficient pure FP algorithms for many everyday tasks, for example, sorting.
Pure functional and functional programming aren't (necessary) the same thing. OOP was "invented" in Simula 67, but it never went truly mainstream before the 90s ...
Procedural programming "invented" around the same time, but there were hot debates about it well in the mid of the 80s. The basics of agile methodologies were created at the beginning of the 70s, but agile went mainstream only on the mid of 2000s. And so on and so forth. This is just an illustration of how conservative software development is.
OOP is just one of MANY paradigms that you can apply, there is no hard set rule on when or where to apply, as always it depends on your context. You write your opinions about OOP as if they broke up with you!
Hahaha, kind of ... ^_^
I've seen both sides of the argument, and also have seen public opinion filp-flop between sides over the years (seems to cycle).
OOP and FP have their own sets of pros and cons. Some may be better suited for certain projects, architectures, or even developers personal preferences.
But to me, FP is not better than OOP, or vice versa. They serve a purpose, and it's the developers job to chose the one that suites their purpose best.
Thank you for the post.
A small comment: Golang is almost as much of an OOP language as Java or C++. It doesn't force you to use OOP but it has objects (a function with receivers is an object method), and I have seen it used in a very standard OOP way: everything is an object, design patterns, SOLID, and so on. Sure, it doesn't have inheritance, but it's still just as possible to write OOP.
Similarly, it's possible to write non-OOP Java. I guess the correct way to classify these languages is "OOP-capable", and Goland definitely fits the bill.
Thx for the details. I haven't really done that much GoLang development, so I wouldn't really know. But thx :)
I'm cracking up. I got here from the GraphQL article but this one is a gem too. I will add... almost all contemporary programming languages OO or otherwise are all sprinting to provide more and more functional paradigms with every release.
Hehehe, no sjiiit ...? :D
They're still a decade behind Lisp. Lisp was invented in the late 1950s ... ;)
Wow! I find this whole mass pyschosis thing super interesting and really enjoy how you tied this to the fallacy that OOP is infallible.
But yeah, I just had to look more into this mass psychosis thing...
From a wikipedia entry on "List of mass hysteria cases":
Thought2 created a YouTube video about it. A must see ;)
Seems a bunch of people are hating on you for this article, but I agree with one caveat: GO can also be written as an enterprise OOP nightmare.
Regarding OOP in general: my experience of it was one of constant inadequacy and corner cutting because of all the principles and patterns work
The worst sin for me in OOP is the "What if" fallacy. Want to write an application that needs to interpret a scripting language? Best make a factory that outputs an interpreter that follows an interface because you might want to swap Lua for Python one day!
Want a new class? We'll just make and interface for that too! You may want to abstract it eventually.
The amount of projects I've walked into where every class has an associated interface is shocking, and I'm not saying that is necessary for OOP, but it leads many programmers to that conclusion.
I used to be all about OOP, but ended up moving into full stack development with typescript and it's so liberating to just write what you need knowing that there no need for OOP principles. You don't have to write it, and nobody misses it (except the Java Devs). So suddenly you find yourself wondering : what was the point in all that boiler plate? What was the point in all those bloated projects where the behaviour is hidden behind 8 layers of abstraction? OOP has made the projects I've walked in to harder to maintain, not easier
Hahaha :D
Bingo! And at the end of the day, it's the only important thing to measure an idea around ... ;)
Just laid down a book I am reading on object-oriented programming in Python. Lol Thomas, which OOP developer hurt you? 😄 Entertaining post though. Exposes how ugly the purists' approach to coding can be.
If your goal is to kill that fly that was bugging you all afternoon long, you won't buy a gun to finish that poor insect off. There's an assortment of problems that OOP can solve more efficiently. Then there are usage scenarios where functional programming is superior. But then you have purists that force their one and only one purest approach to every problem they are assigned to solve.
Hehe :D
My problem isn't as much with OOP as it is with "the fanatic believer" yes, as you adequately pinpoint ;)
Yo, Thomas. Why argue with the psychotics? The only people who truly love OOP are the people who have only ever used OOP. I've known many people who have switched from FP to OOP. I've never known one to go the other way.
This comment stream is a pointless waste of time. If you're going to publish controversial (but obvious) truths like this, just turn the damn comments off. You will never convince the psychotic of their psychoses. Those who aren't actually psychotic about it will maybe try FP and few who give it a real try will ever go back. Slowly, but surely, OOP is losing steam. The word is out.
Thx mate, and you are correct ...
Isn't it all much more fluid than all that, practically speaking? Isn't mixing and matching more common?
Just thinking of C#:
Here's the parallel fetch (using the excellent Flurl library for http):
Not quite as brief but still readable and flexible.
And the hashing question wouldn't need a class, first instinct would be an extension method in a static class in a shareable string helper:
Then just used like this:
In fact, linq and other "fluent" libraries, are very common. And popular I think. They feel expressive and satisfying to use. But also, sit happily along side OOP, classes, interfaces, inheritence, dependency injection etc etc which also feel powerful and comfortable to use when done well.
The graphics reference is interesting, there it's about speed in parallel. You have to think different anyway. For example, if you have a reasonably heavy calculation, in desktop or embedded, you might implement a look up table, in shader code, its quicker to calculate it each time. And you never want to do an if branch.
And DOTS (with the Burst compiler in unity, at least) give you incredibly fast function calls but all setup and organised inside game objects.
Beautiful flurl code - I wasn't aware of that it could do that.
Apparently you are "too new" because the
React.createClass()factory function was the standard way (2013-05-29) stateful React components were created before React supported the ES2015classsyntax.At the time a constructor function would have been the standard way of implementing a template for creating objects. That would have supported prototypal inheritance out of the box but there were other inheritance schemes around (combination inheritance, parasitic inheritance and parasitic combination inheritance).
The entire point of class-free object orientation was to get away from inheritance and use composition exclusively.
But the truth is that inside a factory function the React team could do whatever they wanted. ES2015 classes weren't supported until 0.13 (2015-03-10) which finally introduced
React.Component(but of course IE never supported ES2015 classes in the first place).React.createClass()wasn't deprecated until React 16 (2017-09-26) and the factory function was relocated to create-react-class.James Coplien
"How many of you do object-oriented programming? What language? Java is the only language in which you cannot do object-oriented programming. Huh? Other languages. Smalltalk - no. C# - no. Python - no. No. Any JavaScript programmers here? Here are my object-oriented programmers - they're writing objects - the rest of you are writing classes."
Teaching OO: Putting the Object back into OOD (2003)
"Almost everyone who teaches object orientation uses the class as a fundamental building block. Such an approach misses the central point of object orientation: the objects themselves, and what they portend for flexibility and effective design. This weblog is a case study in teaching object orientation."
Why OO Sucks by Joe Armstrong
Ralph Johnson, Joe Armstrong on the State of OOP (2010)
"He said object oriented languages aren't object oriented. I might think, though I'm not quite sure if I believe this or not, but Erlang might be the only object oriented language because the 3 tenets of object oriented programming are that it's based on message passing, that you have isolation between objects and have polymorphism.
Alan Kay himself wrote this famous thing and said 'The notion of object oriented programming is completely misunderstood. It's not about objects and classes, it's all about messages'. He wrote that and he said that the initial reaction to object oriented programming was to overemphasize the classes and methods and under emphasize the messages and if we talk much more about messages then it would be a lot nicer. The original Smalltalk was always talking about objects and you sent messages to them and they responded by sending messages back."
The mass psychosis is in the wording of this article and the author's intent to elicit attention. It has no regard for anyone still using OOP and is simply a lie. Why bash OOP when you could have written an article about FP.
You said it yourself "attention". Look how many comments there already are.
Lie is perhaps a strong word but it's a rather biased rehash of previously known limitations. Every paradigm has limitations and it's important to be aware of them and know how to deal with them. To some degree it plays on the one language theme—in a "one paradigm" way.
Otherwise just ignore it.
If for whatever reason I was tied to the C# ecosystem right now I'd be paying more attention to Mark Seeman (Code that fits in your Head)
He's a veteran in the OO space and is simply looking for better solutions to real problems.
(And beyond that Scott Wlaschin.)
I read Seeman over 25 years ago, he's nothing special. All OOP winds up functional. What? Yes SRP guarantees it. So all your noise shows you are unaware of that.
After 25 years you should have stopped clinging to SRP by now.
It's a place to start ... not dogma.
With statements like that you are just feeding into the author's argument.
The "point" isn't "to win", the point is to find the best argument ...
Clinging is a word you picked. My word is working. The code style employed everyday I write it, works perfectly. More importantly it's maintainable even years later. Proof? Yes, I have code running world wide every day. I use SRP and Open Closed exclusively. As well as Compositional techniques. If it ain't broke don't fix it right?
BTW the video is ridiculous to me.
I disagree with your stand. The concept you list are not inherently flawed but become one due to people taking them to a next level.
Mapping data with function is not necessarily bad if you think in the sense of Object.
First caveat. I took a look at hyperlambda - it looks interesting.
It isn't about whether OOP is right or not. Instead it is about getting to the bottom of what the job needing to be done is. I read Plato's Cave way back, and without rereading it, believe it pretty much maps out OOP over 2000 years ago. This doesn't mean it makes OOP valid today, but modelling out instances or classes topologically makes some sense. Whether it is optimal or could be misused is a different question altogether.
In no way, is this stating that OOP is the right way to go - I don't do it, but if people do a bit of inheritance, it can make sense.
Where you mention thousands of classes - well, it does make sense to break things down to smaller chunks, logical units of work. A lot of the code is boilerplate and offers granularity. Would a project with thousands of classes make sense? Doubtful.
Your point on encapsulation - well, that is more of an expression of intent? How much should one open up the functionality? Aren't functional calls a product of encapsulation? Hyperlambda appears to be a declarative language which has to be a product of encapsulation?
The problem with OO encapsulation is that it becomes much more difficult to create your code because you start out with something that's intrinsically a verb, and you then have to apply a subject to it. Before you do, you need to group your verbs together in logical entities belonging to each other to create a subject that makes sense. In an FP everything becomes simpler because you can just do.
No grouping of similar verbs, which always is bound to fail BTW because of our incapacity to predict future change. FP has fever "opportunities" for over engineering, because it follows the natural path of our thinking. It's intrinsically "simpler" in structure.
Thank you :)
Somebody here asked me about Hyperlambda use cases a month ago, but this discussion is way too long to try to find a specific comment in it, so I'll just provide my example use case here and hope the person sees it :)
Somebody here asked me for a use case, so I created an open source use case you can study and look at that demonstrates my point here ...
The above will be our primary support ticketing system at Aista
With a (good) functional programming language it’s not possible, not even in theory, to end up in “monolithic hell”. Monoliths is a (mostly) pure OO problem …
As to your C problems, I feel sorry for you. C has nothing to do with functional programming though …
I still don’t get the advantage of MVVM! Can’t just buy into the mass psychosis. Is it just me? And vb.net? I’d rather use vb6 than this wolf in sheep’s clothing, VB.NET! Still reeling from the m$ betrayal of the vb6 community, I guess. They could have spent that energy on delivering true polymorphism to vb6 along with the other fixes we all were clamoring for as well as included the vb6 runtime MSVBVM60.DLL calls into what’s now the CLR and solved DLL hell…but no killing a wildly successful language while shipping development overseas and forcing everybody onto a new platform was more profitable!
How many knowledge workers jobs were sent overseas. How many of those workers had new homes and most likely they also qualified for some of those crazy mortgages of the early 2000’s with huge balloon payments? How many couldn’t refinance because those jobs were shipped overseas?
Few realise this, but it's perfectly possible to use C# as a partial functional programming language. Yes indeed, my rant was more about the style of programming people use, than languages themselves. Every time somebody spells out SOLID for instance, I swear a fairy dies unless you rapidly clap your hands or something ... :/
As an interesting peculiarity, I wrote Hyperlambda (a 100% functional programming language) in C# (an OO language), using most best practices from OO, and even providing dynamic bindings towards C# classes and types ...
Wait, doesn’t Go use structs which combine behavior and data?
Totally agree with the opinion btw 👍
Yes, but as I've understood it (I'm no GoLang expert), it's about as far way from OO you can come today without being "bullied our of the room" ... ;)
Speaking up against OO is difficult today unfortunately - It's kind of like speaking up against the Pope back in the 1500s ... :/
The real loss of reality was that for 20+ years Javascript was the only language a browser supported. Thank God those days are over.
People see objects, realise they're useful, and think they have to build their entire programming paradigm around them. The problem is that objects are a good abstraction for certain problems, but terrible abstractions for others.
Say you have a mutable string as an object and want to write a hashing function for it. Some languages let you monkey-patch the string class. That's an atrocious idea. More likely, the OO programmer will write a string hasher class. They may even find some state to shove into the instance, so it seems more like a proper object.
But the thing is: hashing a string is a function. It's not an object, it doesn't have state, and it certainly doesn't need inheritance.
Once you learn that difference, objects can be really useful. They are very good at one specific thing: Abstracting mutable state. Beyond that, whether you define
class.method()orprocedure(type)is little more than syntax."For the record, if you want to work in a sane programming language, there exists dozens of nice languages out there"
but this is cop-out.
i think the point is you have to pick one
In short:
I agree on something though: there is a lot of misinformation out there.
PHP nowadays, for all it flaws, supports both paradigms (functional and OOP) and at its core it leans more toward the functional side (e.g. strings aren't objects, doing string work requires you to call functions, no "hello world"->capitalize() etc...) And I must say. When browsing through open source repos and projects, whenever something is functional it's a clusterfuck. Most often in large functional projects even basic things like documentation are a clusterfuck. It's far easier in OOP to go through unknown code. As long as you know your design patterns all you need to do is "Object->" and you get all the available methods inside your IDE. With functional structure ... I don't know where to begin, lol. Also it's very nice that private/protected methods - I don't even care about them in the slightest unless I'm extending a class. Although, extending a class of a library is generally frowned upon. Rather use composition and rely on public methods. I am coding professionally for a little over 12 years across various languages. I have yet to see a large functional project that's easy to work on. All the assumptions you've made that "less code - better" is kind of a shitshow. There's a term - cyclomatic complexity and OOP is guilty of falling into the pit but it's up to the programmer. There's a reason Laravel is the most popular framework in PHP-land. It's not because it's better than Symfony. It abstracts everything away and reduces everything to one-liners for the most part. Close to 0 cyclomatic complexity. It's a breeze working with that thing. And it's OOP. Also while we're at it, fuck hungarian notation.
Anti-OOPs ranters === OOPs noob
You have argued exactly 4 points ranting (as will be called without examples), to declare OOPs suffereing from psychosis.
I will disect your first point, as rest are equally bad without examples:
This acclaim is as extraordinary as : I stabbed myself with a rubber duck!, rubber ducks are created to be soft toys, how you ended up stabbing yourself is bit difficult to comprehend.
Encapsulation by the very definition means to hide complexity and wrap such complex code into simpler interface. How you ended up using Encapsulation,an otherwise conceptual medicine for complex code, to create complex and virtually impossible to understand code ?
He's acting as if there's no IL generation. He doesn't get that we can do all of the example in one line of code. Nobody cares what IL generates. We're using 5 core GHZ processors now.
LINQ is great and it is in fact a functional paradigm. The same goes for the fairly new C# record types and switch statements. C# has been adding more and more functional capabilities.
LINQ is a great example of what @polterguy means when he says that programming is about input -> verb -> output.
The LINQ function
SelectManyis usually calledflatMaporcollectin the FP world and it is a part of the defition of monads. So collections in C# can behave in a "monad-ish" way in C# with the addition of LINQ.And we didn't even mention
ActionandFuncyet ... ;)That's not the only angle.
Data-Oriented Design (Or Why You Might Be Shooting Yourself in The Foot With OOP) (2009).
Why?
Data-Oriented Design: What's wrong? — Mapping the problem:
"Object-oriented development is good at providing a human oriented representation of the problem in the source code but bad at providing a machine representation of the solution. It is bad at providing a framework for creating an optimal solution, …"
Which ultimately lead to the development of the Entities, Components, Systems (ECS) architecture.
"The most amazing achievement of the computer software industry is its continuing cancellation of the steady and staggering gains made by the computer hardware industry."
— Henry Petroski
The processor-memory performance gap (especially on commodity hardware) forced certain segments of the video games industry to abandon OOP.
This lead Unity to develop their "Data-Oriented Technology Stack" (DOTS) which introduced a C# dialect—"High Performance C#" (HPC#).
Brilliant walk through, thx mate :)
Single responsibility is nothing to do with oop.
SOLID is against OOP.
Could anyone give an example of classical vehicle/car/helicopter example to be done shorter without OOP anyhow?
Nobody told that OOP is solution to everything by itself. It is merely a tool for encapsulating complexity. And yet it is often misunderstood and misused. Please do not build a strawman.
Your entire post needs one big [citation needed]. That which is asserted without evidence can be dismissed without evidence.
The evidence is in our code. Open your IDE and look at the last OOP project you delivered, and ask yourself; "How would this look like in a functional programming language?"
Probably pretty much the same, but with far less organisation, and far less friendly to newer developers?
OOP and FP aren't mutually exclusive. SOLID principles don't automatically result in code explosions.
This is a good point, and when I code in C#, I typically choose the functional constructs much more than the OO constructs ...
... yes, C# has a lot of functional constructs ... ;)
Anecdotes are not evidence.
I appreciate your sentiment and I believe you make some compelling points, however, you are not presenting any concrete evidence. You are making the claim that OOP is not the answer, ok, fine, why? Just saying that it's convoluted is not enough because anyone is capable of creating terrible unreadable code. It is possible to write terrible OOP code for many reasons. Furthermore you say functional programming is better, I tend to agree for the most part. Why? It just seems like you dislike OOP and want to see it removed.
I agree that any programming paradigm can be poorly executed regardless of its merit. Poor application of principle can lead to faulty and subpar code.
I also believe OOP has it's place as does FP.
The proof is in the code. Look at any "brilliantly architected OO solution, with all the relevant design patterns, 'SOLID' as a rock". But thank you.
By the way: FP has its own design patterns. They are just different than OO ones. Functors, monads, lenses, etc. are nothing else than design patterns.
Looks like a lot of hand-waving. Show me proof with some practical examples!
Oh man... Mass psychosis
Hyperbolic much?
Thank you for sharing, but please work on language.