4 ms·

> Most of the time, you end up being wrong on how things should be segregated, and your behavior ends up fragmented across a variety of objects, making it diffi

> Most of the time, you end up being wrong on how things should be segregated, and your behavior ends up fragmented across a variety of objects, making it difficult to easily see the flow of your program. This can only become a problem if you pay little to no attention to modularization, software architecture, and even encapsulation. The responsibility of a paradigm and a language is to allow a developer to freely express their concepts. The programming paradigm is not to blame if the developer chooses to express poorly thought-out ideas that are riddled with detrimental consequences.

julienfr112 4y ago
the problem is not about software development, it's about business logic that change, when a new client arrive and want new features, some feature where not usefull, other needed change ...
- arinlen 4y ago
  > the problem is not about software development, it's about business logic that change, when a new client arrive and want new features, some feature where not usefull, other needed change ... You're giving the textbook example of problems created and solved by putting together a working software architecture. Books like Bob Martin's "Clean Architecture" refer explicitly to needs to accommodate changes to business and application layers, and the need to design components to accommodate changes, and the book is language-agnostic.
hudon 4y ago
I disagree. Consider the Brainfuck argument. You can totally blame Brainfuck and its “paradigm” for detrimental consequences. My point is it’s easier to modularize and encapsulate properly with procedural or functional paradigms because they don’t force you to do that work before you start solving problems. The dev flow is: solve problem, then modularize. With OOP, the flow is: modularize, then solve problem. I’m simplifying and of course you can architect correctly upfront, it’s just harder because you’re doing speculative generalization (akin to premature optimization).
- arinlen 4y ago
  > I disagree. Consider the Brainfuck argument. You can totally blame Brainfuck and its “paradigm” for detrimental consequences. That's a poorly put-together red-herring. Brainfuck is not one of the leading production programming languages that has been used for decades to write all sorts of applications, from operating systems to web services and specially desktop applications, AAA games, and high-performance computing. Brainfuck is a gimmick "esoteric" programming language used as a challenge. > My point is it’s easier to modularize and encapsulate properly with procedural or functional paradigms because they don’t force you to do that work before you start solving problems. The thing is your point does not hold at all. It's trivial to modularize and encapsulate and even isolate components with C++. You only need to want to do it. If you don't want to modularize or encapsulate or isolate components then you get what you want. Don't blame the language for the software architecture you chose to adopt for your project.
  - avmich 4y ago
    I think you miss the point. First you backtrack your generalization regarding languages, which makes one ask what other omitted features have to be present to rely on the statement. Second you're not supporting your claim "It's trivial to modularize and encapsulate and even isolate components with C++. You only need to want to do it." It directly contradicts the observation that programs, when written, are often found to be designed incorrectly, and it's important that the language would support enough their recomposition. Just wanting to make a good architecture doesn't make it right all by itself, sometimes you have to change already existing things, and how easy it is has a lot to do with the language.
zbentley 4y ago
I think you and the GP are actually saying the same things. Where GP says OOP requires you to "create upfront the separation of concerns, before code has had a chance to run...", you refer to allowing "a developer to _freely_ express their concepts" (emphasis mine). I think that "freely" is what GP is complaining about; that OOP practices limit your freedom by encouraging early lock-in and making past decisions hard to revisit in light of new facts. I'm not sure I entirely agree, mind you, but I do think you're in more agreement than disagreement.

julienfr112 4y ago

the problem is not about software development, it's about business logic that change, when a new client arrive and want new features, some feature where not usefull, other needed change ...

arinlen 4y ago
> the problem is not about software development, it's about business logic that change, when a new client arrive and want new features, some feature where not usefull, other needed change ... You're giving the textbook example of problems created and solved by putting together a working software architecture. Books like Bob Martin's "Clean Architecture" refer explicitly to needs to accommodate changes to business and application layers, and the need to design components to accommodate changes, and the book is language-agnostic.

hudon 4y ago

I disagree. Consider the Brainfuck argument. You can totally blame Brainfuck and its “paradigm” for detrimental consequences. My point is it’s easier to modularize and encapsulate properly with procedural or functional paradigms because they don’t force you to do that work before you start solving problems. The dev flow is: solve problem, then modularize. With OOP, the flow is: modularize, then solve problem. I’m simplifying and of course you can architect correctly upfront, it’s just harder because you’re doing speculative generalization (akin to premature optimization).

arinlen 4y ago
> I disagree. Consider the Brainfuck argument. You can totally blame Brainfuck and its “paradigm” for detrimental consequences. That's a poorly put-together red-herring. Brainfuck is not one of the leading production programming languages that has been used for decades to write all sorts of applications, from operating systems to web services and specially desktop applications, AAA games, and high-performance computing. Brainfuck is a gimmick "esoteric" programming language used as a challenge. > My point is it’s easier to modularize and encapsulate properly with procedural or functional paradigms because they don’t force you to do that work before you start solving problems. The thing is your point does not hold at all. It's trivial to modularize and encapsulate and even isolate components with C++. You only need to want to do it. If you don't want to modularize or encapsulate or isolate components then you get what you want. Don't blame the language for the software architecture you chose to adopt for your project.
- avmich 4y ago
  I think you miss the point. First you backtrack your generalization regarding languages, which makes one ask what other omitted features have to be present to rely on the statement. Second you're not supporting your claim "It's trivial to modularize and encapsulate and even isolate components with C++. You only need to want to do it." It directly contradicts the observation that programs, when written, are often found to be designed incorrectly, and it's important that the language would support enough their recomposition. Just wanting to make a good architecture doesn't make it right all by itself, sometimes you have to change already existing things, and how easy it is has a lot to do with the language.

zbentley 4y ago

I think you and the GP are actually saying the same things. Where GP says OOP requires you to "create upfront the separation of concerns, before code has had a chance to run...", you refer to allowing "a developer to _freely_ express their concepts" (emphasis mine). I think that "freely" is what GP is complaining about; that OOP practices limit your freedom by encouraging early lock-in and making past decisions hard to revisit in light of new facts. I'm not sure I entirely agree, mind you, but I do think you're in more agreement than disagreement.