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

Write Libraries, Not Frameworks

brandons.me

Post reply on HN
Print view View original

171–180 of 338 posts

Re: Write Libraries, Not Frameworks

#171

Post by mping »

lmm wrote: post #162
mping wrote: post #153

Earlier quoted context omitted.

If I give you a jar (or equivalent) of my compiled app, can you still apply cross cutting concerns (over compiled code you may not own)? Because that's what AOP and bytecode transformation can do.

You can't insert them at completely arbitrary points in third-party code. But libraries can be written generically (in terms of e.g. a general monad) so as to propagate cross cutting concerns from your callbacks to the right place, even when those concerns are implemented later on and the library doesn't know about them. Look at e.g. fs2 and http4s: everything's written generically in terms of some F[_] type which th…

I'm not familiar with scala but will take a look. Completely agree over your last point. I very much prefer libraries over frameworks, and as you said pointcuts are a bit fragile, but my main point is that they behave differently because of bytecode transforms.

Re: Write Libraries, Not Frameworks

#172

Post by iso947 »

userbinator wrote: post #9

A framework, usually, must predict ahead of time every kind of thing a user of it might need to do within its walls. The one thing not mentioned in the article is that the above line of thinking is almost guaranteed to lead to an insane level of abstraction, which was parodied in this classic article from nearly 15 years ago: http://web.archive.org/web/20141018110445/http://discuss.joe... (Sadly, that site is gone, b…

> Sadly, that site is gone

Probably because the author has a weird obsession with murdering women

Re: Write Libraries, Not Frameworks

#173

Post by iso947 »

flukus wrote: post #127
chii wrote: post #94

Earlier quoted context omitted.

It does have it's place. Aspect oriented programming will allow you to write, for example, logging code that are very configurable. It allows you to remove the concern of logging from your classes completely. In fact, any cross-cutting concerns - like transactions, can be done this way. So you can write code that don't care about transactions, but behind the scenes, it is all within a single transaction, and transact…

> It allows you to remove the concern of logging from your classes completely. You say that like it's a good thing. When there's a bug to look into grepping strings from the log is one of the first steps, the first step if you don't have a stack trace, I want that string to be where the problem is. Having the logging in with the rest of the code is an inevitability anyway and unless you only want logging at function…

Modern OSes don’t log to simple text files you can grep, tail, watch, open in a text editor, etc.

Re: Write Libraries, Not Frameworks

#174

Post by openfuture »

The frameworks that people really like are things like emacs and xmonad. That is to say, the framework is opinionated enough that you are writing configuration not applications but also flexible enough that your configuration can be completely arbitrary.

Many frameworks are too close to being libraries while still being frameworks, so you lose your control for a dubious return (you don't start with working software and tweak it, rather you have to build from scratch inside of someones else's paradigm).

Re: Write Libraries, Not Frameworks

#175

Post by dmitriid »

keanebean86 wrote: post #112
infogulch wrote: post #97

Earlier quoted context omitted.

All of which end up getting allocated to a single 56 core cpu.

Even the CPU adds at least one layer of abstraction. Spring JVM Container OS hypervisor x86 Real CPU instructions Electrons Unknown EDIT: formatting

And "EDIT: formatting" is now an additional layer, too :)

Re: Write Libraries, Not Frameworks

#176

Post by ChrisMarshallNY »

fphilipe wrote: post #144
ChrisMarshallNY wrote: post #21

I agree. However, I program for Apple devices, so my libraries are called "Frameworks." I'd say that we should call them "Modules," instead. That probably covers all the bases.

> so my libraries are called "Frameworks." Not if you make them static libraries.

Tru, dat, but static libraries are so “five minutes ago.”

Re: Write Libraries, Not Frameworks

#177

Post by auggierose »

Frameworks' key trait is that they impose limitations on the programmer

You could say that a type system also imposes limitations on the programmer. Is a type system a framework? Would you rather use a library than a type system?

I think the point is rather that making a framework is much much harder than making a library. So it makes sense to first create a library to solve a problem if that is feasible. Once you are reasonably comfortable with your choices during creating your library, you might think about turning your solution into a framework. You should do that only if there is an actual benefit in doing so.

I think frameworks live on a higher abstraction level than libraries. If you need that higher level, libraries are a poor fit. If you don't need it, why make your life harder in going there?

Re: Write Libraries, Not Frameworks

#178

Post by winter_blue »

The general principal the author is talking about — ie not being overly opinionated— and asking yourself “Could I use this in combination with something else like it?” — could be applied to even something like a programming language.

For example, Elm 0.19+ would be the counter-example in this case. It makes it very hard t/ almost impossible to interact with JS code. A more flexible web front-end wouldn’t force such a strong opinion upon its users. It would let the users decide, and leave flexibility / room in various aspects of the language.

Re: Write Libraries, Not Frameworks

#179

Post by foobar_ »

On another note here a a few claims framework authors make which are usually short sighted

1. Frameworks promote code reuse

Frameworks however don't promote reuse within different versions of the same framework, which makes the code reuse claim hypocritical at best.

Where is the code reuse between Angular 1 and Angular 2 ?

Libraries also promote code reuse by the use of shared object files (C) or modules (Python, Node.js ...) and it is usually more long lasting.

2. Frameworks are easier for beginners to use

Frameworks get difficult quickly once the initial use case is run out. Frameworks appear deceptively simple because they hide complex code under the rug, but anytime you need to do functionality similar but different to that initial complex code, you will have a problem.

With a library, you can inspect the code ... copy it and edit it to do what you want, it is not as simple with frameworks especially when you have to deal with 100 levels of inheritance.

In a way frameworks encourage code illiteracy.

3. Frameworks are not composable

Using two or more frameworks is next to impossible because of all the assumptions frameworks make. Frameworks are totalitarian in this regard.

4. Object Relational mismatch is real

By forcing the object model on everything, it makes understanding non OO models for data, which is most data ... very difficult.

Relational model is more generic as it supports references and is obviously more efficient.

Post reply on HN