Live data from Hacker News

Problems with DSLs for non-programmers

artur-martsinkovskyi.github.io

91–100 of 144 posts

Re: Problems with DSLs for non-programmers

#91

It would have helped if the author would have given their definition of a DSL at the start. Embedded in a later paragraph a DSL is defined as having a syntax where "code that must look similar to proper English of the domain." I tripped over that because, as a schemer, it's easy to discover there's really no fundamental difference between a "DSL" and "a program", in any programming language.

Completely agree; this is a difference of degree, not kind. Quoting myself[0]:

> As soon as you have something as apparently simple as named procedures, you're really writing a DSL, albeit very coarsely, for your business problem.

[0]:https://news.ycombinator.com/item?id=18770192

Re: Problems with DSLs for non-programmers

#92
Who changes the titles of HN posts?

I'm just curious... the blog post has the title "DSLs for non-programmers are a hoax" and this HN post originally had the same title. At some point it got changed; I've seen this happen before. Is this HN editorial intervention, or did the OP make the change?

Just curious...

Re: Problems with DSLs for non-programmers

#93
post #72

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

It's funny how some Smug Emacs Lisp-guy are confronted with why the Emacs with extension mail client was deprecated. It must have been some life changing experience chatting with non Smug Emacs Lisp-guys people actually wanting to use Emacs.

I can quite understand why you would want Emacs for Customer support emailing, with the ability to semi-automate tasks and extend extensions. If it's your full time job to write quite similar emails, it's probably worth the effort.

Re: Problems with DSLs for non-programmers

#94
Is a thing where DSLs are expected to be for non-programmers? I mean language is right there in the name. They are programming languages and you have to have programming skills to use them.

Unless by non-programmer you mean non-developer. People for which programming is secondary or tangential activity. Like scientists.

Re: Problems with DSLs for non-programmers

#95
post #92

Who changes the titles of HN posts? I'm just curious... the blog post has the title "DSLs for non-programmers are a hoax" and this HN post originally had the same title. At some point it got changed; I've seen this happen before. Is this HN editorial intervention, or did the OP make the change? Just curious...

Mods sometimes change the title if it's incorrect, unclear, or deemed to be too click-baity.

Re: Problems with DSLs for non-programmers

#96
I agree with most. But I find SQL to be a very bad example for a failed DSL. On the contrary, It is a highly successful DSL. In most large companies business analysts (with no programming education) do use SQL extensively.

Re: Problems with DSLs for non-programmers

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

Re: Problems with DSLs for non-programmers

#98
post #12
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…

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.

Re: Problems with DSLs for non-programmers

#99
post #67
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…

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…

> ...how many mistakes have been made...

It actually doesn't matter. Yes, we can all agree that Excel is a dreadful interface for a programmer. But programmers don't use it for things better done otherwise. The people using it are not programmers. If you suggest they try to accomplish their ends in more sophisticated language, they look at you with wide-eyed horror.

Every moderately-sophisticated Excel document written by a "non-tech" person is something which would previously have required either the endless back-and-forth of a middle manager trying to explain a poorly thought out spec to a programmer or, more likely, simply have been done by hand till the end of time.

Maybe it could have been better accomplished by that middle manager learning a real language. But it's neither here nor there, because that was never going to happen. Excel, for all its faults, actually convinced people that they could build simple programs (by pretending they weren't). That is the criteria by which it is successful.

The question I'd ask is: why do you think it's important that all of these features be included? Why should it have a debugger? The people using it don't want one - make it look any more like programming and they'll go back to asking IT. The people who'd appreciate a debugger - they aren't programming in Excel. Who is served by making Excel a more sophisticated language?

Re: Problems with DSLs for non-programmers

#100
Also: Not discount the power of some basic training to unlock the power of DSLs.

I work a lot around RDBMS. Most people have almost null training about SQL, relational model or how databases work. They learn it in the most ad-hoc, step-by-trick-step.

Is mostly: "Hey how do that? Look! this cool trick do the work!". You see this everywhere. Sometimes people ask you this question a lot (about excel, sql, how use email, what? Word can do some mat too?) and so on.

Eventually, I sit a few minutes with them and explain the fundamentals. It change the game. A lot.

Post reply on HN