OK, here's a question I am being asked a lot but I have no ready answer but always trying to come up with answers on the fly: why do we need end user programming? I mean, I am totally convinced that democratizing coding is super important and will change the world. But when I talk to "normal people" they don't seem to feel the need. I always have trouble to come up with examples where creating and running code is useful, instead of just downloading an app or whatever.

One way I use is to ask about dissatisfactions within existing apps or between apps. It's pretty easy in my experience to get little things from anyone that they wish they could change, situations where two apps would interoperate. No comment on how easy these use cases are to solve for. But my experience is that everyone has things they wish would change, even if nobody wants to learn anything to actually make a change. Which is natural and human nature. I hate the abstract idea of having to learn new things just to fix some minor annoyance, even if I'm constantly doing so in practice where the energy barriers are economic.

So that's about taking existing apps and modifying that - I see that point, but wouldn't that assume that all these apps are available as open source and that they are created within the end-user programming system?

Yeah, I tend to assume those prerequisites. A common definition for the term: changing the behavior of a system should be no more difficult than using the system. Which pre-assumes that there is an existing system. I currently think of closed platforms like the App Store as antithetical to end-user programming. But I'm sure others here have wildly divergent views 🙂 (I actually tried recently to capture the state space of ideas/projects/goals that are easy to conflate: http://akkartik.name/post/neighborhood. Additions most welcome.)

OK, understood, and a very worthy goal. I am more wondering about a path forward for end-user programming within the world as it is, where we have to share the space with closed source apps, and where the "end user development space" is probably just an app like any other.

Is Yahoo Pipes or ifttt an example of the sort of thing you're thinking about? It sounds like your original question can be rephrased as people asking, "why do I need to use a new app to get the cool programmability features you're talking about? Why can't you meet me where I live, without me needing to change my habits?" Is this accurate? To me it seems self-evident that if I can't modify some external thing (website written in obfuscated JS/webassembly, app, OS, piece of hardware) that limits how much I can interoperate with it to whatever its designers happened to take into account. Does that seem like giving up too easily?

Many hurdles: • A person being frustrated and not remotely having the concept that the problem app could, even in principle, be under their control. • Now imagining the app could "do that one thing" but not having a clear idea of how it would work. • Having an idea of how the new feature would work, but having no idea how to make it work. • Having an idea of how to make it work, and now at last we come to the end-user-programming problem of making it work be tractable. Considering that even if rich invocation is possible, it's hard to cast the spell, "Hey Siri, set an alarm to go run the errand at 8:30am on Wednesday." Or even if all the affordances seem to be in place, looking at the iOS Shortcuts app right now, if there's, say subtle concurrency constraint, even though I'm a professional, there may be no hope. In that case, why even bother?

The easier software becomes to make, the wider the opportunities to create it, because the time investment makes sense. I once wrote a python script to combine photos into 2x2 combi photos because it was cheaper than getting them printed quarter size. I wouldn't have bothered either combining them manually, or doing it in assembly. A huge number of work-hours are wasted operating computers manually at the moment. Many, many businesses create (or comission) bespoke software that is only used by them. In my experience the process of building this software ("requirements gathering" shudder) is about 5% efficient at actually solving practitioner needs. All this stuff should be made by end users because it will actually result in better software.

I agree with all that, but I worry that 'efficiency' is an idea too close to 'delegate', which is anathema in some ways to this whole endeavor. Personally I prefer the argument about the qualitatively different things that get made when everyone takes charge rather than a small group of engineers and PMs.

I'd say the question to ask "normal people" should be phrased such as to avoid the term "programming". More like: Would it be important to you to have more control over the digital appliances in your life?

My non answer is that it seems important but the "why" is yet to be discovered. Computers are a medium, much like writing is a medium. Look back and imagine a world in which very few could write... one might ask "so what's the advantage of everyone reading/writing? everyone is already able to do their usual stuff - be it art or music or farming or cooking or sport." The thing is these activities, as they existed, evolved in a world of "not much writing". Once writing permeates society, it changes not just how we do things but what we do (qualitatively different organization, communication, science etc become possible). Right now we've started to use the computer medium, but it's mostly the old medium in a different form: writing -> digital writing, drawing -> digital drawing, mail -> digital mail. Yes a smaller set of folks use more computing powers like simulation. But what does a future look like where the computer medium permeates society in a way that is qualitatively different than providing an easier version of the old style writing, communication and record keeping? What does this medium look like? I suppose it won't be called end-user programming, but just computering or something.

@Kartik Agaram I agree that any progress shortening the hurdles I mentioned gives a person more energy to hop the others. Take the Siri shortcuts example. A person looking through the app might think "oh, I never thought of controlling that." Here's a vision friends. What if our favorite OS's MVC UI framework required all controller actions to be human interpretable calls. Supporting undo/redo already requires something like this. What if your whole system history were an inspectable thing. Then to get a handle on any action you wanted to script we just be a matter of doing it and consulting the history. Certainly there are graphics programs, Photoshop even, that kind of work this way. Some parametric 3D modeling CADs make it a central part of the workflow. Yes, you go through the steps at first, but then you'll want to edit that list/stack/history of steps explicitly to better parameterize the model later on.

