4 ms·

Maybe controversial, but I believe a lot of OOP/Clean Code patterns are the software equivalent of corporate BS.

by alcasa 7mo ago

rdevilla 7mo ago
I agree. Mostly they are copes for lack of first-class functions and multiple dispatch. Go through GoF and you will see this is the case for 80% of the patterns. OOP has no firm theoretical foundation, unlike FP which is rooted in the formalisms of mathematics.
- red_admiral 7mo ago
  Ok, I'm in an argumentative mood, and I think this is more true than not. The first theoretical foundation of OOP is structural induction. If you design a class such that (1) the constructor enforces an invariant and (2) every public method maintains that invariant, then by induction it holds all the time. The access modifiers on methods help formalise and enforce that. You can do something similar in a functional language, or even in C if you're disciplined (especially with pointers), but it was an explicit design goal of the C++/Java/C# strand of OOP to anchor that in the language. The second theoretical foundation is subtyping or Liskov substitution, a bit of simple category theory - which gets you things like contravariance on return types and various calculi depending on how your generics work. Unfortunately the C++ people decided to implement the idea with subclassing which turned out to be a mess, whereas interface subtyping gets you what you probably wanted in the first place, and still gives you formalisms like Array[T] <= Iterable[S] for any S >= T (or even X[T] <= Y[S] for S >= T and X[_] <= Y[_] if you define subtyping on functors). In Java nowadays you have a Consumer<T> that acts as a (side-effectful) function (T => void) but composes with a Consumer<? super T> to get the type system right [1]. Whether most Java/OOP programmers realise the second point is another question. [1] https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/function/Consumer.html https://docs.oracle.com/en/java/javase/21/docs/api/java.base...
delecti 7mo ago
I worked with a junior dev who suddenly got really excited about Clean Code. Every example he brought up left me feeling that there was a kernel of good advice, but the book wanted you to take it to such an extreme that it would result in shitty code.
- ansgri 7mo ago
  I feel like half of junior programmers are susceptible to this.
- jghn 7mo ago
  > there was a kernel of good advice, but the book wanted you to take it to such an extreme that it would result in shitty code I see you're familiar with Uncle Bob's handiwork
- teddyh 7mo ago
  There is now a second edition of that book which has supposedly been rewritten to fix that.
- oldestofsports 7mo ago
  It strongly pushes for max 3 LOC per function, and I am not even joking.
joe_mamba 7mo ago
> but I believe a lot of OOP/Clean Code patterns are the software equivalent of corporate BS. They're the corporate equivalent of USSR soviet style conformism, when everyone had to call each other comrade and refusal to do that had repercussions. Similarly, if you say you refuse to follow the Agile/Scrum manifesto or clean code practices, you get ousted, as that's Haram/not-Kosher in this racket. I still wonder how Valve manage to ship Half Life without Agile or clean code practices.
t43562 7mo ago
I think it's more the idea that if using a pattern is good then using all of them at once is even better.
glitchc 7mo ago
Why is OOP lumped with Clean Code? Objects are useful for managing complex states and relationships. They are complementary, not mutually exclusive, to procedural and functional programming.
- kdfjgbdfkjgb 7mo ago
  I think they meant "OOP patterns". Not that I agree with them
- array_key_first 7mo ago
  Usually when people refer to OOP they don't mean encapsulation, although that's the core tenant of OOP. Encapsulation, private and public etc is a given. Usually they're talking about the other OOP stuff, like inheritance. Inheritance is pretty much bad and is the wrong abstraction for 90% of stuff.
Aeolun 7mo ago
When applied without thinking about why. Yes. Except dependency injection. I really can’t imagine why you’d ever not use that. I suppose it’s possible to overuse, but you’d still have better code than without. Certainly more testable code.
- Scarblac 7mo ago
  Because code becomes harder to understand. With direct dependencies, if you are trying to understand some code that calls some function and what it does exactly isn't completely obvious, you can press a button to go to it, understand it, and come back. With dependency injection it depends on what is going to be inserted during runtime, so you can't.
  - 9rx 7mo ago
    If you can press a button to understand what is going on, "it’s possible to overuse" most definitely applies. Dependency injection, as the name implies, is for dealing with dependencies — things that you cannot observe until runtime. Hence the benefit to testing; allowing you to inject a deterministic implementation while under test.
  - Aeolun 7mo ago
    With dependency injection your interface always describes what your implementation can do. If you see the interface and you have to care what is going to happen when you use it you are doing it wrong.
