Write small sharp tool modules like "left-pad", not libraries.
Write Libraries, Not Frameworks
111–120 of 338 posts
Re: Write Libraries, Not Frameworks
#112Earlier quoted context omitted.
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.
Even the CPU adds at least one layer of abstraction.
Spring
JVM
Container
OS
hypervisor
x86
Real CPU instructions
Electrons
Unknown
EDIT: formatting
Re: Write Libraries, Not Frameworks
#113Earlier 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…
You can also do it visibly in Java without too much noise IMO. The point of AspectJ is to hide this stuff completely from application code (but it's still visible in its definitions). Whether that makes sense or not I'm not going to debate (I personally don't think AspectJ is particularly great) but arguing that other languages allow you to do that in a more or less visible way is besides the point.
AspectJ is a language, these aspects are visible and have their own language abstractions, just separate from the application code. Just like you have monad implementations separate from their uses. So writing aspects is also "plain code". How the weaving happens (at compile time/load time, on source code or on bytecode, etc.) is an implementation artifact
Also, AspectJ isn't Java and the problems AspectJ tries to solve and the approach apply to a bunch of languages and variants for functional languages also exist.
Re: Write Libraries, Not Frameworks
#114Earlier quoted context omitted.
I think all the major frontend frameworks are overly complex beasts, they're too big and can't be used as libraries - for example, you can't replace some functionality out of the box without making a fork. I also didn't find any other reactive frontend framework that could fill this requirement, so I decided to write my own. [0] It is the simplest thing I could conceive (to build, not to use - I plan to provide more…
Off the cuff, that sounds a lot like Knockout. https://knockoutjs.com/
Knockout was the last time I felt I really understood the js ecosystem. Since then it’s a mess of npm, webpack, and long complicated front end builds to do simple things.
What interesting is of all the js code I’ve written the code that lasted the longest was pure business logic Written in vanilla js, separated from any library or framework. It’s gone through knockout, angular, and react versions of the site, and people always try to rewrite it the new way, but it just doesn’t work as well and they end up writing a thin simple shim to bridge the old and new code.
Re: Write Libraries, Not Frameworks
#115Earlier 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…
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?
Re: Write Libraries, Not Frameworks
#116That'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.
Re: Write Libraries, Not Frameworks
#117Earlier 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…
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.
Re: Write Libraries, Not Frameworks
#118Earlier 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?
I don’t thin AOP is specific to static languages. From my understanding, the “aspect” part implies the ability to “hook into” and extend an application at specific “cut points”, which are typically pre/post function/method calls. This is done in Java by modifying byte code to insert proxies. I imagine something similar could be developed with other languages. It might just be easier to do in Java because the type signatures are static.
Re: Write Libraries, Not Frameworks
#119I was expecting a one-sided rant. Instead, I got a reasoned distinction between two different approaches, the trade-offs of each, and a discussion about the cases where one approach (frameworks) can be beneficial but also identifying the added risks of going that route. I agree with the conclusion, and why. I wish even more people were willing to write down a discussion of alternatives and their trade-offs. Instead o…
Yeah, I was expecting something a lot less nuanced after that warning at the beginning. I both love using full-featured frameworks (I reach for Django over Flask) and totally agree with the article.
This was the blog equivalent of someone sincerely saying “Pardon my language, but gosh darn it that man is a jerk!”
Re: Write Libraries, Not Frameworks
#120Earlier 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?
In the dynamic languages world this is done with monkey patching.
If you invent a declarative way to monkey patch your code, you've got AOP as done in Spring.