- cross-posted to:
- [email protected]
- cross-posted to:
- [email protected]
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.
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.