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.
Write Libraries, Not Frameworks
91–100 of 338 posts
Re: Write Libraries, Not Frameworks
#92A 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…
Re: Write Libraries, Not Frameworks
#93Re: Write Libraries, Not Frameworks
#94A 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.
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
#95Earlier 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?
Re: Write Libraries, Not Frameworks
#96Re: Write Libraries, Not Frameworks
#97Earlier 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.
Re: Write Libraries, Not Frameworks
#98This 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
#99More 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
#100Earlier 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)