Is “Low Code” declarative by default?

Question

Something that has really be getting under my skin recently is that Salesforce uses the term "Declarative Development" to mean "Low Code" or "visual code".

For example, this article explains the difference between imperative and declarative programming, while making claims that their "low code" solution is declarative (and thus superior).

However, I'm not sure I can agree with that... In implementation, it seem very much to be imperative programming.

Am I wrong here? Does replacing text with shapes somehow make the procedure shown above "Declarative"?

Is this not just a transaction script in fancy new clothes?

Answer 1

TL;DR -- for most folks "low code" usually means "little/no typing" while "declarative" means something a little different. I'd agree that what Salesforce allows is not "declarative development."

I also agree mostly with Robert's answers, with a few small differences. FWIW, the terms "imperative" vs. "declarative" go back to early programming languages.

"Imperative" programming languages were used to describe languages that essentially mimicked what you would do at the machine level, i.e. execute a list of commands that computed a value, assigned a value to a storage location, sent a value to an output device, etc. Statements were executed in a sequence with branch points and conditions to implement loops, if-then-else structures, and so on. Languages like Fortran, COBOL, ALGOL, C, and Pascal were all imperative. They were "imperative" because you specified how the program worked, sometimes in ways that very closely matched what happened at the machine level (i.e. C).

"Declarative" programming languages were supposed to be more abstract, and specified more what you wanted computed and less how it was done. Languages like SNOBOL and Prolog were this way. Such languages generally were interpreted because they required large compute engines underneath them to execute. Later it became common to compile them into executable images in which the compute engine became part of the image.

The dichotomy between the two terms fails somewhat since in both cases you need to know how the elements of the programming language will be executed to know how you should construct your program.

I haven't programmed in Salesforce, but I have programmed in BPEL, and it's very similar in appearance. You basically draw flowcharts with relatively small amounts of typing. This approach goes back to the early graphical programming languages that were coming out in the 1980s. It's "low code" in the sense you spend more time dragging and dropping shapes and less time typing programming statements. I'd argue that it's still imperative because the flowchart you're constructing has the same elements as an imperative programming language (sequence of statements, computing values, assigning values, branch points, etc.).

There are some more declarative graphical programming systems. I'm currently using SnapLogic, an iPaaS, which reminds me a lot of APL or SNOBOL in the way you have to think to construct your programs. It's nice in that you don't have to specify certain things (i.e. looping over a list of data items, which happens implicitly), but it can be more challenging to do things that are, at least to me, straightforward in a more imperative approach.

Ultimately I agree with Robert -- the important question is less, "What do you call this?" and more "How easy is it get things done in it?"

Answer 2

I share your criticism and I do not agree with Robert's answer. Robert says

Declarative programming is telling the machine what to do (rather than how)

Telling a computer what to do is essentially the same thing as telling it how to do it. The only difference is the "level" of the programming language. It is the same paradigm.

The essence of declarative programming is telling what you want as a result rather than providing steps. And this is in line with Wikipedia's definition: the lack of a control flow description.

You graphical example from SF is indeed just a pretty way to express flow control, complete with if statements and loops.

Answer 3

Imperative programming is concerned with telling a machine how to accomplish a task, usually by writing individual programming language instructions. It also includes any method calls where you are still essentially describing how.

Declarative programming is telling the machine what to do, and then letting the machine work out how to accomplish it. SQL falls into this category, as does Linq from the .NET Framework. You tell the machine what data you want, and it works out how to retrieve that data in the best possible way.

Exact definitions of these terms are not useful here, as it is easy to believe that you're still telling the machine "how" to accomplish something, when in actual fact there are a lot of implementation details and decisions made under the hood (the real how) that the user need not concern themselves with.

The main reason that SalesForce calls this "declarative" is because it involves visual symbols to describe a business workflow, and you don't need programming skills to successfully create one. The underlying workflow engine reads the workflow and works out the necessary machine instructions to execute it.

Answer 4

From a theoretical perspective, "declarative" languages are usually not Turing complete, and are used in contexts where that isn't necessary or even counterproductive, for example when you need to prove correctness and don't want to run into a variant of the Halting Problem.

For example, HTML and older CSS versions were purely declarative, "there is a heading in front of this paragraph", and "headings get a larger font", which is sufficient for displaying information, but not for processing, so JavaScript was used to manipulate the document structure from an imperative program.

Because the rendering engine still interfaces with a declarative document tree, we can be sure that rendering the page will take a finite amount of time -- there is no way to write an "endless loop" web page with just HTML and CSS, and while you can write an endless loop in JavaScript, the only thing you can do to keep the rendering engine perpetually busy is to feed it new changes continuously.

At the bottom of the software stack however, the CPU still needs to execute instructions in sequence, so you cannot have a fully declarative stack, so whenever you have something that is declarative, that is one layer that the user interacts with.

There are also "visual" programming models where the program is not necessarily declarative, but represented graphically. The number of objects on the screen is finite, so they can be saved to a declarative "there is a loop" file format, but to realize the loop and actually execute it that file needs to be compiled, and at some point we still need to leave the declarative framework if we want a Turing complete language (textual source files also have a finite size, but can describe a program that doesn't terminate).

There are a lot of use cases where a purely declarative model works, and the safety gained from the limitations is worth it, but that is independent from the editing method used.

Answer 5

I think the "what vs how" comments aren't very helpful and the article reference from Salesforce falls into this trap. For example if I write a = b + c is that a what or a how?

To me, the distinction between the two ideas is more about the fact that, in an imperative language (for example C), when you see a = b + c it doesn't say anything about the fundamental relationship between the three variables. It merely describes a step in a process. In a declarative system like Haskel however, a = b + c represents a fundamental relationship, not just a step in a process. This is also true in Excel and in reactive systems.

So in this click and drag language of theirs, do the shapes merely represent steps in a process, or do they represent fundamental relationships between things?