What’s the relationship between domain-specific programing (i.e DSLs) and end-user programming?

End users care more about their domain than about programming. A DSL is a step towards the point of view of a domain expert.

Thanks for sharing @Konrad Hinsen, I’m trying to tease out the differences between the two! Some follow up questions: Is end user programming inherently domain specific? What is the boundary between a domain expert vs. an end user?

First, a warning: I really dislike the term "end user". End of what? That said, I see the space of what is often called "end user programming" as really two spaces: "domain expert programming", and "daily life progrmaming". The latter is to-dos, shopping lists, smart home automation, writing letters, etc. The realm of HyperCard. These two categories almost coincide with desktop vs. smartphone use today.

FYI Observations: • Programming = providing details to a solution in a way that even a machine can perform the steps • End-user programming = UX • Rhetorical questions: Are Spreadsheets DSLs? Are Spreadsheets UXs? What about Hypercard? • DSL == programmers’ solution to the “languages are hard to build” problem • if languages were easy to build, we wouldn’t need to bother with DSLs • we could just build micro-languages for each problem • [recursive descent parsing in the past ; now, PEG, Ohm-JS] • when doing consulting, I would always assume that my clients knew their domain better than I did • my job was to provide them with ways to automate their knowledge and give them a 10x boost in productivity • I would try to “invent” a language that mimicked the way that the clients thought about their domain, yet I tried to make every part of that “language” compilable • instructions in the form of “text” is only one kind of programming language (very 1950s) • many non-programmers use whiteboards and dry-erase markers instead of programming languages • programmers think in details and want to use all 10 fingers, users want to skip over details (“elision”) and use swipes and voice and game controllers and “easy-to-use” HCI devices • notations (aka “programming languages”) for programmers are vastly different from notations for users • example: FEDEX bar-code-reader hand-held-device marries high tech (bar codes and lasers) in an HCI that makes it easy-to-use in the field ; how was this programmed into being? Did someone have a vision then hire a bank of engineers (software and hardware architects and engineers and implementors), or, was there an easy-to-use intermediate micro-language that let the envisioner implement / mock-up the MVP without engineers? Could we have designed this more easily today?