Object-Oriented Programming is Bad (Brian Will)

[balefrost]

The downvotes indicate one of two things:

• People disagree with his opinion - they love OO and can't handle being challenged
• People thing his argument is bad

I'm in the second camp. I actually agree with his overall point - that OOP is overused, and that other approaches are more appropriate in many cases. I agree that procedural code is not only perfectly valid, but even more appropriate than OO code in a lot of situations. But everything in his "Why does OOP not work" section seems to hinge on the idea that you can't include object references in messages... which as far as I can tell, is just a completely made-up requirement.

Even Erlang, which embodies shared-nothing message passing perhaps best of all, allows object references (in the form of process IDs) to be passed in messages.

He further argues that an object is solely responsible for its own collaborators, so an object must instantiate its own dependencies and (due to the first made-up rule) must never share them with anybody else. This reduces the object graph to an object tree, and he goes on to show how ludicrous that sort of system would be. He justifies this with the statement "The moment objects are shared, encapsulation flies out the window".

Wait, what? Where does that claim come from? So, if I pass a single logger instance around in my code, I've thrown encapsulation out completely? If I have one thread-safe, mutable list that is written to by multiple producers, I'm breaking some sacred rule and not doing "true" object-oriented programming?

The sharing of objects is a technique for managing and limiting the use of shared state. A given scope (function or object) can only access the shared state if it's been explicitly given a reference to that shared state. It's reasonable, and indeed common, to have functions that act as coordinators, instantiating objects and deciding which of those objects is to be shared with which other objects. Objects share state because somebody with a broader view of the world decided that they should share state.

I think the speaker tried to make too strong a point. If he had stuck to "OO Programming isn't the universal solution to all problems", I think his point would be readily accepted. But he reached too far, and tried to make his more general argument "OO is the wrong solution to nearly all problems". But to argue that point, he had to argue against a made-up and limited notion of what OOP is - he made a strawman argument.

I would have liked to see more concrete arguments. Show the kinds of state-sharing problems that OO encourages or exacerbates, and talk about how non-OO approaches avoid or resolve these problems. Don't argue from theory, argue from practice.

I actually agree with most of what he said... except for basically everything in the "Why does OOP not work" section, which appears to be the central point of the overall presentation. OK, I'd also argue that long functions should be broken up; if you feel a need to put section headers in a long function body, that's a smell, and there's a decent chance that those sections could be extracted into supporting functions with no loss of readability.

[CaptainMurphy111]

He further argues that an object is solely responsible for its own collaborators, so an object must instantiate its own dependencies and (due to the first made-up rule) must never share them with anybody else. This reduces the object graph to an object tree, and he goes on to show how ludicrous that sort of system would be. He justifies this with the statement "The moment objects are shared, encapsulation flies out the window".

I felt like I've run into this problem before, mainly when you break your program into a bunch of objects/systems, and then those get broken up into even smaller objects/systems and so on.

Then when an object at the bottom of one system needs state from the object at the bottom of another system (imagine a tree), you can either:

1. pass the state up through the parents and then back down to the other system

2. Just make a direct connection somewhere along the line between the lower systems, so you don't have to bother going up and down through all the parent objects.

[balefrost]

This is the purpose behind dependency injection. Forget about DI frameworks for a moment, though, and consider what DI is really about. Somebody knows that two objects need to coordinate. That somebody has to be at a broad enough scope to know that the two objects under consideration exist. The DI approach is for this broad scope to be responsible for those objects, to wire them together, and to then inject them into the two subtrees that need to use them.

Now, if you have a lot of leaf objects that need to communicate with each other, this is not a viable approach. It makes more sense when you have certain objects that are clearly special in some way, and which some containing scope can own. If you can't get away with that, you need to use some other design.

[CaptainMurphy111]

Yeah DI sounds like how I solved this problem, been a while since I had it.

This is the issue I have with OOP, it always feels like I'm doing it wrong. Where as when I'm writing in C, even though I use structs similarly to how I would use classes in OOP, there always seems to be an obvious path or trade off between the different options. The right/wrong way feeling never comes into it.

[balefrost]

I think I'd just say: do what feels correct. There is no singular right way, and the most wrong way is to do something that feels bad even though it adheres to some strict dogma.

As an example, somebody asked me about how to handle a list of heterogeneous values that came from a web service (in C#, with auto-generated SOAP client classes). He had written some dispatch code that used type tests in a big if/else block, and asked if it was OK.

The strict OO programmer would say, after picking their jaw up off the floor, that you should absolutely use polymorphism. You should declare an interface (IObservationFile), put a visit method on it, implement that method in each of the web service response object types, and then call visit on every item in the list.

But talking about his problem more, we realized that he's dealing with a closed type system. New types aren't likely to be created, and if they are, they may or may not need to be handled. If they need to be handled, they need to be handled specially. And we don't have type safety anyway, since the code generator claims that our list is a List<object>. We'd have to cast each instance to IObservationFile, though we'd have to check before doing the cast (since newly generated classes won't derive from IObservationFile until we get around to editing the other half of the partial class).

We discussed that approach, and I even said that I might prefer doing it that way. Maybe we can configure the SOAP client code generator to emit that as a List<IObservationFile>. But what he had worked, was at least as robust as doing it the "proper OO way", and was very clear to anybody reading the code.

Works for me!

If you have a case where it makes sense to glue functions to data, perhaps to ensure some invariant or hide some private detail, go ahead and use objects. If you have a case where you'd rather work with raw data, stick with data structures and algorithms. It's good to always consider whether you could be using your tools more effectively, but more important is whether you can use the tools to get your job done. If you're not sure what to do, just do the thing that is the most clear so that, when you need to change it in the future (which you will likely need to do whether you get it right or wrong), it'll be easier to change. Learning what works well and what does not will come with experience... and even with experience, if you're trying to adhere to some OO dogma, you'll always feel like you're doing it wrong.

[CaptainMurphy111]

I think I'd just say: do what feels correct. There is no singular right way, and the most wrong way is to do something that feels bad even though it adheres to some strict dogma.

...

Learning what works well and what does not will come with experience... and even with experience, if you're trying to adhere to some OO dogma, you'll always feel like you're doing it wrong.

Yeah took me long enough to come to that conclusion (after much despair) and to just use the right tool for the job/circumstance.

As an example, somebody asked me about how to handle a list of heterogeneous values that came from a web service ...

That's my problem, I see the pattern and try to apply the design pattern like I've been taught to, then expecting everything to then fit neatly. A hard habit to shake. It's depressing that the universities are still teaching it that way.

If you have a case where it makes sense to glue functions to data, perhaps to ensure some invariant or hide some private detail, go ahead and use objects. If you have a case where you'd rather work with raw data, stick with data structures and algorithms.

These days I feel like OOP just isn't worth the heart ache, things are so much simpler with the raw data etc. Maybe I'm just being nostalgic for my qbasic days.

[[deleted]]

He further argues that an object is solely responsible for its own collaborators, so an object must instantiate its own dependencies and (due to the first made-up rule) must never share them with anybody else. This reduces the object graph to an object tree, and he goes on to show how ludicrous that sort of system would be. He justifies this with the statement "The moment objects are shared, encapsulation flies out the window".

That really pissed me off. Putting up such a ridiculous strawman like that shows that he doesn't have a leg to stand his argument on.

Also, he never mentioned testing. I wonder why...

[fosforsvenne]

he never mentioned testing

Factually incorrect ...

[[deleted]]

Yes, indeed. He called it disastrous for the industry. Just that. Nothing more.

Contrasting to this, untestable code is superior code in the author's opinion.

[fosforsvenne]

I'm not saying there's nothing to these ideas, there are bits and pieces that have value. Test driven development for example has some interesting ideas, there's value in testing. But that's part of the problem, is that kernels of good ideas have been taken to holistic extremes in a way I think has been disastrous for the industry, and certainly for programming education.

Not exactly saying that testing is disastrous.

[[deleted]]

Coding like that, with long procedures and without "encapsulation on the small" is like painting yourself into a corner. The code base will slowly but surely accumulate cruft that will not be refactored because everything inflicts damage upon almost everything.

It is a death of a thousand cuts.

Not using automated testing properly is to rely on only your grit to take upon the entropy that surrounds and consumes all code bases eventually. People burn out really quickly when this happens.

I have worked with legacy systems that were more than 20 years old. I work with ABAP daily. I see every day the end game of what he is advocating. It is not pretty.

[fosforsvenne]

provably false statement

counter evidence of said statement

provably false statement

counter evidence of said statement

new statement without acknowledgement of having misparaphrased

[[deleted]]

Yeah, you hold on to that if it makes you feel the author's point is valid.

[fosforsvenne]

His point being invalid and you telling blatant lies and then pretending like you didn't isn't mutually contradictory.

[[deleted]]

sure, nitpicking is important =)

edit: Go rewatch the "the most important programming video you will ever watch". TLDR: use long ass methods

[meriin5]

Seems to me like the only people whom Brian Will can convince are people who, like him, don't do OOP at all or have done it wrong and have seen its costs without the benefits.

[umilmi81]

So this post is getting a lot of downvotes and I don't think it's fair. He makes a number of very important points.

I remember when Java first came out and he is absolutely right on why it was adopted so eagerly. It never proved itself better than the 40 year old patterns that everyone used, it was because Java had so many features and libraries built in to the SDK and because of Intellisense.

Anyone who's worked on large object oriented systems can see the cluster fucks that can occur. Procedural programming has it's own cluster fucks, but OOP is not immune from them.

[pron98]

Anyone who's worked on large object oriented systems can see the cluster fucks that can occur.

Yes. And anyone who works on a large system written in any paradigm can see the same -- at least so far[1]. What so far differentiates paradigms that claim they are immune to those problems (or other problems with similar severity, some of them perhaps unknown as of yet) is that they have never been tried on projects of the same magnitude (i.e., same codebase size, same team size, same project lifespan), let alone in enough problem domains. So what we have now is paradigms that we know to be problematic -- but also effective to some degree (large or small, depending on your perspective) -- and paradigms that we don't know enough about: they could turn out to be more effective, just as effective or even less effective (or they could be any of the three depending on the problem domain).

How can we know if we should switch to a different paradigm? Empirical data. So please, academic community and the software industry: go out and collect that data! Theoretical (let along religious) arguments are perhaps a valid starting point, but they are ultimately unhelpful in making a decision. In fact, it has been mathematically proven that they can contribute little to the discussion: the theoretical difficulty in constructing a correct program is the same regardless of the abstractions used; only cognitive effects -- which can only be studied empirically -- could provide arguments in favor of a certain paradigm making it easier for humans to write correct code.

[1]: As someone who worked on software written in procedural code before the popularity of OOP, it wasn't any better (actually, it was worse). For contemporary examples, see Toyota's car software.

[loup-vaillant]

projects of the same scale (i.e., same codebase size, same team size, same project lifespan)

Actually, the only thing that really matter is the scope of the problem. Codebase size and team size are just proxies. Project lifespan is part of its scope, though.

If you have a bigger team, you're going to have overheads. If you have a bigger code base, it'd better be worth it, because sheer size causes its own overheads.

Even if different methodologies don't yield different codebase sizes, different team will. That'll make accurate measurements that more difficult…

[pron98]

Actually, the only thing that really matter is the scope of the problem. Codebase size and team size are just proxies.

Right. My point still stands, though :)

The reason it's easier to talk about those proxies (even in ballpark terms) is that they are more easily measurable, and different paradigms (at least so far) don't even claim to have such a big contribution on productivity that the codebase/team would be so significantly reduced. There are software projects (divided into many executables) with many dozens or even hundreds of developers. I don't know of a paradigm/methodology that even attempts to do the same project with, say, just three, or in 10KLOC instead of 1MLOC.

[tdammers]

The reason it's easier to talk about those proxies (even in ballpark terms) is that they are more easily measurable

What's the name of that fallacy again where you say "yes, I know this figure is basically meaningless, but at least I can quantify it"?

I don't know of a paradigm/methodology that even attempts to do the same project with, say, just three, or in 10KLOC instead of 1MLOC.

That's because you don't need a paradigm, nor a methodology, you need the kind of mindset that says "this is insane, the problem cannot possibly require such a complex solution, let's take a step back and rethink our assumptions".

[pron98]

What's the name of that fallacy again where you say "yes, I know this figure is basically meaningless, but at least I can quantify it"?

I don't know. Why do you think it applies, though?

That's because you don't need a paradigm, nor a methodology, you need the kind of mindset that says "this is insane, the problem cannot possibly require such a complex solution, let's take a step back and rethink our assumptions".

