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

Avoid Mini-Frameworks

laike9m.com

Post reply on HN
Print view View original

91–100 of 119 posts

Re: Avoid Mini-Frameworks

#91

Post by gherkinnn »

smetj wrote: post #16

Somehow, somewhere there is a pleasant balance between DRY and non-DRY which is different for everybody. God forbid having a colleague who sees a thing repeating and slaps an abstraction over it at whatever cost because DRY!

Optimising for "code is easy to change" hits that balance well enough.

Start with a loose bag of functions. These are easy to compose in to larger pieces of functionality. And, this is key, easy to decompose when things change. Once this WET bag becomes a chore to change, the right abstraction might just show itself for DRY-ing out.

Re: Avoid Mini-Frameworks

#92

Post by geoffpado »

> We often hear that "people leave managers, not jobs." But sometimes, people leave jobs despite loving their managers.

These two aren’t really mutually exclusive. Your manager may be extremely friendly and accommodating to you personally (as it seems like the author’s manager was), but part of a manager’s job is growing and supporting their reports with their career goals. If you’ve spent years majorly underleveled like it seems this person did, your manager is failing you. No matter how much of a nice person they might be, they’re not doing their job well if you’re attempting to grow at the company and aren’t succeeding.

So yes, I do think that this person still left a manager. He left a manager who wasn’t meeting the needs he had to stay at the company.

Re: Avoid Mini-Frameworks

#93

Post by tucnak »

geoffpado wrote: post #92

> We often hear that "people leave managers, not jobs." But sometimes, people leave jobs despite loving their managers. These two aren’t really mutually exclusive. Your manager may be extremely friendly and accommodating to you personally (as it seems like the author’s manager was), but part of a manager’s job is growing and supporting their reports with their career goals. If you’ve spent years majorly underleveled…

Wrong thread!

Re: Avoid Mini-Frameworks

#94

Post by 65 »

erkok wrote: post #59

Having been around in the industry for a while I'm seeing abstractions being misused all the time. Being guilty of it myself also when I was younger. For me, the only purpose of an abstraction is to reduce complexity, but often times I'm seeing it being used to reduce repetitiveness, which often times replaces well understood more verbose code with less understood less verbose and less flexible alternative. For me, a…

Everywhere I've worked that uses DynamoDB, someone will invariably write a bunch of abstraction functions that become very annoying to debug, to add functionality, and can break an entire app if changed.

DynamoDB is admittedly very verbose, but it's almost always worth it to keep your CRUD operations written within the SDK rather than as an abstraction.

Re: Avoid Mini-Frameworks

#95

Post by didip »

The problem in big tech is that: Sending upstream patches to THAT team (that owns the original framework) is like pulling teeth.

Those people have their own OKRs and promo desires.

Often times, sending patches to OSS orgs are easier.

So naturally, extension to the original framework happened.

Re: Avoid Mini-Frameworks

#96

Post by gejose »

dpark wrote: post #63
baobun wrote: post #15

Earlier quoted context omitted.

If you look above the unorthodox library/framework distinction, I think the criticism is about birthing new (inadvertently leaky) abstraction layers with new semantics to capture the specifics of the domain. Often with either esoteric words attached to supposedly novel patterns, and/or unconventional usage of existing terminology. The promise is to simplify and unify things but as noted, such efforts often have the o…

> magically solves everything This is the real problem. Too often frameworks/libraries are geared towards making things magic instead of making things solid. Magic solutions are usually very one dimensional. e.g. The Magic only works for a really narrow use case, or at low load. I don’t think this is specifically a problem with “mini frameworks” but homegrown stuff exhibits this more, if only because magic solutions…

> lot of magic to make it trivial to start and they don’t scale to real projects

Ruby on Rails is probably a great counter example here though.

Re: Avoid Mini-Frameworks

#97

Post by zephen »

sunir wrote: post #60

