programming for the next billion
(spreadsheets on steroids)
if we can eliminate software engineering as a profession our work will be done. there will be nothing left for humans to do, because at that point we will have invented a general ai. not that engineering is special, rather, like many roles it requires generalized problem solving skills to do effectively. up until that point, software engineering will be an important job. i really don't understand this attitude that everyone should be a programmer or that programming should be easy. it isn't easy. obviously, we should remove unnecessary friction and complexity from the process, but framing your thoughts precisely takes discipline. building maintainable systems takes practice and understanding. it takes years of study and work to become a good engineer.
people *should* be taught programming in school, like literacy and mathematics, but that doing so is not going to prepare students to make production-grade software. we need trained engineers for that.
i definitely think people should be exposed to programming in school, but we study physics and chemistry there too and nobody expects everyone to be a physicist or chemical engineer. specialization is a good thing. good tools are very important, and we shouldn't stop working to make them better. what i disagree with is the idea that good enough tools can replace engineers without first developing general ais. until we get to that point, there will be systems that need to be built that only professionals are qualified to work on. i'm not saying that we need licensing boards or any of that nonsense, just that nobody is going to merge poorly constructed code into an important project.
1: with eve
assuming people have been *exposed* to programming, the types of user interfaces that are acceptable changes. people aren't stupid, in the early days of computing the interfaces we much different. closer to what people today would consider an expert tool cli tool. if we assume people are capable of learning, giving users much more powerful tools becomes feasible. consider spreadsheets. millions of people use spreadsheets every day to solve all kinds of problems. imagine if your computer was more like a spreadsheet.. and less like an infotainment console.
acme from plan 9 is a contemporary example of this idea. to control your computer you simply type commands and click on them. this concept has been explored many times, but the scripting tools are always too powerful. the scripting interface *should not* be a general programming interface. doing this effectively is difficult, but it helps to make the language declarative. it should be easy to extend the system vocabulary, of course, but it is important to remember what role the scripting interface is trying to fill.
3: acme from plan 9
the future is more exciting when you feel empowered to kick its ass. well designed tools can give you that feeling of power. a computer should not be an intimidating presence. a computer is a tool, not a djinn. if we remove and simplify the control surfaces, machines can become psychic extensions to our bodies *without* brain-interface technology. it isn't certain what this would look like just yet, but that's something that we can explore together.
I think I'm mostly in agreement with that essay. (It's very similar to the thesis of my essay 'Big and Small Computing'.)
Two points where I think we might disagree:
1. I think most of what software engineers do right now, by volume, is stuff that (were interfaces more flexible) ought to be handled by users. Software engineers do this stuff because it's walled off from regular users unnecessarily, but we aren't happy doing it & the users aren't happy with the results.
I agree with that more interfaces need to be programmable in a safe and easy way.
2. UIs that are capable of general purpose programming are fine, so long as the user isn't expected to perform general purpose programming in order to perform common tasks. The success of the unix shell among non-programmers in professional settings is evidence that this can work, as are things like lua scripting in game modding.
i think what i'm trying to get at is that there is an inflection point where the inherent complexity of a given problem is more than a user should be expected to handle on their own. at this point an engineer is needed to solve the problem effectively.
i do think that users are capable of a lot more programming than they are expected to do today. i also think that many of the restrictions that you would want to put on user scripting would make writing programs to solve problems above this inflection point annoying or difficult. because of this and the amount of detail an engineer would want vs a user, i think different (compatible) tools are needed for each group.
I think we're in agreement. Maybe we disagree about where that line is, though.