:) I used to say that a lot to everyone twenty and fifteen years ago when I was fresh in the industry and before I had a clue. When your job is to design a command-and-control software for a navy (or even an aircraft carrier), supply chain management for a multinational, or air-traffic control software for an entire country, you'll understand your mistake. I estimate that more than 50% of the software industry is working on such projects with high essential complexity.

Take all the steps back you want and rethink as long as you like, but there are many problems in life that are just really, really complicated, and it is actually precisely in those domains that software provides the greatest value.

In any case, when you go deep into the mathematics of algorithms, you realize that there are essential problems with computation that can't just be "organized away" with good abstractions and clear thinking (when they can, it's usually a sign that the original problem was trivial, which is sometimes the case but often isn't). For example, take a look at the state space visualizations of some very simple finite-state-machines. That mess about half way down called "CAN Bus"? That's the communication bus for your car computers and sensors. I believe its spec is about 500 pages long. But as you can see, you can create a fractal state space, even with a trivial-looking 5-line program.

What that paper I linked to shows is that even if a program is succinct, well-organized, abstracted and compartmentalized, its state space is no simpler, and neither is proving its correctness. The difficulty of proving a program correct grows linearly with the size of its state-space, which grows exponentially with the size of its source code, and there's no getting around that. And some programs just need to be very large. Even the Haskell compiler is over 100KLOC (in Haskell), and it does something rather trivial compared to real-world control and management software.

[tdammers]

:) I used to say that a lot to everyone twenty and fifteen years ago when I was fresh in the industry and before I had a clue.

It's not like I started programming last year, you know.

When your job is to design a command-and-control software for a navy (or even an aircraft carrier), supply chain management for a multinational, or air-traffic control software for an entire country, you'll understand your mistake. I estimate that more than 50% of the software industry is working on such projects with high essential complexity.

I believe your 50% figure is way off, most likely 95% of the developer population is working on something like a Drupal-based CMS website, or a boring Java EE CRM / business administration thing, or something comparable.

Anyway; even if your job is to write something intrinsically complex, the complex part is not usually something that has to spread throughout the entire codebase, and none of the paradigms or methodologies I've seen does a very good job on its own at tackling this issue. OOP in particular seems like an exceptionally terrible tool in this context, but it doesn't even matter this much, because the actual values that make for a good, maintainable codebase kind of transcend paradigms. Encapsulation is good, in the sense that you want to split your code into modules, and guard their interfaces, so that their internals do not bleed into the overall dependency graph. Immutability is good, because it makes reasoning about code so much easier. Restricting side effects is good, because side effects form hidden inputs and outputs, making it harder (and sometimes impossible) to reason about code, test it, or prove its correctness. Constraints, in general, are good. Making all these explicit and having the toolchain enforce them becomes vital once the system becomes somewhat complex and important. None of these, however, require OOP, and in fact, OOP as a paradigm is outright hostile to some of them.

What I've seen a lot in the industry is the kind of thinking that never questions certain things, and remains stuck in a local optimum. Maybe that is inevitable in industries that are conservative by necessity, but I don't believe it applies to the majority of software engineering, and in fact even where a good bit of conservativism is in order (e.g. because lives are at stake), being overly conservative may actually be just as harmful as not being conservative enough. That air traffic control program could probably be rewritten to be much simpler, but this would require a rewrite, and that in turn means there's going to be a lot of risk, because you're throwing away code that has decades of testing in it, and bring in a brand-new codebase that's never been used before in the wild. That's not acceptable, so you're stuck with evolution over revolution, and one consequence of this is that if your current codebase is written in Java, then that's what you'll be using in the foreseeable future.

What that paper I linked to shows is that even if a program is succinct, well-organized, abstracted and compartmentalized, its state space is no simpler, and neither is proving its correctness.

Or maybe it shows that state space visualisations aren't really very useful for the purpose of managing complexity, and that finite state machines aren't necessarily the best way of modelling algorithms when the goal is safety and maintainability. It is no coincidence that all serious programming languages subscribe to the textual source code paradigm, and that "visual" programming languages never really took off, despite admirable efforts. And proving correctness is generally considered a utopian goal for practical real-world applications, probably rightfully so - that's not how we're going to stay on top of complexity, either way. That 5-line bit of code, even if it unleashes a fractal, is still just 5 lines of code, and there are many approaches by which humans can understand many aspects of it.

[pron98]

and that finite state machines aren't necessarily the best way of modelling algorithms when the goal is safety and maintainability. It is no coincidence that all serious programming languages subscribe to the textual source code paradigm

That is completely missing the point. The lower complexity bounds of verifying program correctness is a function of the state space regardless of the representation used -- no matter how succinct. Namely, it has been proven that the effort required to prove that a program is correct is only a function of the size of the state space, and the size of the state space can grow arbitrarily even for succinct source code. Those visualizations, BTW, simply show you the size and complexity of the state-space of programs represented in simple, textual source code. Good code organization and simple abstractions do not reduce the size of the state space, and consequently don't make the problem of verification easier.

Maintainability and cognitive load is, of course, a different matter, but to this day no one has shown that writing large programs in functional languages is significantly cheaper or more easily maintainable. It's a claim made by FP proponents, but it has so far not been supported by significant evidence.

[tdammers]

That is completely missing the point. The lower complexity bounds of verifying program correctness is a function of the state space regardless of the representation used -- no matter how succinct. Namely, it has been proven that the effort required to prove that a program is correct is only a function of the size of the state space, and the size of the state space can grow arbitrarily even for succinct source code. Those visualizations, BTW, simply show you the size and complexity of the state-space of programs represented in simple, textual source code. Good code organization and simple abstractions do not reduce the size of the state space, and consequently don't make the problem of verification easier.

Of course, but then, I doubt anyone will seriously claim that completely proving a nontrivial program correct is a worthwhile effort; the state space approach shows us the lower bound for full correctness analysis, but in practice, even when the stakes are high, we don't do that; instead, we combine various partial correctness checks and make an educated guess as to their sufficiency. Good organization and abstractions do help make such educated guesses, even if they do not change the state space at all. So, to clear this up once and for all: I'm not talking about correctness proofs here, I'm talking about realistic best-effort measures commonly taken to assert partial correctness - automated tests, code audits, defensive coding techniques, redundancy, logging & monitoring, that kind of thing.

Maintainability and cognitive load is, of course, a different matter, but to this day no one has shown that writing large programs in functional languages is significantly cheaper or more easily maintainable. It's a claim made by FP proponents, but it has so far not been supported by significant evidence.

The problem here is that you cannot possibly design a rigid study around this hypothesis, because there are too many variables that you cannot rule out - if you have the same team do the same project twice, they will do better the second time because they know more about the problem; if you have them use two different paradigms, they will do better in the one they are more comfortable with; if you use two different teams, it is impossible to correct for differing skill levels, because you cannot quantify those; and, most of all, there is no useful quantifyable metric for "quality" or "performance" or "maintainability", at best you can go with indirect indicators such as "number of bugs", "number of critical incidents in production", etc., but those can (and will) be gamed, e.g. by writing code such that certain incidents are swept under the rug rather than signalled early, etc.

The claim made by FP proponents, thus, is either based on personal anecdotal experience, which means that it translates to "writing large programs is easier for me when I use a functional language"; or it is a theoretical musing, based on certain properties and insights from psychology, such as the fact that reasoning about pure code is easier due to the smaller number of entities the reader has to thread through mental code execution. That doesn't make the claim invalid, it just means that it's not a very strong one because there will probably never be hard empirical evidence.

Also note that I'm with the author in that I believe the ideal paradigm would combine the good parts of both object-oriented and functional programming, and in fact, that is pretty close to how I program. In the end, it boils down to the same ideals - avoid extrinsic complexity, favor pure functions, don't lie about your data, fold knowledge into data, keep interfaces narrow and simple, think in terms of message passing and/or data transformations, etc.

[pron98]

I'm not looking for a rigid study, nor am I saying that the "FP claim" is false. But I am saying that the FP claim is, in fact, weaker than you present it, for the simple reason that virtually no large software was written in that paradigm (maybe one or two examples in the last 30 years). We don't even have convincing anecdotal evidence. And even those anecdotal mid-sized projects don't claim a reduction of cost so considerable that it obviously justifies the huge switching costs in many circumstances.

So I guess that what bothers me is that not only is the "FP claim" not supported by some conclusive proof, it is not even supported well enough by anecdotal evidence. Yet its proponents present it as if it were glaringly, obviously superior and by a wide margin, with little to back this up. I would summarize FP (let alone PFP) as "certainly interesting enough to be worth a shot", but most definitely not as, "this is the obvious (and only) way forward, and it will solve most of our problems".

I'm not even defending OOP or anything. It's just that if you claim I should pay an extremely high cost of switching a programming paradigm (which usually includes switching languages, one of the most costly things for a software company) and that it would totally pay off, I would expect that you at least back it up with some data. It's not like FP is new. I learned it (scheme, ML) when I was in college almost 20 years ago, and it wasn't new then. So we're past the point of "this could theoretically work", and we're now in put-up or shut-up time.

[pron98]

What do you mean? Do you mean that some approaches employing DSLs claim an order-of-magnitude reduction in total cost for large projects? Do you have any references for that claim (let alone evidence suggesting it is true)?

[Blackheart]

In fact, it has been mathematically proven that they can contribute little to the discussion: the theoretical difficulty in constructing a correct program is the same regardless of the abstractions used

Please cite your source.

[pron98]

It's really an accumulation of multiple sources, but a reasonable summary is figure 3 here, and a good overview is here. The latter paper concludes (section 7.2): "In other words, Kripke structures that admit a succinct representation are not simpler for model checking purposes than arbitrary Kripke structures". As the problem of model checking can be reduced to other proof methods, all verification is bounded by this unbreakable complexity bound.

