Why I Hate Frameworks (2005) • Hacker News Board

Re: Why I Hate Frameworks (2005)

#331

Post by dreday » Sat, Jul 08, 2023, 1:53 PM UTC

von_lohengramm wrote: post #184

dreday wrote: post #180

You know why this is so dumb? Because there's an analogy that's very similar that explains why we have frameworks. A: I wanna buy a tree. B: Ok. We have trees. What do you need a tree for? A: i want trees so i can make lumber out of them. So i can cut them in two by eights. So i can build a deck deck for my patio B: Hmm we sell two de eights. You wanna buy that instead? A: Oh yes why! I would like that! I'll buy two…

It appears that you are entirely missing the point and the author's criticism of frameworks. Your analogy is the false promise repeatedly fallen for that created the situation described in the story.

No, i get it. But the author analogy is dumb (even if funny). There's literally no one stopping you from just downloading a "hammer" from the internet and just using that. The "stores" haven't stopped selling "hammers". Even if they're also selling "factory factory factory".

Go ahead and build your apps out of whatever you want, no one is forcing you to build it using frameworks.

But I promise you, if frameworks did not exist half the apps I use today wouldn't either. There's a right tool for every job and the article pretends there isn't.

Re: Why I Hate Frameworks (2005)

#332

Post by josephg » Sat, Jul 08, 2023, 1:57 PM UTC

sfn42 wrote: post #324

BlargMcLarg wrote: post #298

Earlier quoted context omitted.

Not everything needs a hyper-abstracted solution. Most people suck at writing neat abstractions, so they spend an excessive amount of time writing shoddy solutions which no one really wants to deal with but there's a soft, begrudging agreement to use them anyway while the business sees no value in having their devs rewrite it. This goes double when you step into the world of microservices, where you now have another…

Sure, you can write bad code using abstractions. Doesn't mean abstractions are bad or useless. There's just a lot of devs out there who don't write very good code. There are also devs writing decent code but too tightly coupled, making it much more difficult to develop the code further without first refactoring the existing solution. It is also often very difficult to refactor the solution because its parts are also…

Eh. It’s usually not that hard to take two tightly coupled components and insert an abstraction layer in between. Usually tightly coupled code is small, and you can almost always use the compiler to find all the places you need to modify things.

Practically speaking I’d much rather that problem than it’s inverse. It’s exhausting dealing with code that’s too abstract. Especially if the abstractions don’t do anything anyway. Eg - Java interfaces with exactly one implementation. Removing useless abstractions never feels pressing enough to do, but you pay a tax for those abstractions constantly. And it doesn’t take many abstractions before your productivity plummets. No thanks.

The best code is like the best writing. Say what you mean. Be direct. And be humble enough to redo it all when you figure out a better way to proceed.

Re: Why I Hate Frameworks (2005)

#333

Post by chongli » Sat, Jul 08, 2023, 2:07 PM UTC

hajile wrote: post #325

chongli wrote: post #172

Earlier quoted context omitted.

Most people who take trigonometry (or "precalculus" as they usually call it today) couldn't tell you anything about limits let alone derivatives, integrals, and the fundamental theorem of calculus. And to those people, the calculator is a magic “black box” that spits out cosines. My original point stands: if you are using a tool professionally you should understand how it works, at least on a basic level. For a calcu…

Did you know that lots of calculators (including the famous TI-83) actually use CORDIC and that the basics of that method predate calculus by a hundred years? Did you fully understand your tool? Did that keep you from using it? If you know the purpose of a trig function, it doesn't matter HOW the answer is calculated so much as that you know the answer is accurate. This doesn't require calculus. I took calculus. As a…

My original point used calculus as an example. You turned this whole discussion into a referendum on calculus which I have no interest in continuing. Substitute linear algebra or even the basic theory of electronics and my point still stands, which you agree with. Furthermore, you studied calculus so you understand the principles behind the tools you are using, even if you aren’t using those principles directly, and that is valuable. People who don’t understand their tools risk being owned by them.

Re: Why I Hate Frameworks (2005)

#334

Post by sfn42 » Sat, Jul 08, 2023, 2:17 PM UTC

josephg wrote: post #332

sfn42 wrote: post #324

Earlier quoted context omitted.

Sure, you can write bad code using abstractions. Doesn't mean abstractions are bad or useless. There's just a lot of devs out there who don't write very good code. There are also devs writing decent code but too tightly coupled, making it much more difficult to develop the code further without first refactoring the existing solution. It is also often very difficult to refactor the solution because its parts are also…

Eh. It’s usually not that hard to take two tightly coupled components and insert an abstraction layer in between. Usually tightly coupled code is small, and you can almost always use the compiler to find all the places you need to modify things. Practically speaking I’d much rather that problem than it’s inverse. It’s exhausting dealing with code that’s too abstract. Especially if the abstractions don’t do anything a…

Two? Sure. How about when the whole application is tightly coupled so a change in one class necessitates changes in 4 others? And sure if the logic is straight forward and simple that's fine, but add in that the code is a complete mess with a bunch of weird convoluted solutions to things and whoever wrote it is long gone so nobody knows what it's supposed to do beyond "exactly what it currently does".

I think I'm pretty good at programming but that's generally what I've been doing in my career and to me it's incredibly difficult. Not that much new code, just a lot of wrangling shitty old code and in retrospect regretting that I didn't just delete it and write everything from scratch.

Re: Why I Hate Frameworks (2005)

#335

Post by nemetroid » Sat, Jul 08, 2023, 2:18 PM UTC

