[dmoy]

You can make the same argument about basically any technology that has gotten more reliable, cheaper, easier, etc over the years.

Cars is a big one.

Going back farther, textiles. We don't spend a staggeringly large percentage of our time making and/or repairing our own clothes anymore. For the most part, clothes "just works", and the average person doesn't have to worry about it.

[peter_l_downs]

Taking cars and textiles as an example, though, is pretty disheartening if you would like to see a future with a lot of computer programmers in it. Although taking the cynical view, as a young-ish programmer today it probably points to a world where your skills only get much more valuable over time, as there will be less competition from a younger cohort in the future...

[Green_man]

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.

[munk-a]

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.

[davemp]

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.

[Green_man]

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?

[canhascodez]

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.

[munk-a]

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.

[NTDF9]

> You can make the same argument about basically any technology that has gotten more reliable, cheaper, easier, etc over the years. Cars is a big one.

This is really it. Kids grow up with Ipads as their computer and cloud storage. They dont see the need for local paths, desktops, memory, disk etc.

Soon, computer programmers who actually understand what a computer does will become as rare as a IC engine engineer.

[TeMPOraL]

Yeah, but this spins into another problem - dependencies.

Cars, be it 60 years ago or today, were and are things you buy and own. You may take them to specialists for maintenance, but you're generally responsible and in control of the overall operation of the machine. Computing today is ceding most of it to third-party services. Suddenly, your experience is dependent on multitude of companies (which fold as quickly as they pop up), and you don't own anything.