191–200 of 550 posts
Earlier quoted context omitted.
> Frameworks actually add to a deplorable side of the software industry. They encapsulate truly great efforts and wisdom into a package which cannot be unwrapped and used partially. Do you have a concrete non-hypothetical example? Because I don't think I've seen this.
Exactly. The framework I’m most familiar with, Symfony, specifically is arranged to be antithetical to this statement.
“Time will harm the maintenance of software.”
Simpler, more correct.
Earlier quoted context omitted.
I find it highly improbable you have never encountered a Facade pattern. ;)
One of my goals this winter is to clear my head of as much OOP dogma as I comfortably can, fill it with as much DevEx thinking as possible, and read Christopher Alexander, A Pattern Language, from that frame of reference. My very hot take is that we will start referring to everyone who bought first editions of the Design Patterns book as the Lost Generation, because we have completely misinterpreted Alexander's work,…
One may also find it interesting how Elixir/Phoenix-framework uses the OTP to greatly simplify implementation. =)
Frameworks are designed to predict the future about how they're going to be used. They're often wrong in that prediction but people try to write frameworks nonetheless.
If you're not using a public framework then you're writing one from scratch. If you're writing a framework from scratch then you're predicting the future. If you're predicting the future you'll probably be wrong, and the person who came after you is stuck using your framework.
Since most people don't greenfield apps, most people will be stuck using someone elses framework.
The problem with frameworks is the problem with software. How do we design things such that the design has enough flexibility to perfectly anticipate the future?
I don't think the issue is frameworks but rather being locked in to a framework. I'm really interested in seeing where the micro-frontend trend as well as island-centric tools like Astro, Fresh, or Hotwire evolve. Tools like these show it might not be the frameworks themselves but rather the way we use the frameworks that are the issue. Despite React praise for being "a library not a framework", there is a very clear focus on SPAs throughout the ecosystem and I feel like its potential flexibility is really stifled by this
Earlier quoted context omitted.
A framework is what happens when you write a ton of similar apps and factor out the common parts. The quote here is no more literally true than the original lisp quote, but (just like the original) that doesn't stop it from being true in spirit.
If that were true, what would be the difference between a library and a framework? Is a library not also factoring out common parts? Or is a framework just a bunch of libraries? No, this definition doesn't describe what people understand as frameworks.
Quoted post unavailable.
He likes to generalize the kinds of problems he has with Rails and Rails-like frameworks to all frameworks. This seems impertinent, since Rails-style frameworks are a particular style/flavor of framework, those of which I'm sure experience the problems he describes, but more generally? I'm not so sure about that.
Earlier quoted context omitted.
You don't need a framework. You can control execution and use libraries. Once you use a framework changing back is hard. Removing a library on the other hand is easy. Because for libraries you control execution, and for frameworks you have to fuck your code so it will obey the requirements of that framework.
Easier still, Spiral-development doesn't have to plan anything except the next feature... works right up to the point it implodes. Thank you, I will see myself out... ;)
And even then, whats really a "framework"? You could argue it's even the language itself. Android apps used to be written in Java, and now they are pushing Kotlin way harder (and it may even be the default soon). Everyone who wrote those JavaScript apps back in the 1990s without TypeScript, are they still just as maintainable as their TypeScript counterparts? Such a shortsided and ignorant view IMO.
I think what bugs me the most is any sort of purist mentality (about anything) in software engineering. WE ARE ENGINEEERS. ENGINEERS USE THE RIGHT TOOL FOR THE RIGHT JOB! It should NEVER be "always use X", "never use Y". Both X and Y exist for a reason, so they are both useful for some reason.
And again, because I'm an engineer, I've also built my fair share of apps in just "purist" languages, the classic HTML / CSS / JavaScript, so I'm not against the purist approach either. Again, right tool for the right job.