Live data from Hacker News

Problems with DSLs for non-programmers

artur-martsinkovskyi.github.io

131–140 of 144 posts

Re: Problems with DSLs for non-programmers

#131

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

I agree with you completely.

I mean, they want you to write "expect(some_thing).to be_true" and even more ornate stuff.

I mean, why not "expect(some_thing)" or "expect(some_thing==true)"?

Rspec, Cucumber, etc. do have matchers that are helpful and more concise than idiomatic Plain Old Ruby but some of them are so basic and yet so ornate that they really seem like some kind of a joke.

Re: Problems with DSLs for non-programmers

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

Are those successful DSLs just texts with editor UI? Or they are something like block diagram?

Re: Problems with DSLs for non-programmers

#133
post #73
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 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.

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.

Re: Problems with DSLs for non-programmers

#134

Earlier quoted context omitted.

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

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

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.

Re: Problems with DSLs for non-programmers

#135
post #73
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 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.

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.

Re: Problems with DSLs for non-programmers

#136
post #81
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…

> Which is exactly where their power comes from. Because each time you shrink the required knowledge to do work, you broaden the pool of people who can perform that work.

That's an excellent point.

It seems the same concept could also apply to broadening the scope of complexity that an individual could handle. The fewer things that the user needs to have in mind, the more mental space is freed up for other things, like domain complexity.

Re: Problems with DSLs for non-programmers

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

> experts needed to program extremely complex systems to perform tasks in much shorter timeframes than would be possible if programmers needed to get involved I always think of DSLs as automating my own job as a software engineer. It makes it possible to have someone with a different skillset than me not need to go through me to build features.

> I always think of DSLs as automating my own job as a software engineer. It makes it possible to have someone with a different skillset than me not need to go through me to build features.

It's interesting that this sort of drives against our own motivation of professional self preservation.

In my own experience, it has generally worked out better to just empower others as much as possible, rather than trying to lock down and add friction and permission to the system.

It's a great feeling to give someone the power to do something they couldn't do previously.

Re: Problems with DSLs for non-programmers

#138

Earlier quoted context omitted.

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…

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

Re: Problems with DSLs for non-programmers

#139
post #83

Earlier quoted context omitted.

Everyone has to admit there's a lot of programming minutiae that could and should be thrown overboard. If you show your language / app / webpage to someone and they ask "Why is X preventing me from doing work?", it would behoove all of us to honestly ask ourselves "Is X important enough that we should keep it?" Otherwise, we end up with 10,000 gotchas and only someone who studies for 2 years can use things. And I'd p…

Which is a different way of saying that most computer UI still sucks for most users. I agree, and I think that one of the key reasons programmer-y people are successful at navigating computer tasks that stymie the proverbial grandma is this: faced with a question about how to accomplish a task inside some UI, we're just inherently more likely to follow a similar train of thought as the person who wrote the program in…

Agreed - great insight. And this effect is exacerbated when there is genuine malicious intent on the internet. I've sat with my mum or dad on several occasions, when they've been confused by 'ads' on websites which are designed to look like dialog boxes.

It was far too difficult for me to explain how to tell that this was not a legitimate dialog box. Or understand the concept of phishing.

Re: Problems with DSLs for non-programmers

#140
post #73

Earlier quoted context omitted.

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.

Notice that the GP didn't include managers at the groups he created DSLs for. And Visual Basic (or COBOL if you want to go back) are meant for what group exactly? It does not look specialized into any domain.

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.

Post reply on HN