bret victor:

I do think that it would be kind of a shame if in forty years we're still coding in procedures, in text files, in a sequential programming model. I think that would suggest we didn't learn anything from this really fertile period in computer science.
That would be a tragedy. But even more of a tragedy than these ideas not being used would be if these ideas were forgotten. If anybody were ever to be shown this stuff and actually be surprised by it. But even that's not the biggest tragedy. The real tragedy would be if people forgot that you could have new ideas about programming models in the first place.

alan kay:

A lot of the problems that computing has had in the last 25 years comes from systems where the designers were trying to fix some short-term thing and didn't think about whether the idea would scale if it were adopted

programmers tend to make tools for programmers. it is much easier to write a program if you can require a high level of technical sophistication of your users. we programmers are also addicted to highly technical problems, we love to build ingenious applications, scalable products, fancy technologies and algorithms. after all this is our home turf, this is what we learned and love.

Every student in every school should have the opportunity to learn computer science http://code.org

you've certainly witnessed the strong push from the technology industry to teach everyone how to code. but is this really the problem we are facing right now? because what i see in my environment is people who are struggling presenting their photography portfolio to other people or creating a community of friends to play sports. creating a website or a mobile application isn't really the problem they are trying to solve. for example, they just want to make information available to others, they want to communicate or they want offload repeatable tasks to their computer.

however for many problems, powerful tools like a programming language are too capable: they drain the energy to solve the problem you actually want to solve. after all, a website or a mobile app is just means to and end; and so they fail. then they ask you if you can help them, because you are so good with computers. but actually the difference between you and them is this:

Technologists know too much about too many layers and non-technologists know too little about too few layers to be able to establish effective direct communication Jean-Baptiste Quéru

you, my dear programmer friend, know about tcp, ethernet and iso/osi layers. you know about domains, dns, cname's and redirections. you know about server setups, heroku and git deployments. you know about browser quirks and html standards. you know about fancy css instructions and the impact of hardware acceleration. i could go on. and when you start to explain layer by layer you always run into leaky abstractions:

The only way to deal with the leaks competently is to learn about how the abstractions work and what they are abstracting. They save us time working, but they don't save us time learning. Joel Spolsky

and this is why you spent years and years learning about current and new technologies, about better ways of solving problems, about improving your coding skills and how to build projects. and this is also why you can't teach somebody to become a programmer in just a few months. of course you should try to do so, but that is not the point i am trying to make here.

whenever discussing this topic with friends and colleagues, somebody brings up the story that back in the early decades of the last century, everybody knew how to repair and tune their cars. and if your car broke down and you couldn't fix it yourself, a passing stranger would certainly be able to help you. with the current generation of cars this is not needed anymore and people don't actually need to know how their engine works in order to drive.

while this might be true, i think this is the wrong analogy to make here. more importantly, this story should teach us that cars evolved into a state in which they became a tool to solve one problem, which is getting from a to b.

with our so called general purpose machines this problem is much harder to tackle. but if you look at research projects and prototypes from the mother of all demos to von neumann style liberated programming to flow based programming you will find so many great minds who were and are trying to seize exactly this problem. who were and are trying to bring computing technologies to people and not trying to bring people to technologies.

it looks as if history is filled with two types of people: the ones that want to maintain a comfortable status quo and the ones that want to move humanity forward. i really hope that we can push humanity forward, but not by teaching everyone to code, but by thinking about how we can evolve the currently sad state of computing. by thinking how we can make the power computing technologies give us available to everyone. the rest will follow automatically.

thanks to diego escalante urrelo, nicolas christener and ruben vermeersch for reading drafts of this.