It's time to move on from OOP? - <AUTHOR> https://medium.com/better-programming/object-oriented-programming-the-trillion-dollar-disaster-%EF%B8%8F-92a4b666c7c7 <comment><USER3> I've been around long enough to remember when OOP was the savior who would free us from the previous generation of trillion-dollar disasters (spaghetti code, CASE tools, DFDs), and I'm sure someone will be writing _" Functional Programming - The Trillion Dollar Disaster"_ in 10-20 years.

In other words, I don't do hype or fads anymore.

<comment><USER4> Depends on what you mean with Functional Programming. Do you think we will ever see: "Math - The Trillion Dollar Disaster"?

Because we really ought to go that way (more proofs like Idris/Agda).

> "Simplicity is a great virtue but it requires hard work to achieve it and > education to > appreciate it. And to make matters worse: complexity sells > better." > ― Edsger Wybe Dijkstra

<comment><USER5> Unless the tooling makes it trivial - which is still a long, long time away, if possible - I'm not sure there is a world where the increased cost of formal verification (mostly in terms of engineers who know what they're doing) makes sense for things like line of business PHP/node.js websites, internal python apps, bash scripts, etc.

<comment><USER4> 100% agree, but I'm hopeful.

</comment></comment></comment></comment><comment><USER6> I broadly agree, but this article is really poorly written. It takes every downside of OOP to extremes which make it really hard to take the author seriously. Yes there are problems with mutable state, even if you think you've encapsulated it. Yes there are problems with dependencies, dependency injection and the associated boilerplate. Yes there are hideous issues with concurrency.

I don't think OOP as we see it in most languages today is particularly helpful. I do increasingly feel that data structures and operations should not be muddled together, and the polymorphism strategy should be something more like Haskell's typeclasses/Rust's traits or Go's idea of interfaces.

I'm also sure that using those for a few decades would show us plenty of things wrong, and lead to something else.

We are still children in this world. There are no correct answers - but there are definitely some wrong ones, and the increasing realisation of that is evident in the popularity of languages like Go and Rust, and the development of C# is also interesting - increasingly new language features are FP features, not OOP features, and the language becomes increasingly hybrid. It will always be limited by being built on a fundamentally OO runtime, but it's interesting how things are changing.

<comment><USER7> This article is just not very good, the author keeps talking about a zillion different things without really focusing on the actual, underlying issues. But one thing it does say right away is that mutable state is not a problem as far as it goes, what's problematic is _mutability_ plus _promiscuous sharing_. This is what makes it unfeasible to reason about what the code is doing.

Similarly, encapsulation (bundling code and data) definitely has its uses - <USER2> preserving class-wide invariants, or in providing a "common" interface that makes it possible to disregard the inner workings of some data structure, and interact with it in a way that's not dependent on the implementation. But in practice, implementation inheritance in OOP often encourages what amounts to breaking encapsulation and making it possible to violate class invariants, all in search of some dubious "code reuse". If you can't express your desired code reuse pattern via some combination of simple interface inheritance, delegation and dispatch over "sealed", non-extensible variants (the mechanisms that plain old composition/FP gives you) there are _probably_ some underlying problems with it that you haven't thought through.

Of course the standards of programming improve continuously over time. Even FP and broadly "FP-like" programming is not what it was in the 1980s, and some of that progress was brought (if perhaps incidentally!) by OOP languages. This is to be expected!

</comment></comment><comment><USER8> No paradigm, OOP, FP, etc is "perfect". Yet they are all practical in the hands of competent programmers. Personally I don't particularly like C++, C# or even Java. I have seen way too many dreadfully implemented systems in those languages. BUT it is not the fault of the languages. Bad programmers can shoot themselves in the foot with any language, it's just a bit harder with some but not impossible.

In my experience, business applications are all about state. The state of an account, a customer contact, an invoice. Changing state is what messages / methods do. In a well designed and implemented system minimal inheritance gets the job done. And bypassing encapsulation is a big no-no. Polymorphism reduces cognitive load. A toString method should return a meaningful representation of the state of all objects in a well designed system, etc.

