Using a framework will harm the maintenance of your software • Hacker News Board

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

#361

Post by ddevault » Thu, Oct 13, 2022, 9:27 AM UTC

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 time to time, whereas with a toolkit, you are in control and defer to the toolkit when necessary. A toolkit-style library can still do most or all of the heavy lifting for you in a single library, but this approach is much more powerful and flexible than a framework approach while retaining most of the benefits.

Many people view the framework/no-framework debate from the angle that the no-framework side describes a hodgepodge of libraries thrown together to create a crappy half-framework in the downstream code, but that is not necessarily the case. A "one big dependency" approach works with or without the framework design, and a toolkit design offers many advantages that the framework approach cannot.

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

#362

Post by pjmlp » Thu, Oct 13, 2022, 9:30 AM UTC

vidarh wrote: post #346

flohofwoe wrote: post #318

Earlier quoted context omitted.

The overall program flow in this case is: shell => CRT => main(argc, argv) => exit code => shell (to me, the CRT and C standard lib are not strictly separate, although that's debatable of course)

Except none of these steps are dictated by the C standard library (some may be dictated by some libc's) EDIT: To expand on this: You can call the code from stuff other than a shell; I'm assuming you mean "C runtime" by CRT, and some libc's may have issues without them, though usually only access to argc/argv and atexit(), and you can certainly write C without linking with the initialisation code; and while you'll of…

CRT also does stuff like floating point emulation, loading dynamic libraries on demand instead of at load time (e.g on AIX and Windows), handling threads post C11, or runtime checks in hardened code.

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

#363

Post by nottorp » Thu, Oct 13, 2022, 9:31 AM UTC

> In a framework, unlike in libraries or in standard user applications, the overall program's flow of control is not dictated by the caller, but by the framework.

> In other words, users can extend the framework, but cannot modify its code.

He is talking about a specific kind of framework, not about every library under the sun. And for those he may well be right.

Back when Unity was new, most games done with it kinda looked the same. I don't know if Unity evolved to allow more control/customization or people are just better at working around it now.

And if you browse the web, you eventually run into a bunch of sites that all kinda look the same and act the same. Again, this is due to the framework imposing their way to do things instead of the developers/designers deciding it. I suppose an experienced web dev could actually recognize what framework a site like that is done on without looking at the source code, just based on behaviour.

This may be good for cheap one offs but not so much long term indeed.

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

#364

Post by dandellion » Thu, Oct 13, 2022, 9:35 AM UTC

spion wrote: post #340

dagw wrote: post #252

Earlier quoted context omitted.

Of which you are the creator and expert No, I'm not. The guy who quit 2 years ago was. I've worked with custom frameworks, and while they where both clever and powerful with some quite cool features which would have been tricky to do in a more generic framework, they where also virtually undocumented, fragile, difficult to extend and slow to get people up to speed on.

Building a library or a framework comes with implied obligation to write extensive documentation. I wish more software engineers understood this.

I'm confident most software engineers I've worked with understood this. Usually the problem wasn't understanding that but rather meeting the deadlines and finding the resources to write that documentation. The only time I've seen documentation done really well, the company had a dedicated technical writer whose main job was making sure they had good documentation. Engineers would write the first draft and hand it off to the tech writer. My impression is that many companies don't want to spend resources on that level of documentation, which is the level you'd probably want to roll your own framework.

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

#365

Post by jll29 » Thu, Oct 13, 2022, 9:38 AM UTC

Architectural mismatch leads to a clash when one's own architectur (or framework, for bigger projects) does not align well with another one that one wishes to use. As a friend of mine used to say "frameworks are like hollywood: you can't call us - we'll call you".

If you can, supply your functionality as a toolbox instead.

In the context of NLP, I addressed some of these issues with using frameworks and toolkits in this 2003 paper https://dl.acm.org/doi/10.3115/1119226.1119233 .

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

#366

Post by throwaway0asd » Thu, Oct 13, 2022, 9:38 AM UTC

piokoch wrote: post #265

throwaway0asd wrote: post #73

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. After 25 years of experience writing software I can honestly say I have encountered many people that agree with this, and perhaps all of them (every single one) have not actually experienced writing an application without a framework. This sentiment sounds correc…

Where do you draw the line between using and not using framework. Programming language is a framework over machine language. Java garbage collector is a wrapper around manual memory management. Java Servlets is a pretty thin wrapper over HTTP request/response, is this a framework already? How about Java JAX-RS, it is built on top of Java Servlets and built to handle mostly REST type requests. Same with database conne…

It appears you are falsely using the word framework to describe abstraction. Language is not a framework. APIs are not frameworks. A framework is a tool providing conventions that dictate exactly how to proceed, typically demonstrated as a packaged architecture. The appeal, it seems, is not having to independently form many minor decisions.

It appears bias, and possibly even neurological limitations, largely account for framework dependence. Typically this is self evident when you step back and examine the opinions qualifying that dependency as most such arguments are fallacies from ignorance. Decision avoidance is the primary indicator of ASD.

For example many of the arguments in favor of frameworks will sound something like: ”I tried without a framework once and produced a framework anyways, so therefore you must use a framework”.

Another example: ”The code must broken and slow if not using a framework.” Without evidence (numbers) this is a bias (or a lie). Before making that claim there is likely no performance measure or comparative defect count. In my experience doing this for 25 years rarely measure anything and instead invent assumptions to qualify whatever opinion they want. Example (look at the parent and peer comments for comparison): https://news.ycombinator.com/item?id=33004060

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

#367

Post by vidarh » Thu, Oct 13, 2022, 9:39 AM UTC

pjmlp wrote: post #362

vidarh wrote: post #346

Earlier quoted context omitted.

Except none of these steps are dictated by the C standard library (some may be dictated by some libc's) EDIT: To expand on this: You can call the code from stuff other than a shell; I'm assuming you mean "C runtime" by CRT, and some libc's may have issues without them, though usually only access to argc/argv and atexit(), and you can certainly write C without linking with the initialisation code; and while you'll of…

CRT also does stuff like floating point emulation, loading dynamic libraries on demand instead of at load time (e.g on AIX and Windows), handling threads post C11, or runtime checks in hardened code.

The point is all of that is optional. You can - and I have - write C to be executed on bare hardware with no initialisation code, and depending on your choice of libc you can still use it (though some functionality may not be available).

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

#368

Post by pmontra » Thu, Oct 13, 2022, 9:40 AM UTC

wink wrote: post #308

pmontra wrote: post #189

Earlier quoted context omitted.

Sometimes I stated writing a web app with Sinatra, which is about the less frameworkish thing you can do in Ruby unless you are also writing your own router. I regularly end up having to 1. Either write my own code to query the db and build Ruby objects from the response and viceversa OR use ActiveRecord. 2. Same thing about managing the database schema. Either my own code or someone else's. So why not Rails' well te…

Counterpoint, and let's assume mostly parity of flask :: sinatra and rails :: django. I've usually used Flask and even when I needed a few db operations you could easily contain that to a small part of the code and stepping up to django would have felt like a huge step up in complexity. But I guess it really depends on what you're actually writing - your use case sounds a bit like "something like wordpress" from a "c…

Small REST APIs are usually not very small because they hit the database to perform useful operations, must be tested etc. Furthermore a framework enforced common structure shortens the onboarding time for any developer regardless of the seniority.

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

#369

Post by pydry » Thu, Oct 13, 2022, 9:41 AM UTC

m00x wrote: post #213

Test0129 wrote: post #130

Earlier quoted context omitted.

I've been burned by so many frameworks I am hesitant to use one unless the advantage is abundantly clear. Even something as mundane as an ORM can cause massive problems down the line if you're not careful, or you forgot to anticipate the case you need something more complicated than braindead CRUD. Frameworks force you into a paradigm. Yes, to spin up quicker, get new engineers onboarded quicker, etc a framework will…

> You're bound to their bugs If you do it yourself, you're bound to your own bugs. When they have bugs, it's fixed by a team of highly skilled contributors. Not using frameworks is just an ego problem, or a lack of skills.

I kind of feel that people talk past each other on this issue. If you use a bad framework, no framework is vastly better.

If you use a really good framework, no framework is vastly worse.

From one day to the next there will probably be one or two frameworks which dominate your work. If it's really good you'll have an overall positive impression of them and vice versa.

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

#370

Post by camgunz » Thu, Oct 13, 2022, 9:42 AM UTC

spion wrote: post #359

camgunz wrote: post #335

Earlier quoted context omitted.

These are generally just resource issues. Companies generally won't pay for engineering hours to build really good framework documentation. It's not in the critical path. Companies that know that documentation, as well as tests, compatibility guarantees, security policies, etc. are actually critical components would probably not ever make the decision to take on that engineering burden themselves unless it were a bus…

> In my experience this has been a point in favor of OTS frameworks Its not guaranteed. I've seen many developers spend lots of time trying to get the framework they're working in to cooperate or dig through bad documentation. Framework authors are fallible too and general-purpose software is really hard to get right.

Well, my point here is that even if there are little patches against a framework, we're talking something like 5% of the repo's code is framework-y stuff. If you've got your own framework, then... what even is the limit? 50%? 90%?

I wonder if some of the disagreements in this thread are just like, people in favor of frameworks used Rails/Django, people against them used Spring/Struts.

> Framework authors are fallible too and general-purpose software is really hard to get right.

Yeah, I think that's solved by the "market". There was a big explosion of Python frameworks in the aughts: TurboGears, CherryPy, Pyramid/Pylons, Zope, web.py, etc. etc. Lots of stuff. The ecosystem now is Django/FastAPI (Flask/Tornado legacy apps are either stuck or moving to FastAPI IME). Django got it right.

But more broadly, what are the odds a bespoke framework will do it right? Will you think up a new way to organize controllers, or to abstract auth, or to manage database sessions, etc. etc. etc. That sounds like a nightmare to me; just let me focus on the business logic please, haha.