I'm not sure thats a perfect analogy. in both those cases, the big change has often been machine aided manufacturing (especially with textiles), combined with lots of engineering/materials science. engineering and materials science has definitely aided the speed and effectiveness of computer hardware design as well (and anecdotally, people seem to be buying phones and laptops less often, they last longer), but that isn't true of software- we need (or the market demands) more software engineers than ever, afaik. and, as far as i am aware, we are still a ways out from machine aided software design.
I disagree, modern textile workers probably aren't good at hand-carding wool, similarly modern software developers tend not to be good at writing hand-optimized assembly code. Sure, you _could_ do that and there are resources available to learn how to, but (except for some niche fields) there isn't a reason to do it. It isn't productive when a compiler can do a good enough (sometimes better) job quicker.
I’m not trying to step into the discussion, but analogies usually make for weak argument tools IMO. High quality textiles cannot be copied and distributed at almost zero cost.
That's a very good point, assembly does work as a good analogue for more primitive textile manufacturing. but as a CS student that hasn't yet learned assembly, is a programmer using a compiler so much faster as to be analogous to a spinning jenny? or a modern loom?
Assembly is one of the roots of computing, but so is lambda calculus. One might also argue for gates or boolean logic as fundamental concepts. Higher levels of abstraction are much, much more productive, but it's hard to compare like with like, since you are fundamentally measuring different quantities. Is a coder "faster" if their compiler generates much more code than necessary, or if they use optimizing flags to generate fewer instructions?
The point of abstraction is rarely (if ever) speed, either of coding or code execution. Abstraction is about managing complexity. It's not that one couldn't write a prime-finding algorithm just as quickly and easily either way, it's that you can't write Facebook in assembly, and if you did, you would have to reinvent a ton of features from higher-level languages. Are programmers using HLLs more productive overall? Probably: more abstract code uses fewer symbols to express the same concept. However, you lose precision. One can say, "make me a sandwich", and assuming that you have sufficient access privileges, you will likely get some kind of sandwich, but since that's a pretty high-level description, you may not get the kind of sandwich you were expecting. Most of the time, it's easier and faster to just say (e.g.) `let x = 5` than to get bogged down in the details of what that might actually mean. However, if what you really want is `mov eax, 5`, then all of the other things that your HLL might be doing may not be a net benefit.
Hopefully that thoroughly clarifimuddles the subject.
I think that work done at a higher level of abstraction yields much higher productivity, and if you haven't worked with assembly compare working in Python without packages or plain-old-javascript vs. node or react. Our language abstractions improve expression (if they're done right) and make it easier to turn concepts into actions...
But! That isn't even the part I care about. Once you get into the world you'll find that maintenance and improvement, rather than greenfield development, is the majority of what you'll be doing and that's where this difference really pays off. Higher level languages and programming tools have let us comprehend, inspect and refactor logic with much greater ease, and that's where the improvement hits the most. Coincidentally, that's also what whoever pays you will actually care about.
