Why do we need appimage when we can have single binary statically compiled executable?
Additionally, I can't really understand why are dynamically linked libraries so popular and how on earth anyone who ever had a ".dll / .so not found" error thinks this is a good idea.
The main idea as far as I understand was to be able to share code which I think everyone knows work only in theory, besides would it not be easier to just recompile the executable from source with updated dependency statically linked?
Other idea behind dlls were that you could replace a dll with different dll as long as the api was compatible which is very unlikely scenario for average people.
Yet another possible advantage would be that the library code is shared so it takes less space on disk which might be true for some libraries which are very common but on the other hand static compilation only includes the part of library code that is used by the program so it takes less space anyway and is more optimized.
So the reasons to use the dlls can be easily dismissed.
About the disadvantages - if the dll is not present the program will not work. It's quite simple and in my view if you create a program which does not work by itself then that's a failure on your side.
The dlls are just nightmare most of the time, static compilation for the win. (pic for attention)
Because programmers find a good way to do something then apply it to everything. It becomes the one true way, a dogma, a rule. Like how OOP was the best thing ever for everything, and just now 30 years later is proven to be actually bad. At least appimage is more like DOS-s "just unzip and run it" then "download another 500MB of useless stuff because the program depends on 1 20kB file in it".
That said, well made libraries are good. As in those that have a stable API so versions don't matter that much.
Alan Kay coined the term 57 years ago and we have to look at the landscape back then to see just how much OOP has actually influenced pretty much all languages, including ones that distance themselves from the term now. Avoiding shared global state. Check. Encapsulating data and providing interfaces instead of always direct access. Check. Sending signals to objects/services for returned info. Check check check.
Data oriented design is the new thing, much different from that.
OOP, other then smalltalk and maybe few other languages, is somewhat different in practice from the original idea. I can dig up a great talk from Alan Kay on OOP if you want. Actually i want to watch it again so i'l edit it in here when i find it.
Edit: https://www.youtube.com/watch?v=fhOHn9TClXY Great talk, as far as i remember.
That said, we often have to process seemingly unrelated data together which is slow with the model of passing data arround (even when by reference). When OOP was invented memory access was as fast as actual operations on it, while today memory is much slower then processing. With caches and simd and such, it is much faster if everything is an array. Peronally i'm not a fan of OOP because of the "everything has to be an object" mentality, but do whatever you like.
DOP, OOP... just give me "C with classes" and I'll cast whatever
void*to whatever's needed ๐