"Normal people" don't really have a need for end-user programming, because computer interaction has evolved away from it. There's the base assumption that everyone should be able to use a computer, but that programming requires formal training. I think that's what Kartik was getting at with end-user programming as a means to change the "landscape of energy barriers." What an intractable problem 😳 I think the practical way to move end-user programming forward is to start with small domains, where there's a more specific need and very motivated people who are willing to learn different ways of problem solving. And once they are able to think with new tools, they can expand the applicable domains themselves. This has been a real challenge for Parabola.io but I think we're having more luck these days! We've recently been narrowing our focus, trying to show folks using eCommerce SASS tools that they don't need to know what an API is or hire a developer to connect the many silo'd cloud tools they use. Many people start by fixing an inventory syncing problem, and all of a sudden are running book clubs with flow based programming 😛

"end user programming" is necessary because the packaged software (maybe provided as saas) can not permute all possible combinations. By providing somewhat end user programmability, user can combine given (limited) features themself, without asking the packaged software vendor to pre-package the combination for them. It is a economical choice between software vendor and user.

my go-to example is: think of all of the times you have tried to find something—an apartment or airbnb that meets some criteria, a website or video you saw a few weeks ago, an actually competent recipe you’d like to try, a really good book on a topic you’d like to learn more about. how many times has that happened, and you’ve had the sense that you could describe your criteria (or some criteria that would significantly narrow your search) in pretty specific, formal terms. but you couldn’t communicate that criteria to the tool you were using (eg craigslist, google, allrecipes, facebook, twitter, spotlight on os x) because their interface didn’t support it, even if they clearly had the data?

Email filters has long been my favorite trojan horse for introducing programmability. Because of course if you have a few filters they'll do surprising things. So you need tests. There's potential for a gateway drug here. I remember in 2007 when I was apartment hunting, using the Google Maps API to build a simple thing I called "pins on a map". Type in addresses and it drops a pin. http://akkartik.name/map Of course, in the normal sequence of events, the Google API no longer works. Being able to visualize multiple arbitrary addresses at once remains difficult.

google maps is a major pet peeve for me. i live in boston: it’s critical to avoid certain intersections and roads at certain times, and there’s no way to do that in the ux

But when I talk to "normal people" they don't seem to feel the need.

In fact, I guess that depends on end-users to whom you are asking the question. And of course we need end-user programming not for everyone, but for those end-users that have the need and/or the pleasure to do some programming without being an expert. Maybe you should ask this question to the "NoCode programmers". There are lots of people there who are not professional programmers, but create things with these "programming" environment that are useful to them.

This is the reason why I use Emacs as my main mail client: I can adapt it to my workflow. But the mail client example also illustrates the difficulty of the problem. What would the user-extensible mail client look like? Some users would want a very simple extension system for adding the occasional button. Others would want more sophisticated programmability. But how many users would be willing to learn a programming environments specific to a mail client? The other approach is the Emacs Way: have an extensible platform and implement the mail client in it. Learning the environment is then more attractive, because it covers multiple use cases. But it's also more difficult. And then, if the idea ever catches on widely, we will see tens of such environments, all incompatible, and we are back to the extensible-app situation where learning the extensibility mechanism is hardly worth the effort.

I really like the Emacs example. I guess it has already a really good abstraction level for extensibility. It was my every day editor twenty years ago, I don't use it anymore, but I remember that I enjoyed adding custom features. I also like Vim very much but mainly for the editing part (I really like the editing paradigm) but found the customisation (i.e. scripting) part less powerful than Emacs one. Now I am using mainly VS code which is another story. But even if Emacs is very powerful as an extensible environment, I guess the language to use is a barrier, maybe we need a more accessible language. I use to program with elisp but I never feel comfortable with it. So what I would like to have is an environment as extensible as Emacs but with an easier way to program, like with a visual programming environment. Maybe a mix between Scratch and Emacs can be an inspiration.

@ogadaki Have you ever taken a serious look at the Glamorous Toolkit?

A look, yes. A serious look, well, not yet. It is definitely a great inspiration in that space, but for now I didn't take the time to play with it, and also to learn and practice Smalltalk (which also requires some serious time). There was that great initiative here called #C01CD90V1NF but I didn't really follow it beside the first intention. Anyway, thanks for the reminder!

Thanks for all the answers! It showed me - to my surprise - that i have a rather peculiar view, it seems, about the future of coding. I am funnily enough neither interested in changing the whole ecosystem, as I think that too expensive, nor in scripting and adapting existing apps - although both are great and worthwhile goals! No question about that, these are great and important things, and I am looking forward when they take fruition. What I am looking for is to democratize the coding experience in the sense that anyone can write and run functions. And I agree that this might help with actualizing the idea of the computer as a novel medium, and that this is a tough sell even though an important one. I need more use cases and a better story. Thanks for some ideas, I will keep looking! This was a very valuable conversation for me. Thanks!

