Anyone who thinks DSLs for the general public can't work has never used Excel. The real trick is creating a domain model that "clicks" in the heads of your users.
I wouldn't go as far as that, but yeah. Adding up a column is not the same as actually coding in Excel or even using a few math functions in a cell. And considering how many people take classes just to handle the basis spreadsheet functions, much less anything complicated, the naive accessibility of Excel can be overstated.
I've never tried to make a DSL for non-technical people because every single time I've seen a client get an expensive product aimed at their industry and designed to "not need a programmer" to customize, they end up paying to have me or a coworker to not-program customizations for them in an excruciating interface.
On the other hand, I think a lot of this side stems from insistent terminology in treating programmers like some tiny priesthood separate from the general public. That woman who can actually put together fairly complicated SQL queries? She has learned to program in SQL. That guy who put together a ramshackle VBA atrocity that gets the job done? He has learned to program in VBA.
All the mess comes from not accepting that. No DSL or templating interface or whatever will let people do programming without learning how to program to some little extent. Acceptance fails when the "public" doesn't want to give/can't spare the time and effort to do so. On the flip side, when it doesn't fail because the "public" does work to learn to program in some case, developers take that to mean that this can work in any case, so long as the public is approached properly with the right DSL/graphical environment/etc.
> designed to "not need a programmer" to customize
> they end up paying to have me or a coworker to not-program customizations
These things aren't contradictory, though. The software doesn't need a programmer to customize. They likely tested that, and proved that regular people can set it up just fine. Regular people just aren't normally motivated to do so, when it's so easy to just spend money in order to not have to learn something new.
IMHO there's a clear division that forms between people very early in life, and it can be predicted which side of the line someone falls on as early as the third grade: there are humans for whom solving puzzles that involve "wrapping their brains around" a new mental skill is a fun diversion; and there are humans for whom that same experience is aversive and something they will flinch away from. And—importantly—this has nothing to do with how good they are at doing it!
We can endlessly invent new ways to make hard things easy, but no matter how easy we make them, as long as they're at all novel or unfamiliar, the people for whom absorbing new mental models is an aversive experience will just do everything they can to avoid it. It's like people with social anxiety doing way more work of some other type to avoid socializing, but with "forming new mental connections" in place of socializing.
But the fact that a large part of the population is like this, doesn't mean that there's no value in these customizable systems. They still increase accessibility, bringing tasks that were impossible for a non-programmer into the realm of possibility! It's just that for most people, the line isn't between "possible" and "impossible"; it's between "trivial" and "not worth the trouble." The question only becomes one of possibility when you're forced into a corner of solving the problem yourself, no matter what, unable to even quit and walk away. When people are in that situation, they're thankful for these systems. But only then.
Good DSL are hard and expensive to design and maintain. Look at the good example of DSL in comments here. They are not small project with small workforce.
If not very limited, a DSL is an ambitious project (if very limited a GUI will surely do a better Job).
Developers should think twice before writing a DSL for "non-programmers"
Nonsense. Making a good DSL is easy. I’ve built production DSLs that users adore.
What’s hard is finding developers who know the domain and its users in the first place. You can’t solve a problem if you don’t understand the problem space. And most devs don’t understand shit except how to turn it off and on again, nor are they willing to learn. So if your average professional university-educated programmer can’t even get a simple turnkey CRUD app right, what chance of them delivering a tool that successfully hands those keys to its users?
..
Go read the “Collaborative Work Practices” chapter of “A Small Matter of Programming: Perspectives on End User Computing” by Bonnie A Nardie that describes how basic users, expert users, and trained developers can develop their own software tools together, where each layer supports and educates the layers above and below it.
And then count the number of programmers you know who’d embrace working like that. Sadly I doubt you’ll run out of fingers.
The counterpoint would be Visual Basic. It was meant for non-engineers/managers to be able to write programs, but that never really happened. It was always easier for a manager to write an email 'I need an app that does X' than to write the app themselves.
I think later-legacy-VB (eg 6) suffers harshly from failing to properly separate primatives.
Imho (open to disagreement), one should think incredibly hard before adding primatives to a DSL. Because what that's essentially saying is "My abstraction was incomplete over the target domain, and now I'm going to hack something in." And now you have a "domain + some other stuff" language, which starts to look like a general purpose language.
SQL vs VB is an excellent example of focus.
(Although I do think VB.net added sanity back to the mix, by saying more clearly "These are VB things" and "These are .net things", and if you want to do the latter in the former, just make a library call)
I saw VB6 used by many non-programmers. It often wasn't pretty, but got the job done (helped in no small part by a rich ecosystem of COM/ActiveX components).
There are many more success non-popular stories around DSLs. Last year, in the Community event of JetBrains MPS, a bunch of big companies (Siemens, Bosch, Workday, etc.) showcased their DSLs built with MPS technology. Here are the videos: https://www.youtube.com/watch?v=102hoaAdctk&list=PLQ176FUIyI...
That may be true in some sectors but not all. In capital markets (banks, investment funds etc) a lot of coding (via DSL or not) is done by folks who are not developers/programmers or self-declared coders. They just get it done and don’t bother calling on IT which is often counter-productive. Wether its SQL, VBA, R, Python or some some horribly-convoluted Excel worksheets, there is plenty of technical work getting done by non-developers.
Visual Basic definitely opened up programming for a lot of people that otherwise never wouldn't have written software. You will never be able to create something everyone can use (unless it can do mind reading and even then I am not sure) but tools like VB, Access and Excel have enabled a lot of people tow write software.
COBOL is specialized for business applications by supporting records (i.e. punch cards) and decimal numbers (as opposed to the binary floating point of FORTRAN).
Visual Basic is specialized for using COM (with a high-level interface to its features), I suppose - otherwise it's definitely general-purpose.
> Anyone who thinks DSLs for the general public can't work has never used Excel.
I would say Excel is exactly the opposite of a positive example. Unless you mean being used as a sort of electronic scratchpad, which works okay.
But apart from that there's too much freedom in Excel to be used to make anything properly. Every time I've ever seen a non programmer use it, they make a pile of spaghetti. You never have any assurance that you're actually calculating what you want.
Even highly qualified domain experts (eg in derivatives trading) will end up building utter nonsense in Excel, and then use it to trade millions of dollars worth of exotics. Whenever they need something fixed, it takes an enormous effort to trace through all the cells to make sure things are correct.
Excel is a great example of a domain-user tool that's very hard to use correctly, and even harder to know when you're using it incorrectly; that's not "snobbism".
Totally agree. Whole companies run on Excel spreadsheets maintained by non programmers. Maybe they are not up the quality of good software engineers but they are good enough. When I was contractor I saw in one company the IT department taking over all Excel spreadsheets and creating "proper" software. It was a total disaster. Instead of same day turnaround users had to wait requirements and then wait for months often. Costs went up, productivity down. Good software engineering practices have their place but if something works we should leave it alone.
I don't think it is snobbishness. Some programming systems definitely encourage hacky spaghetti more than others (if you don't believe me try using LabVIEW) and Excel is definitely in that category.
There are ways that they could make it less so, like only allowing cell references by name, using a saner scripting language than VBA, allowing multiple cell grids on a single page/sheet, etc.
"Millions of successful businesses are built on Excel" is no argument at all. You can build a successful business with pen and paper.
I'd love to hear your take on the rise of "notebook" environments. :)
Directly stated, I don't feel any dissonance agreeing with both of your posts. I do think it is snobbish behavior. I also believe some environments make for worse results on some problems. There is usually room for both.
