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