Live data from Hacker News

Write Libraries, Not Frameworks

brandons.me

91–100 of 338 posts

Re: Write Libraries, Not Frameworks

#91
post #12

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…

The repeated joke about killing your ex-girlfriend did not age well.

I hope, one day, that we look back on the "woke" over-analysis of the last few years and say "That didn't age well."

Re: Write Libraries, Not Frameworks

#92

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…

I kinda want to make a Spring class name generator now.

Re: Write Libraries, Not Frameworks

#94
post #47

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…

getInstrumentableClassLoader() Return a ClassLoader that supports instrumentation through AspectJ-style load-time weaving based on user-defined ClassFileTransformers. Oh man... I admire the people who have invented this. But at the same time I feel sorry for those who have to use this in order to earn their living.

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 transaction errors are handled centrally.

It adds runtime costs of course. And the more you add this way, the more complicated it becomes. And certainly can be abused.

Re: Write Libraries, Not Frameworks

#95
post #12

Earlier quoted context omitted.

The repeated joke about killing your ex-girlfriend did not age well.

I think the same thing every time reading this otherwise-excellent post. I don't think we should attempt to erase history, but it is super jarring, at least for me. Was it ever actually funny?

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

Re: Write Libraries, Not Frameworks

#97
post #48

Earlier quoted context omitted.

Most of those crazy looking Spring classes aren't used by users and are just used internally by the framework developers. Of all the complaints people have about Spring, I've never heard "these classes are too abstract" or "these names are too obtuse." There was maybe one instance where I had to deal with obtuseness like that. Definitely not the norm.

After X11 and Spring, the Maximum Abstraction Task Force shifted to focus on infrastructure, which is why your Java Virtual Machine processes are now running as a uniquely allocated user ID in a container scheduled by a control plane on a pool of OS instances separated by the hypervisor service of a dynamically sized cloud placement group.

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

Re: Write Libraries, Not Frameworks

#98
I rather have the comfort of frameworks, and the occasional edge case than dealing with creating the world from scratch.

This is what gives "hunt for libraries" mentality of Khronos versus the comfort of using MetalKit or DirectXTK.

Happily using frameworks since Turbo Vision.

Re: Write Libraries, Not Frameworks

#99
I totally get what would have gone in to come up with this. Often frameworks are released and their versions are bumped up with major changes without thinking about the struggles/emotions developers might face. Speaking from experience, just recently I had to sit together fixing and upgrading my codebase to the latest version of a framework that I was using. More than the development process itself these take more time and the developer frustrates himself going over StackOverflow and reading through comments on GitHub issues to figure the point he is missing out on.

More importantly, I think that framework writers need to think of their developers as their users and make sure everyone is notified about the updates happening and are on the same level. I know it is a lot to ask for given that these projects are open source but a huge gap in the way we leverage open-source products for its use.

Re: Write Libraries, Not Frameworks

#100

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)

I will be honest and tell them it is because these are more productive and I enjoy being productive
Post reply on HN