It's the right attitude to take, but let's try to provide some definitions. What does it mean "to program"? Certainly we have contemporary ideas of what it all involves. But at the end of the day it's hard to come up with a more encompassing definition than "telling a computer what to do (and possibly what to do later)." This means that by merely "using" a computer (ie through a GUI or whatever -- manipulating it somehow) one is, by this definition, doing some kind of programming.
With that definition in mind, we now see that the systems we have provided users are completely hamstrung. We have given them limited environments and languages (languages here being mostly of a visual/UI variety) to work with.
What's worse is that we have goo examples from even recent history about how alternatives can work: Visicalc, Hypercard, Smalltalk, etc.
Insofar as these conversations rely on discussing "programming languages" -- a loaded term, and only part of the picture really -- rather than whole "computing environments," then we tread further down a losing path for everyone.
Whatever definition you end up with, it must have equal representation of data and code.
Current GUIs are have the same problems as the 50's analog computers that required somebody inside them plugging cables all day long.
APL does the hard part of choosing composable functions and presents those to the user, as a simplified interface. Sorting isn’t a global namespace of thirty different sort algorithms so you can delight in picking the exact one you want, sorting is one character (⍋) so you can use it as a composable building block and not care about the details.
I might agree that the core issue is that programs have become less composable over time - but what you ask for doesn’t seem to address that at all. Part of the job of designers and creators is to make simplifying decisions on behalf of users; I don’t want the lightbulb raw interfaces to be exposed to me as an alternative to a crummy closed app product, I want a well designed composable app product as the api I use - all at once, so I don’t have to care about negotiating access tokens or header padding anymore than I have to care about LED heat dissipation or mains smoothing inside the bulb when I flick a light switch.
For composition I want Lego not a machine shop, and I accept compromises in ability to get that. I want grep not fopen().
When you say you want composition what you’re asking for is a machine shop; not a bad thing to ask for, but completely different from where you started out with Unix shell composing of finished product programs which you originally said you wanted.
So if I have a computer and I want to access the internet, I should have to write my own browser first?
No... "to use a computer you should program it" isn't a philosophy, it's a technical limitation from when "programs" were simple and everything ran in a terminal, and no one but engineers and students would ever be expected to touch a computer in the first place, and it doesn't scale.
Should people be able to write software for their own computers? Yes.
Should programming be considered a normal part of computer use, and be far more common than it is, with systems and software being more open than they are? Yes.
Should people need to write their own software? NO.
>I think we as an industry made a wrong decision turning programs into products. We should have kept programs as programs - make them super composable, and then let the end user design their own products that fit them best.
It wasn't entirely wrong. End users don't want to write software, they want to use their computers do to things - and most of those things now require multiple thousands or millions of lines of code written by engineers with domain specific knowledge. Turning programs into products is a way of managing the complexity necessary for software that's useful to people in modern society.
"... (browsers) are multiple different kinds of programs, welded together for no sensible reason: an http fetching daemon, a "runner" to open URLs, several document viewers, a virtual machine, an OS with an API, extensive libraries for everything that the OS below the OS already offered, one or several programming language JIT compiler(s) and runtime(s), and some bits and pieces. In a healthy environment, there would not be a second OS on top of the normal one. And all those parts would be separate software, with standardized interfaces. ..."
It also potentially creates a similar problem to DLL hell in Windows, where updating or changing a component potentially breaks dependent software, or multiple versions of the same component need to be kept around. And then there's the "n+1 standard" problem, where everyone doesn't actually agree on what the "standardized" interfaces should be.
The real problem, to me, is that the FOSS model of every user being a programmer fundamentally breaks down when software reaches nontrivial complexity (wherever you choose to set that bar.) You could substitute the browser as the subject of your first sentence with just about any software people use - most of it is too complex for the average person to fully reason about, much less the average programmer.
I don't know how to solve that, other than require all software to be simple enough to fit in a single file and run in a REPL but that's obviously not feasible.
> The language that you build your extensions on shouldn't be thought of as a programming language in afterthought; it should be designed as a programming language. In fact, we discovered that the best programming language for that purpose was Lisp.
> It was Bernie Greenberg, who discovered that it was (2). He wrote a version of Emacs in Multics MacLisp, and he wrote his commands in MacLisp in a straightforward fashion. The editor itself was written entirely in Lisp. Multics Emacs proved to be a great success — programming new editing commands was so convenient that even the secretaries in his office started learning how to use it. They used a manual someone had written which showed how to extend Emacs, but didn't say it was a programming. So the secretaries, who believed they couldn't do programming, weren't scared off. They read the manual, discovered they could do useful things and they learned to program.
> (2) Bernie Greenberg says that Dan Weinreb's implementation of Emacs for the Lisp Machine came before Greenberg's implementation for Multics. I apologize for the mistake.
~ "My Lisp Experiences and the Development of GNU Emacs" (Transcript of Richard Stallman's Speech, 28 Oct 2002, at the International Lisp Conference). https://www.gnu.org/gnu/rms-lisp.html https://news.ycombinator.com/item?id=20374467
I found myself being frustrated recently at Lifx smart lights. I had wanted to put a slider widget on my home screen of my phone. There is no way to do that. The only way is for me to write my own program. I started work on it, then had to wade through ridiculous amounts of documentation on the lifx api site, android docs. I still haven't finished it.
Consider on the other hand, if android were a massive lisp environment where every API is available in the global scope - think emacs - how easy would it be to program the things you want!
Now I use Lifx as an example and I appear to be bashing them. I am not. At least Lifx publishes their API for consumption. Another time I tried to pipe an app that generates white noise for sleep to another program (TL;DR I was too cheap to buy a Sonos), but alas no publicly accessible API. I had to hijack the BT stream to do something remotely useful to it.
You may think the solution is to get people to publish accessible APIs. I think that's a band aid solution. The core issue is somehow programs have become less composable over time. Far from the original ideals. Programs become standalone products.
I think we as an industry made a wrong decision turning programs into products. We should have kept programs as programs - make them super composable, and then let the end user design their own products that fit them best.