This is along the right lines. Whoever cracks end-user programming will be someone who embraces lists, and is willing throw away the vast vast majority of modern programming language-y control structures.
Lists of strings + function calls + function definitions, that gets you pretty far. Anything that tries to reach much beyond that will fail. Function definitions are probably just lists of strings. Deeply nested statements are probably counterproductive.
I think even IF statements are probably not necessary. Comparison operators plus function calls get you conditionals and so much more.
Lisp does way more than that. Far too much to be a plausible EUP design. The work in the Lisp community is mostly about using Lisp to make complicated generic control structures, but none of that is needed for EUP. The thing missing for EUP is a human relevant stdlib and you don't need anything fancy for that. Again literally just lists of strings, function calls, and comparators.
Isn't this just another species of the same fallacy: that programming is just a special case of natural language use -- and to get all the non-programmers in on it, we just need to make a more humany language?
This isn't true. Programming is the expression of your understanding of a problem in a totally novel medium, as with painting or mathematics. I dont think there's "End User Math" for describing the problems of daily life. The ability to express oneself in a target domain totally unlike the original requires a skill set of translation and expression that isn't reducible to "making the tool better".
The thing stopping people building their own houses isn't the hammer. Painting their own landscapes the paint. Formalizing their motion through their house, the symbols of math.
These are the smallest barriers to understanding. The appear significant, to you, who has already acquired (to a great degree) the skill of programming. The painter who is very practiced may well think that the ultimate problem preventing the masses from painting is how "thick the oil gets sometimes". Since that is his preoccupation.
> Isn't this just another species of the same fallacy: that programming is just a special case of natural language use
No, because I'm describing a bounded system with a very simple grammar. Statements like:
say "Will this solve the problem?"
onAnswer "yes", unlockBillableClock
... that's not natural grammar. That's a function call. And strings.
And second, I'm not talking about ALL programming, I'm talking about end-user programming. Below this layer is a lot of code written by profession programmers in lots of languages.
You're not going to write a web browser with only function calls and string literals.
What I would question is the orthodoxy that there is NO place in your codebase where you could refactor to a non-programmer understandable form by forcing yourself to use only calls and lists of strings.
I agree with you that programming is a skill that has to be learned, and that not possessing this skill is a greater barrier than the tooling.
However, I think that a lot of problems currently dealt with by programmers do not actually require programming skill, and could be solved by the end-user if they had a better interface available.
I think something similar has already happened with the standard libraries and package ecosystems of modern languages. You no longer need the skill necessary to write a performant hash table, or XML parser, or HTTP client; if you want to quickly throw something together, you just import what you need and then add glue as necessary.
So in a way, a "human relevant stdlib" could actually provide lots of people with the tools to do things that are currently "programming", but that aren't actually inherently complex. I'm not really sure what should and could be in such a toolbox, but trying to make programming more accessible seems like a good way to find out.
Well it seems like you've just described turning the 70s cohort of C programmers into 2000s cohort of PHP programmers.
It's a programmer group -> programmer group transformation.
Solving problems, as programmers do, is just going to create groups of programmers.
Programmer's can design interfaces, specailized to a problem, that may give the end user some flexibility in that problem.
However I fear that this perspective of yours is the same one which recurs at a certain level of mastery over a particular skill: to now no longer be consciously aware of all the things you need to know, and therefore to assume your highly adapted and sophisticated behaviour is not something that this been trained into you; that is essential and natural to the things you're doing.
The professional plumber may as well be saying, "surely there is some sort of end-user plumbing system for these 'simple' tasks could". It probably seems to him that turning a bolt with the right spanner in the right place is as easy as breathing, but it is not. He just does it now with a similar reflex.
> Programmer's can design interfaces, specailized to a problem, that may give the end user some flexibility in that problem.
Yes, that's what I'm talking about.
For example, moving all photos within a certain date range into a different folder could be done using a quick shell script. Only a programmer could do that, right? But then if you give an ordinary user a file manager where they can switch to a tabular view, click on the Date column to sort the files and then do a range selection, they can suddenly do it, without any programming ability.
There is a spectrum of kinds of tools, from a single button that says "Do it", to a simple form where you fill in some details and then click "Do it", to a toolbox where you can perform various actions in sequence, combining them freely to get to your goal (the file manager example), to a general-purpose programming language.
Along this spectrum, the increasing number of options makes the tool more powerful, but it also becomes more difficult to use, because the user has to make more decisions to arrive at their goal. Making the right decisions requires having a mental model of the effect these decisions have, and in the case of programming languages, this mental model is essentially equivalent to "programming skill".
However, not all problems that currently require a programmer to solve are really so hard, and it might be possible for an expert user with the right toolbox to do it just as well.
> However I fear that this perspective of yours is the same one which recurs at a certain level of mastery over a particular skill: to now no longer be consciously aware of all the things you need to know, and therefore to assume your highly adapted and sophisticated behaviour is not something that this been trained into you;
While I am not usually consciously aware of everything I know, I am aware that it required training to get where I am and that not everyone has this training or will ever have it.
For example, I know that there are people, generally quite adept at using computers, who would be unable to complete the file manager example I gave above; either because they don't know how to do one of the steps, or else because they could not mentally connect them to get from what they have to what they want.
However, I am fairly sure that there are more people who could do that than those who could write a program to achieve the same effect; that is what counts in my book. If you can move a problem from requiring an expert tool maker to only requiring an expert tool user, you should do it.
Regarding your plumber example: there is an "end-user plumbing system" that allows you to get running water and regulate its temperature by turning the right knobs, and everyone can learn to use it, no plumbing experience required.
Sometimes, not always, but sometimes, programming is like that.
Whoever cracks ... programming will be someone who ... is willing throw away the vast vast majority of modern programming language-y control structures.
There are already many examples of end user programming that have taken off, just not many that can create full general purpose programs that run at an acceptable speed.
I'd like to see this self-contained. It looks like if I want to share a mesh with someone, I need them to be familiar with developer build processes (needing npm or yarn, etc; and including having Electron installed? not sure yet, since I haven't been able to try it out and poke at it yet—my case in point, really)
I'd rather be able to send anyone my-data.mesh.html, they double click it, it opens in their browser, they can modify it at will, and there's a button that's functionally equivalent to a Save button to let them overwrite the orginal file. (Like a quine on steroids. Think TiddlyWiki.) This can be done, the only problem is that you don't get the typical Ctrl+S workflow—you use the in-page button instead, and it wouldn't let you get around the "Save As" dialog, but I'm thinking it should be only a minor nuisance.
If you do it right, you could even standardize your serialization so that other tools could ingest a meshfile.
This is really neat, and I'm going to play with it tomorrow.
Right now you could share a Mesh file as code, but yes, you'd need to have a way of consuming that code. Right now there's no way of communicating the UI interface; I had envisaged that people would download Mesh separately from the internet.
Embedding Mesh and its dependencies in the file itself is really clever. The file would get a bit bloated but maybe that's OK if:
(a) when the file is consumed by other code, the interface exposed is clear
(b) when the file is opened as a Mesh program, all the user can see is the program shown in the spreadsheet, not Mesh's code.
It is potentially more risky from a security perspective if it is not easy to verify the Mesh source embedded in the file hasn't been changed to be malicious.
It looks nice and all... but what can I do with it? Citing Paul Graham[0] You Need an Application to Drive the Design of a Language.
What is the use case here? The readme describes vaguely that it's more suited to arbitrary length data processing and generation... but I can't come up with a practical example for which this IDE is applicable. I wish the developer would showcase SOMETHING besides the base interactions. Anyone have any ideas?
Clicking through on the link that says "more discussion here" [1] the OP does at least explain the original problem with Excel that he was trying to address:
>Mesh was started because I couldn't find a way in Excel to output the results of a formula across an arbitrary number of cells. ...
This is definitely on the right lines.
But it's a very difficult problem, both from a UI design point of view and actually producing a performant implementation in Javascript.
I'm in the same thought as you about this. IDE's are designed for one common purpose: Efficiency. In fact, everything that has to do with software engineering drives towards efficiency. This appears more like a pet project than a product with a vision of solving a specific problem.
Things I could use that for that I can think of right now:
- fast prototyping of regexes
- very good prototyping and feedback tool for record processing
- computational graphics (plots, barcodes)
- state machines
And I bet many more.
Very straightforward tool, and nicely done.
This is neat. I've made some small prototypes in the same kind of space, trying to come up with a new way of doing spreadsheet-based programming.
My one nitpick is that I want to be able to just try it in my browser right now. Oh also you really need a target project with something like this. In other words, you need problem you are trying to solve, so that you can know once you've solved it.
See my other comment[1] in this thread, and the one by sheeshkebab[2].
There are no shortage of instances where Excel plays a depressingly crucial role in critical LOB operations (including shops that you'd expect to know better). Essentially what happens is places like big manufacturing corps pour all their engineering budget into staffing themselves with folks who have domain-specific knowledge, but no idea how to build something resembling sane IT infrastructure, let alone focus on rolling out anything that could scale. So they all fall back to what they know from school, which are terrible (terrible!) hand-crafted spreadsheets that get passed around through email or thrown on a network store that everyone gets write access to. As in: this is literally how things run at the fab that produced the chips in your phone or the silicon in your big name desktop GPU.
Occasionally, someone comes along who knows how to do pivot tables or use VBA to create basic macros and is revered as a wizard. Even in the best cases they end up being unmaintainable messes.
Heck, a quick and dirty TiddlyWiki-like tool that just lets average people make basic tables would go far in dislodging Excel from places where it's burrowed down and is screaming "wrong tool for the job"[3].
I use and love Calca which is a maths oriented text editor that does live display of equation results as you type. I really wish that more programming were like this: real-time feeling, high feedback. It's a great model for exploratory stuff and I often use it in place of spreadsheets
This is a cool project, I'm excited to see where it goes
I'm not sure if the parent did, but I followed what you were looking for and the answer is still "try clojure", perhaps more specifically it is "Try the Clojure libraries figwheel and devcards to do web stuff" but the push for immediate feedback and "interactive programming" is central for everyone. It's a community that took Bret Victor's Inventing on Principle talk to heart, already agreeing due to the REPL centric workflows that most people used.
Bruce Hauman has some good talks about his tools, which are GUI application-centric and a joy to use [1][2][3]
If you aren't doing web or native mobile GUI stuff then the default tools have immediate unit test/linting/spec compliance feedback triggered every time you save a file.
Unless you mean you want a very simplified language, in which case you should look elsewhere. Clojure has definitely chosen the high power side of that trade-off, but this also allows some truly first class tools to be developed.
Well, programs are data and logic - so this is definitely a way to write and visualise data more easily, and potentially also a way to visualise logic tables more easily (such as cases of 'switch' statements, although that display logic hasn't been implemented yet).
If you get a chance to try it, please let me know if you have any feedback!
something that converts an excel spreadsheet to code might be pretty useful - since most businesses run on crappy excel spreadsheets, having something that occasionally converts one to code could go a long way in "scaling" business.
Lists of strings + function calls + function definitions, that gets you pretty far. Anything that tries to reach much beyond that will fail. Function definitions are probably just lists of strings. Deeply nested statements are probably counterproductive.
I think even IF statements are probably not necessary. Comparison operators plus function calls get you conditionals and so much more.