gigel82 wrote: post #20

This must be a Java joke I'm too C++ to understand. But I was actually hoping for a factory automation online game because I feel like I need to sink the next 2 - 14 days of my life into a shapez.io or mindustry or something like that...

Well, there's not much preventing a C++ programmer from limiting themselves to a feature set similar to Java's (replacing garbage collection with generous shared_ptr usage).

Re: Why I Hate Frameworks (2005)

#336

Post by Kamq » Sat, Jul 08, 2023, 2:37 PM UTC

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.

> Most projects are average by definition. Otherwise that wouldn’t be the average.

You're assuming outliers in both directions don't dominate the process.

As an example, let's say we have 10 projects, that have some property that can be rated on a scale from 1-10. Difficulty to accomplish is the first thing coming to mind. If we have 5 projects that are a 1 on this scale, and 5 projects that are a 10, the average is going to be 5.5 despite none of the projects being anywhere close to that.

Re: Why I Hate Frameworks (2005)

#337

Post by sanitycheck » Sat, Jul 08, 2023, 3:01 PM UTC

Aeolun wrote: post #305

sanitycheck wrote: post #282

Earlier quoted context omitted.

I'm even more cynical than you. The senior's (personal) objective is to add fashionable buzzwords to the resume/CV so in a year they can hop to another company and get paid 20% more. You get a pay rise and a promotion a lot quicker by changing jobs than sticking around. No Kubernetes experience? Just unnecessarily add Kubernetes to your current project. Now look for that Kubernetes job! The worst thing is, this is to…

I dunno, I just want an environment in which I can deliver the features biz requests without fear or fuzz. Right now it’s just firefighting every second of the day.

Perhaps that's what we should call ourselves, instead of "engineers". I suppose that'll only annoy the real firefighters instead though.

Re: Why I Hate Frameworks (2005)

#338

Post by notjoemama » Sat, Jul 08, 2023, 3:07 PM UTC

adrianmsmith wrote: post #244

epiccoleman wrote: post #4

The worst part of this kind of thing is that young carpenters honestly, really, truly, just need to learn to use a hammer. They can't even conceive of the problems that are being solved by the hammer factory, let alone the factory factory. 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 comple…

> 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. Where I work, everyone has the authority of the position below them. The middle management above my team decides language, framework, and architecture. They were hired from much larger companies, so naturally they just know more. I think our 10mil/yr company doesn't need the complexity of a 100mil/yr solution because we're not Amazon and we're never going to be Amazon. But, we now we have dozens of lambda functions in multiple languages with multiple configs designed in different ways deploying from multiple processes from multiple repositories. Our team is having a hard time changing and fixing anything because the cognitive overhead nears the limit of human capability. I was told "off the record" its because we didn't execute their vision the right way.

I'm starting to think I work in a toxic environment.

Re: Why I Hate Frameworks (2005)

#339

Post by afiodorov » Sat, Jul 08, 2023, 3:10 PM UTC

whstl wrote: post #318

afiodorov wrote: post #285

Earlier quoted context omitted.

There isn't a one-size-fits-all solution to this issue. Before joining the department, I was part of a start-up where, with a considerably smaller team, we were able to process even larger amounts of data. We could introduce a new feature in a single day - a feat unthinkable in the department I just described. This speed was not achieved at the expense of stability but was a direct result of our choice of tools. Addr…

Dare I suggest that it is possible that the nimble startup was moving quickly not necessarily because of tool choice, but because of the small team size and because the appropriate amount of complexity was introduced? And conversely the inflated team was slow exactly because it was inflated and complexity was introduced? This effect happens with or without bringing third-party or in-house tooling/frameworks into the…

The speed difference boils down to flexibility and tool usage. In the startup, I could swiftly create a new service, harness Kubernetes for deployment, and seamlessly integrate it into the existing architecture. Data computation used tools like Airflow/BigQuery, storing results in production PostgreSQL.

In contrast, with a Golang monolith, service integration often involved complex, time-consuming conversations due to rigid NIH abstractions. And given the tendency of senior engineers to resist changes, progressing became challenging. A developer like me would be caught between resistant seniors and a product team demanding immediate feature release. Additionally, data processing often required extensive custom coding, slowing down operations. And if more than one machine was needed, it would mean a total overhaul and a long wait.

In comparison, a lean startup allowed me to use apt tools (like BigQuery), containerize it with Docker, and then let it be - without involving anyone senior. Moreover, in case of a new feature, we could simply replace the entire component instead of struggling with additions.

The agile startup emphasized less on seeking senior developers' approval for every change. In the monolithic Golang environment, senior devs often fixated on code quality without acknowledging that, in a microservices context, it's frequently more effective, faster, and simpler to reboot and rewrite parts instead of altering the existing solution. Hence, the intense focus on solution maintainability becomes less critical.

Re: Why I Hate Frameworks (2005)

#340

Post by pnt12 » Sat, Jul 08, 2023, 3:16 PM UTC

notjoemama wrote: post #338

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. Where I work, everyone has the authority of the position below them. The middle management above my team decides language, framework, and architecture. They were hired from much larger companies, so naturally they just know more. I think our 10mil/yr company doesn't need the complexity of a 100mil/yr solution because we're not Amazon and we're never going to be Amazon. But, we now we have dozens of lambd…

Yeah that's quite toxic. If the project is successful, the top level gets the praise for the vision. If it doesn't, the team gets the blame for lousy execution.

The responsible for executing should have a day in a lot more things, else it's gonna be a blame game.