Sridhar Vembu’s Blog

The previous thread What is Declarative Programming got too big, so I am splitting it up. An Old Acquaintance said

The HTML + browser combination does satisfy what you say in the second para there. I simply declare I want a title, and it figures out how to do it. Think about the million details it abstracted from me. The display device could have varying resolutions. The default font could differ. The operating systems are very different. Yet just a simple declaration of title does the job.

It is a very meaningful model of computation, when you consider the sheer number of details it abstracted away from you, to be performed by the browser. The reason it doesn’t appear so meaningful to you may be that its output of the computation goes to the visual display device.

I disagree. I would say what you call “models of computation” is a very imprecise notion. Fundamentally it resolves to a syntactic notion, in my opinion. Take a well designed library that insulates the user from the details of the underlying implementation, so the library user simply declares what he wants done, and the library figures out how to do it. If you restrict your computational power, so that you are restricted to using just those library primitives, and the rest of the language isn’t Turing-complete, then your code is, at some level “declarative”. Note that the implementation of the libary itself may need a Turing-complete language, but the library user is restricted from that.

That is what HTML is doing here. The contract is the Document Model (DOM). You are allowed to use those DOM primitives (aka HTML tags) but nothing else. It definitely is easy, a lot easier than creating the implementation that interprets those tags. It is technically possible (indeed that is what Gecko layout engine from Mozilla does) to provide the DOM itself as a C++ API. This allows you to embed the DOM API in your code. In this case, you have “imperative” C++ code calling “declarative” DOM C++ APIs. The reason why this is harder than HTML design is that we would have mixed up the purely “declarative” DOM-API-calling C++ code (i.e the equivalent of HTML code) in all the other general C++ code. The divide-and-conquer strategy to master complexity has been lost.

Note that Javascript + HTML is _exactly_ analogous to that C++ with DOM API, except that the Javascript gets access to the DOM through the HTML tags, and not directly with the C++ API. They live in distinct syntactic spaces, enforcing the separation between the “declarative” and “imperative”.

Now, what is a library and what is a language feature is a distinction without a difference. In languages like Lisp, there is not even a syntactic difference.

I venture that what is traditionally known as “functional style” (again an imprecise notion, mostly overlapping with the “declarative style̶ really amounts to writing well-designed libraries and macros, and then gluing them together in a “declarative” fashion. It would be possible to change the small parts sitting in the libraries (the implementation) without changing the glue that spans across them. It is bottom up in terms of development (libraries/macros and then the glue) but you can understand it top-down. In general, library/macro writers (equivalent to browser writers) need to be more skilled in programming than the declarative glue writers, who would need to be skilled mainly in the “domain” (User interface design in the HTML case).

But since Lisp encourages the whole code to sit in a common syntactic space, we can get into “logically undecidable” disputes. Two Lisp gurus can select differing ways of partitioning of what is library and what is declarative glue, and both would be “right”. Selection of what primitives to offer in a library is akin to selecting which set of axioms are more fundamental, which ones should be derived. In practice, good libraries give a redundant set of primitives (so there is more than one way to do something in the glue layer above), for syntactic convenience. HTML and LaTex do similar work, and both are declarative, but they don’t standardize the same primitives.

Frameworks (another fancy word for libraries) like J2EE or Ruby-on-Rails, and languages like HTML, standardize the library layer. And with time, more and more of what was previously imperative glue migrates into the library, making more and more of the resulting glue declarative.