- layer8 7mo ago
  Unless you mean just regular constructor parameters, dependency injection in the sense of a runtime dependency injection framework is the one thing I try to avoid like the plague.
  - oldestofsports 7mo ago
    That is called a "DI Container", and usually manages the objects and order of instantiation etc. Dependency injection simply means to take objects as parameters, and not instantiate them themselves (which causes "Inversion of Control" also commonly mentioned when talking about DI). DI Containers just makes the managing of objects easier. Avoiding it like a plague seems excessive, did you have a bad experience with them?
antonymoose 7mo ago
Wildly controversial! I look at OOP Patterns as standards and practices. The same way we have building codes for staircases the framing of walls and electrical installations to prevent injury or collapse or fire. Sure, you can dodge a lot of design pattern paradigms and still make a working application that makes money. You can also invent your own system when building your house and maybe nothing bad will happen. That tragedy hasn’t yet struck does not make the building codes bad just because you got away with it.
- domga 7mo ago
  A decent chunk of OOP patterns was due to lack of language features, notably passing and returning functions
  - irishcoffee 7mo ago
    Are you referring to function pointers? I believe C has allowed passing and returning functions from... the jump, no?
    - scott_w 7mo ago
      I recall a lot of this comes from Java 5/6 where I think passing function pointers around was difficult, if not impossible. Back in those days, I had many a conversation with a friend who would ask "can Python do pattern/feature X?" to which I'd respond "it doesn't need to."
    - ndriscoll 7mo ago
      Not just function pointers. E.g. in Scala: def addX(x: Int): Function[Int,Int] = { y => x+y } addX(5) then returns a function that adds 5. So closures, which are equivalent to objects (behind the scenes, the compiler needs to allocate a structure to remember that 5 and know the "member function" to call to do the plus), and usually more straightforward. Once you get used to doing this, you realize it's useful everywhere. In a decent language with functional programming and generics support a lot of GoF patterns can be directly encoded as a simple type signature where you receive, return, or both some function, so there's not really much else to say about them. Like half of the behavioral patterns become variations of the interpreter pattern.
hibikir 7mo ago
OOP pattern were useful for people stuck in a pure OOP language (say Java 1.4) And needed to make something understandable. Today, when many languages, including Java, have reasonable functional programming support, a large percentage of the patterns are over complicated. Just look at the list, and see how many can be replaced with less boilerplate by passing a function, doing some currying, or both.
- bluGill 7mo ago
  That doesn't replace the pattern, it just does the pattern by a different name. Design Patterns was never about OOP - the publisher added OO to the title because that was the fad at the time, but the patterns happen in other systems as well, they are just implemented differently.
hsuduebc2 7mo ago
I believe it's more like formal letter, or prefilled form where you only fill data when required. It actually can be useful.
exceptione 7mo ago
I think you can safely omit 'maybe'. OOP is harder and requires more design experience to achieve good results than functional programming. I welcome you to look at OOP code from people who don't get the patterns. OOP can be wonderful, but the people who aren't able to step up a level in conceptual abstraction should really not touch it. Remember, for many years languages like Java didn't have any concept of lambda's and higher order functions, so design patterns were essential for elegant solutions. As they say, a design pattern is a symptom of the language being not expressive enough. In other words, many design patterns in OOP languages express the same thing as first-class language features in the functional paradigm would do, Visitor vs fold for instance.
SoftTalker 7mo ago
Most of OOP and design patterns was yet another attempt to make it possible for lower-ability (i.e. cheaper) developers to be productive. Just like dimensional lumber and standards like "wall studs are spaced 16 inches on center" made it possible for a lower-ability carpenter to frame a house and have everything fit together properly. Though in the latter case, it actually was successful.
- PunchyHamster 7mo ago
  Nah, the engineering standards like that generally make everyone's job easier; the "pro" carpenter will save just as much time as the newbie, hell maybe more. Design patents are more of "you need to build house with this exact room layout" than "the materials and ways to put them together are standarized"
- mikkupikku 7mo ago
  There's a strong element of that, but there's more to it. It is to the advantage of management that even their experienced developers all speak the same design language, if only because this makes any individual developer easier to replace. Corps don't want a situation where the whole company is hanging off one brilliant programmer's completely impenetrable code. TempleOS is awesome, but not for businesses.

