3 ms·

This is always going to be a problem with dynamic linking. It happens with dynamic linked libraries. In order to use some function, you have to bundle and depen

by sago 12y ago

This is always going to be a problem with dynamic linking. It happens with dynamic linked libraries. In order to use some function, you have to bundle and depend on a whole library. That library may have functionality you don't need, which may make it reliant on other libraries, and so on. And if two of the libraries you depend on, in turn depend on different versions of some other library, you get dependency hell. But libraries are just one level of fractal self-similarity. Packages bundle libraries and other supporting tools, so one package depends on others, containing tools and functionality you never use. And packages suffer the same dependency hell. Then we invent even higher abstractions to make the dependency hell go away. Maybe Docker containers. But then what happens when you need assemblies of those? Pods of Containers? This is a problem with the dynamic linkage model of code reuse. Not that static linkage solves the problem totally, but it doesn't have the same dependency bloat, and dependency failures occur in the development phase, rather than during deployment (or worse, many months later). So yeah, Cathedrals are more elegant, and better code. But, so what? Cathedrals might be nice to go sightseeing at in a new city. But they took years to complete, were funded by government and rich benefactors, and are mostly empty. I'm sure God appreciates them; but they are largely irrelevant to most mortals. I've been doing this for more than 20 years, and my old self cringes when I download a 4 megabyte package for anything, given what we used to achieve with 4Kb. But I can't deny that I can get a product out much quicker now than I used to. It might not be as elegant, or perhaps as maintainable, but the market doesn't care: I can worry about that when I get revenue. If I spend time building a cathedral, a bunch of others are going to come build a bazaar outside the door and clean up, well before I've put down the foundations. I agree with everything he writes, but I don't see any practical alternative.

Silhouette 12y ago
(The site appears to be down, so apologies if I've got the wrong idea here.) But I can't deny that I can get a product out much quicker now than I used to. Ironically, I'm not sure even that is true for some of the projects I work on. The amount of time we spend dealing with dependency, build and deployment issues caused by some variation of package and repository management is crazy. It's often true that you can get a quick and dirty prototype out quicker by throwing together the right combination of libraries, I agree. And it's certainly true that a lot of places are selling products and services where the code is of that quality. It's also true that the people using those products and services are all too often getting what they're paying for as a result, both in how well the software works and the kind of customer service they get when it breaks. I continue to hope that at some point the pendulum will swing back the other way, probably when we reach a point where significant markets are so fed up with short-lived, poorly supported, half-broken junkware that they understand the benefits of paying for something better. For now, sadly, the "everything should be free, or at least no more than $2 on my platform's app store" mentality is so prevalent that outside of serious professional industries it's hard to make money selling software that is actually good any more. Back on a more technical subject, dynamic libraries do have one major advantage that is sometimes overlooked in the static vs. dynamic debate: you can access code in them from different programming languages at run time. In contrast, tools for compiling and statically linking code from different languages are rare, assuming you're even talking about languages that compile and link statically in the first place. Often the best you've got is hoping that each language can generate object files using the same probably-C-based ABI, making it possible to statically link them assuming that the various run-time systems are then set up correctly by the code itself.

by sago 12y ago

Silhouette 12y ago

(The site appears to be down, so apologies if I've got the wrong idea here.) But I can't deny that I can get a product out much quicker now than I used to. Ironically, I'm not sure even that is true for some of the projects I work on. The amount of time we spend dealing with dependency, build and deployment issues caused by some variation of package and repository management is crazy. It's often true that you can get a quick and dirty prototype out quicker by throwing together the right combination of libraries, I agree. And it's certainly true that a lot of places are selling products and services where the code is of that quality. It's also true that the people using those products and services are all too often getting what they're paying for as a result, both in how well the software works and the kind of customer service they get when it breaks. I continue to hope that at some point the pendulum will swing back the other way, probably when we reach a point where significant markets are so fed up with short-lived, poorly supported, half-broken junkware that they understand the benefits of paying for something better. For now, sadly, the "everything should be free, or at least no more than $2 on my platform's app store" mentality is so prevalent that outside of serious professional industries it's hard to make money selling software that is actually good any more. Back on a more technical subject, dynamic libraries do have one major advantage that is sometimes overlooked in the static vs. dynamic debate: you can access code in them from different programming languages at run time. In contrast, tools for compiling and statically linking code from different languages are rare, assuming you're even talking about languages that compile and link statically in the first place. Often the best you've got is hoping that each language can generate object files using the same probably-C-based ABI, making it possible to statically link them assuming that the various run-time systems are then set up correctly by the code itself.