Hmm good question. I think the conceptual model is definitely simple, but as you say, since it's only a piece of the pattern, many devs opt for obtuse boilerplate (ignoring DRY), rather than buckling down to build higher level abstractions to achieve KISS and make code easy to reason about and navigate/digest. They are afraid to write utility code, or code generators (because it's perceived as hard) to essentially be as lazy as possible and write the least code. So they are lazy and wasteful instead and accrue tech debt and increase illegibility. Most devs don't write their code for humans to read with the simplest conceptual model. I love plain functions. Simple data, single argument, no side effects, simple data out. Most code should literally look like an excel spreadsheet. Classes are table rows, lists of classes are tables, formulas are static mapping methods to new tables. Unidirectional and simple.
My gut blames encapsulation as well. If one can't easily open an engine, and mod it, then we get these weird unreadable codebases like Dan Abramov was referring to. Everybody is solving a small slice of the problem and a lot of the problems internal to the project are hidden and not exposed to the community. I noticed this when I re-implemented entire utility libraries that I later noticed Microsoft had in their own reference source (often with the same signatures), but had not shared. So we get all these npm snapshots of pieces of the problem and people repeating the same solutions all over the place and they're hard to hook together and model cohesively. A big pet peeve of mine is that all code should be public and modifiable from anywhere. Swim not dive.
I suspect encapsulation doesn't scale well, because when one is 200 levels up from a problem (the npm packages folder depth is insane), perspective is lost. My gut says that if there was an R&D group that built an app from the ground up modeling everything like a physicist would, be it temporal logic (reactive extensions), asynchrony (promises), UI component models like react, the mapping of state to UI with redux, the low level rendering of graphics, etc. All those things would need to be in the same codebase to evolve together (as a modelling exercise). The fact that our dev environments don't come with hygienic macros or simple code generators built in (controversial I know), means we can't create DSLs to solve all our issues with minimal bloat when the libraries don't quite capture our requirements.
Unfortunately the difficult nature of code sharing and collaboration fragments this and separates concerns that perhaps shouldn't be separated. Not sure much of this diatribe helps anything though D:
PS: I am not a DRY extremist, I lazily model problems by how many times I see code repeating. Ad-hoc, on the fly with little forethought. Only when my bad code spidey sense tingles, do i step back and think about things. The repetition hints at missing conceptual models and informs what abstractions I create. This is really hard to do collaboratively however, as it requires training people to use a ruthless refactoring algorithm while they code. I still haven't had any luck teaching people how to do this at scale. I've never really taught people anything en-masse, so i'm sitting here on my high horse when perhaps I should be trying to convert a few people at work and see what comes of it. :)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hmm good question. I think the conceptual model is definitely simple, but as you say, since it's only a piece of the pattern, many devs opt for obtuse boilerplate (ignoring DRY), rather than buckling down to build higher level abstractions to achieve KISS and make code easy to reason about and navigate/digest. They are afraid to write utility code, or code generators (because it's perceived as hard) to essentially be as lazy as possible and write the least code. So they are lazy and wasteful instead and accrue tech debt and increase illegibility. Most devs don't write their code for humans to read with the simplest conceptual model. I love plain functions. Simple data, single argument, no side effects, simple data out. Most code should literally look like an excel spreadsheet. Classes are table rows, lists of classes are tables, formulas are static mapping methods to new tables. Unidirectional and simple.
My gut blames encapsulation as well. If one can't easily open an engine, and mod it, then we get these weird unreadable codebases like Dan Abramov was referring to. Everybody is solving a small slice of the problem and a lot of the problems internal to the project are hidden and not exposed to the community. I noticed this when I re-implemented entire utility libraries that I later noticed Microsoft had in their own reference source (often with the same signatures), but had not shared. So we get all these npm snapshots of pieces of the problem and people repeating the same solutions all over the place and they're hard to hook together and model cohesively. A big pet peeve of mine is that all code should be public and modifiable from anywhere. Swim not dive.
I suspect encapsulation doesn't scale well, because when one is 200 levels up from a problem (the npm packages folder depth is insane), perspective is lost. My gut says that if there was an R&D group that built an app from the ground up modeling everything like a physicist would, be it temporal logic (reactive extensions), asynchrony (promises), UI component models like react, the mapping of state to UI with redux, the low level rendering of graphics, etc. All those things would need to be in the same codebase to evolve together (as a modelling exercise). The fact that our dev environments don't come with hygienic macros or simple code generators built in (controversial I know), means we can't create DSLs to solve all our issues with minimal bloat when the libraries don't quite capture our requirements.
Unfortunately the difficult nature of code sharing and collaboration fragments this and separates concerns that perhaps shouldn't be separated. Not sure much of this diatribe helps anything though D:
PS: I am not a DRY extremist, I lazily model problems by how many times I see code repeating. Ad-hoc, on the fly with little forethought. Only when my bad code spidey sense tingles, do i step back and think about things. The repetition hints at missing conceptual models and informs what abstractions I create. This is really hard to do collaboratively however, as it requires training people to use a ruthless refactoring algorithm while they code. I still haven't had any luck teaching people how to do this at scale. I've never really taught people anything en-masse, so i'm sitting here on my high horse when perhaps I should be trying to convert a few people at work and see what comes of it. :)