Maybe controversial, but I believe a lot of OOP/Clean Code patterns are the software equivalent of corporate BS.

by alcasa 7mo ago

Maybe controversial, but I believe a lot of OOP/Clean Code patterns are the software equivalent of corporate BS.

I agree. Mostly they are copes for lack of first-class functions and multiple dispatch. Go through GoF and you will see this is the case for 80% of the patterns. OOP has no firm theoretical foundation, unlike FP which is rooted in the formalisms of mathematics.

red_admiral 7mo ago
Ok, I'm in an argumentative mood, and I think this is more true than not. The first theoretical foundation of OOP is structural induction. If you design a class such that (1) the constructor enforces an invariant and (2) every public method maintains that invariant, then by induction it holds all the time. The access modifiers on methods help formalise and enforce that. You can do something similar in a functional language, or even in C if you're disciplined (especially with pointers), but it was an explicit design goal of the C++/Java/C# strand of OOP to anchor that in the language. The second theoretical foundation is subtyping or Liskov substitution, a bit of simple category theory - which gets you things like contravariance on return types and various calculi depending on how your generics work. Unfortunately the C++ people decided to implement the idea with subclassing which turned out to be a mess, whereas interface subtyping gets you what you probably wanted in the first place, and still gives you formalisms like Array[T] <= Iterable[S] for any S >= T (or even X[T] <= Y[S] for S >= T and X[_] <= Y[_] if you define subtyping on functors). In Java nowadays you have a Consumer<T> that acts as a (side-effectful) function (T => void) but composes with a Consumer<? super T> to get the type system right [1]. Whether most Java/OOP programmers realise the second point is another question. [1] https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/function/Consumer.html https://docs.oracle.com/en/java/javase/21/docs/api/java.base...

delecti 7mo ago

I worked with a junior dev who suddenly got really excited about Clean Code. Every example he brought up left me feeling that there was a kernel of good advice, but the book wanted you to take it to such an extreme that it would result in shitty code.

ansgri 7mo ago
I feel like half of junior programmers are susceptible to this.
jghn 7mo ago
> there was a kernel of good advice, but the book wanted you to take it to such an extreme that it would result in shitty code I see you're familiar with Uncle Bob's handiwork
teddyh 7mo ago
There is now a second edition of that book which has supposedly been rewritten to fix that.
oldestofsports 7mo ago
It strongly pushes for max 3 LOC per function, and I am not even joking.

joe_mamba 7mo ago

> but I believe a lot of OOP/Clean Code patterns are the software equivalent of corporate BS. They're the corporate equivalent of USSR soviet style conformism, when everyone had to call each other comrade and refusal to do that had repercussions. Similarly, if you say you refuse to follow the Agile/Scrum manifesto or clean code practices, you get ousted, as that's Haram/not-Kosher in this racket. I still wonder how Valve manage to ship Half Life without Agile or clean code practices.

t43562 7mo ago

I think it's more the idea that if using a pattern is good then using all of them at once is even better.

glitchc 7mo ago

Why is OOP lumped with Clean Code? Objects are useful for managing complex states and relationships. They are complementary, not mutually exclusive, to procedural and functional programming.

kdfjgbdfkjgb 7mo ago
I think they meant "OOP patterns". Not that I agree with them
array_key_first 7mo ago
Usually when people refer to OOP they don't mean encapsulation, although that's the core tenant of OOP. Encapsulation, private and public etc is a given. Usually they're talking about the other OOP stuff, like inheritance. Inheritance is pretty much bad and is the wrong abstraction for 90% of stuff.

Aeolun 7mo ago

When applied without thinking about why. Yes. Except dependency injection. I really can’t imagine why you’d ever not use that. I suppose it’s possible to overuse, but you’d still have better code than without. Certainly more testable code.

Scarblac 7mo ago
Because code becomes harder to understand. With direct dependencies, if you are trying to understand some code that calls some function and what it does exactly isn't completely obvious, you can press a button to go to it, understand it, and come back. With dependency injection it depends on what is going to be inserted during runtime, so you can't.
- 9rx 7mo ago
  If you can press a button to understand what is going on, "it’s possible to overuse" most definitely applies. Dependency injection, as the name implies, is for dealing with dependencies — things that you cannot observe until runtime. Hence the benefit to testing; allowing you to inject a deterministic implementation while under test.
