An outline of two extreme viewpoints that turns into a dramatic but subtly stated endorsement of end-user programming. Or am I just predisposed to interpret it that way? https://www.sicpers.info/2019/10/zen-and-the-art-of-software-maintenance There's an analogy here with typing. It used to be common to want to have secretaries who typed out things for us. That doesn't seem an aspirational goal anymore for most people. What are the reasons for this shift? Could they apply also to programming?

Oh, funny, looks like we’re both following Graham. My interpretation was close, but slightly different: https://twitter.com/stefanlesser/status/1187706584400617473

Yeah, that's the middle of OP. But then the ending has a twist, pointing out that even if you're entirely romanticist when thinking about the next release, thinking more long-term forces you to reintroduce the classicist viewpoint. To me the conclusion seems inescapable in the context of this channel: end-user programming is fundamentally about giving people a sense of architecture, and of teaching them this without them noticing. Programming isn't like motorcycles at all, something fewer and fewer people hack on over time. It's more like typing, an activity that used to be restricted to professionals but now performed self-service by everyone.

@Kartik Agaram Hmm… not sure if we are on the same page then. For me, focusing on user experience means you need both classic and romantic — can’t have one without the other, but you need to get the priority right — that’s why I quoted that exact sentence in my tweet. I’m also thinking hard about your typing analogy in this context. The motorcycle analogy in the book/article assumes a divide between programmer and user. And the different mindsets make the distinction between classic and romantic possible. Part of that is that some “romantics” don’t want to know how to fix their motorcycle and are happy having somebody fix it for them. That notion is easy to overlook in the quest for making programming more accessible to more people. (Which we absolutely should, but…) Should we focus on expanding the mechanics of programming to include users, effectively teaching everybody how to type, perhaps by making it a little easier (that’s how I understand your typing analogy)? I’d much rather want to build better things that appeal to both types of people, classic and romantic; those who type because they like writing, the craft, wordsmithing perfect prose or poetry, but also those who just want to write a damn email to move their project forward — those who want to get stuff done that has nothing to do with typing, typing just happens to be the most convenient way for them to make progress. Programming has proven to be great for one group and terrible for the other. I’m not convinced that programming will someday be like typing; that we can make it so easy that it becomes the most convenient way for everyone to take advantage of computation. That’s why I have personally turned away from trying to invent a “better programming language” or a different (perhaps visual?) way to specify computation. Instead I like to think harder about what it is that people want to do with those computational powers we have access to and they don’t. And how we can generalize those things to enable more people to take advantage of computation. Just like everybody today can take advantage of typing. But the mechanics of typing are not the important part. I’m struggling to convey what I mean, and I realize that it might be hard to see the difference there. But I fundamentally believe it’s that difference which is what Alan Kay means when he talks about the computer revolution that still hasn’t happened. Or Bret Victor when he feels misunderstood when people ask him about his Inventing on Principle programming system demos that were just supposed to be a specific example for making a much larger point. Or what Michael Nielsen and Andy Matuschak explore when pushing the limits of what a website can do to help you learn something. These are all excellent, dare I say even legendary programmers, but that’s not the point. They use that skill to get somewhere else. After all it doesn’t matter that today everybody can type, what they type matters. And tomorrow it shouldn’t matter if everybody can program, what they put computation to use should matter. How they put that computation to use is an open question which I believe has more answers than just “programming” — to get there, however, we need programming, and much better and easier ways to do it.

Yes, there's a divide here. And yes, you're on the side with Alan Kay and Bret Victor on it 😄 No point thinking hard about analogies. Mine was intended just as an existence proof that not all fields get specialized away. Some disappear by diffusing into the pool of generalist activities. Beyond that, analogies will never persuade anyone and they shouldn't. So setting analogies aside, here's the argument I see: * We all want people to be able to write more sophisticated programs. * All programs tend to grow more complex with usage. Not even great programmers can avoid this trajectory, it seems. * Managing increasing complexity requires design sense, a certain taste, and that requires accumulating some scar tissue. There are rules of thumb to be aware of, and also an essential humility about how easily the simplest of problems can explode. Probably other things. But most importantly, you can't learn them until you've experienced some failure. To me the conclusion seems ironclad: we have to figure out how to get people on the trajectory of learning about design and architecture. Which piece of this puzzle has wiggle-room for a different conclusion? I think Victor and Kay are focusing on just the next step but not attending to where it leads.

@Kartik Agaram Design sense, yes! It’s late here and I should be sleeping, but these are words I should have used. Thank you.

Which piece of this puzzle has wiggle-room for a different conclusion? I think Victor and Kay are focusing on just the next step but not attending to where it leads.

Can you elaborate on that? I’m not sure I’m following. Again, it’s late here (so also please take your time, I’m going to sleep now. ;-)

Perhaps it's overstating things to say they're 'not attending'. Perhaps they're just not emphasizing that the "bicycle for the mind" will also train design experience.

I really like the way you put that:

not just for the domains they care about but also for meta capabilities like system design

what about flipping it on its head? Would focusing on expanding capabilities for system design result in gains to the other domains?

Good point! The esteem programmers hold Christopher Alexander suggests other fields already do use design. But yes, I think software can be a vector to disseminate it further.

@Kartik Agaram Interesting. So are you saying Kay and Victor are too focused on computation still and not enough on design?

Hmm, not sure I understand that distinction. Perhaps a concrete example will help, in two parts: 1. Spreadsheets are great for non-programmers. Let's generalize spreadsheets beyond tables. 2. Spreadsheets often grow too complex to debug, and bugs are often missed. Let's improve spreadsheets to be easier to debug. I've long suspected both these endeavors to be doomed. If you focus on just one side the other will get you. And if you try to focus on both the problem ends up getting too constrained. The issue here is that both problems are Romanticist in their framing. Here's a Classicist reframing: spreadsheets are great for non-programmers but they're fundamentally incomplete. Let's use spreadsheets as a gateway drug to teach people to test what they build, value simple solutions over complex ones, decouple solutions into sub-systems, etc. I'm starting to think Alan Kay and Bret Victor would agree with this. The new steelman model of them in my head agrees that tools need to help people change, but just hasn't found a way to clearly communicate this nuance at scale. Their fundamental goal is to inspire.