
Object-Oriented Programming – The Trillion Dollar Disaster - throwaway3157
https://medium.com/better-programming/object-oriented-programming-the-trillion-dollar-disaster-92a4b666c7c7
======
mntmoss
I think it helps to know of ways to model problems beyond "arrangements of
objects in patterns" which is the thing that CS education has dropped the ball
on the most: you get the algorithms, you get some exposure to practical
systems, but then there's no checklist of approaches to try, no nmemonics to
learn. Just a faint hope that slathering objects on a problem does something
helpful, propped up in turn by the large body of articles and blogposts that
advertise silver bullet patterns(lately dominated by "ECS", which isn't really
OOP specific but fits in the usual pattern of the hype cycle).

And that is in some ways related to the consumer nature of the programming
stacks in use: If there isn't a named-and-documented "feature" for it, and
it's not in the hype cycle, it's a less legitimate, more hyptothetical
technique.

But what are those other ways? Where's the starting place? My own WIP answer
is:

* Data modelling techniques(beyond algorithmic complexity concerns: data lifecycles, persistence, schema design, and so forth)

* Formal models of finite state(decision tables, statecharts, behavior trees, and so on)

* Constraint solver techniques and their many applications(type checking, physics steps, pathfinding, depedency checking, UI automation).

* Dataflow modelling, with static routes and bounded buffers.

* DSP techniques used to do analysis and filtering of digital events at scale.

There's still an overarching tendency to let execution flow get out of hand,
and our current trend for asynchronous concurrency is an antidote only in the
sense that it motivates the existence of rigor by blowing up easily.

~~~
7532yahoogmail
Like the thought. And list.

------
dchyrdvh
That's an interesting topic, but I think the article fails to address it and
instead resorts to enumerating the long list of well known cliches. I'd be
more interested to learn about the evolution of complexity in software
projects in general, what role OOP plays there and functional programming is
different.

~~~
Psyladine
Somewhat obligatory:

[https://m.youtube.com/watch?v=QM1iUe6IofM](https://m.youtube.com/watch?v=QM1iUe6IofM)

------
blackrock
The problem I found with OOP, is that it requires you to leave huge swaths of
your code open and accessible, while you continue to develop and build out
your code. This requires a larger cognitive load to understand, internalize,
and remember the mechanics of your code and all its relevant business logic.

In C++ and Java, you have these member variables, that act as global variables
within the Object. Any member variable can be accessed at any time, either
read or written to, by internal functions that are allowed to modify it.

This appears to work ok, while you write out your toy code for your CS 101
class, but it doesn’t seem to scale too well when developing real-world
production code.

What I find better about Functional Style development, is that my functions
are much smaller, and all inputs to the function, are validated, and its
outputs fall within a narrow band that is acceptable. And by forcing the
validation of all inputs, this tends to stop defects during development, very
quickly, and very visibly.

The unit testing of pure functions becomes simpler, and it allows you to
systematically perform rigorous validation of your code.

The added benefit, is that once I build out my functions, then all that
complexity, is hidden behind a one-liner function call. And I just pass data
containers from one function to the next, until I get my final desired result.

This helps to minimize the footprint of the codebase, that I must remember and
internalize.

And since most of the parts are just dumb components, now, I can focus on
remembering the core parts of the business logic instead.

Nothing is absolutely perfect of course, but this is as close to a programming
silver bullet as I can get.

~~~
jdlyga
I've worked on projects with a more iterative pipe and filters approach, and
it can lead to situations where it's difficult to maintain or test anything.
The problem that frequently occurs is that there's a new configuration
parameter, but it needs to pass through a dozen different levels to get to the
place that it's used. That and structs on top of structs as parameters gets
very complex fast.

------
noncoml
OOP of the '90s is the Async Programming of the '10s.

Looking forward to reading about the Quadrillion Dollar Disaster in 10 years.

------
mikewarot
I used to use Turbo Pascal, then Delphi long ago... both object oriented, and
useful as heck. These days I'm getting warmed up to Lazarus/FreePascal, as the
Delphi price hikes killed it as an option. I have no idea what a "factory"
is... and hope I never find out. C++, C#, etc all are too darned fixated on
proving how clever the programmers and language designers are.... meanwhile we
just get stuff done in the Pascal world. It's the C that's the problem.

------
ncmncm
Medium again.

OOP, functional, generic, data-oriented, reactive, whatever. It's all just
programming. The mistake is trying to be "pure": different jobs, and different
parts of any job, call for different methods. Everything has a place.

Add to your toolbox, but don't lose what you have.

------
7532yahoogmail
(Repost & from 2019).

------
_bxg1
Here we go.