- Aeolun 7mo ago
  With dependency injection your interface always describes what your implementation can do. If you see the interface and you have to care what is going to happen when you use it you are doing it wrong.
layer8 7mo ago
Unless you mean just regular constructor parameters, dependency injection in the sense of a runtime dependency injection framework is the one thing I try to avoid like the plague.
- oldestofsports 7mo ago
  That is called a "DI Container", and usually manages the objects and order of instantiation etc. Dependency injection simply means to take objects as parameters, and not instantiate them themselves (which causes "Inversion of Control" also commonly mentioned when talking about DI). DI Containers just makes the managing of objects easier. Avoiding it like a plague seems excessive, did you have a bad experience with them?

antonymoose 7mo ago

Wildly controversial! I look at OOP Patterns as standards and practices. The same way we have building codes for staircases the framing of walls and electrical installations to prevent injury or collapse or fire. Sure, you can dodge a lot of design pattern paradigms and still make a working application that makes money. You can also invent your own system when building your house and maybe nothing bad will happen. That tragedy hasn’t yet struck does not make the building codes bad just because you got away with it.

domga 7mo ago
A decent chunk of OOP patterns was due to lack of language features, notably passing and returning functions
- irishcoffee 7mo ago
  Are you referring to function pointers? I believe C has allowed passing and returning functions from... the jump, no?
  - scott_w 7mo ago
    I recall a lot of this comes from Java 5/6 where I think passing function pointers around was difficult, if not impossible. Back in those days, I had many a conversation with a friend who would ask "can Python do pattern/feature X?" to which I'd respond "it doesn't need to."
  - ndriscoll 7mo ago
    Not just function pointers. E.g. in Scala: def addX(x: Int): Function[Int,Int] = { y => x+y } addX(5) then returns a function that adds 5. So closures, which are equivalent to objects (behind the scenes, the compiler needs to allocate a structure to remember that 5 and know the "member function" to call to do the plus), and usually more straightforward. Once you get used to doing this, you realize it's useful everywhere. In a decent language with functional programming and generics support a lot of GoF patterns can be directly encoded as a simple type signature where you receive, return, or both some function, so there's not really much else to say about them. Like half of the behavioral patterns become variations of the interpreter pattern.

hibikir 7mo ago

OOP pattern were useful for people stuck in a pure OOP language (say Java 1.4) And needed to make something understandable. Today, when many languages, including Java, have reasonable functional programming support, a large percentage of the patterns are over complicated. Just look at the list, and see how many can be replaced with less boilerplate by passing a function, doing some currying, or both.

bluGill 7mo ago
That doesn't replace the pattern, it just does the pattern by a different name. Design Patterns was never about OOP - the publisher added OO to the title because that was the fad at the time, but the patterns happen in other systems as well, they are just implemented differently.

hsuduebc2 7mo ago

I believe it's more like formal letter, or prefilled form where you only fill data when required. It actually can be useful.

exceptione 7mo ago

I think you can safely omit 'maybe'. OOP is harder and requires more design experience to achieve good results than functional programming. I welcome you to look at OOP code from people who don't get the patterns. OOP can be wonderful, but the people who aren't able to step up a level in conceptual abstraction should really not touch it. Remember, for many years languages like Java didn't have any concept of lambda's and higher order functions, so design patterns were essential for elegant solutions. As they say, a design pattern is a symptom of the language being not expressive enough. In other words, many design patterns in OOP languages express the same thing as first-class language features in the functional paradigm would do, Visitor vs fold for instance.

SoftTalker 7mo ago

Most of OOP and design patterns was yet another attempt to make it possible for lower-ability (i.e. cheaper) developers to be productive. Just like dimensional lumber and standards like "wall studs are spaced 16 inches on center" made it possible for a lower-ability carpenter to frame a house and have everything fit together properly. Though in the latter case, it actually was successful.

PunchyHamster 7mo ago
Nah, the engineering standards like that generally make everyone's job easier; the "pro" carpenter will save just as much time as the newbie, hell maybe more. Design patents are more of "you need to build house with this exact room layout" than "the materials and ways to put them together are standarized"
mikkupikku 7mo ago
There's a strong element of that, but there's more to it. It is to the advantage of management that even their experienced developers all speak the same design language, if only because this makes any individual developer easier to replace. Corps don't want a situation where the whole company is hanging off one brilliant programmer's completely impenetrable code. TempleOS is awesome, but not for businesses.