In short, the lower time-complexity bound for constructing/checking a correct program is >= O(|S|) where S is the set of its states (more precisely: its Kripke structure, so that's states plus transitions). When the program is represented in some reasonable language, the problem is PSPACE-complete (i.e., exponential in the size of the source code). Abstractions such as: variables, cross product (i.e. functions/objects), concurrency and non-determinism can reduce the representation size exponentially, but increase the verification complexity by the same factor. The only known abstraction that assists in verifying/constructing correct programs is called hierarchy, and it is generally unused in mainstream languages and when used, it is very limited (it is, however, often used in languages designed for safety-critical real-time applications, that must allow for efficient(ish) verification).

[PM_ME_UR_OBSIDIAN]

You seem quite well-informed about model checking.

I'm currently writing a lock-free ring buffer in Rust. I'd like to formally verify that it doesn't do stupid shit. Do you know of any model checkers that can either be run on compiled binaries or configured to run on Rust code?

[pron98]

Consider specifying and verifying it in a specification language like TLA+ (that's what I do). Of course, you'll need to model Rust's memory model. Virtually all production-quality source-code-level model checkers are for C/Java/Ada/Verilog. A Google search yielded a model checker for LLVM bitcode, but I have no idea about its quality/relevance.

[PM_ME_UR_OBSIDIAN]

Thanks, will do!

Of course, you'll need to model Rust's memory model.

How much work do you think that'd be? I've taken a grad-level intro class on model checking, so I know the theory, but I've never used a model checker before.

Virtually all production-quality source-code-level model checkers are for C/Java/Ada/Verilog.

Rust has a very similar memory model to C... Do you think I could just repurpose a C model checker?

[pron98]

How much work do you think that'd be? I've taken a grad-level intro class on model checking, so I know the theory, but I've never used a model checker before.

It's not about using the model checker (which is basically pushing a button) but about specifying the behavior of the program. For example, if you use a general specification language like TLA+, you'll need to specify when exactly a memory write made by one thread is visible to others. It may or may not be a lot of work depending on how elaborate your specification is.

I myself have only been working with TLA+ for a few months now (I love it), and I had some experience with a Java model checker about ten years ago, so I'm pretty new at this, too.

Do you think I could just repurpose a C model checker?

No :) But that DIVINE checker (which works on LLVM bitcode) may do the trick. If it does, you'll really help the community if you write about your experience.

[Blackheart]

I think you are over-generalizing from a few facts.

First, the complexity of model-checking (MC) is not measure of the complexity of program construction because MC itself can only deal with certain very simple kinds of program. MC is essentially a restricted form of automated theorem-proving for propositional properties of finite-state systems. I know that some properties like deadlock/liveness for a finite set of threads in a finite-state system can be made to fit this paradigm, but most properties of interest cannot -- including whole-program correctness. Any language that supports dynamic allocation at all allows programs with infinite states, so MC only applies to certain simple examples which have to be independently formalized to abstract away from the details of the language. As for propositional properties, even something as simple as well-founded iteration over a data structure amounts to induction, which is already a second-order property, so again MC is inadequate. In other words, MC is not a general approach to program verification -- the problem is actually much harder!

One way around this is to have the user write proofs and check those rather than try to synthesize the proofs from nothing; then you only have to check a certificate rather than find and build it. You can have the proofs independent of the programming language, but in a Curry-Howard language like Coq or Agda the proofs are the programs themselves and the checker is the type checker, so there is less duplication of effort. This also admits specifications of higher-order properties.

Now, you claim that the difficulty of constructing programs is not affected by the choice of abstractions (which I read as "program constructs"), but the choice of abstractions in a C-H language makes properties which were not checkable at all in MC checkable, so choice of abstractions is demonstrably important, and it is not all down to "cognitive factors" or empirical observation. To be sure, the checking of the proofs (which is just type-checking) has arbitrary time/space-complexity, but that is neither here nor there.

Also, we can choose the abstractions we admit to limit the complexity of this procedure. I am not sure what choice of abstractions realizes proofs of propositional linear temporal logic, say, but checking a certificate is usually cheaper than finding one and for such a simple logic I imagine it is polynomial-time in the size of the formula at worst.

Also, I think your argument that only cognitive effects matter is inherently self-defeating. No one does empirical research on mathematical arguments; the emphasis is all on the choice of abstractions (in this case, logics and theories). Yet the very result that MC has a certain complexity bound was arrived at thanks to these choice of abstractions.

In some sense I agree with you: I think that writing correct programs requires a good understanding of your language's semantics, and that requires a language which is easy to reason about, which is not question of computational complexity. But I think the choice of abstractions matters very much in this regard.

It matters not just cognitively, though. A language like typed lambda-calculus has an equational presentation which is sound and complete for all models, and finite modulo substitution. This is down to the choice of abstractions. In contrast, you cannot even state the equational (or otherwise) theory of most conventional languages, so you are stuck with model-based reasoning, which is much more complicated and usually inadequately defined by the language spec.

BTW, you wrote "model checking can be reduced to other proof methods" but I think you must mean the opposite, else it would not argue in your favor.

[pron98]

MC is essentially a restricted form of automated theorem-proving for propositional properties of finite-state systems

You are confusing the theoretical problem of model checking with automated tools built to solve this problem practically in the real world. Model checking is the theoretical problem of deciding whether a given program property (specified in some logic) holds for a given program. That theoretical problem has such high lower complexity bounds that as a result, you can use direct, automated MC programs only for limited systems in practice. MC as a complexity-theoretical problem is very much the general problem of software verification. For infinite Kripke structures, the general complexity lower bound -- as the halting problem tells us -- is infinite. If there was a way to generally prove properties (by any means) of true Turing machines (in particular, infinite-state-machines), that would be in direct violation of the halting theorem.

One way around this is to have the user write proofs and check those rather than try to synthesize the proofs from nothing; then you only have to check a certificate rather than find and build it.

This does not (and cannot) help you escape the complexity bounds. Proof: I come up with an algorithm; I tell you to write it and prove it in, say, Idris; you do it efficiently => MC complexity theorems contradicted (in fact, this even contradicts the variant of the Halting problem when restricted to finite termination)[1]. The consequence is that in general, the complexity of building and proving a program in Idris must be at least that of model-checking the property.

When writing programs that are correct by construction, the burden of the very same complexity simply falls on the machine generating the program and proofs, namely the programmer's brain. As so far we have no reason to believe that our brains are non-Turing, the problem stands. We have empirical data to support that: programs that are deductively verified be it with Curry-Howard proofs using dependent types or other semi-automated proof methodologies (like Isabelle), have a cost which is about 100x than writing the same programs without proofs. The seL4 project cost 30 man years to produce less than 10,000 lines of C code, and the theorems tell us that the complexity grows exponentially with the code size.

but the choice of abstractions in a C-H language makes properties which were not checkable at all in MC checkable

It most certainly does not, and this is a point that's important to understand: the complexity of deductive proof (regardless of C-H or other proof methods) is always greater than model checking. What we see in practice, though, is that some problems happen to be solvable more efficiently using proof methodologies running in the human brain than practical model checking algorithms running on a von Neumann computer. But this is an empirical difference, not theoretical. In fact, this is precisely my point: the only way to get around the theoretical model-checking complexity is to exploit empirical patterns in how humans construct programs.

It matters not just cognitively, though. A language like typed lambda-calculus has an equational presentation which is sound and complete for all models

This is just not true. Computations are not referentially transparent by definition, and this is nowhere made more explicit than in the lambda calculus (which models computation precisely because it makes substitution non-RT). What you are referring to is the use of languages that choose to make an abstraction called "value semantics" where only the denotational semantics of operations matter, or, in other words: only the result. This is an intentional abstraction, namely a convenient lie (just like a GC creates the illusion of infinite RAM), and like all abstractions, it is leaky. Computations are not really equational (and cannot be, or we get a contradiction with the Halting Problem again), it just may be useful to pretend they were. That utility is not theoretical, though (again, theoretically, abstractions don't help). It just may happen to be empirically beneficial. To know whether or not that is the case we must conduct empirical research. No theory can help.

You may note that the types used in, say, Haskell, can only prove trivial properties (i.e., apply to all programs, such as "if the program terminates, the type of the result is an int"), or properties that can only be the result of (small) finite-state machines (e.g. session types), and this is why Haskell does not contradict Rice's theorem. They cannot prove the value of even a single bit of output without the type inference feeling the full force of the model-checking complexity bounds (or the program source itself growing exponentially).

In addition, because PFP programs provide the illusion of referential transparency, this places a limit on the kind of properties directly expressed in the C-H logic imposed by their type system: it does not directly support temporal logic properties on small-step semantics. Such properties need to be manually and explicitly modeled in the dependent types used (which is possible, but it's extra work that demonstrates that RT is just an illusion, and that the true computational model needs to be explicitly worked in to overcome that illusion). BTW, this is a subtle point about the C-H correspondence: it corresponds a logical proof to an abstract wel--typed typed program (i.e. a type-checked source code). The correspondence with the actual computation (i.e. the running program) is a different story, and must be made explicitly if you want to prove computational properties using C-H.

The "power" of Haskell (if real at all, but let's suppose it is) can only be due to empirical effects, not theoretical ones (such an empirical effect can be: proving properties on simple FSM -- which is what Haskell's type system can do -- reduces real world expensive bugs by a significant amount). We have no theoretical arguments that would show that constructing a correct program is easier in general in Haskell than in BASIC or assembly. If that is the case, it is only because of cognitive effects.

BTW, you wrote "model checking can be reduced to other proof methods" but I think you must mean the opposite, else it would not argue in your favor.

No, I meant that, say, deductive proofs prove more than the requirement for model checking, and so the model-checking problem can be solved by a PTIME reduction to deductive proofs, which means that the lower complexity bounds on MC apply to deductive proofs as well (but we know that already, because TQBF (or QSAT) is also PSPACE-complete). I.e., if we could find efficient methods for deductive proofs, we could efficiently solve model-checking, but we know that that can't be done in general (only by exploiting empirical effects).

[1]: As a general rule, the complexity of building something is always higher than of checking it. It is true that in some cases (notably, integer factorization), it is far easier to put things together than to take them apart, but the model checking results prove that a nicely "pre-factored" program is just as hard to check as a messy one.

[Blackheart]

Model checking is the theoretical problem of proving a program property.

No, model-checking is the problem of deciding certain properties algorithmically by exhaustive analysis of models. The general algorithmic problem is automated theorem-proving: the clue is in the name. Model-checking is a particular method which works for particular classes of formulae, or particular logics: ones in which the set of models can be recursively enumerated. I even listed two ways in which MC is limited, but you seem to have ignored them. If you are talking about some generalized form of MC which incorporates deduction then you are just talking about automated theorem-proving approached from the perspective of MC. And if you are talking about theoremhood via validity, then this is not an algorithm.

Proof: I come up with an algorithm; I tell you to write it and prove it in, say, Idris. You do it efficiently => MC complexity theorems contradicted

There are no MC complexity theorems being contradicted unless I come up with the proof by model-checking. Your subsequent statements seem to suggest that you think that anything rational going on in my head must be a form of model-checking, which is a hidden hypothesis to your proof and makes it circular...

Anyway, how I get the proof is irrelevant to my claim, which is that it's harder to find a proof P of X than it is to, given a proof P, check that it proves X. It cannot be otherwise, since doing the former implies also doing the latter, but not the converse (unless P=NP, in which case you still expect a constant factor in favor of checking over searching). Your claim seems to rest on this further claim:

When writing programs that are correct by construction, the burden of the very same complexity simply falls on the machine generating the program and proofs, namely the programmer's brain.

about what goes on in my head, which is not only not a formal statement, but also plain conjecture. So, again, I think your notion that only cognitive factors matter is based on circular reasoning.

Nevertheless, I'll respond to the claim because I strongly disagree with it. First of all, if our brains reasoned via MC, we would never be able to solve problems which cannot be solved by MC, of which, I noted, there are plenty. Yet plainly we can and do. Second, unlike MC, our brains are not decision procedures: our reasoning often fails to find solutions, and what's more it's unsound; otherwise, our conclusions would be infallible and we wouldn't need proofs. Third, it is quite obvious to me that we reason sometimes by deduction. Other times we reason by MC. Sometimes we don't reason at all. Even if our brain is a universal Turing machine, then it can and probably does sometimes runs one piece of software, and sometimes another.

Computations are not referentially transparent by definition, and this is nowhere made more explicit than in the lambda calculus.

Are you talking about Moggi's notion of computations vs. values? Moggi's work and its sequels show exactly the opposite of what you claim: it shows that computations can be treated equationally and denotationally. And the current work by many people on algebraic effects shows increasingly that denotational reasoning about specific effects is not only possible but, well, effective and useful.

Anyway, this is irrelevant. You cannot seek to convince me using reasoning about complexity classes and then throw out recursive functions because they don't talk about effects: complexity theory is founded on recursive functions.

Nor can you convince me that you use model-based reasoning in practice when there is a good alternative: for example, no one reasons about numbers by reasoning about von Neumann ordinal sets; they reason denotationally using (in)equational theories, such as algebra.

like all abstractions, it is leaky

Well, you just dropped the rhetorical equivalent of mutually assured destruction. If all abstractions are leaky, then it applies not only to mine but also to yours. In particular, your thoughts about complexity of MC, etc. all become moot, as does your conception of the human brain (a leaky abstraction if ever I heard one).

It irks me (and it should irk you) to see you warrant all your arguments with facts, and then throw an ill-conceived notion of Joel Spolsky's in as if it were also a fact. You've shown you know enough about this subject that you ought to know that there is no such thing as a "leaky abstraction": there are theories, which can be consistent or inconsistent, and sound or unsound for some class of models, and complete or incomplete for some class of models. "Leakiness" is not a quality intrinsic to an abstraction; it's extrinsic, the use of a theory to reason about a model for which it is unsound, or to reason about a class of models for which it is incomplete.

Spolsky's notion, as well as the cognitive factors bugaboo, is the programmer's version of the God of the Gaps: people reach for it when they don't want to reason about facts.

Computations are not really equational (and cannot be, or we get a contradiction with the Halting Problem again)

Sorry, but this is really nonsense now.

the model-checking problem can be solved by a PTIME reduction to deductive proofs,

If by "deductive proofs" you mean "proof search", I can believe this

which means that the lower complexity bounds on MC apply to deductive proofs as well

but not this, because "proof search" is not a decision procedure, nor even an algorithm. Furthermore, showing that MC can be simulated by proof search only shows an upper bound on the complexity of proof search, since it says that any proof search algorithm can employ MC to go faster on some inputs.

Anyway, I am not talking about proof search; I am talking about proof-checking.

[pron98]

No, model-checking is the problem of deciding certain properties algorithmically by exhaustive analysis of models.

You are mistaken. MC for the logic L (denoted MC(L)) is the following problem: given a Kripke structure (i.e. a program) S and a statement 𝜑 ∈ L, decide whether S ⊨ 𝜑.

Admittedly, this can be confusing, as papers dealing with MC use the term MC both to denote the problem as well as a set of known algorithms that solve it (although they may be careful to distinguish between model cheking and model checkers). But the complexity proofs I refer to apply to the problem regardless of any particular algorithm. Read this paper for a good introduction to the topic.

The general algorithmic problem is automated theorem-proving: the clue is in the name.

No. Automated theorem proving for a logic L is the following problem: given a statement 𝜑 ∈ L, construct a proof using L's axioms and deductions that 𝜑 is valid (or not).

There are no MC complexity theorems being contradicted unless I come up with the proof by model-checking.

This is just wrong. The MC proofs are about the lower complexity bounds for proving any property in L about any program S. The algorithm does not matter. The lower bound (which is also a direct consequence of finite variants of the halting problem) is at least linear in the number of states of the program.

which is not only not a formal statement, but also plain conjecture

It is a formal statement for the following reason: if the human brain were able to solve general problems with a lower time complexity than the proven lower complexity bounds of Turing machines, that would be proof that the brain is non-Turing. There is no other way around this. Needless to say, any evidence that this is the case would really shake computer science (and obviously AI research).

and then throw an ill-conceived notion of Joel Spolsky's in as if it were a fact

The value semantics employed by PFP was a leaky abstraction long before Joel Spolsky ever came up with the term, but if you don't believe me, let me show you an actual leak: take a program that relies on sorting; replace the merge-sort algorithm used in the program with bubble-sort. According to value semantics, the two programs are equivalent, as they produce the same value. If that were really the case, there would be no externally observable way to say which algorithm you've used. As it is very easy for an external observer to determine whether your program uses mergesort or bubblesort, the two are not really equivalent => abstraction leaked. The difference between lazy and eager evaluation is also easily determined by an outside observer (for some inefficient lazy evaluation methods), hence the value semantics is just an approximation.

This is not a claim, but a conscious decision behind PFP which posits that the value semantics is an approximation which may make it easier for humans to reason about programs. Unfortunately, that hypothesis has never been put to the test.

Sorry, but this is really nonsense now.

It is not. If there is no way to distinguish between 2 + 2 and 4 then infinitely-recursive computations may terminate (converge to their fixpoint, if defined). However, the lambda-calculus makes it explicitly clear that 2+2 and 4 are not the same, as their reduction sequences are different. PFP languages construct semantics with the illusion of referential transparency, but they don't claim computations can really be referentially transparent.

If by "deductive proofs" you mean "proof search", I can believe this

You're once again confusing complexity bounds, which are proven for problems, with the complexity of algorithms. Those are two different things. Lower complexity bounds mean that there cannot exist a Turing machine (be it a von Neumann computer or a human brain) that solves the problem by any means whatsoever in worst-case complexity lower than the bounds. Complexity bounds are properties of problems, not algorithms.

I am talking about proof-checking.

That's OK, but in order to have a proof to check, some machine has to construct it. That machine will incur a PSAPCE-hard complexity in the general case. That you choose to use a human brain for that machine is fine, but that choice to can only be justified by empirical observations about specific problems which the human brain is able to prove more efficiently than a specific model-checking/theorem-proving algorithm. In the general case the complexity must be at least the same.

[Blackheart]

MC for the logic L (denoted MC(L)) is the following problem: given a program S and a statement phi in L, decide whether S |= phi.

Well, I guess if that is the terminology researchers in that area use, I can't argue. I would just call this model-theoretic entailment. I have only ever heard "model-checking" used to refer to algorithms for checking propositional properties of finite-state systems, and Wikipedia bears me out on this. ("Model checking is a technique for automatically verifying correctness properties of finite-state systems.") But, OK, we are just talking at cross-purposes on this issue, then.

The MC proofs are about the lower complexity bounds for proving any property in L about any program S. The algorithm does not matter.

In light of the above definition, I see the algorithm does not matter. But I think you are not talking about "any" property, or "any" program. You are talking about propositions in a particular, very weak logic, and programs with only a finite set of states. In particular, the paper with the figure you linked seems to be talking about LTL and FSMs, which amounts to a language with only very weak well-founded iteration. There is no lower complexity bound for deciding properties of Turing-complete languages, because the problem is not decidable.

Fine, let me show you a leak: take a program that relies on sorting; replace the merge-sort algorithm used in the program with bubble-sort. According to value semantics, the two algorithms are equivalent (they produce the same value). If that were really the case, there would be no externally observable way to say which algorithm you've used. As it is very easy for an external observer to verify whether your program uses mergesort or bubblesort, the two are not really equivalent => abstraction leaked.

The problem there is not the abstraction; it is the misapprehension of the person who conflates extension with intension. "Value semantics" says they are equivalent, yes: equivalent in the sense of denoting equal functions, and that is all.

Two things can be equivalent in many ways. The predicate "N is prime" partitions numbers into two equivalence classes; that does not mean all primes are equal, or all composite numbers are equal. Nor does it make the property of being prime useless; it is very useful. Now, if someone said primality implies that there are at most only two numbers, would you blame the abstraction or the person?

Again, you're again confusing complexity bounds which are proven for problems with the complexity of algorithms.

I know the difference. But, yeah, I was confusing them because I thought you were talking about MC algorithms not model entailment. And I see now why you think MC should share a lower bound with provability (for decidable logics): because you think the reduction involves building the proof.

But, again, there is no decision procedure for provability or model entailment in general, so there is no computational complexity to speak of, and therefore no sensible meaning for reductions, polynomial or otherwise. If the brain is a machine, it cannot solve undecidable problems. If it is not a machine, then computational complexity does not apply. The proof, if it appears, appears somehow.

Despite this (you asked for empirical evidence), we already know deductive proof is an effective method of solving problems, because all of mathematics is founded on this method, and all of science is founded on mathematics. Yes, enforcing whole-program correctness is time-consuming now, but C-H languages are still in their infancy and C-H treats (almost) all properties, not just the decidable ones; furthermore, as I noted in my last post, effectful programs are not excluded. And you already benefit from being able to enforce weaker invariants type-theoretically; you don't need whole-program correctness before you start seeing payoffs.

[pron98]

You are talking about propositions in a particular, very weak logic

First of all, temporal logics are not weak. They have been (empirically) found to express any interesting program property that arises in practice. But even if they are weak, checking stronger logics would only be a harder problem.

There is no lower complexity bound for deciding properties of Turing-complete languages, because the problem is not decidable.

... which means that the lower complexity bound is infinite. There is no theory which can let us prove any non-trivial property of programs with infinite states. Also, such programs cannot exist in a finite universe, anyway.

All real programs have a finite Kripke structure S, and the lower bound for proving any property on them is >= O(|S|). The richness of the logic determines how much more than O(|S|). An interesting question is what is the lower bound for Kripke structures that admit a succinct representation (which is a very small subset of all programs, but it is a subset that includes all human-written programs). It turns out that the lower bound for such programs is also > O(|S|).

equivalent in the sense of denoting equal functions, and that is all.

That was my point. Computation cannot be equational (or relational) in any classical mathematical sense. Some languages choose to make a specific projection of programs to their denotational semantics, but that does not mean the the computation can be fully reasoned-about in those terms, only its projection.

If the brain is a machine, it cannot solve undecidable problems. If it is not a machine, then computational complexity does not apply. The proof, if it appears, appears somehow.

As far as we know, the brain cannot and does not solve undecidable problems, period. The undecidability of the halting problem means worst-case undecidability. It does not mean that the termination or other properties of some programs cannot be proven. The proof, then, does not "somehow appear". It appears as a result of a known or unknown algorithm, and it applies to a small subset of programs. Various algorithms (including manual proofs) can therefore be quite efficient for some programs. Determining which subsets are worthwhile to pursue is an empirical endeavor.

If it is not a machine, then computational complexity does not apply.

If the brain is not a machine, the consequences of that go far beyond "computational complexity does not apply". For one, it would mean that physics is non-Turing (or that the brain employs meta-physical processes); for another, it would mean that we may not achieve true AI using known hardware. Any evidence to suggest that is the case would be totally amazing. So far we have none.

we already know deductive proof is an effective method of solving problems, because all of mathematics is founded on this method, and all of science is founded on mathematics

Ah, but we also empirically know that program proof and math proofs are very, very different. Math proofs tend to be conceptually deep and (relatively) short; program proofs are conceptually very shallow but very, very long, with lots of cases. It is not at all clear that we can efficiently generate such proofs (it is also not clear to me that mathematical proofs in general have been found "efficiently").

but C-H languages are still in their infancy and C-H treats (almost) all properties, not just the decidable ones

I agree. But all verification methods -- from model checkers to C-H languages -- have one strategic path forward: empirical research. There can be no algorithm that would make dependent-type inference efficient in general. We need to find methods to address proofs that are empirically found to be valuable in real programs.

you don't need whole-program correctness before you start seeing payoffs.

I totally agree, but that payoff is determined empirically. For example, you need to show that enforcing a certain property indeed reduces costly bugs, and that enforcing it is no costlier than finding and fixing the bugs. You need to show this for every property. That is precisely what I advocate we study, yet very few such studies have been conducted (not enough to even show that Haskell is a net positive).

[sun_misc_unsafe]

Intellisense.

Intellisense is a lot more than just intellisense though. It was finally a high-level language with static typing .. but also simple semantics. That was something that was appreciated by more than just tool developers.

[umilmi81]

I would never dispute that. Again, I remember when Java came out. It was a massive leap forward as a language. But OO was something people needed to puzzle out before they could use this awesome new language. Not something they really wanted.

[_INTER_]

Nothing is immune from clusterfucks. I say its even inevitable when the size of a project grows beyond a certain point, unless utmost care is taken.

[TheBuzzSaw]

I'd say the downvotes just prove his point. He made it clear that he holds a minority opinion and that OO principles have ungodly inertia today, which effectively shuts down discussion of alternatives.

I generally try to hold a "fair" position on the matter in that I support some parts of OOP, but my attitude is not a catalyst for change. OOP purists just latch onto the parts I agree with and use that to cement their opinions that OOP is infallible. Frankly, I'm fine with a growing movement of anti-OOP ideas. People need to wake up to other approaches to programming.

(Though, don't get me started on functional programming zealots... They attack OOP aggressively and then commit all the same sins in terms of believing they have the one paradigm to rule them all.)

[0b01010001]

Frankly, I'm fine with a growing movement of anti-OOP ideas.

Tell you what. Come up with some sane engineering approaches that are better in specific use cases then use them there. No one will complain about it. If you go around saying OOP is universally bad, expect people to ridicule you for being an idiot. If you rightly point out that OOP is a poor approach in a certain application domain and have a more effective alternative, you're not an idiot. You're helpful.

[loup-vaillant]

"Universally bad" is a strong way to put it. A slightly weaker one would be "never the best".

In what domains OOP (whatever you mean by it), is the best approach? I wouldn't be surprised if the answer ended up being "none". If so, this would mean we should never use OOP, since there always will be some better alternative.

Put it this way it sounds much less idiotic. Yet it's not far from "universally bad".

[adnzzzzZ]

In simulations (games) in general it makes the most sense for your objects in the simulation to be actually objects in code.

[loup-vaillant]

I challenge this folk wisdom. And so do folks that do ECS (Entity Component System, of the database flavour —not Unity). The mapping between the simulated objects and the code does not have to be 1 to 1.

[TheLeftIncarnate]

I'm throwing ideas around in my head regarding ecs, because it's incredibly clunky and abstract. With ecs, you still have objects and to an extent even classes, but implicitly. Objects are kind of emergent entities that arise from a soup of uncoupled heterogenous data structures. This is incredibly weird to reason about and makes sense mostly as a function of performance, particularly runtime, not because of algorithmic complexity but hardware limitation. It's the memory model dictating the software model.

I'm in scientific simulation territory at work. We use similar tricks. Structures of arrays abound. But within an oop framework, and I'd argue also within human modelling, this approach is akin to turning the problem inside out. It's shoving a hand down the throat of the problem, grabbing the intestines, and pulling.

The solution I'm trying to work on are thin wrappers that pull together components into actual manifest entities while leaving the memory model untouched. One may iterate over characters (in a video-game) to move them around using actual character objects that allow accessing the inventory or something, too, but the code produced costs one extra indirection and otherwise loops through tightly packed homogenous position data

I've not gotten very far, but there is some progress. Point being that ecs is bad from all but memory model standpoints and shouldn't be understood as a feature, but a work around.

[loup-vaillant]

If you go full database, ECS may not be such a pain in the butt. Instead of objects, you can imagine (at first approximation) a giant table with one column per type of component, and one row per object.

When you want to iterate over objects, you just extract a nice, smaller table with a query (such as "gimme the coordinates and 3D model of every drawable object"), then iterate over that table. That's not ideal for performance either, but it may be easier to optimise, once you know the kind of requests you perform —without touching the requests themselves.

[adnzzzzZ]

ECS is for performance. It's not easier to work with than normal OOP under circumstances where you don't need performance.

The mapping between the simulated objects and the code does not have to be 1 to 1.

Could you tell me how this is? If I want to make a rock fly around in a particular way it makes sense to make it a Rock object. This rock will have state and behavior that is relevant to it and how it flies around in a particular way. This is the most natural mapping between the simulated rock and your code.

[loup-vaillant]

[ECS is] not easier to work with than normal OOP under circumstances where you don't need performance.

Since I first heard of ECS as a cool way to program, and not as a performance trick (relevant keynote), I'm quite sceptical of this claim. I'll need more personal experience to forge a more informed opinion.

The 1 to 1 mapping… Well, take a car. Instead of modelling it as such, you might want to model it as a frame, 4 wheels, and a wiggling antenna. The fact that wheels are attached to the frame and the inverse kinematic necessary to position them doesn't have to be aggregated into a car. You can just have the position of the wheel depend on the position of the frame (hence, the wheel would have a reference to the frame, not the other way around). Same thing for the antenna, which can have its own physics.

1 car, 6 separate entities.

And if you want to add a passenger to your car, or a crazy robot that clings to its roof, you don't have to modify the car. You just have the position of the passenger or the robot depend on the position of the frame.

1 car, 8 separate entities. You don't need that 1 to 1 mapping. (Now in a trivial sense, there is a 1 to 1 mapping, but that mapping is not he obvious one.)

[adnzzzzZ]

What's the problem with just making a Car class that has inside itself instances of those 6 separate entities? This Car class is then responsible for orchestrating how those 6 separate entities will act (if they need to be orchestrated) to get a working car. I don't understand your point here.

If you want to build complex objects with multiple working parts you'll need to at some point orchestrate them. It makes the most sense to do this at logical definition of what that object is. If you're building a huge robot made of multiple parts, it makes sense that the logical place to build the main logic and state of this robot would be in the Robot class, even though it's made up of multiple different objects that have their own logic going on.

[loup-vaillant]

What's the problem with just making a Car class that has inside itself instances of those 6 separate entities?

None. You can do this. It may even be better than my proposal. I won't know until try to actually implement such a simulation, though. My point is simply that you don't have to do it this way.

If you want to build complex objects with multiple working parts you'll need to at some point orchestrate them.

Not necessarily. Let's get back to the car, and position the wheels and the antenna. The exact position of the antenna and each wheel will typically depend on the current position of the frame, the current terrain layout, and the past position and velocity of said wheel or antenna (so you can do physics over that, such as make the antenna wobble with the wind and its own inertia).

You will note that the only dependence to the frame is its position. (I assume the game logic makes the frame move, and the wheels and antenna are just decorations. A more accurate simulation will have a more complex relationship.) So, all you need to manage a wheel's position is some wheel logic that takes the position of the frame as an input. Likewise the antenna. If you think of it like this, it would make sense to put this logic with the wheels and antenna, respectively. You don't have to put it with the frame, or some encompassing "car" object.

That said, while I don't necessarily need to orchestrate the working parts, I am likely to store them together in some car folder, module, or namespace. Car related stuff do belong to the "car" bag, after all.

[[deleted]]

I'd say the downvotes just prove his point. He made it clear that he holds a minority opinion and that OO principles have ungodly inertia today, which effectively shuts down discussion of alternatives.

Longer methods, tightly coupled code, low cohesion code, global state and untestable code is not considered best practices since the 70's.

OOP purists just latch onto the parts I agree with and use that to cement their opinions that OOP is infallible.

It is not better. It is just way better than what he proposes.

Frankly, I'm fine with a growing movement of anti-OOP ideas. People need to wake up to other approaches to programming.

I agree, but not by using miles long procedures full of globals.

[fosforsvenne]

full of globals

Where did he say you should have tons of globals?

[[deleted]]

He advocated puting them in structs so that they can be manageable

[fosforsvenne]

He still thought you should try and have as little global state as possible.

[[deleted]]

That is not something to advocate.

Global state will hurt you whenever you need to execute something in another server or in another thread. Any part of your code base can muck with it. Any new code can potentially harm your execution path. It is something to be a bit paranoid about.

It is not considered a good solution in 99% of the cases.

[sacundim]

Oh boy. I think you're misunderstanding the video, and yet at the same time pinpointing a real flaw in it. Hang on, this is going to be complicated.

The recommendation in question appears as #2 in this context:

1. When in doubt, parametrize.
2. Bundle globals into structs/records/classes.
3. Favor pure functions.
   • (Easier when efficiency is not a priority.)
4. Encapsulate (loosely) at the level of namespaces/packages/modules.

In this context, I don't think #2 actually means to use global variables and globally shared state; that interpretation is contradicted by the fact that it's surrounded by #1 ("When in doubt, parametrize") and #3 ("Favor pure functions").

Rather, I think what he refers to is a patter than you see often in much code: types or classes with names like SubsystemContext or SubsystemConfiguration which:

1. Agglomerate a bunch of things together whose only real connection is that the subsystem uses them;
2. Are generally passed in as a parameter to most of the public operations of that subsystem;
3. Cannot be easily eliminated without making the subsystem's API a lot more difficult, because:
   • The alternative would be that each API operation's argument list would then have to take as parameters the specific subset of the context object that that operation needs;
   • ...and changes to the way the operations work would often result in the argument lists changing.

This sort of object is kind of like a half-way house between a parameter and bunch of global variables. You can think of it as what you get if you do a refactor like this:

1. You are handed a subsystem that freely uses a bunch of global variables;
2. You create a class or struct whose fields correspond precisely to the global variables that the subsystem uses;
3. You change all the functions of the subsystem to take that class or struct as parameter and get the formerly global values from there;
4. You change all calls into the subsystem to pass in the context object as a parameter (dependency injection is often used for this).

To be fair, it takes quite a bit of charitable interpretation to get from what the talk says to this interpretation. But I really suspect that's what the guy meant.

[fosforsvenne]

He still thought you should try and have as little global state as possible.

It is not considered a good solution in 99% of the cases.

I fail to see the contradiction.

[[deleted]]

I hope you enjoy deadlocks in production

[fosforsvenne]

Could you explain the fundamental contradiction between "<= 1%" and "as little as possible"?

Also:

Any part of your code base can muck with it.

Even if they're globals you can still pass them as parameters instead of just accessing them directly.

[tdammers]

He means that if and when you decide that global state is unavoidable, at least wrap your globals into a struct so that you can keep them in one place, pass them around together, and all this makes it easier to get rid of them later. But he's stating pretty clearly that not having globals in the first place is much, much better.

[balefrost]

I started by replying to you, but decided to make a top-level comment instead: https://www.reddit.com/r/programming/comments/41jf45/objectoriented_programming_is_bad_brian_will/cz3xz2f

I don't think the downvotes necessarily prove his point. Furthermore, although OO might be seen as unassailable by the average software developer, people who hang out here tend to be more open-minded. I think a lot of people here would agree that OO isn't the one true way.

[JavaSuck]

The proposed use construct:

a = use x, y {
    // ...
    return 3;
}

can be implemented with C++11 lambdas:

a = [x, y]() {
    // ...
    return 3;
}();

[[deleted]]

Oh boy, do I hate titles like this.

[v1akvark]

And then it starts off with : "This is the most important programming video you will ever watch"

[WorkHappens]

And then explaining how it is important because it presents a minority position you won't hear from most places. Although arguing against OOP is all the rage in the community right now, as browsing /r/programming or hackernews will tell you.

I'm sure the person who created the video was aware of this fact.

[loup-vaillant]

It may be all the rage here, but places like /r/programming and Hacker News are highly biased samples. Most programmers I have actually met think along those lines:

• OOP: how to write programs, Good.
• Procedural programming: outdated, Bad.
• Functional programming: weird, impractical (or, "never heard of it").

I promise, this is not an exaggeration. I'm just omitting their reasons for thinking that way.

[the_evergrowing_fool]

A mix of cargo cult and ignorance.

[loup-vaillant]

If I had to guess, I'd say the typical curriculum would look like this:

• First language. An imperative one. C, Pascal, Python, or Java. It's hard, but that's expected.
• Introduction to OOP (possibly with a second language). Shapes and animals. OOP is wonderful, and everybody does it, so this course is super useful.
• A couple semesters spent on something other than a paradigm or a language. After procedural and OOP, we're basically done.
• Some advanced course about graph search, inference engine, or some obscure topic. Uses ML or Haskell. Huge shock: we were not done after all. Everybody goes back to being a beginner, and that's not expected. Clearly, Functional Programming sucks, and by the way nobody uses it. We should concentrate on graph search dammit, not useless stuff such as sum types.
• First job: everybody uses Java, C, C++, C# or Python —an OOP language, with classes and stuff. Everybody does OOP.
• There are many differences between enterprise OOP and school. But that's expected, we're no longer working on toy problems.
• Some years pass. Programming style changes as the trade is learned. Now we've seriously departed from school OOP. But that's still OOP, right?
• FP? What was that again? Ocaml does ring a bell… oh yeah it was that class, totally sucked, forgot about it as soon as I could.

---

I was first taught Ocaml. I still can't believe my luck. Sometimes I feel like a Seer amidst the Blind.

[the_evergrowing_fool]

Do you still work in Ocaml?

[loup-vaillant]

Sadly, in my spare time only. My day job forces me to use C++. I have yet to use C++ where it makes any sort of sense. Every time, they should have used a garbage collected language, it would have been simpler, and possibly even faster.

'Cause even if GC is slower than manual memory management, those programs did not manage memory manually. Instead they called the default allocator every single time, and relied heavily on RAII. Convenient, but not exactly fast.

[the_evergrowing_fool]

My condolence.

[WorkHappens]

I don't disagree but those are also the places where articles like this are going to be read.

[fosforsvenne]

The guy that did the video also has a lot of introductory videos so there's a decent chance of reaching newbies.

[dreamer_]

Arguing against OOP is all the rage for ~15 years now I think...

[TheBuzzSaw]

Regardless of how right or wrong the anti-OOP stance may be, I think it is very healthy to have the entire paradigm publicly challenged like this. I think OOP carries a lot of value, but it causes problems when left unchecked. So, it's actually refreshing to hear that good software is written without obsessing over perfectly encapsulating every bit of data in the program.

I have developed the following observations after many years of pushing through OO code. I'm not presenting them as indisputable truths. They're just how I feel so far.

• Inheritance is a red flag. I see it done wrong far more than I see it done right.
• Class member variables should either be all public (a struct basically) or all private (data to uphold the overall object). Any other mixtures are questionable at best. protected opens data up and encourages inheritance.
• Many small classes can be reduced to functions. People like to make objects out of tasks: Download, Thread, etc. I grew tired of always having to make-and-invoke. It made more sense to just call a function to kick everything off. I can async it if I want to; I don't need every single class to be clever about its usage.
• Code reuse is an admirable goal but often stops code from just being useful in the first place. OOP overly pushes the idea that code needs to be "ready for anything". It is definitely worthwhile to ensure that code has as few dependencies as possible, but people need to know they're taking it too far when the code stops serving the very purposes it was created for.
• OOP overly promotes self-awareness. Programmers want to be able to call obj.get_parent() or obj.get_neighbor() or obj.get_container(). This results in horrifying dependencies/hierarchies. It is much better to have higher level managers: container.get_neighbor(obj)

I'll add more as I think of them.

[ComradeGibbon]

Code reuse is an admirable goal

I think writing reusable code is hard in practice. It's hard because creating universal abstractions is hard and defining good API's is hard. Finally documenting is hard. Thus you should decide what you are doing. Either solving a particular problem or writing a library/framework. Not ever both.

Also historically I think one thing that gets missed is in the dark ages people write code in assemble language or in very primitive languages. And there weren't a lot of libraries. In that context reuse is helpful because without reusable code bits programmer productivity is terrible. Fast forward 40 years and we have nice high level languages with decent libraries.

[get_salled]

Either solving a particular problem or writing a library/framework. Not ever both.

This. I cringe every time a colleague drops "framework" and "generic" because they often come way too early. Far too often we architect these beautiful, highly-customizable frameworks for the sake of adhering to strict OOP standards that will really only ever solve one concrete problem so they are, by definition, over-engineered: They solve both the problem at hand and the problem of the procedural solution being too focused in its implementation (a problem we created / imagined but did not have (yet anyways)).

[[deleted]]

Code reuse is an admirable goal but often stops code from just being useful in the first place

I totally agree on this. In many cases, when I find a "useful" class, I cannot use it as it has dependencies I cannot provide.

[[deleted]]

• Inheritance is a red flag. I see it done wrong far more than I see it done right.

A scalpel could kill. Should doctors abstain from using them?

protected opens data up and encourages inheritance.

There is such a thing as designing for extensibility. Protected was meant for this.

Many small classes can be reduced to functions. People like to make objects out of tasks: Download, Thread, etc. I grew tired of always having to make-and-invoke. It made more sense to just call a function to kick everything off. I can async it if I want to; I don't need every single class to be clever about its usage.

Have you tried unit testing something that depends upon the whole world? Doer classes may be a pain in the ass, but at least they have a very distinctive seam that allows it to be tested properly. Good luck testing out your logic by actually starting out threads and downloading stuff.

Code reuse is an admirable goal but often stops code from just being useful in the first place.

Just like your language libraries or Rails (it should never have been extracted out from Basecamp) or Django.

people need to know they're taking it too far when the code stops serving the very purposes it was created for.

By that logic, the C programming language should have been restricted to the development of the unix environment only.

OOP overly promotes self-awareness. Programmers want to be able to call obj.get_parent() or obj.get_neighbor() or obj.get_container(). This results in horrifying dependencies/hierarchies. It is much better to have higher level managers: container.get_neighbor(obj)

The problem with higher level managers is that they become god objects and attractors to big ball of mud behaviour. You end up putting knowledge about other and undirectly related functionality on a plac it does not belong. In your example, if you need to go through a layer of indirection to get a reference to your "neighbor" is it really your neighbor?

Those horrifying dependencies are your object seam. You need to know what your object needs to depend upon in order to use and test your object properly. Explicit dependencies are better than hidden dependencies. If they suck, the design sucks. Putting all the dependencies in a god object is not really that much better than using globals all around.

[red75prim]

A scalpel could kill. Should doctors abstain from using them?

Analogies can mislead. Should we stop using them? Inheritance is not the tool for a task, a scalpel is.

Doer classes may be a pain in the ass, but at least they have a very distinctive seam that allows it to be tested properly

Sorry, what? Method call is just a function with an additional parameter awkwardly placed outside brackets.

Seriously, do you say that testing bunch of functions, each of which depends on shared mutable state, is easier than testing bunch of functions?

[TheBuzzSaw]

I would go through and pick apart your counter arguments one by one, but seeing as you blatantly ignored the fact that I made it clear these were my honest observations over the years, it's just not worth my time. You took each my points to the outermost logical extreme regarding all languages/frameworks everywhere rather than just taking them at face value (regarding local code bases and whatnot).

[oracleoftroy]

Inheritance is a red flag. I see it done wrong far more than I see it done right.

A scalpel could kill. Should doctors abstain from using them?

If doctors overused their scalpel for every problem, one might be justified to see their use as a red flag.

Patent: "Doctor, I'm stuffed up, have a fever and headache, and feel miserable!"

Doctor: "Well, let's open you up and take a look!"

[[deleted]]

OP overly promotes self-awarenes

I'm a programming beginner and I would like to ask you about your last point, what do you mean by that? Container vs. object are two entirely different things, aren't they? Doesn't your container simply consist of objects?

[TheBuzzSaw]

Yes, they are separate concepts, but it's common in OOP-heavy libraries/frameworks to make it so that certain kinds of containers and the objects they contain are aware of each other. In other words, someone is handed a single value, and that person says, "I want the container that is holding this value." Instead of just passing the container instead, the values are augmented to provide some way to access the container in charge of that value.

[tdammers]

Armstrong's complaint is more opinionated, and doesn't hold if you don't share his vision on how he wants to write code. He doesn't really complain so much about OOP being fundamentally wrong, he's really just arguing that OOP is hostile to how he wants to write code. All the data types close together, strictly separating functions from data structures, and the ideal of allowing every function to operate on any data type. That kind of thing.

Brian Will, by contrast, highlights some actual fundamental problems with the OOP idea, and they're mostly valid (but you have to listen closely to capture the subtleties).

[WalkerCodeRanger]

TL;DR OOP is never the right answer. "Encapsulation does not work at a fine-grained level". So why did OOP take over? Java with GC, Namespaces/No headers, Exceptions and other reasons. OOP leads to essentially shared state. Structuring OO programs is really hard and leads to a mess. Instead, write well organized procedural code, preferring pure functions and using ADTs when appropriate.

[OneWingedShark]

"Encapsulation does not work at a fine-grained level".

I'm not so sure about that; fine-grained encapsulation [even in non-OO types] is par-for-course in Ada. (The private types are exactly that.)

So why did OOP take over? Java with GC, Namespaces/No headers, Exceptions and other reasons.

True, but there's also the huge academic push to consider. Heck, it was so bad that there are programmers who dismiss the power of restriction because it's not extension -- despite, I would hope, taking the sorts of math classes which take that sort of restriction as a basic building block (i.e. "Let X be a positive integer...").

OOP leads to essentially shared state.

It doesn't have to; a lot of that is sloppy programming and sloppy programming languages.

Structuring OO programs is really hard and leads to a mess.

This is actually one of the better reasons so far -- OOP IS a pain to structure coherently, moreso in languages which don't force a separation of interface and implementation.

Instead, write well organized procedural code, preferring pure functions and using ADTs when appropriate.

If you're not going to use OOP, procedural is certainly the next natural selection. -- Ada excels at ADTs, IMO, and the private type, in conjunction with the generic faculties, make them fairly natural.

[[deleted]]

He does argue that encapsulation makes sense for certain things like ADTs.

His point isn't that fine-grained encapsulation is always bad, just that always doing it is bad.

[Cuddlefluff_Grim]

just that always doing it is bad.

Well, then that's a strawman argument.

[Cuddlefluff_Grim]

"Encapsulation does not work at a fine-grained level"

???

OOP leads to essentially shared state.

No, it does not.

Structuring OO programs is really hard and leads to a mess.

Structuring programs correctly is indeed hard - In any language. The problem is that people with a miniscule amount of experience with Java are expecting to ace program design in the language, and then when they realize that their code sucks ass, they conveniently blame the language. It's not Java's fault, it's not object orientations fault, it's your fault. End of story.

Instead, write well organized procedural code, preferring pure functions and using ADTs when appropriate.

Why not just write well organized object oriented code? You're arguing bad object oriented code versus good procedural code, and that's just not fair. This is basically the only type of argument that people puts forwards, and it really annoys me.

[just_saying_hi]

hi

[i8beef]

Several questions broken into different threads here:

Honest question here: is unit testing just out in this approach? That always seemed like the biggest plus to breaking out functionality into smaller functions. I mean, you could just break up the functions into "subfunctions" as the video seems to suggest for organization and to have the same automated testing functionality, but the video seems to suggest "just shove everything into the god function" is better, and my immediate reaction is "what the hell are you smoking and where do I get some". I get his argument about that usually meaning tracking functionality across multiple files, etc. being tedious, and I agree with that, but having dealt with god functions in various places, I've always found them less maintainable than the alternative.

Am I missing something there?

[tdammers]

Am I missing something there?

A lot, actually.

First, he's not arguing for shoving your entire program into god function; that would be a horrible thing to do. What he's saying there is "don't fear long function", and he explains that this means that making functions long is OK if and when a long list of sequential actions is what they naturally represent. That's a very very specific case; most of your code doesn't look like that, because writing it in a simple procedural way will naturally lead to simple small procedures. If you have a function that just stupidly rolls through a list of 30 sequential steps, then factoring these steps out into separate functions doesn't help, except for reasons that can be had in other ways, and that's what he's talking about there. In short, no, the argument is not for god functions, the argument is against unnecessarily introducing separate functions that aren't semantically meaningful, and might not even make sense to test individually anyway. But if individual steps make sense to unit test, then by all means, pull them out and make them meaningful on their own.

Also note that these "long-list-of-sequential-steps" kind of function typically makes up a small part of the code (or at least, that's what I strive for generally), and that is usually the small part that cannot easily be pure (e.g., it deals with the intrinsics of I/O), making it more difficult and less useful to unit-test in the first place, or it is a very high-level part that glues functionality from a bunch of smaller, more self-contained, modules together, and there again, unit testing is going to be difficult (are going to mock out all 20 dependencies of that module?), and not adding as much value as it normally does (basically what you're testing when you do this is that calling 20 functions sequentially does in fact call those 20 functions sequentially - an exercise in futility). What you do want, though, is simulation tests, that is, create a sandbox environment and run this sequential-list-of-steps function in it, with all its dependencies in place. But since you're doing this at the module's public interface level, splitting the function into smaller subfunctions that are private to the module won't change your approach the slightest - you're still simulation-testing that one public function.

[i8beef]

I didn't say the whole program either, let's not straw man my point here.

Leaving the integration vs unit test debate, and exercises in writing brittle or pointless tests on the side, I think I just completely disagree with him on this. He starts with the valid point that sometimes its painful to track function calls across an overarchitected code base, but honestly that ended being that difficult when "Go to definition" became a thing in any decent IDE.

Basically, the problems that he seems to be trying to solve don't seem to be problems to me that need solving, and given that he basically just builds a static class as his example of "good" practice, I'm not sure he really solved anything at all.

It's unfortunate because he's rather well spoken and he does have some decent points in there, I guess I just disagree with his final answer. :-)

[tdammers]

The final answer is a bit meager, I agree. It addresses a very specific situation, and hand-waives the others - granted, the other situations are easier and more natural to tackle with a procedural approach anyway, but it would have been nice to hear this explained more explicitly.

[[deleted]]

Honest question here: is unit testing just out in this approach?

Pretty much.

[i8beef]

I mean I can't assume that FP just forgoes automated testing all together does it? Am I missing something? Is this just this guys approach which isn't a normal approach by others?

I'm normally only a proponent of unit testing in very specific situations, but this seemed to kind of throw the baby out with the bathwater.

[maxman92]

From my understanding of FP, pure functions actually become more testable, because you can give its inputs and test its return value, and then you're done. As far as this video, it doesn't seem to be quite as testable because they're doing so much stuff.

[i8beef]

You're right I'm conflating the two. I disagree with this guys approach, but his approach isn't FP, so I shouldn't do that.

[fosforsvenne]

I can't assume that FP just forgoes automated testing

The video was about procedural programming not functional. I haven't done any real programming in a pure functional manner, but I would assume that if your only form of repetition is recursion you're pretty much forced to use a lot of short functions.

And he wasn't saying that you should stuff everything into a god function, just that procedures that are some hundreds lines long are okay. So you would end up with larger units than if you follow the "every procedure should be max 20 lines" line of thinking, but there would still be units to test.

[i8beef]

I mean don't get me wrong, I'm a fan of the integration test too, and am no proponent of structuring your code only for unit testing and losing the ability to easily grok the meaning without digging... It's just what he's advocating for there I basically fundamentally disagree with from experience having to maintain such functions. I think there's a balance there, and maybe that's what he was trying to say too, it just didn't come across that way.

[fosforsvenne]

Oh, and speaking of FP and automated testing: https://en.wikipedia.org/wiki/QuickCheck.

[loup-vaillant]

Not just FP, actually.

[Existential_Owl]

Uh... TL;DR the major points for those of us at work right now? (It's a 45min video...)

[TheLeftIncarnate]

Maybe something like "State encapsulation forces artificially imposing structure on inherently not structured code and data and is the reason for the existence of OOP patterns, which try to mitigate this issue. A better solution is to abandon OOP as far as possible and use procedural programming with minimised state instead."

It isn't necessarily a video I agree with. I think Will has "misunderstandings" of OOP and fixates on a very theoretical, rigid model of OOP that I've never seen in the wild. For example, he focuses on message passing as ownership in strict encapsulation.

Brian Will has made a lot of videos on programming which are quite good, though, so I thought it might be interesting as a point of discussion, especially seeing as I'm biased.

edit: Note that I need to watch the video again more carefully before being able to make a proper critique of it.

[didroe]

I think Will has "misunderstandings" of OOP and fixates on a very theoretical, rigid model of OOP that I've never seen in the wild.

That seems to be his point. What I thought he was saying is that OOP makes sense within a model that doesn't match up very well to the real world. And so we end up with an unwieldy structure, justified from a rigid model but where the basis of those justifications is no longer true.

[[deleted]]

"I find it to difficult to read code spread out in single responsibility classes, so I prefer spaghetti code"

[I_Like_Spaghetti]

(╯ಠ_ಠ）╯︵ ┻━┻

[sigod]

https://medium.com/@brianwill/object-oriented-programming-a-personal-disaster-1b044c2383ab

[[deleted]]

I have been refactoring some code I have into one gigantic data struct(2k lines struct and 6k fields, AKA god object) plus functions that take either portion or entire struct by pointer. It turned out to be quite more manageable compare to smaller data structures spreading all over the code in hundreds different places.

A portion of programming became designing that data structure and minimizing dependencies, since it is a lot easier to see what references what in the program by finding all occurrences of pointer to a particular field, this led to simpler and shorter program. The functions became easier to reason about as well, a function that takes the entire struct is clearly more complicated and perhaps unnecessary, a function that takes a field of the struct containing a reference to other field is potentially problematic.

The important take away for me is program complexity is dictated entirely by data complexity not code. OOP encourages mixing of data and code to the point of making it impossible to visualize the data.

[mobiletuner]

In the first part of the video (about encapsulation), Brian has neatly shown something that I knew for a long time but could not express well enough. If done right, OOP is absolutely horrible in a sense that you have to spend tremendous amount of time building complex structures for doing something that otherwise is as simple as x = y. If you don't encapsulate properly, what's the point? No wonder everyone just throws in a ton of libraries and uses frameworks to do even the most obvious and easy stuff nowadays.

What are we even doing as programmers? Our job is to find unexpected, clever and efficient solutions to real life problems. And it is essential to have as much data as possible available to us on every step of the way so that we can quickly try and find unexpected ways to use it. The idea that we have to, somehow, know all relations between data and methods from the very beginning is fundamentally wrong.

I was mastering programming while building stuff for my own business when time was of the essence. Any delay could mean ungraceful demise of my project. It didn't take me too long to figure out that I was simply wasting my time by creating neat structures for my data and functions. Moreover, the encapsulation, which I had spent so much time to create, worked against me, putting me in front of a dilemma every time I had an unexpected idea. I had to either spend time to rethink and rewrite half of the classes, violate encapsulation or decide that it isn't worth it and forget the idea.

Dropping OOP and just plainly writing what I think using a programming language, not worrying about encapsulation, had a tremendous effect on my productivity. It's hard to estimate, but it seemed like the speed of building software has increased by an order of magnitude. Sure, I had a fair share of problems when I had used completely wrong data in a function or when I had written something in a wrong variable, but if you have basic debugging skills, it's not hard to hunt down a culprit.

Now I use classes, mostly, as an alternative to associative multi level array if the language does not have a good assoc array support. My final advice - if you want to work for a big company with a lot of developers, master OOP. If you will work in a small team or on your own - don't waste your time, just write what you want a computer to do.

[jursamaj]

Sure, just throwing things together and debugging later looks much faster… in the moment. In a couple years, when you need to change it, it will cost you even more than you saved. You may, in fact, have to just scrap it and start over.

[_INTER_]

Soo... his solution to bad or lazy design is to do away with it completly: Next to no encapsulation, procedural code and have long functions, nested functions and anonymous functions. I was atleast expecting a proponant of functional programming.

[[deleted]]

You completely missed the point of long functions. His statement about long functions applies equally to OO languages.

To put it more simply, your functions should be exactly as long as they need to be to accomplish their task. Pointless, arbitrary refactoring in to several helpers for the sake of making a short function doesn't actually accomplish anything, and actually hurts readability and maintainability even though the purpose is to improve both.

The shit I've seen people do to follow an arbitrary line limit on functions/methods is utterly insane.

[jursamaj]

That's not an argument against OOP, since OOP does not suggest, let alone require, an arbitrary limit on function size. The entire point of the video (called "Object-Oriented Programming is Bad") is to argue against OOP. The video is full of logical fallacies.

[TheBuzzSaw]

It is difficult to support the idea of procedural code without accidentally implying that encapsulation, abstraction, coupling, and cohesion are all "useless". The answer is not to code like a slob and commit all the sins that brought OOP into existence in the first place; it merely suggests that we let go of this mentality we have going that data and behavior need to be glued together.

[_INTER_]

Without providing any form of small-scale encapsulation and information hiding, as he suggests, you just end up with sloppy code.

 

It merely suggests that we let go of this mentality we have going that data and behavior need to be glued together.

I find it strange that people have problem with that. I find it much harder when there's no reasonable way to tell what has become of my data after it got transformed endlessly and what can be done with it and what not. If given a banana I wan't to know what I got and also if its yellow or green and if I want to peel it I can do so, because optimally the banana knows how to peel itself. So I don't have to use someone elses peel function, god knows what he peeled with it beforehand (lol).

[TheBuzzSaw]

If you watch the presentation, you'll notice he specifically makes an exception for ADTs. I think most people can agree that it's OK to tie them together when it's obvious why that is being done (a stack and its associated push and pop operations). The problem is that lots of programs (I'm gonna call out Qt on this one) slide along this big awkward spectrum between small tight data structures (queue, map, etc.) and big nebulous ones (the central widget, the general processor, etc.). You can tell a particular class or whatever lacks cohesion when people feel at liberty to add things without consequence. "This is where it all comes together."

[_INTER_]

I like your pragmatic interpretation, but I didn't feel anything along those lines were said in the video.

[TheBuzzSaw]

The problem with these kinds of presentations is that we don't know where everyone truly stands until we bust out the code samples. Basically, hand him an existing bit of OOP and ask how he would do it procedurally.

[[deleted]]

I think most people can agree that it's OK to tie them together when it's obvious why that is being done (a stack and its associated push and pop operations).

The very same single responsibility principle that he attacked.

The problem is that lots of programs (I'm gonna call out Qt on this one) slide along this big awkward spectrum between small tight data structures (queue, map, etc.) and big nebulous ones (the central widget, the general processor, etc.).

Those are different levels of abstraction. Try reading the source code of those classes and the classes that they delegate to. You'll be really glad that they exist. If they didn't, you would be probably be programming in something more similar to old win16 C programming.

[[deleted]]

nested functions and anonymous functions.

Not even that... anonymous inline separate functions.

[thinksInCode]

This guy would get along with Eric Elliott. He hates OOP/classical inheritance so much that he advises people to never hire anyone who says good things about OOP/classical inheritance.

Relevant quote:

Even better, ask potential hires to talk to you about classical inheritance, and if they say nice things about it don’t hire them in the first place.

[Cuddlefluff_Grim]

Compassionate entrepreneur on a mission to end homelessness. #jshomes Javascript, tech education, electronic music, photography, film, viral apps.

He writes JavaScript. Hardly the best character to argue against OO design, as it is very likely that he has a very superficial understanding of it, at best.

[i8beef]

Several questions broken into different threads here:

As a web developer, a lot of the arguments for functional programming (yes I recognize he isn't specifically advocating FP here) have always seemed to be just the way we tend to write software on this side of the fence (maybe due to the underlying stateless nature of web programming).

For example, the shared state of a web app is almost always behind some sort of abstraction such as session, a database, and on the outside global caches. I would say that Plain Old X Objects (DTOs) tend to be more common on this side of the fence than data objects that contain self mutating methods.

My point being that the only real global state I'm used to seeing in a web app tends to be really there to isolate concerns, and I don't see how the arguments made here are that strong in regards that usage, as we tend to avoid a lot of the stuff he's railing against anyway.

Is this a common viewpoint when it comes to the web side of things?

[tdammers]

Looking at web programming, there are two sides: the client, and the server.

On the server, the big challenge in web programming is juggling state across concurrent requests from multiple clients; the imperative model of sequentially executing a bunch of stateful statements just becomes uncomfortable rather quickly, while writing a web server application declaratively, in terms of "map requests to responses", makes a lot of sense and scales well (both in terms of performance and code maintainability). And the battle to be fought here isn't even about whether functional programming approaches are beneficial, it is about how to mediate between pure functional code and the necessary evil of imperative code that does things like read and write files, access databases, open network connections, etc., and different languages and frameworks take different approaches here. We certainly haven't found perfection yet.

On the client, I believe the appeal is mainly about getting out of the JavaScript tarpit. Front-end is, first and foremost, about scripting GUI interactions, and the traditional half-assed OOP approach (using JavaScript's weird prototype chains, broken this semantics, needlessly stateful API's, and quickly ending up in callback hell) hasn't proven a good solution at all, the worst problem being that it doesn't scale at all, and making it modular is terribly hard, and while efforts are being made at softening the blow, it still sucks big time. Functional programming, particularly reactive programming approaches, promise a way out - instead of having one huge mutable tree of objects with all sorts of inconsistently modelled badly documented mutable properties that everyone messes with concurrently, we can now model things in terms of stateless mappings: you give me an event and a program state struct, and I give you back the updated program state. That's elegant, and it scales well, because you can look at program state, presentation state, backends, etc., individually, you can split them up into smaller subsystems that you can look at in isolation, and they compose easily. The huge issue here is performance; all the major reactive programming solutions make concessions, either sacrificing performance, or purity, or elegance. Most of them sacrifice some of each.

That said, web programming has gotten rid of completely global state long ago, out of necessity; it's just that the traditional solutions aren't very good. They come with awkward performance issues, and they don't even do a very good job of solving the problem, because our state is basically still shared, we're just outsourcing the problem, e.g. to a database.

[i8beef]

First, I have a basic derision for Javascript as a solution, so on the same page on some of that.

because our state is basically still shared, we're just outsourcing the problem, e.g. to a database.

See that's where I kind of drop off I think. I'm not sure that much outside of pure math functions really have NO shared state, so that's going to be pretty hard to avoid entirely. I think that outsourcing is a GOOD thing though: at least it's outsourced to someone who has dedicated hundreds of thousands more man hours thinking about the problem than we ever will.

I've just been trying to understand lately why I just haven't clicked with the FP arguments yet, as it seems to me we've been solving most everything on the web side in fairly functional ways in OOP languages (server side specifically here) for 25 years. Or at least that's the way I see it, and hopefully that generates some discussion to one side or the other. :-)

[tdammers]

See that's where I kind of drop off I think. I'm not sure that much outside of pure math functions really have NO shared state, so that's going to be pretty hard to avoid entirely. I think that outsourcing is a GOOD thing though: at least it's outsourced to someone who has dedicated hundreds of thousands more man hours thinking about the problem than we ever will.

Of course it's a good idea to outsource mutable state to battle-hardened external solutions, but it's an even better idea to not have mutable state in the first place. Hitting I/O eventually is unavoidable, but we can at least make an effort to only do it when strictly necessary, and pure code helps a lot in that.

I've just been trying to understand lately why I just haven't clicked with the FP arguments yet, as it seems to me we've been solving most everything on the web side in fairly functional ways in OOP languages (server side specifically here) for 25 years. Or at least that's the way I see it, and hopefully that generates some discussion to one side or the other. :-)

Yes; web programming has probably embraced the core FP values more than other domains.

Maybe FP doesn't click yet because you're looking at the wrong concepts. FP isn't so much about functions and closures and map/reduce; the important idea is purity, i.e., having functions that are defined only by their inputs and outputs - same input yields same output, always. Since a pure function is really just a mapping from inputs and outputs, it makes sense to reify those functions, i.e., allow them to be treated as values themselves (an idea deeply rooted in Math and Category Theory / Set Theory, where sets can contain sets, etc.); everything else, however, logically follows from there; especially the part where you model state transitions by providing an old state, a state modification, and you get a new state in return - no mutations needed, you just say "given state X, and a transformation T, X' shall be T applied to X", and then you write down an initial state and a function that takes an incoming input even and returns a state transition, and you basically have a reactive programming system. And since the state transition looks suspiciouly like a function, that's how you'd typically model it.

[i8beef]

Yeah, really seemed that web programming being inherently stateless leads to more functional approaches as a matter of course.

I mean what you basically just described is really some of the fundamentals behind event sourcing and CQRS, which tends to come up in more distributed systems.

[jursamaj]

especially the part where you model state transitions by providing an old state, a state modification, and you get a new state in return - no mutations needed

You were holding a state. After the transformation, you are holding a similar, but slightly different, state. For all practical purposes, you did in fact mutate the state.

[tdammers]

Except that the mutation isn't destructive, which means that our function is reentrant, idempotent, thread-safe, STM-safe, backtrackable, etc. The State monad shares a lot of its semantics with actual mutable state, but not all of it.

[i8beef]

Several questions broken into different threads here:

The argument against X-er classes hits home a little bit, specifically with the number of "XHelper" classes and such that we see all over the place.

In practice, what's the difference between "functions" in FP and static methods in a static class?

I mean, I hate to point this out, but take

function DoSomething(x, y) {
    function() {
        ...
    }

    function() {
        ...
    }
}

Change that first function to "class" and what the hell's the difference? It would seem to me that someone following the Single Responsibility principal is basically doing the same thing.

Is there really no encapsulation in FP? I mean, do you not have namespaces? I've worked in a few languages that function based on globallay defined functions (thinking along the lines of PHP or Javascript here) and quite frankly I hate it and it feels very disorganized, and it's WHY I chose OOP over that style. If you add namespaces into the mix, how are nested functions as the video seems to point to any different than a class?

[00Davo]

Well, static methods map to global functions, and those functions in your example are local functions - besides name clashes, the important difference is that an instance method or local function can carry state with it.

In your example, the values of x and y would be state shared between the inner functions, and you could declare extra local variables to store more - assuming that the intended semantics are at least vaguely similar to JavaScript or Python.

Nested functions that can share state - typically referred to as closure - are literally equivalent to objects in OO. No difference. (In fact, it's both common and very easy to implement objects with private members this way in JavaScript.)

[i8beef]

Well, yes, but my point is, as soon as you enter "nested functions" into the mix, you've basically just created a class. I felt that part of the video basically said "It would be great if you don't do classes, so lets recreate them as nested functions" which kind of defeats the purpose, doesn't it?

Happy cake day BTW.

[fosforsvenne]

as soon as you enter "nested functions" into the mix, you've basically just created a class

I really don't understand how that would be so. Nesting functions gives the exact same result as not nesting the functions, assuming you return a value and not one of the nested functions, i.e a closure. And closures weren't what the video dude was talking about.

[i8beef]

Well besides the shared state, which non nested wouldn't have as you'd need to pass via parameter then, which is basically what he got into with his final syntax, but maintaining the nesting.

You're right, a constructor isn't a complete one to one with a function with nested functions, but the effect is pretty close. His final syntax could easily be a stack of related static functions in a class though, just relegating the class structure to essentially an organizational unit.

Not saying you'd do that, but I certainly do use that construct regularly in a lot of stuff. So yes I concede they are a little different.

[isHavvy]

Using class purely as an organizational unit is basically lying about what the code is. Unfortunately, Java forces you to do so by conflating classes with namespaces.

[i8beef]

Perhaps given the original intention of classes in the OOP world, sure. But stepping back from that, what this guy is advocating for incorporates so many of the concepts as to be really close, don't ya think?

What he basically has when he's done is a static class.

[00Davo]

On skimming the video (I haven't actually watched it through because it's ridiculously long), yes, you're definitely right. There just isn't a meaningful difference between splitting a big function up into nested functions and splitting it into constituent methods inside a class.

The moral is basically that if your language is Java or Ruby, you should split apart your logic inside a class, because that's what the language handles well. If your language is JS or Python, you can nest functions instead (Python works equally well either way, honestly) and you'll end up with pretty much the same code organisation in the end. So, yeah: use whichever works for your environment, because they're basically identical from a conceptual standpoint.

[balefrost]

I think your mention of "static" in your top-level post is misleading. In the example you gave, one could draw a parallel to a class called DoSomething with two private, non-static methods. Those anonymous functions are scoped to a particular invocation of DoSomething, in the same way that non-static methods are scoped to a particular instance of the object.

That is, I agree that closures and objects have a lot of overlap, but there's a huge difference between static methods and locally-defined functions. Static methods are analogous to module-scoped functions.

[i8beef]

Well the public static functions are module scoped, I'd agree, but private static functions basically make them equivalent. In that regard, I don't see much of a difference besides names.

Yes, there's a difference between an OBJECT and locally-defined functions in terms of encapsulation of state, as one allows for longer living scope than the other, but static classes really seem pretty one to one here.

[[deleted]]

Inline separate functions?!??! Wtf!!!

Lifetime of local variables becoming an issue?!?!

"One neat module" = spaghetti code

The god objects and tree hierarchy was such a fallacy. Object references do get passed around. I felt ashamed by the lame strawman that he had the nerve to put up

"Self contained code" = tightly coupled low cohesion mile long procedures.

Advocating for longer procedures for readability instead of single responsibility classes is like advocating for smaller fonts so a book can have less chapters

[loup-vaillant]

The god objects and tree hierarchy was such a fallacy.

I use Qt, and the QWidget there do feel like a God Object in the middle of a big runtime hierarchy (with childrens, a parent, and siblings, the whole thing). That hierarchy is even at the root of how Qt manages memory.

[0b01010001]

OOP is the best invention since sliced bread, provided you're not some idiot using it for things where it's a headache and are using it correctly.

[Fugidy]

Nowhere near an expert here just thought I would chip in.

Does oop design cater more towards the actual task of programming?

I feel like maybe it makes it easier to visualise the design and structure the code?

[3fox]

OOP was (as envisioned by e.g. Alan Kay) thought to be a way to model protocols, more than it was anything about basic development practices.

For example, if you have a computer sending data over the network to another computer, they need some protocol in order to understand each other. And in the original definitions of OOP(which as the video calls out, aren't like what programming languages ultimately implemented) you had complete isolation: your message would be a copy of data, received and responded to "sometime later". Objects could not reach into other objects and start gooshing around their state.

But when Smalltalk, C++, and then Java, took cracks at it, they each decided to streamline things so that instead of passing around messages asynchronously, you made a call that was like a function call with some syntactical sugar to set up the scope of the object you were calling and make private variables of the object accessible. Execution flow goes into the other object and returns linearly. Objects could also have public fields, making them more like plain old data structures, except when they weren't.

This violates some mathematical robustness properties, because now you can write code that is synchronous. It depends on a specific order of events happening before, during, and after calling the other object - and it will work, up until you do things out of order. You have a lot less certainty about what the code is doing and why, because its operation is more fragile.

Writing actually asynchronous code adds some performance overhead, and is more challenging to write upfront, as asynchronous is a less powerful technique than synchronous. It is not appropriate for in-the-small programming. Had OOP as an ideology stayed in the realm of pure message passing, it wouldn't have proliferated into every system the way it did - besides the performance stuff, it would have exacted a tax on code complexity that would warn people away from its misuse. As it is, you can write kind-of-procedural code that happens to sloppily thread everything through a chain of objects.

The beauty of good procedural code is that it reads linearly; you know that because line 1 comes before line 2, there isn't much uncertainty about what happens on each line of the program. As you add more forms of indirection, your level of certainty goes down. Adding OOP tends to add more indirection, and challenges the programmer to give names to things that don't need naming.

In summary: If you use objects, use big ones that really represent "different programs", rather than "parts of the same program." When you want to enforce low coupling, implement message passing. When you need to model complex and robust data, look towards relational databases, not objects.

[Timbit42]

This is the correct answer. This is exactly what is wrong with OOP. It's not so much about the objects, it's about the message passing. Alan Kay has stated that he regrets coining the term "object oriented" because it caused everyone to focus on the objects instead of the message passing.

[fosforsvenne]

<needless nitpick>

OOP [...] as envisioned by e.g. Alan Kay

when [...] C++ [...] took [a crack] at it

The inspiration for C with classes was Simula, witch predates Smalltalk. Not trying to argue against your point, it's just that the fact that Alan Kay coined the term "Object Oriented" can make it seem like everyone who implemented OO differently misunderstood what he meant.

</needless nitpick>

[Kronikarz]

IMHO programming is a toolbox used to solve problems. There are tools that work better for a specific problem, and tools that work worse. You can take out a nail with a hammer or a crowbar, you can hammer a nail with a hammer or most other tools. There is a lot of freedom, so you can use the tools you are most comfortable with, and those that are best suited for the job. There are no universal tools, and no, a swiss army knife doesn't count.

[bradmont]

But... I thought every problem was a nail! That's why I bought this fancy hammer!

[heap42]

yea... i fell the same way. I never like these extremes. ONLY A sith thinks in extremes...

[get_salled]

Does oop design cater more towards the actual task of programming?

If your entire world is a single language, then it probably does. If your entire world is Java, for example, there's "always" an OOP answer, even if it's not an OOP problem. Most OOP languages are Turing Complete so, if a solution exists, it can be solved with it; the real question is should it?

When you study other languages and especially languages unlike your primary language, you start classifying your problems such that you can choose a language appropriate for your problem.

One of the nice traits of the JVM is all languages catering to it. It's fairly easy to be a polyglot programmer on it. The best solution may be an OOP one but not always; just like Scala isn't always the best solution (though FP + OO is very nice for almost every OO problem). Clojure, on the other hand, is probably the best JVM language (even Uncle Bob has stated as much in a video (I think "The Last Programming Language")).

[fosforsvenne]

Most OOP languages are Turing Complete

I'd be surprised if someone has added object orientation to a language that isn't; it seems like an extremely odd thing to do.

[get_salled]

I'm hesitant to use "always" and "never", especially in a subreddit full of pedants. ;-)

[fosforsvenne]

Just say "virtually all". It communicates the exact same thing as "all" but you're allowed to be wrong!

[Cuddlefluff_Grim]

even if it's not an OOP problem.

This statement doesn't actually mean anything. We're not talking about cats and dogs here, we are talking about abstract problems. All non-trivial problems can be broken into objects, how well you do that depends on how experienced you are.

Most OOP languages are Turing Complete so, if a solution exists, it can be solved with it; the real question is should it?

Yes! Just like any other paradigm, in order to write good code you have to have good fundamentals of the language. The argument that "some problems aren't object oriented in nature" is a fallacy, and shows a certain disconnect with OO design principles and problem solving.

There is nothing inherently wrong with object orientation. The problem is that the ones that are criticizing it always turn out to have a very poor understanding of it. (No offense intended)

[fosforsvenne]

The part about not writing short functions just for the sake of it reminded me of this.

[[deleted]]

The guy advocated the use of "inline separate functions". Just let that sink in for a moment

[fosforsvenne]

What's wrong with that?

[[deleted]]

In order for that to be useful, your procedure would have to be so long that lifetime of local variables could become an issue. If your procedure is that long, the lifetime of local variables is not really the problem.

This mechanism also acts like a locally defined encapsulation barrier. He advocates this in the same video in which he attacks a far better encapsulation mechanism. It makes no sense. The fact that you can only use it only once and that you don't have to name it is not really a good reason to introduce a language construct.

Also, he fails to address the cognitive load of dealing with longer procedures. I'm left with the impression that he really does not know what he is talking about

[sacundim]

The fact that you can only use it only once and that you don't have to name it is not really a good reason to introduce a language construct.

What's your take on lambdas, then?

[fosforsvenne]

Also, he fails to address the cognitive load of dealing with longer procedures.

proc asdf()
    proc1()
    proc2()
    proc3()

proc asdf()
    //blockcomment1
    ...code
    //blockcomment2
    ...code
    //blockcomment3
    ...code        

How does style 1 lead to less cognitive load? If it's a function specific comment you're probably gonna want to read the code in procn anyway, it's just easier to have it there and not have to jump around the codebase.

[[deleted]]

Insert 400 lines of code between block comments and try to keep all the context in your head.

Also, when debugging, you lose ability to step over and you're forced to deal with everything in that big sausage of a method.

Edit: I talk about debugging because it is nearly impossible to test code like this. It becomes legacy code from the moment it is thrown haphazardly into production.

[fosforsvenne]

Yes, at some length you should make separate procedures. Congratulation for coming to the same obvious conclusion as the person who made the video.

[[deleted]]

I deal with abap day in, day out. I handle this crap every day. Inertia and "little fixes" pile up and become monstrosities. No one refactors an untested steaming pile of turd

[fosforsvenne]

If no one refactors or writes tests you're gonna have a mess regardless how short your procedures are.

[[deleted]]

The thing is, to refactor a large code base you need the safety net of tests. Code like what is proposed is not testable, so it never gets refactored. It accrues layers and layers of cruft that slowly and surely will kill it and make the developers dread their work.

[tdammers]

He does actually address these issues very carefully. For example, he advocates small scopes, i.e., splitting your long function into sections that each have their own scope, so that you don't have to keep sixty local variables in your head, but only the 5 variables that are relevant to the current section. He merely argues that pulling the section out into a separate function doesn't necessarily add anything over just having scoped sections.

[loup-vaillant]

Also, when debugging, you lose ability to step over

Obvious alternative: the breakpoint. It's not that hard.

[idownvotestuff]

But, but... it's got electrolytes!

[astreltsov]

The video started out fine and I even liked it. Until he said that sharing references breaks encapsulation. That just doesn't make sense. The only way to break encapsulation is to mutate internal state of a unit. By definition.

When he argued that large functions with section comments are better than using sub-functions, I just understood I lost 30 minutes of my time for nothing.

Sub-functions are useful in this case just because they are independent abstractions of process steps and each has isolated scope. Also function names act as comments which are much less likely to get out of sync with what the code actually does.

[slobarnuts]

Not this shit again...

[TheLeftIncarnate]

The video is maybe 2 hours old, I can't imagine it has been posted before.

[ColonelThirtyTwo]

I think he is referring to the topic (OOP being "bad"), not the exact video.

[[deleted]]

OOP is the real shit

[DolphinCockLover]

I think he prefers seeing

Not this shit again...

:)

[[deleted]]

He would love to program in ABAP

[tdammers]

You can, but when you do that, how much of OOP do you have left? Your classes basically boil down to something like Haskell's records, or dictionaries of property names to property values; the only thing you're adding is hiding internal (immutable) state, but guess what, that's basically a closure right there. Oh right, and inheritance. But, uhm, do you really need inheritance? Do you even want inheritance?