3 ms·

Object-Oriented Programming – The Trillion Dollar Disaster

22 points by throwaway3157 7y ago

dchyrdvh 7y ago
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 7y ago
  Somewhat obligatory: https://m.youtube.com/watch?v=QM1iUe6IofM https://m.youtube.com/watch?v=QM1iUe6IofM
noncoml 7y ago
OOP of the '90s is the Async Programming of the '10s. Looking forward to reading about the Quadrillion Dollar Disaster in 10 years.
blackrock 7y ago
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 7y ago
  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.
mntmoss 7y ago
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 7y ago
  Like the thought. And list.
ncmncm 7y ago
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.
mikewarot 7y ago
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.
_bxg1 7y ago
Here we go.
7532yahoogmail 7y ago
(Repost & from 2019).

22 points by throwaway3157 7y ago

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 7y ago
Somewhat obligatory: https://m.youtube.com/watch?v=QM1iUe6IofM https://m.youtube.com/watch?v=QM1iUe6IofM

noncoml 7y ago

OOP of the '90s is the Async Programming of the '10s. Looking forward to reading about the Quadrillion Dollar Disaster in 10 years.

blackrock 7y ago

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 7y ago
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.

mntmoss 7y ago

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 7y ago
Like the thought. And list.

ncmncm 7y ago

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.

mikewarot 7y ago

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.

_bxg1 7y ago

Here we go.

7532yahoogmail 7y ago

(Repost & from 2019).