Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I Hate Frameworks (2005)

factoryfactoryfactory.net

Post reply on HN
Print view View original

261–270 of 407 posts

Re: Why I Hate Frameworks (2005)

#261

Post by strictfp »

grumpyprole wrote: post #258
strictfp wrote: post #253

I disagree with the problem statement; that the framework is trying to solve a meta-problem. The problem with frameworks is instead that they assume that they're in control. They're the program, you're just writing a plugin. This makes it unnecessarily hard to use them in all but the most straight-forward use cases. And they're usually also trying to do too much; config for starting, special way of testing, incompati…

Yes this is possibly why the author renamed the post. There certainly has been a problem of over-abstraction in the industry, with some of the most guilty parties being the frameworks (e.g. the infamous AbstractSingletonProxyFactoryBean from the Spring framework).

Maybe. But that specific overabstraction is in the implementation of the framework. It's trying to proxy all the method calls to objects to perform logic around them. It is true that Spring wants the developer to configure auxiliary logic that gets applied around the written code, instead of actually calling that logic. So perhaps that's what the author was getting at.

Re: Why I Hate Frameworks (2005)

#262

Post by bruce511 »

59nadir wrote: post #236
bboygravity wrote: post #228

Earlier quoted context omitted.

Reminds me of the architect we have at work. By the time he was done formalizing what needs to be done and philosophizing about the best approach (while actively trying to prevent the engineers from hacking away), the programmers and hardware engineers delivered a production prototype that works just fine and that people want to buy.

I wouldn't say that the outcome is necessarily the same all the time, but the getting-nothing-of-any-value-done architect seems to be a common occurrence. We had one that by proxy stopped development on at least 3 projects I was supposed to be involved in because people wanted to make him part of the process, despite me having 10 or so years more experience and an evident track record of successfully greenfielding pr…

I think its good to separate function from title here. There are indeed good architects and bad architects - may you get the opportunity to work with the good ones.

Personally I find that those who ultimately build the thing they architect are the best to work with. As the build they gain experience, they bridge the gap between theory and practice, and the feedback loop leads to better architecture and better code.

But again, humans are in the mix, so YMMV.

Re: Why I Hate Frameworks (2005)

#263

Post by californical »

Aeolun wrote: post #209
californical wrote: post #153

Earlier quoted context omitted.

And interestingly, your argument also falls apart in the same way as the framework argument. It might make the average developer more productive on an average project. But most projects are not average, and neither are most developers. Everyone has some unique combination of strengths, just like every project has special cases that don’t fit within the box of a framework. A framework is great if you don’t know much a…

> But most projects are not average I call bullshit. Most projects are average by definition. Otherwise that wouldn’t be the average.

There’s way too much variance in projects for the average to be meaningful, in my opinion. They will have some or many average parts, but they will also have some number of parts that are special.

It might be normally distributed, but across tens/hundreds/thousands of dimensions. For example, some axes might be

* resource usage requirements * latency * persistent storage options (filesystem/SQL/Redis) * concurrency needs * UI options * error handling technique * etc, etc

Like, if you want a terminal-based UI and don’t need SQL access, then you definitely shouldn’t use Ruby on Rails.

Some of those dimensions are obvious at the start of a project but some aren’t. You might not find out until later that you need something that your framework doesn’t support. And when that happens, you can end up in a situation of hacking together the feature working around the framework, especially if there’s a deadline.

Like I said, frameworks are great if you are very careful with their limitations.

Re: Why I Hate Frameworks (2005)

#264

Post by hughesjj »

LoganDark wrote: post #167
lacksconfidence wrote: post #165

Earlier quoted context omitted.

lol, thats awesome. i suppose i shouldn't be surprised. Can do a heck of a lot with a couple dollars of silicon these days.

