IMHO author is missing the historical perspective of DSL approach. In the time when SQL was developed, users simply needed a much higher level of tech skills than today. One older colleague told me once how he wrote his PhD thesis using ed (unix line-editor), and it was more than 100 pages work. To us that seems crazy complicated and unfriendly, editing 100s of pages line by line using obscure single letter commands, but to them it was a huge improvement compared to typing it on a typewriter - and they all learned how to use it. Similarly, analyst in the days when SQL was invented had very different expectations and ideas about what "simple to use" means. Back then you expected that you need to type your commands as text, so developing specialized tools in form of DSLs was a perfectly logical step. Today DSLs make less sense as we can build spreadsheets, wizards, visual drag&drop UIs, AIs for speech commands and so on. Users' expectations and skills are completely different now, and it's less likely that they'll invest time into learning a new language, they want buttons to click. That's why DSLs are now more a middle step that simplifies life for programmers when dealing with specialized tasks - for those areas where visual tools are too limiting, but still you need a way to abstract the complexity - just the way the SQL does it.
Problems with DSLs for non-programmers
61–70 of 144 posts
Re: Problems with DSLs for non-programmers
#62I think it's better to call the users of such high-level DSLs, accidental programmers . It's not like they are not programmers, its just that they don't see software development as their vocation or profession. Yes, it's important to have languages that target them (e.g. Excel, Latex, SQL). Design of such DSLs is important and hard work. We need more professional activity making DSLs usable, consistent, and extensibl…
[deleted]
Re: Problems with DSLs for non-programmers
#63IMHO author is missing the historical perspective of DSL approach. In the time when SQL was developed, users simply needed a much higher level of tech skills than today. One older colleague told me once how he wrote his PhD thesis using ed (unix line-editor), and it was more than 100 pages work. To us that seems crazy complicated and unfriendly, editing 100s of pages line by line using obscure single letter commands,…
I think one can argue that a "visual drag&drop UI" to build a e.g. a complex query can also be a form of DSL.
Re: Problems with DSLs for non-programmers
#64The argument here boils down to: I haven't seen it work in places where I've been employed so it must not work. Reality check: I've worked on multiple large research teams that successfully developed DSLs still in use by domain experts -- military sigint in one case, doctors in another case, industrial engineers in another. We developed these languages for specific applications where the domain experts needed to prog…
I would actually go as far as saying Basic good enough SQL is easy to teach to people. You can make it easier by creating views for them.
Re: Problems with DSLs for non-programmers
#65To add another counterexample into the mix, I’ve met many artists and designers who are proficient with Unreal Engine’s Blueprint with no C++ experience. Some have even shipped games made entirely in blueprint with no traditional code.
I think you can add stuff like Twine and Inkle's scripting language Ink to that. Their user base is emphatically not programmers, but they are definitely domain specific languages.
Re: Problems with DSLs for non-programmers
#66I've met many non-programmers who are quite comfortable with SQL. There are many smallish scripting languages that should qualify as DSLs that allow lay access to domains that mystify normal people. Excel comes to mind. Mathematica used to be one of these before it became a real general-purpose programming language, if a somewhat limited one. The author appears to be projecting their personal convictions onto everyon…
Autohotkey is another one of those scripting languages. ::F4:: Send {Alt down}{F4}{Alt up} is so much simpler than whatever I would have to do with Java to remap keys. Same with stuff like WinActivate (window title) and MsgBox "hello world". It does get complicated like the OP says pretty quickly, with match modes and conditionals and stuff, but you can go years using it without getting any deeper.
Re: Problems with DSLs for non-programmers
#67The argument here boils down to: I haven't seen it work in places where I've been employed so it must not work. Reality check: I've worked on multiple large research teams that successfully developed DSLs still in use by domain experts -- military sigint in one case, doctors in another case, industrial engineers in another. We developed these languages for specific applications where the domain experts needed to prog…
What is the criteria you use to determine they’re successful?
If you have an interactive debugger and a way to test the code, I could see it being feasible. If not, then there’s plenty of examples of DSLs that are in use that people are forced to use and squander time and brain power due to a lack of concepts that real languages have long since addressed.
Since others have mentioned Excel, how many mistakes have been made in long complicated formulas in little tiny input boxes with no way to comment or even explain what on earth the formula calculations are doing? Yet that’s still not addressed, and it’s a nightmare when you come across complicated spreadsheets for this reason.
Re: Problems with DSLs for non-programmers
#68Earlier quoted context omitted.
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 came to say that exact thing. Good DSLs are almost unnoticed, because they are frictionless.
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"
Re: Problems with DSLs for non-programmers
#69Can I point to a counterexample? The printing dialog which asks for a page range at the UI on windows/Linux/Mac:
12,15,30-40
Re: Problems with DSLs for non-programmers
#70Many DSL can be replaced by python modules: it is far easier to develop and document a well written python module than a good DSL Defining a syntax, documenting it, doing parsing, syntax checking, generating good error reporting on a DSL is far harder than just designing a python API. Of course it is a programming language, but Python can absolutely be used by non-programmers. Not as cleanly as a good programmer will…
This is actually a great idea. You get all the readability and ease of access of a DSL with a strong language backend.
In fact, some gui-heavy software have a python interface to write some automations or plug-ins to extend functionality beyond the GUI, mainly targeted at advanced users.