This is just an adventure in making the word programming as abstract as possible. There's no practical use to doing so, except perhaps to try and ease users that want to learn to program into it.
Historically the distinction wasn't as stark as it is today. Hypertext as envisioned by Ted Nelson and furthered by Tim Berners-Lee's contributions through HTTP/HTML was much more read-write from the get-go.
But you can even go further back in time to Douglas Engelbart's "Mother of All Demos" and Smalltalk during the 70s to see that these foundational technologies tried to inspire and emphasize user empowerment and with it end-user programming.
Things evolved very differently though as systems have become ever more centralized and complex necessitating ease of use and security. It would need systemic shifts on many levels to return to the ideas of the visionaries in our field, the biggest hurdle probably being the "privatization" of the internet itself. Everything is very commercial by design; that was the plan since the early 80s. Elon Musk's Starlink and its use as part of warfare is that DARPA idea fully realized. It only took ~40 years.
We might need to reclaim "territory" from the big platforms and run more communication lines ourselves or at least pull them out from commercial interests. It all flows down to the lower levels; meaning system software and open hardware platforms like RISC-V.
Maybe it's about time for some healthy "devolution" now that we seem to have implemented proof that all of this made sense at and until some point?
End user programming is simply not compatible with the commercial nature of computing, and therefore -- despite very interesting early examples -- it never took off. Now the public have been inculcated into a concept of "what computing is" that is almost entirely on the consumption side.
There are some things that can be done, although it will only help in the cases where such a thing is actually used, which is not always.
The computers can be designed that you can write programs easily (instead of hiding them behind several layers of menus), and design the formats that can be queried and affected by such programs. Services can be made which support such things. The user interface system can be made to easily interact with other programs so that e.g. you can easily interact command-line interface with GUI (something that most existing systems are not very good at).
(You may know about Nushell (which allows command-line shell to be used with structured data; PowerShell does something similar). It is a reasonable idea, and some similar ideas can be used with interaction of data, although there are some problems with it, including that it is not what the operating system was designed to use. This is why I think to design a new operating system which allow to make it much better (in my opinion).)
Furthermore, it must be designed to work efficiently and to avoid unnecessarily requiring internet connections, and to avoid wasting so much disk space, energy, etc.
FOSS will also help, especially if the programs are not too difficult to modify.
A better way to work security than existing mechanisms would also be an improvement; so the user can easily define the security features and specify the source/destination of all I/O, which may also be proxies which are other programs (which might be written by the end user).
(I have some ideas about designing operating systems like many of the things above, although that will not affect many things that don't use it; however, it is a start, and some people may write interfaces with a few other services and programs to support such a thing.)
(Dishonest business practices should also be avoided, although that is really a separate issue, but that will help this one too.)
ugh we could do without the critical theory; the evil technoarchy oppressing users, etc.
The divide here is really between graphical and text interfaces. I think vastly more people would be 'disenfranchised' if everyone was 'empowered' by having to use a CLI, so the inherent non-programmability of GUIs (whatever the author claims, making a new folder is not 'programming') seems like a worthwhile trade-off.
An ideal might be if, as the author falsely claims, apps actually were structured as CLI or APIs overlaid with a GUI. You could then program the CLI/API layer, or re-configure or even re-write the GUI layer to taste.
> An ideal might be if, as the author falsely claims, apps actually were structured as CLI or APIs overlaid with a GUI. You could then program the CLI/API layer, or re-configure or even re-write the GUI layer to taste.
I also thought of like that (although the command-line and GUI are both done from the API; some parts can be done automatically but some parts must be programmed explicitly), it would work better that way. (It is one of the things that I had considered with operating system design.) However, there are details to be considered, such as the usual considerations of CLI, API, GUI, and how these things would be done in order to work well together (I had considered some such details too, though). Of course it would allow to reconfigure and rewrite the GUI layers, which is an advantage; it would also have many other advantages if this mechanism is designed well.
reply