Live data from Hacker News

Using a framework will harm the maintenance of your software

berk.es

521–530 of 550 posts

Re: Using a framework will harm the maintenance of your software

#521
post #465
post #128

Earlier quoted context omitted.

And it is no fun when the manager of the company developing your proprietary framework decides to tank it because of a change in strategy or the competitor buys the company and stops development. Since you have no source code you are forced to do what the commercial interest of foreigners dictate.

That is far, far less likely than a package being abandoned. What happened to your project? What "commercial interest of foreigners" went under that doomed you so?

For example VB6 -> VB.dotnet

Re: Using a framework will harm the maintenance of your software

#522
post #505

Earlier quoted context omitted.

This simply isn't true for, well, every project I've been on. There is always some unique wrinkle in the requirements that means this project needs a different approach. SAP is the classic example of this: SAP implements vanilla business processes (with lots of flexibility built in). Yet every single business implementing SAP needs extensive customisation and modification to make it fit their business processes. Some…

Some have spent millions or tens of millions trying to make SAP fit their business and failed. Any business that tries to make SAP fit their needs will fail to some degree (usually to a large degree, and expensively). SAP will tell you in a heavy German accent that you bought the perfect business practices from them, and if you want to be successful, you VILL make your business fit SAP, not the other way around. In r…

Yeah, I've heard the same. And this echoes what I think happens with frameworks. You cannot make the framework fit your process. You might be able to make your process fit the framework. But the further your ideal process diverges from the framework's process, the more painful it is and the more the benefits of getting started faster are lost.

:s/framework/SAP/g

Re: Using a framework will harm the maintenance of your software

#525
I think this article sums up my experience with frameworks. It's not to say they're worthless but that if you use them then you should minimize how much you modify them based on your stakeholder feedback. That means communicating to your stakeholders the limitations of the framework and the costs up diverging from the framework's structure to build a feature.

Re: Using a framework will harm the maintenance of your software

#526

Earlier quoted context omitted.

> 1. Every sufficiently complex framework-free application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a framework Yet a nicely designed, simple, custom half-framework is cheaper to maintain than a bloated popular framework.

Unless your half-framework has equivalently good documentation as a popular framework (which hardly ever happens), this thesis break apart as soon as someone who didn't implement your in-house creation needs to maintain your project and fix your bugs.

Wrong.

Re: Using a framework will harm the maintenance of your software

#527

Earlier quoted context omitted.

Sorry, I don't accept this very mechanical definition; not only is it a needlessly narrow one, it's downright meaningless in some paradigms, such as when implementing coroutines via continuations, but that doesn't mean you can't have frameworks in Scheme. Conversely, we could describe tuplespaces (a la Linda), or many event- or interrupt- driven systems (like an Ethernet port), as an inversion of control, but whether…

I‘d say Rails is a combination of framework and libraries. Some parts (ActiveSupport, the part that simplifies e.g. date calculations) are clearly libraries. They can be used outside of Rails as well, because they totally ignore the shape of your other code. Other parts (ActionPack, the component that calls your code depending on the incoming web request) are working like a framework. Your code must adhere to their r…

I think it might be better if instead of trying to redefine libraries and frameworks we instead used the terms impure application(frameworks) and pure application(libraries). That would make it evident as to which libraries are actually tainted with impure work and need to be redefined as impure.

When you extend this pure/impure idea all the way throughout the computing eco-system, it quickly becomes apparent that something went wrong a long time ago, and every-time, instead of untangling the mess that is pure and impure into their own buckets, we find a way to run a framework in a framework.

What is an Operating System? What is a container? What is k8s? What is a Programming Language? What is a browser? What is a website? What is next?

Re: Using a framework will harm the maintenance of your software

#528

Earlier quoted context omitted.

I think some of your experiences can be explained by your citing NPM as representative of FOSS. Not that there's anything wrong with the astonishing breadth of functionality available in the NPM ecosystem, but stability isn't its strongest comparative suit. OTOH, Django, which was cited by the author, just doesn't have that kind of volatility in its base features.

> Not that there's anything wrong with the astonishing breadth of functionality available in the NPM ecosystem There are at least two things wrong. One is those things is missing standard functionality (eg, leftpad), and the other is a failure to maintain appropriate hubris (eg, is_even).

I don't think those are criticisms of the repository, are they? They seem like criticisms of modern Javascript.

Re: Using a framework will harm the maintenance of your software

#529
post #521
post #465

Earlier quoted context omitted.

That is far, far less likely than a package being abandoned. What happened to your project? What "commercial interest of foreigners" went under that doomed you so?

For example VB6 -> VB.dotnet

Ah, that's a great example!

Re: Using a framework will harm the maintenance of your software

#530

Daniel Stone once pointed out a key difference between libweston and wlroots, two competing approaches for generalizing the work involved in building a Wayland compositor, to explain why wlroots succeeds where libweston does not. He drew the key distinction between a framework and a toolkit . Weston is the former and wlroots is the latter. The difference is that a framework is in control and defers to your code from…

If you ever feel the need to divulge further into the concept of toolkits as opposed to frameworks, I would be most appreciative to read a blog post outlining such.
Post reply on HN