Functions = pure functions?

yes

Not weird to me. But going back to your original question, what's the value proposition of pure functions to "normal people"? I usually find that people want to email somebody or read some API or draw a picture. Are you thinking of this as a spreadsheet replacement?

Without meaning to derail the above interaction, I've arrived a bit late to this thread... 😄 So, to throw in my answer: 90% of giving the normie control over stuff is simply enabling them to (a) wire their data up and (b) configure pre-canned behaviours; the other 10% will again be 90% linking to EUP code that others have built and shared, and configuring that. So we're actually down to the 1% of someone in their armchair in the evening, tinkering with simple rule-level programs. I also hold the faith of empowering normies over computers, but we need to keep perspective. Having said that, the 1% above is still a potential audience of 10s of millions.

@Kartik Agaram no, not living in that environment. I am thinking of "I need the answer to a question, and the answer is provided by a function" kind of usage. Calculator style questions, but for all domains. Anything where you plug arguments in and get an answer out. Not necessarily plugged into a bigger environment.

I see. I think.. Something like Mathematica?

@Denny Vrandečić Something like Wolfram Alpha but based on Wikidata?

Yeah, but everyone can edit it, contribute new functions, everything is open, embed them in their own systems, etc

Sounds like Wikilambda 😉 The reason I mentioned Wolfram Alpha is because it is (1) very powerful, (2) unknown to most people who could benefit from it, and (3) even those who are aware of its existence don't immediately see its power. So you shouldn't be surprised that nobody is asking for an open equivalent. It's worth building nevertheless in my opinion.

Yes, indeed, Wikilambda is why I am asking 😄 - and indeed, WolframAlpha is there but not widely used. Why? I am trying to figure that out.

My personal theory, based on the feedback from the people whom I recommended to look at Wolfram Alpha: if you approach it with a problem in mind, it is not obvious if and how Wolfram Alpha can provide a solution to that problem. Like a programming language, it's a tool that you have to learn to some degree before you can see how it can be useful for you. And the difference to a popular PL such as Python is that people start learning Python because it has the reputation of being useful. Wolfram Alpha has no reputation at all with most people, it's an unknown.

That was a helpful way to state it, thanks, it got me thinking

I'd expect Wikilambda to fare better than Wolfram Alpha because it's open. Wolfram Alpha is basically a showcase or a demo. It's something that Wolfram makes public to show off their technology. But you can't build anything on top of Wolfram Alpha. And therefore the people who do use Wolfram Alpha productively cannot integrate it into a publicly visible tool. Open tools don't have that problem. Python acquired a reputation because its early users made their Python-based work open as well. It is not difficult to find answers to the question "what can I do with Python?"

Although openness is important I think there are additional factors that play a role. It’s really interesting to see the the current zeitgeist developing around personal knowledge tools. One might argue that the whole mediaWiki ecosystem was very early in terms of knowledge management. But it seems at least to me that the notion of databases and others created some kind of friction. But with the advancement of JavaScript in combination with markdown things got really going.

To answer the OP I offer an analogy. (I know I'm 9 months late) End user programming is like allowing you to disassemble your PC. Are you not happy with what you got and are willing to get your hands little dirty -- then go on and open the case! Buy a thing or two, exchange components, get a better thing than what you started with. You don't need to know ins and outs of transistors to do this. If it got the right port then just plug and play. Majority of people will not do this, but for many it is way simpler than buying a new machine or have an expert do it for you. (Some companies will not like you if you want to do this with their machine.) Similarly, you do not need to know about how code works if the systems are compatible. Just break the one you have, exchange parts, pull it together, and run. Is it surprising that such features are not widely available? There is an incentive for companies to have their software closed and open source cannot agree on a common approach. No attempt for standardization can change this. There is just too many people to persuade and too many companies that do not want it. We would need to see an analogy for the right-to-repair in movement in software. Btw I don't think 'normal people' will ever use it.

Thanks for your take. Yes, the way you described it it was like with older cars, people can play with the engine, but most people won't. But then you explained that you think most people will not use it. I was hoping there was a narrative where most people could use it.

I didn't want to be discouraging, but we should think of what we mean by 'most people'. Tinkering with a car is also a good analogy as you cannot tinker with your car if you have none. Also, of the people that have cars vast majority know just how to keep it working but have no idea how to change things; this was different in the past, but perhaps people didn't have a choice then. With end user programming I believe many people will be able to use it, but I do not see how many people will actually get their hands dirty. It may be actually more beneficial to programmers as some 'normal' user may request some trivial change and the programmer (car technician) just opens the app, taps edit, changes a thing or two and done.

This is one reason why I dislike the label “end user”. At the end of the chain, most users are indeed unlikely to do, or want to do, anything they’d call “programming”. For many end users, it would be more interesting to be able to get a professional to customize software for them. Which is in practice impossible with today’s industrial software. There is no equivalent of the car mechanic.

Reflecting on how "elevator operator" was once a serious job.