121–130 of 338 posts
Earlier quoted context omitted.
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?
That's why you can use several libraries at once, but you can only use one framework at a time. That's also why I refrain myself to use things like unity, unreal engine, godot, etc. Once you wrote something, a framework prevents you from using another framework, or the cost of porting is way too high. Libraries are more easily interchangeable.
In PHP, there is Framework Interior Group that created a few standards to which many frameworks implement their components. The interfaces are designed by FIG, and frameworks implement them (or rather, use libraries that implement them).
Containers, HTTP message objects, request handlers, middleware, caches, they all can be interchanged if they implement these interfaces.
Frameworks can now give the choice to the user to pick their own preferred libraries.
There is Laravel, which is on the far end of opinionated frameworks, but Symfony andnSlim for example provided a lot of flexibility.
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.
The class loader is an important entity for a Java app. And you can have more than one (although this is advanced voodoo already). So, an instrumented class loader.
I think the key difference is that frameworks usually hijack your control flow, while library are not. But is framework necessarily bad or inferior to library? I would like to present React as an example. React heavily regulates the control flow for its developer, leaving several specific hooks to allow you control the timing when your code would trigger. But React is an excellent piece of software. And assuming in a…
The point is that more people, projects and even frameworks can use the library you write. If you write a framework, people have to drop whatever it is they're using and go with your framework. That's bad, unless your framework is the one to trump them all, which it probably isn't.
EDIT: Words
Earlier quoted context omitted.
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 transact…
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 boundaries.
> In fact, any cross-cutting concerns - like transactions, can be done this way.
That's another thing I want to be explicit, if I have some code that is going to to do a bunch of updates I want it to demand a transaction as part of it's interface. I don't want it hoping it gets executed in the scope of a magic layer that will handle the transaction.
The common theme with AOP is that it takes stupid simple code into an opaque mess spread across a dozen classes that's far harder to maintain.
Earlier quoted context omitted.
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…
I think you are being completely unfair here. 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. More importantly, nothing about standard Java development requires The use of AOP.
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 implementation (which is pretty much any language that has higher-kinded types and first-class functions, although do notation can be a useful enhancement), you can comfortably write this kind of thing in plain old code. (I do those very things - transaction boundaries and logging - in Scala all the time).
> More importantly, nothing about standard Java development requires The use of AOP.
And yet, in real-world Java development, people feel the need to use AOP. In my 10+ years of JVM work in companies large and small, I don't think I saw a single one that didn't use some form of AOP. That should tell you something.
Earlier quoted context omitted.
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…
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?
Like:
@get('/posts')
mymethod
...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…
"If you wish to make an apple pie from scratch, you must first invent the universe." —Carl Sagan
The only question is if you can afford hiring a few gods for the task or you are rather satisfied with whatever falls off a truck and in reality is completely uncapable of inveting universe (or even capable of baking).
At the end the customers digestive problems are those that do matter. And you can get sued for food poisoning.
I personally love apple pies and am just not satisfied with plastic taste of supermarket frozen, microwave oven heated "products".
“When you want to hurry something, that means you no longer care about it and want to get on to other things.”
― Robert M. Pirsig, Zen and the Art of Motorcycle Maintenance