Is SQL a “waste of time?” Regular expressions, HTML, Makefiles, CSS (and CSS selectors aka jquery selectors)?
It’s the bad ones that are a waste of time. The ones still called “dsl” instead of just “language, “format,” or “syntax.”
It certainly wastes a lot of my time because it is considered just a DSL and not a "real" programming language, and therefore doesn't get the same kind of attention towards making it better that "real" programming languages get. Maybe there is something to the original thesis.
Like, why can't I import shared query modules to compose into my queries? I can't imagine any other programming language without that feature. The execution engines support it in concept, allowing you to get there with some painful copy/pasting or using code generation (which seems to be how most people use SQL these days[1]). But because SQL is seen as just a DSL it doesn't get any attention towards making the language better.
[1] Which I'm not sure SQL is all that good at being the assembly language of databases either. It is strangely irregular.
It's like, "Geez, regular expressions sure do suck. They don't come with a package manager, concurrency, or a way to make system calls." I only feel comfortable embedding regular expressions or SQL in code because they are inherently restricted "DSLs."
If SQL was a general purpose programming language, then we wouldn't need SQL, we would just use existing general purpose programming languages.
Assuming you have some use case for query composition, why is the feature better handled within SQL as opposed to in the general purpose query language managing the DB queries and making the calls?
If the environment hosting and managing the queries (e.g. psql) is open source, maybe you can hack in support. Often that is not the case. Even when you are able, then your work becomes non-standard and thus not easily shared with other analysts, which kind of defeats the whole sharing of modules.
If you are writing a full-fledged application, using "real" programming languages, then a lot of people build their own query languages on top of SQL, treating SQL as just an "assembly language" that their query language compiles to, to add what SQL lacks. That's all well and good, but totally overboard when you just want to answer some questions about your data.
I do think you make a point that SQL tries to be too many things to too many people. No question, it is useful being able to embed SQL strings into other code without needing to worry about complex dependencies... Except you still have that worry as we already tried adding that composition through stored procedures, views, etc. which are dependent on a particular database state being true. It's there, just not very well thought out from a developer ergonomic perspective. Indeed, SQL is confused.
The article is right. DSLs are, universally, awful, as they grow and grow until they encompass all features of a general programming language - but because of their evolution path the're awkward and twisted and lack basic features of a general programming language (and definitely lack all the tooling you get). Witness what happened with XML as a configuration language. What started off as another leaf node under SGML ended up - by way of the Java ecosystem - growing if statements and loops and all the rest, only in a horrendous, hard-to-read and harder-to-debug monstrous language.
So he's right. We should use real languages. And we should probably all just use Pulmi.
The problem here is that while you can say “Terraform is more than a DSL” - if you ever back the layers or try have a conversation with someone who’s a true dyed in the wool Terraform zealot and start to try and understand where they’re coming from, you begin to realise they don’t love Terraform, they love this weird half language because they’re an expert in it, and they’ve built their entire career on being an expert on something you can only use for one specific use case.
That's from the article, and that really sounds a lot like talking to someone that knows and loved regular expressions (and I count myself as one of those people). The alternative, which is often done in lower level languages, is either some simple nested conditionals or a state machine, and plenty of people choose to just write state machines. I mean, that's all a regular expression is anyway, a shorthand expression for building state machines to process strings.
It should be no surprise that there are plenty of people that think regular expressions are wasteful and you should just write your own state machine (fewer than there were in the past, but they exist). Regular expressions are exactly like everything else that's being discusses in the article, but many people like them. Perhaps that's a point we should focus on to determine what makes a DSL successful and good compared to the alternative.
If you're going to make a serious argument that "DSLs are, universally, awful" then you're going to need to account for regular expressions a bit more carefully. That can be you admitting that you just dislike them and don't use them so consider them awful as well, but if you don't hate them then you may want to focus on the why, and it is likely a much more interesting conversation topic to pursue than "DSLs bad".
https://en.wikipedia.org/wiki/Regular_language
Regular expressions have a deep mathematical background. An ad-hoc DSL from a company that specifies infrustructure does not.
> Regular expressions have a deep mathematical background. An ad-hoc DSL from a company that specifies infrustructure does not.
You very specifically went far beyond making any statement about ad-hoc DSLs from companies that make infrastructure. You said "DSLs are, universally, awful".
I'm also interested why you left out makefiles in your original rebuttal. I think makefiles are a good example a simple and useful DSL for accomplishing what it sets out to do. That's not to say it can't turn into a mess (what language, domain specific or not, is free from that concern?), not that it solves all needs to all people, but makefiles are simple, straightforward, solve a useful problem, are well known by many people (and easy to explain and teach), and I don't think most people would consider them a mathematical concept core to computer science. Are they awful? If so, why?
Sure, Makefiles are a DSL. Just a horrible one. They just make my point in a different way. Have you used a Makefile recently? They are AWFUL. Brittle, complex, half-bash, invisible-tab-prefixed, abominations, sent from another millenium. Let's take a modern codebase - say Python - you're much better to just use something like pyinvoke - handles all the CLI-level stuff, and you get the full force of the programming language you were writing in the first place.
In any case it's clear you're uninterested in engaging on that and nor are you willing to consider your statement carefully and actually support it with additional examples (beyond some puzzling critiques of makefiles which make me think you don't understand the point of a DSL at all) or walk it back to a reasoned examination. So I'm not sure we'll get much out of continuing this.
As I’ve quite clearly said, regex is a good DSL - so I obviously do think, and have argued above, that there is a split between “good” and “bad” DSLs, but examples of good ones are vanishingly scarce.
I think, given that it’s your position that DSLs are generally good; or at least that there are many examples that you find fine, then it’s upon you to provide examples. So far you named Makefiles, which are hilariously bad, but your response to my comments on it was basically some lazy ad-hominem, so I don’t hold out hope for any actual intelligent analysis.
But as I have outlined above there is a giant chasm of difference between mathematically-backed deep and broad DSLs, and… some ad-hoc commercialware that iterates towards being a full language but with bad, ad-hoc design and worse tooling.
A Regex, SQL, TLA, CSS and so on are all better DSLs than allowing a general purpose language because they are meant to restrict inputs of lower priority than other goals, where priorities are largely fixed.
A corporate DSL is meant to expand to whatever grandiose plans the company has for accepting impractical input from platinum customers.
To me, that's a much more interesting (and useful!) discussion than just piling onto the DSLs are awful bandwagon, and I also think it's a flaw in any argument put forth in that argument that needs to be addresses before I can accept it.
This is the Slippery Slope Fallacy writ plain.
A great many DSLs are stable over years or decades. By your reasoning, a stable DSL is bad because it's going to grow. Why is it going to grow? crickets
Peeling away the fallacy, we could perhaps agree that "the uncontrolled growth of a DSL is an evil best avoided." Or if I'm being less generous, we could look at the bottom of that slippery slope and conclude "general programming languages are bad," because that's what the author seems most incensed by.
They are also not application specific. Language design is hard. DSLs are made up by people who's main project isn't the language.
Sometimes the motive for a DSL is something like "I don't like how this takes 5 lines of code in JS, if I made my own language it would only take 3"
No need for the personal swipe.
> The core point is that the article is talking about some quite specific types of DSLs
It used specific types of DSLs as evidence but I don’t see a narrowing of the claim itself? Where are you getting that?
Fair enough
It used specific types of DSLs as evidence but I don’t see a narrowing of the claim itself? Where are you getting that?
What makes me sad, as I posted in a top-level comment, is that I read this exact same rationale 20 years go, by Steve Yegge, and yet we are still having the same stupid debate in programming about whether we should use DSLs and then the DSL grows and grows and, lo and behold, it's Turing-complete, but its ergonomics are dire and its tooling non-existant. And it's not like this is some niche part of the ecosystem - it's how most people deploy infrastructure.
What I despise is seeing the same problems come up again and again, and never seeing good solutions to them, jsut the same mistakes, repeated. Programming is, truly, terrible. Just a load of slaves building the Pyramids.
(And SQL is not a dsl because it’s a … programming language? But also HTML is not a domain specific language precisely because it’s not a programming language? I don’t follow your logic at all. I don’t think either are programming languages, but both are languages in another sense of the word, as evidenced by their full names, and certainly dsls.)
I feel like the author missed a more obvious comparison between Puppetlang and HCL: vendor specific languages.
When you consider them from that perspective it’s clear that the decision is based more on which company you trust to serve your long term needs over any point in time implementation details. Is that company Puppet? HashiCorp? Pulumi? The implementation details obviously matter but if you’re investing 7+ years into an ecosystem like the author did, then there are a lot more factors than just syntax.
(and I think SQL started at IBM but I’m not sure if they tried to keep it proprietary or make it a standard)
Regardless the author getting 7+ years of runway out of a specific technology is hardly a waste! My average technology switching time is probably closer to 5-6 years.
Both are (or at least were originally) “crippled” compared to “real” languages.
Both grew immensely each eventually escaping their single-vendor origins.
SQL and CSS selectors fit the bill. Everyone has just kind of accepted them now. It's not an excuse to try creating new languages for every new thing, it's an uphill task.
then we should all be using c, lisp, smalltalk and perl (add your favourite old language here). because most younger languages don't bring anything new to the table.
The good ones are ones that have always been there
esperanto? not exactly popular, but it is definitely better than english and solves problems that english can't. (it's just that people don't realize the problem yet)
i think we both want the same outcome, that is well designed and useful languages, whether they are DSLs or not, and i agree that most DLSs probably aren't that. but not all general languages are getting that kind of rigor from the start either. some get it rather late after they became popular enough to have demand for fixing the problems that stem from their initial ad-hoc design. i am looking at javascript and php here in particular, but there are probably others.
DSLs, due to their nature are less likely to ever reach the level of popularity where its worth it to fix design problems. general languages on the other hand are more likely designed by people who care and without the pressure of a quick solution. (and its my understanding that javascript was a quick solution, which would kind of prove the point)
esperanto, btw, was designed with rigor.
The exception of course is Lisp where embedded languages can feel like standalone languages.
The article doesn't discuss the possibility of building DSLs with the programming language and using them, all integrated together.
Yes, CSS is crap for instance. The web should have one language for everything in which styling is a DSL.
Regular expressions are better when they are in your language:
2> (regex-compile '(0+ (or "a" "b")))
#/(a|b)*/
3> (regex-compile '(0+ (or "*" "b")))
#/(\*|b)*/
4> (let ((x "[")) (regex-compile ^(0+ (or ,x "b"))))
#/(\[|b)*/It is probably the ultimate DSL if you are willing to get deviant with your tech stack.
For other declarative DSLs, I've definitely bashed my head against the wall and gotten a few gray hairs over "why the f* doesn't this goddamn thing that should work work". Sometimes it's because I'm not grokking how the platform works. Sometimes it's a bug, or unimplemented feature.
I suspect the reason why people don't absolutely abhor SQL is that the biggest players (MySQL, Postgres, Sqlite) have actually done a reasonably good job of making the 98% paths very good and 90% of the rest "good enough".
Exactly - Unless you are doing something really unusual (or wrong), the vendors of these engines have almost certainly encountered and optimized for some shape approximating your scenario.
If you want to get into some extreme ends of the practice, "ancient" engines like DB2 are some of the most capable. Many have been around longer than most developers today have been alive (myself included). That is a lot of optimization legacy to argue against. The halloween problem & iceberg meme comes quickly to mind. Why wouldn't you want to stick with something that has already dealt with all of that bullshit?
Bingo!
Lua was born as a DSL for configuration files. Today is way more than that.
JSON was born as a DSL for describing data, a less verbose alternative to XML. It is more than that.
Which is why it's amazing for data interchange and obnoxious to directly interact with by hand.