Have to say, I wasn’t expecting this in my feed. It is a bit novel of a concept, but if you think about what it takes to build and ship a product, a lot of this makes sense, and modern languages are starting to follow the batteries included mentality (golang, rust).
There’s even an ironic naming ecosystem that just lends itself to this personification: flatpak and containers.
You must log in or register to comment.
My MarioKart 64 cartridge probably won’t inform me that Python2.7 was deprecated.
It also won’t tell you if the OpenSSL library it uses has a vulnerability or not. I program mainly as a hobby and I still wonder how containers deal with that issue.
I still wonder how containers deal with that issue
They don’t. And neither do statically linked binaries. Those are valid concerns against both patterns.
In the end you have to try to keep dependencies to a minimum and update those you have as often as feasible. That could mean that you have to rebuild your container images regularly, even if you didn’t change any code. Or that you rebuild your static binaries with newer libraries and toolchains from time to time.
The main advantage you still get (from both) is that you can at least be sure, that the stuff that propagates between your stages into the production system doesn’t suddenly change, because one of the system libraries is a different version.
Containers also allow your to sandbox your application to a larger degree so that when something goes wrong, it is atleast confined to cause the minimum harm. But the more complex your application, the bigger that “minimum” gets. Each dependency could end up being the key for an attacker to spread.
My AOP Professor once said that today, we build software like medival smiths built swords: The customer would describe how he would want his sword to look and feel like, and the smith crafted each and every one individually. This led to very unique and well fit, but also very expensive products.
He said that we should aim to build software products like the industrialization revolutionalised manufacturing: Assembling many modular parts into something, instead of hand crafting everything. In his opinion, this will lead to faster and cheaper development.
A company I worked for did something like that for websites. Each website was a little module and you could link them together and have special modules that would do database access and things like that. Easy to use, barely required coding skills.
Aren’t libraries a bit like what your Prof suggests. Luckily I don’t have to code matrix multiplication, I just have Eigen. Luckily I don’t need to code back propagation, I just use Torch. Etc. These tools are for coders, arguably less or differently skilled coders. There just needs to be a bit more simplification or a bit more education of the general public.
Libraries are absolutely exactly that. The problem I see is that because this profession is so young, we do not really know how to do anything. For most use cases, there are multiple tools, languages and libraries available, it’s a lot of work to find out which to pick.
I am sure that when people started building hats, there was a lot of different ways to do it. Many techniques must have been pretty shitty. Noone knew what the best way is, but eventually, everyone agreed to one (general) shape.
It’s possible that the same thing will happen to programming as well. Maybe one day, there will not be more tools for coding REST-APIs (or something similar, in case we find something better than REST), because the one tool everyone uses is already perfect.
This is basically the unix philosophy. Build a bunch of separate apps that can be hooked together (via pipes).
Sort of. I think of the Unix philosophy as being like Lego. Here’s a box of goodies, go crazy. Even Ikea still requires user assembly.
Most end users just can’t do much with the first and often even get tripped up by the second. What we need is something in between that a programmer can use to quickly throw something together to user requirements.
Actually, that’s much like what I was doing with Microsoft Access and Visual Basic decades ago. I probably would never have survived in an actual software development shop, but I was kept very busy by a bunch of small businesses that loved the quick turnaround and manageable costs.