It’s a simple math problem. And it is also Conway’s law that says all software design follows the organization that built it—that is all software design is political. A framework calls you. You call a library. A framework constrains the program. A library expands the program. It’s easier to write a library that is future proofed because it just needs to satisfy its contract. It’s harder to write a framework because i…

Technically everything you have written is true. But the proliferation of frameworks is almost a self-reinforcing antipattern.

> No one likes lawyers because they block you from doing what you want.

Or even doing what you need to do.

Certainly, to the extent that a mini-framework is composed of more constraints piled on top of an extant bigger framework, mini-frameworks are, like swimming pools, attractive nuisances. "Hey, look, guys! This is so much simpler!"

> It’s harder to write a framework because it imposes a contract on everything that depends on it.

Judging by what people write and use, I'm not sure this is _exactly_ true. Sure, writing a _good_ framework or library is hard, but people accept piss-poor frameworks, and accept libraries that were designed to work in conjunction with a single framework.

> It’s easier to write a library that is future proofed because it just needs to satisfy its contract.

But the thing is that the library itself defines the contract, and it might be a piss-poor one for many applications.

There is some excellent code out there, and there is a lot of shitty code out there. I think the problem is social; too many people want to write code that is in charge. Now, maybe it's somewhat technical, in that they have used things that are in charge, and they were too big (leading to the mini-framework of the article) or they were otherwise not great, so this leads to yet another framework (cue standards xkcd cartoon) because they realize they need something in charge, but aren't happy with their current options.

And, of course, since the frameworks they know take a kitchen sink mentality, their new framework does as well. (Maybe it's a smaller sink, but everything needed is still shoved in there.) So there are yet more libraries that are tied to yet another framework.

Because writing good libraries that are completely framework independent _can_ be as challenging as writing a good framework. And when someone decides they need a new framework, they are focused on that, and making it work well, and since that drives their thought process, everything else the write gets shoved into the framework.

Re: Avoid Mini-Frameworks

#98

Post by nine_k »

65 wrote: post #94
erkok wrote: post #59

Having been around in the industry for a while I'm seeing abstractions being misused all the time. Being guilty of it myself also when I was younger. For me, the only purpose of an abstraction is to reduce complexity, but often times I'm seeing it being used to reduce repetitiveness, which often times replaces well understood more verbose code with less understood less verbose and less flexible alternative. For me, a…

Everywhere I've worked that uses DynamoDB, someone will invariably write a bunch of abstraction functions that become very annoying to debug, to add functionality, and can break an entire app if changed. DynamoDB is admittedly very verbose, but it's almost always worth it to keep your CRUD operations written within the SDK rather than as an abstraction.

A better abstraction would be a better SDK then.

BTW repetitiveness is not free, it's cognitive load that a developer must deal with. An abstraction is also a bit of cognitive load that grows with the abstraction's complexity; the point is to find a balance that minimizes it.

Re: Avoid Mini-Frameworks

#99

Post by est »

barrkel wrote: post #5

> real and only difference between a library and a framework, is whether it introduces new concepts This isn't what is normally understood in software engineering by those terms. A library is something you call. A framework is some kind of application scaffolding that normally calls you. You can use more than one library. You normally only have one framework in-process. I found the blog post a little hard to parse. I…

> Is it an argument against wrapping frameworks, or wrapping libraries?

I think English is not OP's first language, framework here basically means wrappers.

Re: Avoid Mini-Frameworks

#100

Post by geoffpado »

tucnak wrote: post #93
geoffpado wrote: post #92

> We often hear that "people leave managers, not jobs." But sometimes, people leave jobs despite loving their managers. These two aren’t really mutually exclusive. Your manager may be extremely friendly and accommodating to you personally (as it seems like the author’s manager was), but part of a manager’s job is growing and supporting their reports with their career goals. If you’ve spent years majorly underleveled…

Wrong thread!

Whoops. Not sure how I did that.
Post reply on HN