As it happens, computer science is exactly about those rigid steps of how to get a computer do bigger things. If you could express what you want, you could replace considerable part of Knuth's books by referring to "just sort these numbers for me", leaving the "how" to the computer.
Bridges don't get built because some guys "wants to go see the other shore". Bridges get built by rigorous design and constructed a rivet by rivet or bolt by bolt. Then you can go see the other shore.
For most part, we've come a long way in programming. Sorting has many reasonable algorithmic approaches well-studied and as a result of that in almost any language you can already say sort() and have some stuff sorted. I don't particularly need to know that Python uses timsort, it just sorts. Of course, I can study sorting in detail if I want to and possibly discover something novel.
Why programming never gets easy is that by solving existing problems we accumulate newer, more complex problems and interactions. Programming will always be difficult because we automate anything that's no longer difficult.
The "Sort these" example is not programming, it's something else that potentially builds on programming. Type some stuff into Matlab and watch your computer sort out difficult stuff for you and do the calculations in parallel in highly efficient manner using Cuda. It's not programming, it's using a machinery that has been programmed to interpret certain classes of the user's wishes and take care of all the physical steps required to finish the desired computation. You still can't ever take a blanko computer, ask it to sort stuff, watch it figure out how and call that programming.
I totally understand and concur with the need for the tools to build bridges by rigorous design. I also think we can look for better tools to build bridges, if we understand better the seas and rivers we are crossing, and if we analyze the limitations of the current tools.
Bridges don't get built because some guys "wants to go see the other shore". Bridges get built by rigorous design and constructed a rivet by rivet or bolt by bolt. Then you can go see the other shore.
For most part, we've come a long way in programming. Sorting has many reasonable algorithmic approaches well-studied and as a result of that in almost any language you can already say sort() and have some stuff sorted. I don't particularly need to know that Python uses timsort, it just sorts. Of course, I can study sorting in detail if I want to and possibly discover something novel.
Why programming never gets easy is that by solving existing problems we accumulate newer, more complex problems and interactions. Programming will always be difficult because we automate anything that's no longer difficult.
The "Sort these" example is not programming, it's something else that potentially builds on programming. Type some stuff into Matlab and watch your computer sort out difficult stuff for you and do the calculations in parallel in highly efficient manner using Cuda. It's not programming, it's using a machinery that has been programmed to interpret certain classes of the user's wishes and take care of all the physical steps required to finish the desired computation. You still can't ever take a blanko computer, ask it to sort stuff, watch it figure out how and call that programming.