Anyone who uses a DSL is a programmer. Another way to say that "DSLs for non-programmers are a hoax" is: Good DSLs make programming easy enough that people who aren't otherwise programmers can successfully program.
Problems with DSLs for non-programmers
71–80 of 144 posts
Re: Problems with DSLs for non-programmers
#72Reminds me of a speech rms gave about programmable editors. Money quote:
" Multics Emacs proved to be a great success — programming new editing commands was so convenient that even the secretaries in his office started learning how to use it. They used a manual someone had written which showed how to extend Emacs, but didn't say it was a programming. So the secretaries, who believed they couldn't do programming, weren't scared off. They read the manual, discovered they could do useful things and they learned to program."
Re: Problems with DSLs for non-programmers
#73The 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…
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.
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.
Re: Problems with DSLs for non-programmers
#74> 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. SQL is used widely, but it does not work that well for people who are not programmers. HTML and XML were also originally intended for non-programmers - where are they now? They are used by amateurs or enthusiasts sometimes, but most of the time programmers do the job. At both is my last two jobs (Sa…
My experience has been there are definitely people who become very proficient with sql while not knowing any other programming but they generally hit a ceiling. For most people they can do joins and some basic nesting but they start getting out of their elements if you mention window functions, ctes etc
Re: Problems with DSLs for non-programmers
#75Reminds me of a speech rms gave about programmable editors. Money quote: " Multics Emacs proved to be a great success — programming new editing commands was so convenient that even the secretaries in his office started learning how to use it. They used a manual someone had written which showed how to extend Emacs, but didn't say it was a programming. So the secretaries, who believed they couldn't do programming, were…
Related:
Steve Yegge discussed use of Emacs for a customer-email processing application at Amazon:
https://sites.google.com/site/steveyegge2/tour-de-babel (2004)
""" Shel wrote Mailman in C, and Customer Service wrapped it in Lisp. Emacs-Lisp. You don't know what Mailman is. Not unless you're a longtime Amazon employee, probably non-technical, and you've had to [directly talk to customers]. [....]
Mailman was the Customer Service customer-email processing application for ... four, five years? A long time, anyway. It was written in Emacs. Everyone loved it.
People still love it. To this very day, I still have to listen to long stories from our non-technical folks about how much they miss Mailman. I'm not shitting you. Last Christmas I was at an Amazon party, some party I have no idea how I got invited to, filled with business people, all of them much prettier and more charming than me and the folks I work with here in the Furnace, the Boiler Room of Amazon. Four young women found out I was in Customer Service, cornered me, and talked for fifteen minutes about how much they missed Mailman and Emacs, and how Arizona (the JSP replacement we'd spent years developing) still just wasn't doing it for them.
It was truly surreal. I think they may have spiked the eggnog.
Shel's a genius. Emacs is a genius. Even non-technical people love Emacs. I'm typing in Emacs right now. I'd never voluntarily type anywhere else. It's more than just a productivity boost from having great typing shortcuts and text-editing features found nowhere else on the planet. I type 130 to 140 WPM, error-free, in Emacs, when I'm doing free-form text. I've timed it, with a typing-test Emacs application I wrote. """
Re: Problems with DSLs for non-programmers
#76Earlier quoted context omitted.
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
The issue that I've seen with Excel is that it's often seen as the hammer -everything is a nail- for people that are less inclined with technology / set in their way. They will use it both as intended, a spreadsheet for calculations, usually for reports. But also as publishing software (think InDesign) and format their spreadsheet to look like an invoice / quote, a hand made Gantt chart (yeah with arrows as delimiter…
A lot of it is a matter of perspective.
"As intended" is a suggestion, not reality. Physical reality doesn't have XML tags attached to things, saying "this is a hammer, you shall use it to drive small nails, and small nails only". The same thing applies to software. There are tools more and less convenient for a task, but ultimately it's the task that matters.
Consider invoices: before computers, they were done on the ultimate universal medium - paper. Even today, they exist as documents primarily meant to be read by humans. They have some required information and vague shape they're supposed to resemble, but that's it. It's much faster to make one with Excel than with InDesign, doubly so if you already know Excel. The part that Excel doesn't support - invoice life-cycle management - can be done elsewhere (file system is damn good at it), and often isn't even a part of the task - that aspect is handled by the accountants you CC when sending out an invoice.
Excel is really a kind of smart virtual paper with affinity for grids. People use it for a lot of weird things because it usually works damn well for those.
Re: Problems with DSLs for non-programmers
#77Earlier 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.
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.
There's one key I've seen to DSLs that really work: scope your DSL with iron.
You should be able to clearly say 'This DSL can do X. It cannot do Y.'
(Then, if Y sometimes needs to get done, provide an escape hatch integration point to C et al.: but don't ever expand your DSL beyond the domain!)
Re: Problems with DSLs for non-programmers
#78Reminds me of a speech rms gave about programmable editors. Money quote: " Multics Emacs proved to be a great success — programming new editing commands was so convenient that even the secretaries in his office started learning how to use it. They used a manual someone had written which showed how to extend Emacs, but didn't say it was a programming. So the secretaries, who believed they couldn't do programming, were…
I made a post elsewhere earlier today to demo Multics Emacs, and just so happened to link to the very manual that rms refers to in that quote - the "Multics Emacs Extension Writer's Guide".
https://lobste.rs/s/uwvpl1/110_days_early_multics_emacs_hist...
Re: Problems with DSLs for non-programmers
#79The 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…
There are important differences here. One is the level of engineering effort, but another is the nature of the user of the DSL. Doctors, engineers, and SIGINT specialists are all types of people who are accustomed to doing some type of specialized technical work themselves rather than depending upon others to do it for them.
Re: Problems with DSLs for non-programmers
#80Earlier 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.
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 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).