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

161–170 of 338 posts

Re: Write Libraries, Not Frameworks

#161

Post by oreally »

edem wrote: post #137
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…

Spring is not a good example. If you're a seasoned Java developer you look at an `AbstractDestinationResolvingMessageTemplate` and you just know what it does. I'm not kidding. Spring used to be a bad example yes, but not anymore. They really put the thought and work into fixing its design. Right now I can write an app __completely__ independent of Spring. In fact that's what I'm usually doing. You can do Clean Archit…

> If you're a seasoned Java developer you look at an `AbstractDestinationResolvingMessageTemplate` and you just know what it does. I'm not kidding.

This claim is so bad.

You could look at the name AbstractDestinationResolvingMessageTemplate and the useful information they would be gaining is that it's a message template. They would still not know how to use it; they'd still have to do an additional step like checking the documentation on its usage etc. The amount of useful information to text is small and it doesnt help.

Re: Write Libraries, Not Frameworks

#162

Post by lmm »

mping wrote: post #153
lmm wrote: post #128

Earlier quoted context omitted.

> AOP in Java (and .NET) is a metaprogramming facility that has few equivalents in other languages. The closest thing that comes to it is macros, but those are often compile time modifications. You don't need macros to achieve what grandparent was talking about - handling cross-cutting concerns like logging or transaction boundaries without being too intrusive. In a language that lets you do a half-decent monad imple…

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 the user supplies when they use the library, and it will all be plumbed through correctly. So if you want logging, you use something like treelog as your F[_] type; if you want transactions, you include a transaction type in there. And so on.

In my experience that covers almost all the use cases, while it means that library code can still behave predictably and be understood and tested (e.g. you don't have to worry that a library upgrade is going to break your application, which you do if you've used AOP to define pointcuts deep in its internals).

Re: Write Libraries, Not Frameworks

#164

Post by jmchuster »

lmm wrote: post #159
jmchuster wrote: post #146

Earlier quoted context omitted.

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.

Profiling isn't really a good example; I don't actually mind doing it via language-level magic, since it doesn't affect the actual behaviour of the application - every function still executes the same and still returns the same thing, we just observe it in more detail from the outside. But to answer the question, I'd use a monad, something akin to treelog ( https://github.com/lancewalton/treelog ). Apply the wrappers…

Well, the whole point of AOP is to handle these "not good examples". Now, certainly if you use the wrong tools for the wrong job, you'll shoot yourself in the foot. But there are many powerful tools that we shouldn't eschew just because we fear using them wrong. And then there are many cases where you shouldn't use these tools just because you can.

Re: Write Libraries, Not Frameworks

#165

Post by AmericanChopper »

oreally wrote: post #147
AmericanChopper wrote: post #78

Earlier quoted context omitted.

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.

The OOP paradigm itself requires rather heavy use of abstraction. You can deviate from those patterns to an extent, you can add more polymorphism if you want to, you can be selective in using some design patterns like DTOs. But most of the complaints I hear about Java would apply equally to most of the C# projects I’ve worked on, because those are just the annoying bits of OOP. I’d agree the Java is a bit more inflexible, but it’s not like the other OOP languages aren’t also full of boilerplate and layer upon layer of abstractions.

Re: Write Libraries, Not Frameworks

#166

Post by lmm »

jmchuster wrote: post #164
lmm wrote: post #159

Earlier quoted context omitted.

Profiling isn't really a good example; I don't actually mind doing it via language-level magic, since it doesn't affect the actual behaviour of the application - every function still executes the same and still returns the same thing, we just observe it in more detail from the outside. But to answer the question, I'd use a monad, something akin to treelog ( https://github.com/lancewalton/treelog ). Apply the wrappers…

Well, the whole point of AOP is to handle these "not good examples". Now, certainly if you use the wrong tools for the wrong job, you'll shoot yourself in the foot. But there are many powerful tools that we shouldn't eschew just because we fear using them wrong. And then there are many cases where you shouldn't use these tools just because you can.

> Well, the whole point of AOP is to handle these "not good examples".

I don't have a problem with AOP that doesn't change the functioning of the code. I have a problem with AOP that changes the functioning of the code, which is the overwhelming majority of AOP that I've seen in real life.

> Now, certainly if you use the wrong tools for the wrong job, you'll shoot yourself in the foot. But there are many powerful tools that we shouldn't eschew just because we fear using them wrong.

But you don't need any of the dangerous functionality to do profiling. So that's not a valid argument.

Re: Write Libraries, Not Frameworks

#167

Post by UK-Al05 »

smitty1e wrote: post #60
thomk wrote: post #56

Earlier quoted context omitted.

Stuff like that always makes me feel like someone has turned off their logical reasoning and they are just basically creating code that fills in some personal mental gap that somehow 'completes the set' of the things they are working on at the moment.

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

Tbh that was Alan Kay's vision of object oriented programming. Lots of tiny objects collaborating via messages.

Re: Write Libraries, Not Frameworks

#168

Post by namelosw »

Framework and libraries are both useful. Besides those, languages are also useful.

The problem is there are too many frameworks instead of libraries. People are writing frameworks by default, and frameworks make strong assumptions, making things not flexible, thus frequently burn people.

When tackling a new domain, it's better to write libraries first. Then write frameworks if it can indeed improve things. On top of that, when framework works, there's a chance a language may work better.

In brief, frameworks are overused, while libraries and languages are overlooked.

Re: Write Libraries, Not Frameworks

#169

Post by pscanf »

niftich wrote: post #85
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…

Spring class names are the stuff of legend, but most of those classes you wouldn't deliberately use in your application. They're there so Spring can layer up its own functionality feature by feature. The only problematic part about this is when these class names leak into error messages, and the level of indirection becomes difficult to follow. The way you use the core inversion-of-control framework people often just…

I agree in theory, but in practice I've found it very hard to keep Spring (Boot) out of my code.

Part of the blame I think falls on Spring's DI container, which is "too good". It makes it easy to pull in any bean, even the wrong one, which means developers have to be disciplined managing how beans depend on each other, and you end up with controllers returning entities. Of course, any codebase turns into a mess if you're not disciplined, but my impression is that developers tend to be less careful when working within the confines of a framework like Spring because it gives them the false sense that they can do no wrong.

Recently I started a side project with Spring Boot (after all I like the framework), trying to organise it following Uncle Bob's Clean Architecture approach, which aims to isolate the core business logic of an app from its implementation details like database code and external interfaces. The core turned out pretty well isolated, but the rest is all Spring. Database access? Spring Data. External interface? Spring MVC. Communication with external services? Spring RestTemplate. I'm not saying it's bad, it's actually awfully convenient, but it's not so easy to swap out - say - Spring MVC for http4k, so you end up with Spring being everywhere. Which again, not a bad thing, just something to consider.

Re: Write Libraries, Not Frameworks

#170

Post by inglor »

However if yo write a framework write a framework.

Don't cripple the community by doing the IoC part and the framework calls you but create a fragmented ecosystem of a million ways to do state, routing and so on.

Looking at you React. Doing Vue was so much easier when I had a Vue project because there were a lot fewer choices.

Post reply on HN