3 ms·
"Declarative" programming has become something of a buzzword. This is unfortunate because it prevents finer distinctions between domain specific language techni
by tel 8y ago
"Declarative" programming has become something of a buzzword. This is unfortunate because it prevents finer distinctions between domain specific language techniques.
I think it achieved its buzzword status because it for a long time was something people clearly recognized but couldn't define. Fortunately, Neel Krishnaswami wrote a very cogent post putting his finger on the nerve.
https://semantic-domain.blogspot.com/2013/07/what-declarative-languages-are.html https://semantic-domain.blogspot.com/2013/07/what-declarativ...
With this definition we can see that (a) the author misses the boat on "declarative" in a concrete way and instead lands on something much closer to DSLs in general and (b) then only uses a narrow set of DSLs to provoke criticism and thus presents a very weak argument.
The powerful core of his argument—the "unfolding" principle—is not something I can claim to understand fully from this article, but it suggests something worrying: that every DSL must transparently resemble its interpretation. This makes it easy for a user of the DSL to recognize how it will be interpreted and thus achieve ease of understanding... but it gets dangerously close to banning abstraction all together!
In my opinion, the true measure of a DSL is the consistency and diversity of semantic interpretations (or "models") that are valid for the DSL and consistent with one another. This measure seems to establish the resilience and leverage a given DSL's topic might have.
Consider how SQL can describe set operations, an abstract search process, a logical predicate, and also a concrete set of searches achieved across physical data stores.
Anyway, to answer the question in the title—something the article neglects to do—I'd strongly suggest that "yes" declarative programming is a real thing, "yes" DSLs are real too, and "no" they do not automatically fall to the problems one can potentially extrapolate from by getting frustrated at templating solutions.
- marcosdumay 8y agoI take the "unfolding" principle to be that DSLs do not permit abstractions of their own language. This one is true for most DSLs, but not all.
- drudru11 8y agoI cannot quite decipher Neel’s interpretation. The math syntax on his site isn’t rendering. Can you provide a simple explanation? This is interesting.
- tel 8y agoLet me first transcript his math. He's giving a judgement for regex semantics `s matches r`. - [for all r] <empty> matches r [unconditionally] - [for all c] c matches c - [for all w, r1, r2] IF w matches r1 AND w matches r2 THEN w matches (r1 \/ r2) - (no rule for "w matches bottom") - [for all w, r1, r2] IF there exists w1, w2 such that w = w1 . w2 AND w1 matches r1 AND w2 matches r2 THEN w matches r1 . r2 - [for all w, r] IF there exists w1, w2 such that w = w1 . w2 AND w1 matches r AND w2 matches r* THEN w matches r* So he notes that in the semantics of regex we have non-trivial "there exists" quantification expressing the "search" over possible breaks in the target string. This need for an existential to give semantics to a language is his focus. Perhaps the most obvious example then is Hilbert's epsilon, such as what appears in TLA+ (section 6.6) http://lamport.azurewebsites.net/tla/xmxx00-02-09.pdf http://lamport.azurewebsites.net/tla/xmxx00-02-09.pdf This is called CHOOSE in TLA+ and it's a constructive existential quantifier in that a / b === CHOOSE c in REAL : a = b * c results in evaluating a / b to "some" real value c such that the multiplicative condition holds (or some arbitrary value if no such value exists, fwiw). This shows up in SQL as being essentially exactly what SELECT is doing: `SELECT * FROM Table WHERE Cond` is CHOOSE row in Table : Cond(row) except now CHOOSE returns all matching values as opposed to just "some" matching value.