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

141–150 of 338 posts

Re: Write Libraries, Not Frameworks

#141

Post by skohan »

The more I program, the more I am convinced that owning flow of control is one of my primary jobs as a programmer.

If I surrender this to a framework, there are a lot of decisions I can't make with regard to performance, and I have a lot less certainty about when and in what order exactly things are executed.

There are of course some exceptions, but in general I want libraries to provide me simple, synchronous functions, and it's my job to figure out how to spread them out over the hardware.

Re: Write Libraries, Not Frameworks

#142

Post by _ZeD_ »

louiskottmann wrote: post #129
fulafel wrote: post #115

Earlier quoted context omitted.

For those of us hazy on the AOP concept... Is it an artifact stemming from restrictions of static languages, or would it be a valid concept with dynamic languages too?

It is very close to python's @ syntax on top of methods definitions. Like: @get('/posts') mymethod ...

? no, it's not.

look at https://python-aspectlib.readthedocs.io/en/latest/ for an example of using aspect with python

Re: Write Libraries, Not Frameworks

#143

Post by DmitryOlshansky »

Writing libraries is a never ending grind of:

1. trying hard to do one thing and do it well (and failing usually), but ...

2. there are many dependencies that you should allow your user to pass explicitly ...

3. and that’s the problem - you have 0% control on how the library is integrated but receive full responsibility for how well does it work. Even libc could be very different and will not behave the way you’d expect it to.

The big problem of making everything a small well thought-out library is large integration surface + having to be flexible and accommodate for all potential cases of integration.

That’s why we mostly have hundreds of overlapping “fat” libraries - too much trouble and too much integration complexity to split them up.

Re: Write Libraries, Not Frameworks

#144

Post by fphilipe »

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.

Re: Write Libraries, Not Frameworks

#146

Post by jmchuster »

lmm wrote: post #104
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…

Just use a language where it's possible to implement those things in plain old code. When you have higher-kinded types you don't need any bytecode manipulation, you can just have a type that wraps anything that needs to happen in a transaction, and compose together transactional operations in a visible but type-safe way - and you don't even need the runtime cost. How anyone can look at Java as it's actually used and…

How would you then, say, do a profiled run of the application, to help find the choke points in your application? You'd have to make sure that you apply the exact same "trace the runtime of this function" wrapper around every single function call, then make sure you haven't missed anything anywhere, then have to maintain such usage, and then mentally ignore it everywhere when you're trying to read through the code.

Re: Write Libraries, Not Frameworks

#147

Post by oreally »

AmericanChopper wrote: post #78
smitty1e wrote: post #60

Earlier quoted context omitted.

I always figured that Java folks were - paid per class - sought to reduce the number of executable lines per class to 1.

But that’s just OOP in general. You can choose a language that defaults to not using OOP-style abstractions, but then people will question why you choose python/node/ruby over a proper language like Go (or whatever else)

> But that’s just OOP in general.

Nope, that's OOP taken to extremes rather. Java does that with enforcing things to be classes.

Re: Write Libraries, Not Frameworks

#148

Post by loquor »

mewpmewp2 wrote: post #105
tanilama wrote: post #83

Earlier quoted context omitted.

Yep. React went from React.createClass -> class xxx extends Component -> Hooks. But I don't think that means...change? The fundamental concept of react, that UI is a derivative from the state, stays the same. Class based or Hook (or just a really nice way to write Functional Component), stays the same.

Fc and hooks force you to think in an entirely different manner though. I would say it is an entirely different paradigm. And it is a much higher learning curve. For instance I see a lot of developers and engineers with 6 months and more experience with functional components and still misunderstanding the point of all of this. And these are smart people at high tier companies. The main thing being the meaning of havi…

You're right. But this is the natural progression for React. React emphasizes stateful behavior in components. UseEffects with specific dependencies are actions which depend on the specified variable-set alone, while all the other infinite variables can change however they like. This concept already exists when we talk about state machines.

That said, it isn't a smooth transition going from explicit lifecycle methods in class based components to useEffect hooks in functional components. But it refines the quality of the thinking, and the quality of the code overall, imo.

Re: Write Libraries, Not Frameworks

#149

Post by ivalm »

pfarrell wrote: post #121
stormdennis wrote: post #95

Earlier quoted context omitted.

Is there somewhere you can check what is or isn't funny?

Everybody nowadays is inplementing HumorSensorFactoryFactory to define their own rules for what’s inbounds.

No, real people use EmotionSensorFactoryFactoryFactory. Why limit yourself only to HumorSensorFactory objects?

Re: Write Libraries, Not Frameworks

#150

Post by toshk »

skohan wrote: post #141

The more I program, the more I am convinced that owning flow of control is one of my primary jobs as a programmer. If I surrender this to a framework, there are a lot of decisions I can't make with regard to performance, and I have a lot less certainty about when and in what order exactly things are executed. There are of course some exceptions, but in general I want libraries to provide me simple, synchronous functi…

On the level of practical risk: on the security level libraries are much more risky imo. A good framework for most project i've seen will lead to a more structured and secure codebase. Probably precisely because there is less room for creativity.

For instance Laravel is very structured: orm, auth routes, controllers system etc., where express.js let's you do whatever.

And almost all Expressjs or other Nodejs projects i've joined were a mess and had security issues, something as simple as CSRF tokens, or not allowing redirects to external domains, are often forgotten or not fully implemented.

Doesn't mean I don't sometimes prefer a library approach, but the developer(s) need to be a lot more qualitative.

Post reply on HN