I agree. However, I tend to think of design patterns from the nineties as being OO focused things that were compensating for a lack of support in languages and frameworks for some proper abstractions. Back in the day people were obsessing about creating complex inheritance hierarchies to represent the world in objects. This resulted in some awful frameworks and code.
At the core, it always revolves around coupling and cohesion. This is true whether we are talking about c modules, java classes, ruby modules, javascript namespaces, micro services, com components, etc. If it's highly cohesive and has low coupling, it is easy to understand, replace, and test. If it is not, it's a problem waiting to happen.
The same rule also applies to frameworks: if it looks like a big monolith with everything and the kitchen sink included: avoid at all cost because it will inevitably devolve into a convoluted mess. I know plenty of (former) ruby programmers that got disgusted with rails and the javascript world seems to be hopping from one ui framework to another. Bad software starts before you even code a single line.
Some recent innovations in statically typed languages include type inference and go style duck typing: if it quacks like a duck, it is a duck. This blurs the line between "scripting languages" and statically compiled languages. Or put differently, you can have your cake and eat it. Modern javascript is transpiled, which is basically all the downsides of static compilation without any of the upsides. Unless of course the thing you are transpiling has a sane typing system. Like Kotlin for example, or clojure, dart, or even typescript (if you do it properly).
More importantly, features common across these languages add lots of new patterns and ways of solving problems, while at the same time removing the need for some of the old patterns. However, the notions of cohesion and coupling still apply. The flipside of all these new language features that people have access to these days is that there are plenty of new and exciting ways to blow your feet off. Which is one of the reasons I tend to steer clear of scala projects because inexperienced developers infatuated with it seem to attack even the most trivial problems with insane levels of indirection, complexity, and disregard for common sense. Hint: if you can't figure out what a particular bit of code does without opening 40 files that is just about the very definition of high coupling and low cohesion (i.e. the opposite of elegant).
I fully agree on the Active Record thing. A good software design (regardless of language) has separation of concerns. Rails style active records basically confuse views, controllers and models in one big gory mess with convenience as the common excuse. Add monkey patching to the mix (that shit is just plain evil) and you end up with no cohesion whatsoever and model classes that are tightly coupled to their views and controllers. MVC itself is in any case a bit of a controversial pattern and real software designs are much more complicated these days. Server side MVC made a lot of sense back in the day when javascript was for adding redundant effects and each mouse click actually hit the server. These days it's all asynchonous bidirectional communication over http, websocket, etc. The last thing you want is tight coupling between client side views and server side controllers (because then you are doing RPC instead of REST or reactive).
One nice thing about functional programming, which is popping up in all sorts of places these days, is that functions van be easily made to be highly cohesive (does one thing) and have low coupling (not too many parameters). It also promotes sane things like message passing, statelessness, immutability, and other goodness that you actually need to work hard to achieve in other environments.
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.
I agree. However, I tend to think of design patterns from the nineties as being OO focused things that were compensating for a lack of support in languages and frameworks for some proper abstractions. Back in the day people were obsessing about creating complex inheritance hierarchies to represent the world in objects. This resulted in some awful frameworks and code.
At the core, it always revolves around coupling and cohesion. This is true whether we are talking about c modules, java classes, ruby modules, javascript namespaces, micro services, com components, etc. If it's highly cohesive and has low coupling, it is easy to understand, replace, and test. If it is not, it's a problem waiting to happen.
The same rule also applies to frameworks: if it looks like a big monolith with everything and the kitchen sink included: avoid at all cost because it will inevitably devolve into a convoluted mess. I know plenty of (former) ruby programmers that got disgusted with rails and the javascript world seems to be hopping from one ui framework to another. Bad software starts before you even code a single line.
Some recent innovations in statically typed languages include type inference and go style duck typing: if it quacks like a duck, it is a duck. This blurs the line between "scripting languages" and statically compiled languages. Or put differently, you can have your cake and eat it. Modern javascript is transpiled, which is basically all the downsides of static compilation without any of the upsides. Unless of course the thing you are transpiling has a sane typing system. Like Kotlin for example, or clojure, dart, or even typescript (if you do it properly).
More importantly, features common across these languages add lots of new patterns and ways of solving problems, while at the same time removing the need for some of the old patterns. However, the notions of cohesion and coupling still apply. The flipside of all these new language features that people have access to these days is that there are plenty of new and exciting ways to blow your feet off. Which is one of the reasons I tend to steer clear of scala projects because inexperienced developers infatuated with it seem to attack even the most trivial problems with insane levels of indirection, complexity, and disregard for common sense. Hint: if you can't figure out what a particular bit of code does without opening 40 files that is just about the very definition of high coupling and low cohesion (i.e. the opposite of elegant).
I fully agree on the Active Record thing. A good software design (regardless of language) has separation of concerns. Rails style active records basically confuse views, controllers and models in one big gory mess with convenience as the common excuse. Add monkey patching to the mix (that shit is just plain evil) and you end up with no cohesion whatsoever and model classes that are tightly coupled to their views and controllers. MVC itself is in any case a bit of a controversial pattern and real software designs are much more complicated these days. Server side MVC made a lot of sense back in the day when javascript was for adding redundant effects and each mouse click actually hit the server. These days it's all asynchonous bidirectional communication over http, websocket, etc. The last thing you want is tight coupling between client side views and server side controllers (because then you are doing RPC instead of REST or reactive).
One nice thing about functional programming, which is popping up in all sorts of places these days, is that functions van be easily made to be highly cohesive (does one thing) and have low coupling (not too many parameters). It also promotes sane things like message passing, statelessness, immutability, and other goodness that you actually need to work hard to achieve in other environments.