Nothing here is wrong, but it does ignore the reasons end user programming has proven undesirable.
It’s largely undesirable from an IT management and end user perspective because it allows malicious code to do malicious things and ill thought out code to do bad things that are hard to track down. It also makes it much harder to collaborate or train people on software without also giving them your customization code. Which is great until they need something you hid away.
I would argue that end user programming is already almost everywhere it’s desirable - in various kinds of productivity software.
Probably a better next generation solution would be something that makes it easy for apps to expose apis with a standardized security experience. Which MSFT have tried many times to create. And maybe some standard way to embed some ui extensions- maybe as basic as the ability to tether one window to another.
This is not to say that we’re at a global optimum, but the transition to a more “bicycle for the mind” type computing experience is going to require totally rethinking integration points, sandboxing, and security. This leaves intermediate states “impossible” and getting over that chasm challenging.
I mostly agree, except I think there’s a lot of space for personal tooling. But I also don’t think that the current EUP approaches are as good for personal tooling as people want, because personal tooling involves splicing together lots of (often non-programmable) consumer apps.
I think there is a case in the right size of company. Where envs are cheap, give everybody their own env! That by the way is what Bank Python does: everybody gets infinite envs and you just control the ones that are represented to other people as correct.
Hence what I say about apis ;) but even then there’s a huge level of skills required to be able to make use of any kind of programming because it involves being able to learn a really extensive set of thinking skills.
When I was a lawyer, I used to impress my colleagues with my ability to use a spreadsheet. That’s the most accessible programming tool in the hands of the profession that engages in the most programming-like activity outside of STEM, and it’s still like magic to them.
Even as we get programming to the same place as calculus, it’s not going to change that much. Most people struggle with trigonometry and calculus even they were taught them in school. Everyone (to a first approximation) in the UK used to learn French in school, but even being hilariously bad at French is still considered pretty impressive in the UK.
Personal programming is only going to get big if programming becomes something most people have to do on a regular basis so much that it’s a huge part of our culture, for everyone. Rather like speaking other European languages in the Netherlands or Iceland.
Edit: or for an example closer to home, most developers aren’t that great with text processing tools and plenty don’t really use the shell. Most people don’t use vim or emacs. Even within our profession the demand for personal tooling is lower than it would appear to those of us who do actually indulge in it. Or to put it another way, it won’t even see significant uptake from programmers let alone anyone else until it gets vastly better.
Is malicious code such a large problem because in the vast majority of languages you can insert malicious code anywhere, making it impractical to check for maliciousness? Historically there hasn’t been great options for sandboxing either, at least to my knowledge. If these issues were greatly improved, would end user programming be more common or practical?
It has nothing to do with languages. If users can add code that messes with their own data (and the network) then end-users will install some random snippet they found online which steals all their stuff.
See also: https://enso.org (née Luna).