I generally agree that pretty much every codebase I encounter that is heavily abstracted or patterned is overly complex and engineered, and at the same time, suffers from the same amount of bugs and "problems", typically moreso, than it's streamlined counterpart.
This is an amazing post on the downsides to having to adopt patterns: its a flaw in the language of Java. I remember Joel Spolsky commenting on the flaws of OOP programming in his work "The Perils of JavaSchools". James Gosling believed the language needed to protect developers from shooting themselves in the foot in a language like C. But Guido van Rossum had another approach: since code is read more than written make sure its easy to work with (a great idea!). Both Gosling and Rossum were experienced C coders by the way. They are compiler developers.
These are the various explorations done in Programming Language design. It’s natural in any technology (especially computer science).
Java could be considered mainstream at one point…now it’s a cute language which didn’t adapt. We explored it (and a large part of the industry used it), and then moved on.
There are similar issues with various other languages too, which developers always keep discovering after working with a language for a long time.
Fluid Grammar (eg. macros) languages have their own problems.
We always aim for the ‘current sweet spot’ according to the industry’s current understanding.
Personally, I always recommend programmers to be as close to metal as possible when starting out, so that the architecture of the underlying hardware is clear. After that they could just create their own languages.
I generally agree that pretty much every codebase I encounter that is heavily abstracted or patterned is overly complex and engineered, and at the same time, suffers from the same amount of bugs and "problems", typically moreso, than it's streamlined counterpart.
This is an amazing post on the downsides to having to adopt patterns: its a flaw in the language of Java. I remember Joel Spolsky commenting on the flaws of OOP programming in his work "The Perils of JavaSchools". James Gosling believed the language needed to protect developers from shooting themselves in the foot in a language like C. But Guido van Rossum had another approach: since code is read more than written make sure its easy to work with (a great idea!). Both Gosling and Rossum were experienced C coders by the way. They are compiler developers.
Here is a link to Spolsky's "The Perils of JavaSchools": https://www.joelonsoftware.com/2005/12/29/the-perils-of-javaschools-2/
These are the various explorations done in Programming Language design. It’s natural in any technology (especially computer science).
Java could be considered mainstream at one point…now it’s a cute language which didn’t adapt. We explored it (and a large part of the industry used it), and then moved on.
There are similar issues with various other languages too, which developers always keep discovering after working with a language for a long time.
Fluid Grammar (eg. macros) languages have their own problems.
We always aim for the ‘current sweet spot’ according to the industry’s current understanding.
Personally, I always recommend programmers to be as close to metal as possible when starting out, so that the architecture of the underlying hardware is clear. After that they could just create their own languages.