But fear not, the majority of banks, insurance companies, big business still use COBOL on mainframes. No danger of OOP there. It's all 1960s & 1970s programming with GOTOs and spaghetti code. And yes, those are the systems that manage trillions of "REAL" dollars everyday.

<comment><USER9> Completely agree.

Some of the most literate, easy to comprehend and maintain, stateful, Gui- heavy desktop apps I've written / worked on have been detailed models of interactive objects, because it was _appropriate for the problem_.

In other problems (the classic web, data processing), it doesn't make as much sense to hydrate this huge, complex ecosystem of objects over and over just to throw it away again, or to end up with functions which are nonsensically bound to what is really just a data structure. Other operations are particularly recursive or parallel by nature and lend themselves to FP at least in part because of the work done in the FP community to handle those paradigms extremely well.

</comment></comment><comment><USER10> C++, java and other oop languages have been battle tested, and enabled a trillion dollar economy.

Sure, others could do the same, but they didnt.

Google, msft uses c++, c# and a bunch of others and they are probably the most complex software developers in the world.

It works.

Can it be better? Sure. Rust brings safety guarantees, f# enables functional programming mindset, julia is good for data processing. But oop did bring a lot of to market. We are evolving, and our languages will also evolve.

<comment><USER11> I'd argue that until C++11 C++ was /objectively/ a terrible language and the only reason people used it (and continue to use it) is because it's nearly 40 years old and therefore ubiquitous. C++ is a language that is literally famous for being famous. I know I certainly wouldn't be using it if I had any other viable (high performance) language with the same ecosystem, support and tooling. It's not "battle tested" it's just too big to fail, and therefore a lot of smart people have dedicated a lot of effort to developing tools and standards that make it just barely passable for enterprise use.

<comment><USER5> _> literally famous for being famous [...] not battle tested_

 _> "[no other] viable high performance language with the same ecosystem, support and tooling"_

This comment strikes me as deeply contradictory. I have qualms with C++ as any other C++ programmer, but saying it's famous for being famous is just ridiculous.

C++ has been used to operate nuclear submarines, airplanes, pacemakers, financial systems, ... over the last few decades. I'd like to know what you consider "battle tested".

<comment><USER12> Ada

</comment></comment></comment></comment><comment><USER13> Sure, as if sucessful FP languages weren't hybrid ones with support for OOP programming as well.

The future is neither pure OOP, nor pure FP, it is multi-paradigm.

And with nice libraries, IDE and GUI tooling as well.

Comparing languages based purely on grammar and semantics doesn't help much.

<comment><USER14> Can anyone point to an IDE or GUI programmed from the ground up in an FP style?

The declarative simplicity of FP makes it a joy, but I find myself skeptical that flattening the OOP hierarchy into what would be a right jolly long list of pure functions will prove practical.

<comment><USER13> Not really.

Common Lisp ones make use of CLOS or similar concepts.

For Haskell you have Leksah, but it uses Gtk and Typeclasses which allow for polymorphism, a basic OOP principle.

<comment><USER15> I'd call type classes a non-OO form of polymorphism, it doesn't become OO just because you have polymorphism (if that's what you're implying). I think of OO as late-as possible dispatch, whereas type classes are compile time only in most implementations.

</comment></comment></comment></comment><comment><USER16> Smalltalk (which was a revelation to me when I played with it on Tektronics and Lisa) which the author mentions as a "real" OOP language, is actually a good example of a code maintenance nightmare as a is one of those languages that promotes "image saving"-based incremental development in the context of some unreproducable soup of classes. Also its single-dispatch nature (copied by most non-Lisp OOP systems) makes the intended receiver (and dynamic casting semantics) rather arbitrary.

Any extremeism/fundamentalism taken too far tends not to work - and oop got just ridiculous at one point. It's also not just the idea, but how it is expressed and the level of abstraction that can be brought to bear. Unfortunately, Java, being a "class-orientated language" rather than an object-oriented one (not my original observation/coinage) and not supporting lambda/closures, etc., was both the reason and solution that we needed these baroque oop patterns in the fist place. (Even C# 1.0 had delegates before proper lambdas and didn't require realized nested inner classes to represent event handlers, etc.) Java's verbose solution to the simplest problems was (is?) frustrating, and is only matched by C++'s complex semantics of copy/assignment/... ctors and value/reference semantics which is more clearly make explicit rather than implicit in a vanilla C program.

