If you look at PC magazines from the late 80s/early 90s, you'll find Asm program listings for small but useful utilities. DOS batch files, another form of programming, was common too.
From several decades before that, I have an engineering textbook from the early 60s which devotes an entire chapter to the basics of how computers work and writing programs (once again, in Asm) to use them for solving problems.
Thus I'd say "End-User Programming" has been around for a very long time, but it's only recently that the rise of "user-friendliness" and locked-down walled-garden environments contributed to its demise.
The problem with end user programming is that no matter how much easier you try to make the interface to use, programming requires some ability to think logically and understand systems and anybody who can do that is going to get frustrated by guard rails and just want to do ‘real’ programming eventually. There’s never going to be the magic interface that unlocks coding for everyone because most people just don’t think that way and the people that do, don’t need a more intuitive interface.
Which isn’t to say that quality of life improvements aren’t important, I just don’t think they’ll turn non-programmers to programmers in any great number.
The existence of eg massively customized Excel spreadsheets say otherwise.
Every sufficiently advanced program already needs a consistent model of objects, manipulations that can be done on them, etc. The skill of seeing a pattern of manipulation and wanting to abstract it may not be universal, but it's a larger category than the motivation to pick up a general purpose programing language from square one.
>and anybody who can do that is going to get frustrated by guard rails and just want to do ‘real’ programming eventually.
Sure, if there are guard rails. But ideally the environment available to them is the same environment (at least most of) the system itself is written in; it shouldn’t be dumbed down, just more approachable.
>and the people that do, don’t need a more intuitive interface.
We may not need it, but it sure does help. As a concrete example, I was using an Emacs media player interface a while back and was frustrated with how it responded to mouse clicks. Were it a different media player (even if it were free software) I likely would have just accepted it and moved on. But Emacs does this sort of end-user programming pretty well (once you’re over the learning curve of using Emacs itself) and I was able to quickly trace why it was behaving the way it did and patch the offending code.
> anybody who can do that is going to get frustrated by guard rails and just want to do ‘real’ programming eventually
I think that's the property which is worth fighting for. If those people would not try programming at all otherwise, providing them with a dumbed down ramp leading to frustration and graduating may actually result in non-programmers turning into programmers in greater numbers.
>There’s never going to be the magic interface that unlocks coding for everyone because most people just don’t think that way and the people that do, don’t need a more intuitive interface.
Strongly disagree. The "magic" interface will be a machine that understands verbal instructions well enough to convert them into logic, figure out which cases are undefined and non-obvious, and then ask clarifying questions. I'm not saying we'll necessarily get there in 10 years, but barring civilizational collapse we should get there in n years. It's both useful and theoretically possible, so we will eventually build it.
Sure when we have general intelligence they can do the coding, but those people won’t be doing coding any more than the guy submitting a feature request in Jira is doing coding.
General AI isn't necessarily necessary for this, though it could be what brings it. And I suppose I never compile anything since I don't do it by hand? Why bark when you have a script?
> a machine that understands verbal instructions well enough to convert them into logic, figure out which cases are undefined and non-obvious, and then ask clarifying questions.
Prolog can do that (once the audio has been converted to text anyway.)
I'm thinking of the interactive debugger described in "Art of Prolog" hooked up to e.g. Siri/Alexa-style VOX interface. The user would need some training, and you would need some glue logic of course, but I bet it would work pretty well.
Modern web apps and containerized web apps aren't user programmable. It's hard to do secure and user programmable in most web apps.
Old school GUI apps are often programmable via some interpreter embedded in the application or via apis that can be called from other programs. Lots of people would use these features to automate little tasks... there's just nothing there for web apps. Easy deployment, no maintenance > user programmable.
I am surprised that they used yahoo pipes as an example for "flow based" programming instead of something a bit more modern such as Node Red (1). My own experience wit trying to design a flow based system for mobile (http://flowgrid.org) was that input seemed just to cumbersome (compared to typing) and not dense enough (compared to text) -- at least on mobile.... Labview / lego would probably be worth looking into, too....
Just yesterday I was thinking that I like the iOS Clock app but hate the time picker, and it’s not very OO of it that I can’t subclass the app and fix it. Also that Maps cleverly picks an appropriate scale but there’s no way for me to use that functionality from my app for my data.
iOS apps aren’t unique in this. Modern software isn’t very flexible.
You'd be able to fix the Clock app if your phone was Jailbroken. There's a system for modifying existing apps called Cydia Substrate, and it's very robust.
For simple modifications, there’s also Flex, which doesn’t require any programming! Flex provides a list of variables and methods, and lets you to override them with whatever value you want. I changed setSwitcherStyle from 1 to 2, and now I have the iPad’s “grid” app switcher on my iPhone.
iOS software isn’t inherently inflexible. Apple is just preventing you from modifying it.
I think there's a big fundamental difference between "programming" (with source code) and "reverse engineering". Cydia Substrate definitely looks like the latter.
I also think there's a big difference between "programming" and "toggle a single bit of configuration". You got a different behavior which didn't require programming because someone else had already gone to all the effort of programming it, and you only needed to find the secret switch to enable it.
If there's any system in common use today which allows subclassing applications to permit users to change arbitrary behavior, or plucking out a single function to re-use in a different context, I'd love to hear about it. We've got open-source, but most of those are really not at all designed for end-user programming.
The closest example I can think of today is Greasemonkey.
Creating Cydia Substrate certainly involved a ton of reverse engineering, but I get the sense creating tweaks on top of Substrate is a lot closer to Greasemonkey. There are also tools like Flipboard Explorer[1] that make it easy to see how an iOS view is constructed and what needs to be modified, very similar to a web browser's inspector.
There's a line in a blog post[2] Saurik (Substrate's creator) wrote a while back:
> In general, I also believe the algorithms for reverse engineering have started getting better faster than the technology behind binary obfuscation. [...] I believe that we will find the distinction between closed source and open source crumbling—not just for people like comex and myself, but for the average developer.
Note that all of this absolutely still requires programming though. And Flex is absolutely not a programming tool, although the wealth of options it opens up is very substantial, since you can modify the return value of just about any method.
---
[1] https://github.com/Flipboard/FLEX (Note: Flipboard Explorer's abbreviated name is "FLEX". It has no relation to the other software I mentioned, "Flex".)
Ugh, for 1,5 months I've been trying to find a way to duplicate flow based programming in c# ( like node-red does). If anyone has some ideas on how to create the "engine", please contact me..
Tried everything I can think of. Currently, not much luck.
Around 20 years ago, I wanted to figure out what the simplest "Unix-pipes-and-filters" equivalent was that I could come up with using OO.
What I came up with (in Objective-C) was a 'filter' that has two things:
1. A single -writeObject: message it responds to that takes a single object argument.
2. a 'target' property that also responds to -writeObject:
That was it.
Is it the same as "flow-based" programming? Certainly not at present, simply because I haven't needed various bits of "full flow". On the other hand, it's been up to every task in that general domain I've thrown at it.
What's nice is that it is first order, has named/reusable components, is super-simple, debuggable and can even integrate actual Unix filters smoothly.
Visually is kinda easy. There are a lot of UI tools for that on Github.
The concept, can't be done in a DSL. Because node-red makes exceptionally well use of the dynamic programming paradigm ( and with the optional payload property).
Just converting it to a Dictionary<string,object> when it enters || exits a node doesn't seem enough. + A huge performance drain
How you think
> dynamic programming paradigm
is implemented?
With something like Dictionary<string,object>. Yep, exist some tricks you can apply, but to make things "dynamic" you will need to use something like that.
C# have the buildings blocks for make something like that, like the Expando object and the whole meta programming.
However, a custom interpreter could be best.
P.D: I'm implementing a custom programming language, and research about it a lot. BTW, the use of hash maps with a decent hash function will not be necessarily the bottleneck...
> Because node-red makes exceptionally well use of the dynamic programming paradigm
Because of flexibility around the payload/context property. I can map anything generic through abstracts and T1,T2,... In c#, but it's not enough
Not sure about anything use related. Or I need to reduce the flexibility that I wanted before and look to the mapped properties only and ignore the rest. Which would be a lot easier
Haskell seems to support the flow-based-approach quite well, 'conceptually'. And I'm not sure that it can be done effectively and intuitively without the first-class-functions, lazy-evaluation, strong typing, etc. that Haskell provides.
I'd recommend to write up what you have tried and what your concrete problems are on stack overflow and to post the link here. There are some quite interesting problems with representation, when to trigger, how to queue up data, how to handle recursion etc.
> In fact, the opposite: today our computing devices are less programmable and less customizable than ever before.
Ohh, I'm not at all sure I agree with that -- but then again, I am pretty sure I have an above-average number of scripts for my Android phone's Automagic app, and before that Llama. I have all sorts of automation and customization set up on my phone and workstation -- but granted, this is far above the trodden path for Joe User.
In my case, my end-users are not programmers, their daily job has nothing or very little to do with computer. They don't need customized environment for them to customize by themselves. They need their program to have enough functionalities for them to get job done.
To the downvoters: Please read my comments below or at least provide the reason you think the comment is invalid. My end-users are different than yours for some reasons.
If their work has very little to do with computers, then they don't really need any functionality to do their job. So this article is kind of irrelevant.
Most people can use spreadsheets, but only a small subset are "programming" in them, the rest are basically using it as a graphical csv editor, at best they'll have a sum calculation.
Before computer era, one of use case is librarians. They just want to store metadata into the computer for them to easier to search. Without any computer, they also get the job done. But with a computer, it's more productive for them in their job.
Search terms for older library systems (don't know what the state of the art is) can get quite advanced, and not far off programming. I've seen little old librarians construct some impressive queries, so don't underestimate 'non programmers'.
But when librarians got their OPAC systems, they started writing reports to analyse lending patterns and identify stock that was not being borrowed, and identifying lenders that had overdue books &c.
So the decrease in effort needed lead to an increase in analysis of the information captured in the system - new uses.
I'm not sure about other regions, but in my region, non-tech users are too lazy to "program" their customized job. The reason is many, but it's just the fact to let you know. "Programming" in any kind is a hard work, and not all end-users like to do it. They're lazy to do brain work.
That’s true of almost all users today. They’re not “computing”. Facebook has a billion users and they’re there to chat and share photos of their food, not compute anything.
From several decades before that, I have an engineering textbook from the early 60s which devotes an entire chapter to the basics of how computers work and writing programs (once again, in Asm) to use them for solving problems.
Thus I'd say "End-User Programming" has been around for a very long time, but it's only recently that the rise of "user-friendliness" and locked-down walled-garden environments contributed to its demise.