Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Problems with DSLs for non-programmers

artur-martsinkovskyi.github.io

Post reply on HN
Print view View original

121–130 of 144 posts

Re: Problems with DSLs for non-programmers

#121

Post by davps »

ethbro wrote: post #81
twa927 wrote: post #23

Earlier quoted context omitted.

Are such successful DSLs described somewhere? Generally my feeling is somehow similar to the one expressed in the blog post, ie. that DSLs don't work for non-technical people. If someone is able to use a DSL then he/she is also able to do regular programming, and many people don't have such abilities. And regular programming languages are better tools for the ones with the abilities.

> If someone is able to use a DSL then he/she is also able to do regular programming, and many people don't have such abilities. I'd disagree with this characterization. Because a good DSL abstracts away things that are not relevant to the domain (e.g. in Excel, memory pointers and allocation) while retaining those that are (which data transformation you want to apply). It doesn't follow that someone who understands…

> Because a good DSL abstracts away things that are not relevant to the domain (e.g. in Excel, memory pointers and allocation) while retaining those that are (which data transformation you want to apply).

I agree, I wrote this small example on using DSL for E2E testing, where you abstract away a lot of asynchronous calls, headless browser specifics and other low level concepts to expose a simple API so domain experts can help you to write tests https://github.com/davps/tic-tac-toe/blob/master/src/App.tes...

Re: Problems with DSLs for non-programmers

#122

Post by ivanhoe »

detaro wrote: post #63
ivanhoe wrote: post #61

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,…

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.

Exactly, fully agree. It's a DSL of this era.

Re: Problems with DSLs for non-programmers

#123

Post by shoo »

tyleo wrote: post #14

To 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.

> Unreal Engine’s Blueprint

Previously: https://blueprintsfromhell.tumblr.com/

"Confessions of a unreal engine 4 engineering firefighter": https://news.ycombinator.com/item?id=16775166

Re: Problems with DSLs for non-programmers

#124

Post by taeric »

The problem with programming for non-programmers is so many programmers have told non-programmers that they can't program. Programming is far easier in the small than we'd care to acknowledge. Don't cripple what you let your users do, enable them.

Re: Problems with DSLs for non-programmers

#125

Post by taeric »

IshKebab wrote: post #115
coldtea wrote: post #113

Earlier quoted context omitted.

> 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. That's just developer snobbism. Millions non-devs use Excel with excellent results, even whole business of billions depend on it. (Excel has some flaws, and can give wrong results in some cases, but that's like "gotchas" in any language).

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 busi…

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.

Re: Problems with DSLs for non-programmers

#126

Post by taeric »

scroot wrote: post #112
zwkrt wrote: post #12

Earlier 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.

Or Hypercard, which was popular among non-programmers in its day

There is a great article that explained how an entire office was comfortable with LISP because it wasn't pushed as programming. First hit searching shows it linked off of: https://www.reddit.com/r/emacs/comments/3tj71x/even_office_s...

Re: Problems with DSLs for non-programmers

#127

Post by taeric »

np_tedious wrote: post #21

> 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…

Last time I tried to get my coworkers to use sql for a report, they straight face argued that doing all of the logic in code is clearer. So, I suspect it is selection bias, as well. Amazing how hard that is to look past.

Re: Problems with DSLs for non-programmers

#128

Post by Semiapies »

njharman wrote: post #98
zwkrt wrote: post #12

Earlier 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 technical public. Huge percentage of the general public can't effectively use excel, let alone write code for it. To be clear by technical public I mean much more than just developers. Like everyone that could get a basic stem degree whether they have one or not.

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.

Re: Problems with DSLs for non-programmers

#129

Post by gpsx »

ghc wrote: post #8

The 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…

Matlab - That was designed for engineers who are not experts in software, even if they were highly technical.

Re: Problems with DSLs for non-programmers

#130

Post by thrower123 »

JohnBooty wrote: post #86

P.S. I hate Gherkin, Cucumber and other DSLs that let you write the tests that “read like English” I'm with you there, friend! But then the author mentions Rspec as a good DSL, so I don't know what their ideal of a good DSL is because Rspec's about as English-like as it gets.

Any time I've encountered Cucumber-esque testing DSLs, the amount of work that was required to plumb things up to the actual test code made me want to throw up my hands and just write xUnit tests or whatever and cut that extra work out. It's very possible that I haven't worked with anybody that really understood how this is supposed to work, and with the ten thousand other things I am responsible for, I haven't had the time or inclination to take a real deep dive into it.
Post reply on HN