And they mark up the price to $200 (that's what the device costed... a 68k in 2017...)

Iirc they had to lobby college board to change the rules to allow colored screens on exams since the black and white screen was more expensive than the colored ones since no one made the black and white ones anymore

I'd be open to allowing smartphones/tablets on all tests so long as there's no internet. Note taking is more important then ever imo, and knowing how to apply things rather than doing he computational machinery in your head is the more valuable skill to spend time developing (not that we shouldn't teach mental computation at all, just de focus it)

Re: Why I Hate Frameworks (2005)

#265

Post by bruce511 »

pdntspa wrote: post #237
bruce511 wrote: post #143

Earlier quoted context omitted.

The carpenter doesn't need a degree. The architect and structural engineer do. If you plan to be a programmer all your life, and a journey-man one at that, then feel free to learn-programming-in-21-days. If you're planning a career in software, then I think understanding fundamentals (database normalisation, the Order of a solution, the ideas of Coupling and Uncoupling, memory usage versus performance, the impact of…

You have such an idyllic view of the college environment. My experience was struggling to motivate my teammates to do anything beyond the minimum, and an endless barrage of "will this be on the exam?" questions during class. Looking back it's no wonder I am a self-learner now.

I guess less idyllic view, and more idyllic experience. I was fortunate to find like-minded folk in my class, and fortunate enough to have faculty that allowed us mere undergrads access to equipment "beyond our pay grade".

Obviously the bulk of the class was there to pass, maybe 10% of us pushed the limits, learning the craft beyond the carricilum. We were probably 10 folk or so from a class of over 100.

It was perhaps easier in my day - we had labs with machines no person owned. So you could spend time in the lab beyond the necessary, and the others would be there too.

I imagine today there's less shared working space like that, but hopefully there are still ways to find like-minded souls.

Self learning is great, and we all do that a lot now, but I've been fortunate to find others in my work community who still enjoy sharing, learning, and teaching. Its a bit less lonely that way, and none of us have all the answers.

Re: Why I Hate Frameworks (2005)

#266

Post by afiodorov »

I've always been hesitant about adopting frameworks, and I still favor Flask over Django. Yet, I spent a couple of years in a Go-centric department where the senior members were so against using frameworks that we ended up building everything ourselves from scratch. This included creating our own load-balancer, event store, and aggregation engine.

When I attempted to point out that we were investing substantial time solving problems that have already been resolved, I was invariably met with references to "frameworks" and "complexity". However, in my perspective, our reluctance to utilize frameworks led to an inflated team size, slower development cycles, and a lengthy onboarding process for new members.

I believe that if we had chosen to use industry-standard tools for our backend & infra (e.g. Kafka, Kubernetes, Apache Beam/Spark streams), we might have had to deal with a higher degree of complexity, but it would have been manageable. I would much prefer to diagnose issues with a Kubernetes deployment than to debug obscure panic-inducing code written by a colleague, which is questionably designed and lacks readily available support.

One of the main advantages of using a framework is standardization: thanks to tools like git, we don't need to familiarize ourselves with every company's unique version control tool. Similarly, if everyone agrees on using Kubernetes and Docker, we can eliminate the need to learn each company's specific deployment process. This would allow us to dedicate more time to providing actual business value, rather than contemplating how our code should be transitioned into production.

As for the department - it just got shutdown due to not making enough money and costing too much.

Re: Why I Hate Frameworks (2005)

#267

Post by davedx »

cabalamat wrote: post #208
sixstringtheory wrote: post #88

Earlier quoted context omitted.

There must be some metric of the resonance of a particular piece by looking at the number of reposts and distribution of comments amongst them (plus an analysis of the sentiment of the comments and characteristics of the thread trees in each separate posting). Just looking at this listing, without looking at the comments in each one, this seems to have a sustained resonance. Maybe I’m biased–it certainly resonates wi…

> it certainly resonates with me! I recently started getting into Javascript 2D game programming. MDN has a nice simple straightforward tutorial[1] on how to make a Breakout game in pure Javascript. Having read this tutorial, it all fits my brain. It's simple and I understand it. There are also lots of frameworks you can use, e.g. Excalibur, which also has a breakout game tutorial[2]. This does not fit my brain: ther…

Yup that’s why I like babylonjs. It’s not so much good documentation but that the docs try hard to have working codepen style examples for almost everything you can think of doing with it. Code as documentation. Contrast with a lot of python docs where you usually get a docpage telling you what the arguments are and the return type but nothing else.

Re: Why I Hate Frameworks (2005)

#268

Post by bruce511 »

ekianjo wrote: post #183
bruce511 wrote: post #143

Earlier quoted context omitted.

The carpenter doesn't need a degree. The architect and structural engineer do. If you plan to be a programmer all your life, and a journey-man one at that, then feel free to learn-programming-in-21-days. If you're planning a career in software, then I think understanding fundamentals (database normalisation, the Order of a solution, the ideas of Coupling and Uncoupling, memory usage versus performance, the impact of…

You either have intellectual curiosity or you dont. Colleges will never give that to you.

True, but seeing others exercise it can release it in you as well.

College does not "give" you anything. It never has. All it has to offer is opportunities for you to "take". You get out of college what you explicitly "take" from it. You can class through taking and passing classes, or you can actively search out every possible opportunity, stretch every boundary, suck every bit of marrow from the bone.

Ultimately college can be a time-passing exercise in fruitless make-work. Or it can be the foundation to an amazing career. Only you can determine which it is though, not yhe College itself.

Re: Why I Hate Frameworks (2005)

#269

Post by adrianmsmith »

josephg wrote: post #248
adrianmsmith wrote: post #244

Earlier quoted context omitted.

> But in the world of the factory factory factory, the apprentice carpenter (who really just wanted to drive a few nails) is now faced with trying to understand the gargantuan complexity of the factory factory factory. Sometimes I wonder if that's the point of all this complexity. (EDIT: I mean really excessive complexity as alluded to in the article with factory factory factories, or 100 microservices all in differe…

Senior here. I think this is an overly cynical take. You want to pick a set of tools which will help you get the job at hand done most effectively. It’s often easier and cheaper to hire or train a team to use a framework or library than it is to reimplement the functionality that library provides from scratch. Eg, if I was building a big single page app, I’d rather use react than reimplement react’s functionality, ba…

You're absolutely right, there is definitely an optimal level of framework usage, for the reasons you state.

I suppose what I meant was really excessive framework usage, the type of which is alluded to in the original article with the factory factory factories etc. I shall edit my comment to clarify that.

Re: Why I Hate Frameworks (2005)

#270

Post by hutzlibu »

josephg wrote: post #248
adrianmsmith wrote: post #244

Earlier quoted context omitted.

> But in the world of the factory factory factory, the apprentice carpenter (who really just wanted to drive a few nails) is now faced with trying to understand the gargantuan complexity of the factory factory factory. Sometimes I wonder if that's the point of all this complexity. (EDIT: I mean really excessive complexity as alluded to in the article with factory factory factories, or 100 microservices all in differe…

Senior here. I think this is an overly cynical take. You want to pick a set of tools which will help you get the job at hand done most effectively. It’s often easier and cheaper to hire or train a team to use a framework or library than it is to reimplement the functionality that library provides from scratch. Eg, if I was building a big single page app, I’d rather use react than reimplement react’s functionality, ba…

"Libraries and frameworks rarely tell you when they’re buggy messes."

GitHub Issues usually gives you a good insight, into what problems exists and whether they get fixed, or not.

(as a senior, you likely know, but others reading this, maybe not)

Post reply on HN