</comment><comment><USER17> So much to critique in this article, but I decided to pick on this:

"THE codebase becomes impossible to maintain" "THE codebase becomes too complex and unmaintainable" "What makes THE codebase complex?"

I count fifteen references to "the codebase." THE codebase. THE.

Well your program consists of more than one codebase! What then?

Here's some code that ran on the linked site:

        window.webpackJsonp = window.webpackJsonp || []).push([[8], {
            "./config/polyfills.js": function(e, t, n) {

Medium (codebase A) dynamically interrogates the API provided by my browser (codebase B) as influenced by plugins (codebase C) linking the UI framework of my OS (codebase D) and then loads some polyfills provided by Babel (codebase E)... Which one is "the codebase?"

Your runtime environment is multiple components, each evolving independently! How do you write reliable software here? You can use static types but can't _trust_ them, they can't predict the future and don't know the past. You want runtime interrogation and reflection. You want graceful degradation and dynamic polyfills. You need late bound interfaces. You need objects, not ADTs.

This I think is the heart of the OOP idea: software components realized in classes/objects/messages which can evolve truly independently. Drop the "THE codebase" assumption and some of OOP's strengths will appear.

<comment><USER18> Are you essentially saying that because you are using libraries you need OOP?

If that is what you are saying, that is nonsense.

</comment></comment><comment><USER19> First I was programming in C and I was told C is bad and I must move to a better C -> C++. I listened and moved to C++. Then I was told C++ is horrible and I must switch to modern OOP langauges like Java and C#. I moved more than 15 years ago and I am now very productive when delivering solutions using C# and Java.

15 years later, I am now being told to dump my decade and a half knowledge and competitive advantage and learn a new programming paradigm? Miss me on this one. This time around, I will stick to what I know best. OOP has 80% of what I need and I know ways to deal with 20% of the problems. I will stick to it.

It took me only 2-3 days to learn F# but I feel I will be doing my clients a disservice if I have to start from scratch and start delivering solutions to their problems using a programming paradigm that I have little experience with.

No. Thank you. I will stick to delivering solutions to my clients using what I know best.

<comment><USER20> Congrats, you're old now :)

I think as developers we should constantly learn about new approaches. Doesn't mean we need to use them blindly and follow the herd. Sometimes it's also useful to learn something to realize why one should not use it, and how the current approach is actually better.

<comment><USER19> That's why I learnt F#. Just to see how functional programming is going to help me deliver solutions faster to my penny-pinching clients. It was an eye- opener but I will still stick to functional programming until FP catches on. If it happens.

At age 37, I feel young and really wish that I will still be able to program at age of 50 and beyond.

<comment><USER20> You're definitely still young, just kidding :-)

I've heard good things about F# for business logic, but haven't used it myself yet.

<comment><USER19> I want to try F# on my next side project and see how it goes. I hope I will get help from F# online community when I get stuck.

</comment></comment></comment></comment></comment><comment><USER21> I dream of a future where instead of following messianic paradigms, developers follow the mantra of "the most suitable tool or practice for the task at hand".

<comment><USER22> I dream of a world where instead of finding the most suitable tool or practice for the task at hand, developers follow the mantra of questioning those most suitable tools or practices without blindly adopting them

<comment><USER21> Also that.

</comment></comment></comment><comment><USER23> > Real-world Example, Please!

> Real-world example, please!

> Real-world example, please!

Would it be too much to ask for a REAL real-world example? Unless you are already an expert in both paradigms you (I) have no idea what is the author talking about.

How is nullability supuerir in Functional?

How is error handling superir in Functional?

What is really meant by shared mutable state? (The example with a piece of papaer is equally useless as the explanation that "state is any temporary data stored in memory")

How are "erroneous abstractions" promoted by OOP?

What is the "low signal-to-noise ratio"

How is the state NOT promiscously scatered between objects in Functional programming?

How do you make "core parts of your application be stateless and pure" in Functional programming?

How is global state "the root of all evil"?

Could someone point me to a literature that can explains these questions to someone who don't know the answers already?

<comment><USER20> This may be a useful example for a different approach: [http://www.dataorienteddesign.com/dodbook/](http://www.dataorienteddesign.com/dodbook/)

Particularly the chapter "Relational Databases" which compares to programming with sets in databases. This book doesn't tell you to program as if you worked with SQL, but draws inspiration from it and makes a comparison.

</comment></comment><comment><USER24> This article is just someone's frustrated rant, poorly written.

Definition of OOP has changed over the years, early on it was a lot of focus on inheritance & polymorphism, but today it is mostly about composition, which is basically what you do in FP as well.

New inventive ideas like Go's & Typescript's interfaces flips the relationship between the caller & the callee. Or Rust's traits where you can expand your existing types with new behavior.

There is criticism about OOP to be said, but using Java as your strawman to invalidate OOP is not really a good argument, it is just one implementation of many.

Edit: removed the word dynamically from description about Rust traits.

<comment><USER7> I'm not going to defend the article's writing style, but Rust is effectively a functional language with _controlled_ use of procedural-programming features. Not _that_ much different from how Haskell places safeguards on the very same things. (No, I'm not saying Rust today is _just as safe_ or _just as elegant_ as Haskell - far from it! But it can get there with some work.) Even FP is not what it was back in the 1980s and 1990s!

<comment><USER17> What does functional language mean here?

Rust is not referentially transparent, does not model effects (any function can rm -Rf your drive), permits shared mutable state (RefCell, etc) includes statements not just expressions (break, return). Its most important safeguard is its affine type system, which is absent from Haskell.

<comment><USER25> Break and return are both expressions in Rust.

Item declarations, let statements, expression statements, and macro invocation statements are the four kinds of statements in Rust.

</comment></comment></comment></comment><comment><USER26> I would love to see atleast a few large projects implemented with Haskell/FP before making such tall claims. Large here means few millions of lines of source code and more than 50 engineers working on the same project, a monolith such as a database or a message broker.

<comment><USER4> "Measuring programming progress by lines of code is like measuring aircraft building progress by weight." ― Bill Gates

BTW: Are you considering Go to be OOP? Like it always is in the programming world everything is ill defined. Go has no inheritance from what I've read.

<comment><USER26> The quote is fantastic and it does bring out an interesting dimension. Not all parts of the code base are equally important. That is for another day. I believe you are missing the context. Allow me to explain.

Source lines of code is a proxy to the complexity of the problem in hand. With the assumption that the engineers will not unnecessarily write code just to fill up the code base or pass time, we can safely say that the number of lines of code for a database will be significantly higher than say a networking library. To write more lines of code, we need more engineers. And with more engineers, we uncover a variety of problems.

No accomplished Haskell programmer will agree that Go is a functional language. At least the ones that I know don't. I think FP programmers are not in agreement as to what constitutes a functional language, example Haskell vs Clojure vs Elixir.

<comment><USER4> Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better. \- Dijkstra

My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger. \- Dijkstra

The required techniques of effective reasoning are pretty formal, but as long as programming is done by people that don't master them, the software crisis will remain with us and will be considered an incurable disease. And you know what incurable diseases do: they invite the quacks and charlatans in, who in this case take the form of Software Engineering gurus. \- Dijkstra

<comment><USER26> Different times, different people.

Do you have anything original to add?

</comment></comment></comment></comment></comment><comment><USER27> >functions provide a level of code modularity and reusability never seen in OOP.

Its like this guy has never used an OO language or at least tried to use some FP paradigms in one.

</comment><comment><USER28> I learned Python about 5 years ago, just for context, I know a bit of bash, some html/css etc. I don't really understand this piece. I use Classes in Python, put them in a module, I also put functions there. Some things are nice as a class, some things are nice as general functions. I like inheritance, otherwise I repeat things. Maybe I need to grow my project and run into limitation before I understand the viewpoints. Maybe anyone has to go through this? Should I feel bad about using classes/objects?

</comment><comment><USER29> """The venerable master Qc Na was walking with his student, Anton. Hoping to prompt the master into a discussion, Anton said "Master, I have heard that objects are a very good thing - is this true?" Qc Na looked pityingly at his student and replied, "Foolish pupil - objects are merely a poor man's closures."

Chastised, Anton took his leave from his master and returned to his cell, intent on studying closures. He carefully read the entire "Lambda: The Ultimate..." series of papers and its cousins, and implemented a small Scheme interpreter with a closure-based object system. He learned much, and looked forward to informing his master of his progress.

On his next walk with Qc Na, Anton attempted to impress his master by saying "Master, I have diligently studied the matter, and now understand that objects are truly a poor man's closures." Qc Na responded by hitting Anton with his stick, saying "When will you learn? Closures are a poor man's object." At that moment, Anton became enlightened."""

</comment><comment><USER30> I'm getting sick an tired of all these OOP bashing articles.

X is terrible, Y is super! Fact is that everything has benefits and drawbacks, and so does OOP, Functional programming or whatever.

The strength about OOP is that it's practically the best to program most software. If you look for example at the SDL library written in C, it uses an OOP interface with handles to keep things nice and simple. Yeah that's right, OOP in C, why would anyone do that? Because it has benefits, that's why.

So why is most software nowadays written in OOP? Because it has the most benefits. You can sure find examples where functional programming would be better, but they are a minority.

So yeah, next time I would expect an article to properly make a comparison between benefits and drawbacks of _both_ things that are compared. Not the usual "all drawbacks of X, but look at all benefits of Y". This kind of thing screams "Junior alert" to me.

Meantime, I'm developing my apps and games and applications in OOP, and absolutely loving it. Wouldn't trade it for anything else in the world.

<comment><USER18> SDL having an interface with handles has nothing to do with OOP and is simply the concept of opaque handles. This is often seen in data-oriented code bases where a system behind the scenes is dealing with transforming data in a hardware-oriented and cache optimized manner.

Sure the article isn't super well-written, but it raises a fair point and shouldn't just be thrown away. Just because something is the most used or standard does not mean it is the best solution. Eating junk food is very common, but you would hardly argue that it is the best way for a human to get nutrients.

You can use OOP all you want, and it's fair to say that the article should have been less biased (though he has a disclaimer that says he is biased), but there is nothing suggesting that OOP is practically the best paradigm to program most software other than the fact that it is the most used.

<comment><USER30> There is no doubt that using handles like that takes concepts the same like OOP, such as constructor, encapsulation, object methods, etc. Therefore moving this API interface to OOP would mean a straightforward 1-on-1 mapping. Claiming this has no relation to an OOP setup is therefore not correct. It would have had the exact same interface if it was written in OOP.

Maybe we are talking next to each other about what a good programming language is. For me as a professional programmer, it means to sell value. This implies that the companies I work for can make the most amount of revenue. Thanks to free market forces, we can assume that the most "optimal" programming languages survive. Remark that "optimal" is not expressed in terms of aesthetics or whatever, but is purely the productivity of generating money.

You can indeed claim that fast food is not healthy, but from a business perspective, it is a success story, and therefore also popular. I don't know how "healthy" OOP is, but it is hard to argue that it is not a business success story. And that is exactly what I offer to my clients.

Edit: And to be honest, I would have no clue how I could make the business case for any of the projects I ever worked on for not using OOP. These include games, consumer mobile apps, robotics and various business applications (smart client-server, etc).

<comment><USER18> Fair enough with that argument you can say it has a relation. I think what I was trying to say was that I don't necessarily think the authors of SDL were inspired by OOP when designing this type of interface.

 _Maybe we are talking next to each other about what a good programming language is._

Yes, I think we are at least in a sense. If we are speaking about programming languages from a business perspective we can agree that the language leading to the most productivity will - in a business sense - be the most optimal. I think my point is we have been productive in spite of OOP and not because of it. OOP here meaning the way it has been since Java and not Alan Kay's original ideas. When something like OOP becomes ingrained in an industry like it has been in software development in both the business and in academia, I'm not sure just waiting on the free market is going to do us any good if we (i.e. me) want to change it. Personally I am vastly more productive in the non-OOP code-bases I have worked in as opposed to the opposite. This is a personal bias, but I am no the only one and there is a growing movement of moving away from it and often already completely gone away from it. So it's not just a case of the grass being greener.

I assume you are more senior than me, since I am not particularly senior, so you can again write it off as me being a junior. But it's a growing paradigm shift, especially in game and game engine development, which is what I do for a living.

<comment><USER30> Senior also means that I built up a certain way of reasoning and avoiding or working around common problems. So I might not be the best person to push a new paradigm shift ;).

You got me intrigued about being less productive in OOP. Can you share what exactly you are working on? My first guess would be that it has something to do with concurrency or parallelism? It especially interests me since it's game development :).

<comment><USER18> _Senior also means that I built up a certain way of reasoning and avoiding or working around common problems_

I see this in my current senior colleagues, who may be very OOP-oriented but they are incredibly productive because they are super experienced in their field and in the code-base. I 100% respect that type of seniority of course, because I have learned a lot from my seniors.

Regarding my productivity I think it is first and foremost related to how my brain solves problems. I especially like the idea of Data-Oriented Design, because I think of solving programming problems as three simple steps: 1\. Some data comes in 2\. Data needs to be transformed into something else (based on some business rules) 3\. Data needs to be presented

So when I want to solve a problem I first define my data, then I define my transformation functions and then where they are used afterwards. It's not necessarily a purely functional approach, since they do change state as opposed to returning new state, but it has very little overhead in my brain. And as you mention concurrency, it simplifies it vastly because you usually know exactly who is using which data where.

I work mostly on engine development, so there's a lot of room for optimization and understanding how a lot of data is transformed every frame, which makes performance a super interesting topic for me. I can reason much more easily about performance in a procedural code-base than in an OOP code-base, so that might be part of my bias. :)

</comment></comment></comment></comment></comment></comment><comment><USER31> Written by someone who... "Guides teams to building reliable software. JS/Node/React."

Enough said

<comment><USER32> Not really enough. Facile witty criticism doesn't add much to the discussion and lowers the level of discourse.

The same thought expressed with enough meat to chew on might provide a worthwhile addition to the conversation but such venears once pierced are often as solid as movie sets.

Think more deeply and take time to share.

</comment></comment><comment><USER4> "OOP is considered by many a crown jewel of computer science".

No it's not. It's a crown jewel of programming.

What do proper CS-researchers have to do to not be grouped together with pixel pushers? Slap Theoretical on every paper?

</comment><comment><USER33> > _[OOP] never came out of a proper research institution (in contrast with > Haskell /FP)._

"Out with systems; in with formal languages!"

[https://www.dreamsongs.com/Files/Incommensurability.pdf](https://www.dreamsongs.com/Files/Incommensurability.pdf)

> _I do not consider Xerox or another enterprise to be a "proper research > institution"._

"Also, I don't consider a paper on systems to be publishable!"

</comment><comment><USER34> > There's no objective and open evidence that OOP is better than plain > procedural programming.

Really depends on what is your definition of "OOP" here

> Both Smalltalk and Erlang make use of OOP the way it was originally intended > by its inventor, Alan Kay.

ah, the bad definition of OOP then.

Hint : most C apis that look like

        foo* foo_create(void);
        int foo_get_bananas(foo*);
        void foo_print(foo*, int, int);
        void foo_free(foo**);

are OOP, not procedural. They just lack the syntax sugar.

> Linus Torvalds is widely known for his open criticism of C++ and OOP.

yet he went on doing C++ for user-space code : [https://www.youtube.com/watch?v=ON0A1dsQOV0](https://www.youtube.com/watch?v=ON0A1dsQOV0)

> Some might disagree with me, but the truth is that modern OOP has never been > properly designed. It never came out of a proper research institution

as someone who did a phd in a "proper research institution", that's a completely bullshit criterion.

> OOP doesn't have decades of rigorous scientific research to back it up

oh come on

[https://scholar.google.com/scholar?q=object- oriented](https://scholar.google.com/scholar?q=object-oriented)

<comment><USER20> > Really depends on what is your definition of "OOP" here

I smell a no-true-scotsman incoming..

>> Both Smalltalk and Erlang make use of OOP the way it was originally intended by its inventor, Alan Kay.

> ah, the bad definition of OOP then.

Message-based OOP is usually considered to be superior to inheritance by even OOP advocates, and even composition-based OOP by many. I don't see your evidence for "bad definition of OOP".

>Hint : most C apis that look like

> foo* foo_create(void);

> int foo_get_bananas(foo _);

> void foo_print(foo_, int, int);

> void foo_free(foo __);

>

> are OOP, not procedural. They just lack the syntax sugar.

Not every API that uses a struct is OOP. If your foos use inheritance, virtual dispatch etc, then yes it's OOP. But usually it's just something like a struct to store state instead of having globals or multiple parameters even.

>> Linus Torvalds is widely known for his open criticism of C++ and OOP.

> yet he went on doing C++ for user-space code : > [https://www.youtube.com/watch?v=ON0A1dsQOV0](https://www.youtube.com/watch?v=ON0A1dsQOV0)

He's a pragmatist first and foremost, and the GUI libraries he uses (Qt) and the programmers that work on GUI code use C++, he said. I doubt he would write his own GUI framework in C++.

</comment></comment><comment><USER16> Two other random thoughts...

It amazes me that despite the long-ago realization to favor composition over inheritance, that major oop langs only provide direct support for (implementation) inheritance of methods and not _delegation_. I suppose "delegation in context" has become be purview of DI/IoC add-ons - but direct language support would be nice.

While confounded with OOP by many, Generics are probably best treated as orthogonal -- if they had been the primary focus (including higher-kinded types/modules) rather than inheritance, that would have been nice...

</comment><comment><USER35> So if oo uis so bad, exactly what is better?

What should I be programming with?

<comment><USER36> I usually just keep it very lean group a bunch of functions into logical groups and KISS it.

<comment><USER21> In OOP those groups are called classes, and the fun is that you can instantiate them and call them objects. And within those objects you can set a state, so those functions operate against it. A nice feat of OOP is that you can also inherit logic and expand it.

<comment><USER35> Sounds disastrous.

<comment><USER21> In the wrong hands, it does. Easy to tangle OOP. But the point is each of the two paradigms has its own benefits, and should be used when best for the task at hand.

<comment><USER13> Somehow it seems hard to grasp that at their core classes are basically extensible modules.

<comment><USER37> The key to understanding classes, IMHO is that you are grouping functionality to make the code more cohesive. The style of grouping is to group the functions based on the program state where these functions make sense.

Often people go the other way around and write entity relation diagrams. They write classes to encode the data that they want to work with and put the functions that interact with the data into those classes. This actually leads to code that isn't OO (again IMHO). It actually more closely resembles modular programming. You have areas where you say, "I'm dealing with that data here". All of your instance variables are essentially global to that module. Especially when the classes become large, this becomes mostly indistinguishable from imperative code with global variables.

Instead, consider the parameters that the methods on your class use. Imagine that you had no instance variables and that you had to pass all of the parameters to your functions. Now group all of the functions that use mostly the same parameters. That's a class. The instance variables represent some state of the program and the methods work on that state. _Afterwards_ you can make diagrams to see how these objects interact with each other, but it usually doesn't make sense to do it before hand (because otherwise you end up with bags of data and functions that act on that data as if they were global variables).

Or, more concisely: An class is not a table in a DB and you shouldn't model it the same way ;-)

</comment></comment></comment></comment></comment></comment></comment><comment><USER28> It's blocked for me, I have had 2 free reads... Any tips? I'd actually like to read these, the previous 2 were a let down and I never finished them even.

I don't understand, I actually though medium was sort of free (as in beer), who is getting this money?

<comment><USER38> I was able to bypass by opening in incognito mode as a logged out user.

</comment></comment><comment><USER39> Data dominates. the programming moves toward the data. from initial state to final state, the shortest linear distance between two points. Simplicity is the root of fast, stable and reliable.

`The Pure Function Pipeline Data Flow`, based on the philosophy of `Taoism` and `the Great Unification Theory`, In the computer field, for the first time, it was realized that the unification of hardware engineering and software engineering on the logical model. It has been extended from `Lisp language- level code and data unification` to `system engineering-level software and hardware unification`.

Whether it is the appearance of the code or the runtime mechanism, it is highly consistent with the integrated circuit system.

Using the input and output characteristics of pure functions, pure functions are used as pipelines. Dataflow is formed by a series of pure functions in series. A dataflow code block as a function, equivalent to an integrated circuit element (or board)。 A complete integrated system is formed by serial or parallel dataflow.

It has also been widely unified with other disciplines (such as management, large industrial assembly lines, water conservancy projects, power engineering, etc.). It's also very simple and clear, and the support for concurrency, parallelism, and distribution is simple and natural.

There are only five basic components:

1\. Pipeline (pure function)

2\. Branch

3\. Reflow (feedback, whirlpool, recursion)

4\. Shunt (concurrent, parallel)

5\. Confluence.

The whole system consists of five basic components. It perfectly achieves unity and simplicity. It must be the ultimate programming methodology.

This method has been applied to 100,000 lines of code-level pure Clojure project, which can prove the practicability of this method.

[The Pure Function Pipeline Data Flow]([https://github.com/linpengcheng/PurefunctionPipelineDataflow](https://github.com/linpengcheng/PurefunctionPipelineDataflow))

</comment><comment><USER40> Abstractions and design patterns aren't what object oriented programming is about, you can change the paradigm and you will still have these (though you will maybe name them differently).</comment>


Jazz and Rain - <AUTHOR> http://www.jazzandrain.com/

<comment><USER2> There was a site like this I had bookmarked a few years back that was just rain (no jazz). I loved it and wish I still knew what it was. Anyone else remember it?

<comment><USER3> Or SimplyRain? [http://rain.simplynoise.com/](http://rain.simplynoise.com/)

</comment></comment><comment><USER4> Really like the site. Is there mobile apps for this?

<comment><USER5> Just add it to your home screen and it'll always be there!</comment></comment>


Ask HN: Any need for a better embedded development solution? - <AUTHOR>

I've got a plan for a different approach to software development on embedded platforms. One that doesn't required the typical edit/compile/flash/restart cycle. Instead it allows direct modification of a running system on the device itself. Just trying to gauge interest in something like this. <comment><AUTHOR> Thanks for the responses so far, very useful. I'd just like to clarify a couple of details, in case it makes any difference to the responses. Firstly, the solution is based around a high level OO language, not raw C, so is based on a highly efficient VM. Secondly, it is targeted at the sort of device that might consider a Java KVM, so probably ~128K ram, ~512K flash, or thereabouts, might be able to squeeze certain configurations into less ram. The primary principle is to have the system running on device, and then be able to login from a remote machine and make code changes to the live environment. Please feel free to ask any questions, if I can, I will answer them.

<comment><USER2> No matter how "efficient" the VM - it poses a performance and storage impact upon the platform. For many embedded projects that is unacceptable overhead. For the few projects I have worked on, I've only used assembler and C.

</comment></comment><comment><USER3> For me, 'restart' is generally the most used operation during debug. The vast majority of the time I want to rerun through the init code to clear out the registers and any previous transactions. If I've set something up incorrectly, I can always set a breakpoint and adjust.

So I'm not seeing an immediate benefit to direct modification for my normal workflow. There may be good use cases when writing code that isn't HW dependent or if the compile/flash cycle takes a long time, but those aren't problems I've had very often over the last ~10 years.

<comment><USER4> Ditto.

In addition, usually when I do something wrong in an embedded system the _only_ way to recover is a hard reset and reload. Mishandled interrupt, corrupted stack, jump to a random location, etc.

In embedded systems, there are an infinite number of ways to crash such that there is only one way to recover (reset and reload). There are very few ways to crash that leave a non-reset recovery.

</comment></comment><comment><USER2> I have often wondered whether it would be possible to have an emulator running on a PC and by keeping a before and after image, patching the memory of the embedded system to reflect the new contents. The existing debugger or a very simple small loader/patcher is all that would be required on the embedded system.</comment>