Problems with DSLs for non-programmers
artur-martsinkovskyi.github.io
Problems with DSLs for non-programmers
1–10 of 144 posts
Re: Problems with DSLs for non-programmers
#2Writing the code is very often not the difficult part. Often the difficult is taking the requirements and truly understanding them.
Re: Problems with DSLs for non-programmers
#3> The last time I had a business analyst that wanted to write SQL, he tripped over one join and asked me to do the job.
Anecdotal counterpoint: I've met many an analyst who had some mean SQL skills.
Re: Problems with DSLs for non-programmers
#4> The last time I had a business analyst that wanted to write SQL, he tripped over one join and asked me to do the job. Anecdotal counterpoint: I've met many an analyst who had some mean SQL skills.
Some people are lazy. Some people are busy, stressed etc. There are many reasons that an analyst might not want to write SQL on a given day.
Re: Problems with DSLs for non-programmers
#5For most of the article the author seems to be discussing non-professional programmers rather than non-programmers. Or perhaps using the two interchangeably?
There is certainly a need for non-professional programmers to be able to program (e.g. in the sciences). For non-programmers, programming a task via GUIs have been effective, although admittedly in the worst case they can devolve into a mess of check boxes, drop downs and spinners.
EDIT: Of course in a business you'd hire professionals for a job (or outsource it). That's just good sense for anything your business relies on.
Re: Problems with DSLs for non-programmers
#6[deleted]
Re: Problems with DSLs for non-programmers
#7Counter example: spreadsheets.
Re: Problems with DSLs for non-programmers
#8The 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 program extremely complex systems to perform tasks in much shorter timeframes than would be possible if programmers needed to get involved.
Why did these DSLs succeed? Funding, manpower, and experienced project managers who delivered constant access to domain experts.
Delivering a successful DSL targeted at narrow domains with non-programmer users is much more resource-intensive than normal software--it's more on the complexity level of a compiler or small OS--but that doesn't mean it can't or shouldn't be done. Plenty of systems couldn't be automated otherwise.
Re: Problems with DSLs for non-programmers
#9> The last time I had a business analyst that wanted to write SQL, he tripped over one join and asked me to do the job. Anecdotal counterpoint: I've met many an analyst who had some mean SQL skills.
Our previous PM was better at SQL than most developers on my team at the time (myself included, which was a big motivation in taking the time to properly learn more advanced SQL last year).
Re: Problems with DSLs for non-programmers
#10Counter example: spreadsheets.
Yep. But they're overused and underused each day... Everything can be a spreadsheet and nobody questions if there are better ways of holding that particular data