Problems with DSLs for non-programmers

> 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 the concepts in the DSL must also understand the superset of all regular programming concepts. Hell, most Java coders couldn't even write a memory manager from scratch!

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.

> SQL is used widely, but it does not work that well for people who are not programmers.

Is the key phrase that shows the author has no idea what they're talking about.

I can count 20 analysts, off the top of my head, that I personally interact with on a weekly basis at work that disprove the point.

They have incredibly deep knowledge of their particular datasets. They know more than enough SQL to produce efficient queries for their needs. And they wouldn't understand exception chaining if it bit them in the ass. But they still run their part of the business better than I would.

Author is making an "anything shy of perfection isn't worth doing" claim, which misses the forest for the trees. The objective of programming (DSL or otherwise) is to get work done.

Not to be ideologically perfect.

Which is one reason Python is wildly successful, despite all its Oops design bits.

> (In author's defense of DSLs) There are AWK, RSpec, EJS, Emacs Lisp, bash scripts and a lot of others that are cool because their domains are steady and they are used by professionals.

The pompous twit... so data retrieval isn't a steady domain and business analysts aren't professionals?

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 personally much rather that surgeon be studying medicine for those 2 years!

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.

I think later-legacy-VB (eg 6) suffers harshly from failing to properly separate primatives.

Imho (open to disagreement), one should think incredibly hard before adding primatives to a DSL. Because what that's essentially saying is "My abstraction was incomplete over the target domain, and now I'm going to hack something in." And now you have a "domain + some other stuff" language, which starts to look like a general purpose language.

SQL vs VB is an excellent example of focus.

(Although I do think VB.net added sanity back to the mix, by saying more clearly "These are VB things" and "These are .net things", and if you want to do the latter in the former, just make a library call)

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 the first place, and reach the correct conclusion. (And case-sensitivity in a username is exactly the kind of keen (textual) detail that we're both wired and trained for.)

In other words, we're just iterating on trying things [as xkcd observed][0]. The key is that inside that first decision box, locating an action to try, we have a huge leg up on the "...which looks related to what you want to do" part. I sometimes describe this as "knowing how computers think", but really it's knowing how the people that wrote the program think.

Not that it's an easy problem, but I think we still have a lot of work to do as a field, to make stuff accessible to people whose brains don't follow the same patterns as ours.

[0]:https://www.xkcd.com/627/