Declarative programming is a dead-end for the lowly programmer

Most programmers focus on software execution. We want to understand what the computer is actually doing. Java, C, JavaScript, PHP, Python… all these languages make it easy to build any software you like. In these languages, even at the very beginning, you are truly in charge. They are like hammers, screwdrivers, nails and screws… they don’t know how to do much, but if you are skilled, you can do what you want.

Opposed to this view are declarative programming languages. SQL is maybe the best known. On the web, we have HTML and CSS. Folks who work with XML a lot know about XSLT. And you have regular expressions. These languages are more like entrepreneurs. They won’t let you touch the tools directly. They are telling you “tell me what is needed, I’ll do it”.

That’s why people who only do HTML and CSS, or only SQL, are often not considered “programmers”.

Nevertheless, I think we can agree that HTML and SQL are pretty useful ideas. But like all declarative programming languages, they are dead-ends for the lowly programmer. I use the term “lowly programmer” to distinguish regular programmers from PhDs with IQs above 200 and teams of highly paid Google engineers.

For most programmers, with declarative languages like SQL and XSLT, what you see is what you get. It is hard to extend them meaningfully. I don’t mean that they can’t be extended, but they are typically only extended by people with enormous resources like browser makers or database vendors. This makes sense in the spirit of these languages: you are meant to delegate to the language itself.

When you first learn a language, say JavaScript, you might realize that it has missing features that you need for your domain. For example, JavaScript does not know anything about video games. Neither does SQL. JavaScript does not really have a concept of “library” or “extension package”, but people have still written lots of software libraries to make it easier to write video games in JavaScript. No such luck with SQL.

HTML and SQL have become enormously sophisticated over the years. They are truly powerful tools. But they mostly are as they are.

It is a problem because interesting programming projects are about new unsolved problems. And these mostly get solved by people using non-declarative languages.

If you are interested in a newly emerging discipline like data science, and you know how to program in Python, Java or R, you can build useful software packages. If you publish them, others might use them and extend them. But if all you know is SQL or HTML, you are stuck with what these languages provide you.

Of course, you can write the new great data-science platform in Prolog, SQL or XSLT. In theory you can. But for most people, it is not reasonable. These languages are dead-ends.

Credit: This blog post was inspired by an offline exchange with Antonio Badia. The opinion stated here is mine alone, however.

Reference: MADlib is a library for analytics that started out with a few SQL scripts. It quickly outgrew SQL however.

Rebuttals:

  • Many people object that HTML is not a declarative language. Others object that SQL is also not a declarative language. I defer to Wikipedia.
  • Some people think that instead of “declarative”, I should have written “non-Turing complete”. But SQL is Turing complete. So is CSS. So is XSTL. And so forth.
  • Some people think that some declarative languages are easily and commonly extended by the lowly programmer. Though I will concede that it is indeed possible, I must point out that nobody was able to give me a concrete example.

15 thoughts on “Declarative programming is a dead-end for the lowly programmer”

  1. Minimal cue: View HTML as Lisp written with a funny notion. As with Lisp, you define your own atoms (tags) and attach behavior.

    I failed to explain this well to the HTML5 WG early. So the plumbing is a bit of a mess. We since have frameworks that use exactly this approach.

    Lisp is usually described as extensible. 🙂

  2. So, logical languages (like Prolog, miniKanren, etc.) are also declarative. Do they fall under the same criticisms? They are not mainstream programming, and are used to handle a different domain of problems.

      1. Maybe you are right about Prolog Haskell etc (that they are dead ends for programmers) but not for the same reasons. A prolog programmer can solve all the same problems as a python programmer.

  3. Dear Mr. Lemire,

    The distinction between declarative, imperative, functional programming is like beauty. In the eye of the beholder. It is true that highly focused declarative languages can give one they are not particularly flexible. But every so-called functional language has declarative aspects, and even good fortran programs from 50 years ago made heavy use of functions, so weren’t they functional too? I find all these terms unproductive. Programmers are always looking for leverage, and generality. Sometimes a powerful tool is narrow in application. Occasionally a nice balance between flexibility and general purpose use arises, and that language becomes popular. The best languages and tools rarely become popular because as an industry, programmers are more attuned to job protection than productivity. I have seen time and time again an inferior language or toolchain adopted, always with the excuse that it is more popular and therefore “safer”. I have been working on a new language that combines some of the most powerful features of prolog, with the cleanliness of Modula-2, and novel data structures. Since algorithms + data structures = programs, isn’t the lack of innovation in data structures really the problem nowadays? Seems to me that the relational table is a dead-end. As for LISP, its insidious parenthetical notation makes it unreadable to most people, and transformative languages as categorized by John Backus don’t transfer well between people, which is probably why he never liked them. The truth is that all languages are merely a notation that allows one to more conveniently express a program that ultimately is mapped to the low level instruction set of the CPU, which hasn’t change significantly in 50 years; we still have memory, registers, the basic operations, boolean, etc. … so every program is a bridge from the problem domain to a CPU implementation, and the directness, brevity, clarity, simplicity, all very depending on the language and toolchain selected. The goal of modern language design is improve our overall productivity by simplifying and streamlining the notation, and introducing new productive concepts.

  4. I’ll add my voice to the small chorus that I think “declarative” is not the best word for the languages you’re lumping together. I think the general purpose vs special purpose/domain specific spectrum is much more relevant.

    Agreeing with Andre: You can say bad things about the marketability of functional language programming skills. However, languages like Haskell and OCaml are _at least_ as extensible as languages Java, Python or R. If you insist on ranking the latter over the former, then I think you’re just talking about the vibrancy of the respective library ecosystems, which has little to do with the technical properties of the languages themselves.

  5. …perhaps why I am an “Applications Developer” and not a “Programmer” – lowly or otherwise?

    Found this blog as a reference from something else I was researching. Over my head, but incredibly interesting. I’ll come back when I can.

  6. I use Prolog to write web applications yet I’m not a PhD or a Google engineer. I get well paid for doing it. Yet by your article it’s s dead end for me. I definitely do not agree with this.

  7. SQL, HTML and CSS are domain-specific. What’s the point of using the same language for every domain?

    How about the problems you can solve with SPARQL, those are not interesting?

    XSLT might be a dead end, yet it’s the most advanced language I know, with built-in service location, dependency injection, pattern-matching at the declaration level and high code reusability in both in source and compiled (in 3.0) form.

    JavaScript sucks.

  8. ‘I use the term “lowly programmer” to distinguish regular programmers from PhDs with IQs above 200 and teams of highly paid Google engineers.’

    I would like to be one of those “highly paid Google engineers”. You can remove the “Google” name from there, that doesn’t change anything. that would make for a more interesting blog post.

Leave a Reply

Your email address will not be published. Required fields are marked *