We could quite easily create a model class that isn’t based on ActiveRecord and have it work as Rails is quite decoupled from ActiveRecord, but there are advantages to keeping our model class inheriting from ActiveRecord.

With the introduction of CPUs which ran faster than the original 4.77 MHz Intel 8088 used in the IBM Personal Computer, programs which relied on the CPU's frequency for timing were executing faster than intended. Games in particular were often rendered unplayable. To provide some compatibility, the "turbo" button was added. Engaging turbo mode slows the system down to a state compatible with original 8086/8088 chips.

The problem with this is that it creates a strong coupling between your code and the implementation, exactly what the interface was supposed to prevent.

Systemd flies in the face of the Unix philosophy: 'do one thing and do it well,' representing a complex collection of dozens of tightly coupled binaries

Svelte started with no decoupling anywhere, with everything available at compile-time. Then <:Component> introduced separation at the component level -- but they're still coupled at properties. The spread feature would fill that gap. I see it as an intentional separation as opposed to an accidental shot at static analysis.

Traditional CMSes are "coupled", which means that the CMS also takes care of the presentation layer responsible for delivering the content to the clients. The content and the presentation are closely interlinked. Typically, content managers create and manage their content through tools like WYSIWYG editors. The CMS then delivers the content according to the front-end delivery layer built into the CMS. Typically, a traditional CMS supports your websites but not much else.

Loose coupling and separation of controls allow for more targeted development and debugging

Most traditional (monolithic) CMS systems are “coupled”, meaning that the content management application (CMA) and the content delivery application (CDA) come together in a single application, making back-end user tools, content editing and taxonomy, website design, and templates inseparable. Coupled systems are useful for blogs and basic websites as everything can be managed in one place. But this means that the CMS code is tightly connected to any custom code and templates, which means developers have to spend more time on installations, customizations, upgrades, hotfixes, etc. and they cannot easily move their code to another CMS.

Remove upper bound in our dependencies Doing this we are only asking people to fork our gem or open issues when they want to use a new version of the dependency and we still didn't tested with it.

for example, comments and identifiers