I think it's a lot easier to build what you have in mind than it was 20 years ago when I started because of increasing levels of abstraction and also because of open source.
20 years ago, if I needed to convert a json file to xml (that's a very bad example because 20 years ago JSON was just born and nobody used it, but no other example as simple as that one comes to mind, sorry ), that would have taken me days of coding just for that single utility function. And probably lots of headaches with regular expressions or syntaxic/semantic parsing.
Today, I type "npm install json2csv" and I'm done.
The only thing that might be harder for people starting today is that the level of abstraction is so high today that we almost don't even need to understand the underlying computer science to be a developer, and so the few rare times when you do need to understand what's going on behind the scenes, that might be complicated. Other than that it's only advantages.
Progress and history always go this way, things always get easier and cheaper to build. I don't see why programming would be different.
I'm not so sure about that, CPAN was a thing as early as 1993, and I remember loving the articles in Visual Basic Programmers Journal reviewing various libraries and OCX controls. If whatever it was had some popularity, you would probably find something that could do the conversion.
But whether it was free or not? Maybe another matter entirely.
And worst comes to worst there was always some awful code to cut-and-paste on ExpertSexChange
>the few rare times when you do need to understand what's going on behind the scenes, that might be complicated
Except they're not few or rare. Got a bug? Good luck figuring that out. Performance problem? Who knows. Most of the stuff you're using, you didn't write, you don't understand, it's all just black boxes, or as someone else said, mystery meat, glued together. And when it starts to smell, and oh it will, you're just looking at a mountain of mysterious complexity.
It's not like building stuff anymore. It's sticking stuff together. "Hey, it's just like playing with Legos!" Except quite often you end up with it feeling like stepping on Legos.
My parent was an electrical engineer. While their skillset was varied, and heavily weighted towards physics and math, their day job was mostly about knowing how to pick parts out of a catalogue, which catalogue to use when, and maintaining good relations with the suppliers behind those catalogues. I always saw this as a weird disjunction.
Until now.
I've just realized that while my core skillset is in math, logic, computer science, and system design, I do spend a lot more of my time researching repositories, packages, licenses, etc, than actually coding. But with the new perspective your comment gave me, I finally saw that as totally in line with other, older engineering disciplines.
So, to address the original point of this thread, it seems as if programming has finally evolved into a semi-mature engineering discipline, wherein our ability to gauge the quality of existing supplies is more important than our ability to produce new supplies.
Brad Cox had a concept of Software ICs, in the chip sense, that align with this. He envisioned these as sharable objects rather than just libraries, but either way that’s the present we’ve been given accidentally.
Motorola developed the MC6839 which allowed one to do floating point math with the MC6809. The MC6839 was not a floating point CPU, but an actual 8K ROM of 6809 machine code that implemented floating point math (with position independent code so it could be mapped anywhere in the memory map). This is about the closest I have ever seen of a "software IC" in my life.
20 years ago, if I needed to convert a json file to xml (that's a very bad example because 20 years ago JSON was just born and nobody used it, but no other example as simple as that one comes to mind, sorry ), that would have taken me days of coding just for that single utility function. And probably lots of headaches with regular expressions or syntaxic/semantic parsing.
Today, I type "npm install json2csv" and I'm done.
The only thing that might be harder for people starting today is that the level of abstraction is so high today that we almost don't even need to understand the underlying computer science to be a developer, and so the few rare times when you do need to understand what's going on behind the scenes, that might be complicated. Other than that it's only advantages.
Progress and history always go this way, things always get easier and cheaper to build. I don't see why programming would be different.