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.

enter image description here

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?

  • 1
    FYI, there is no low-code or visual-code tag... I suggest adding one, as this is definitely an area of software development that could use an "engineers" perspective
    – NSjonas
    Commented May 8, 2020 at 15:55
  • also... why the downvote? Seems like a valid question... If it's not fit for this exchange then flag it to transfer
    – NSjonas
    Commented May 8, 2020 at 15:58
  • What is your basis for believing this is imperative? Commented May 8, 2020 at 15:58
  • 1
    @RobertHarvey stackoverflow.com/a/11587378/800619 *** Imperative programming tends towards: Sequences of commands, each of which perform some action; but which may or may not have meaning in the problem domain. *** But I'm not sure, and thus why I'm asking the question in the first place...
    – NSjonas
    Commented May 8, 2020 at 16:00
  • 10
    Salesforce "declarative" vs "imperative" definitions are non-standard. I'd take most of what they say with a grain of salt. For example, it's patently false that declarative programming is point-and-click programming, or that you don't need expert devs to write it. You need expert devs for declarative programming too. Don't believe marketing hype and don't use their definitions.
    – Andres F.
    Commented May 8, 2020 at 19:52

6 Answers 6


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?"

  • 5
    Agreed, and I'll also add: "is it true that you really do not need a skilled developer to write non-trivial programs using this solution?". The answer is "no, it's false" for almost every solution you can think of. Of course, it's Salesforce business mission to convince customers that their solution truly doesn't require skilled workers, but you know... marketing... hype... etc.
    – Andres F.
    Commented May 8, 2020 at 19:57
  • 1
    Another famous declarative language: make (although it contains some imperative bits...) Commented May 9, 2020 at 2:59

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.

  • My examples clearly illustrate what I meant by "how" and "what," and I clearly stated that those two terms can easily get confused. Commented May 8, 2020 at 19:39
  • 2
    I'm my view, there is barely any sensible distinction between "what" and "how" in computing. "What you want" always comes dangerously back to "how you want it done", and a programmer rarely wants to cede to the senseless computer any judgement about what he wants.
    – Steve
    Commented May 9, 2020 at 0:47
  • I've not used SF myself, but I'm not sure that what is shown is the control flow of a program to be executed. It might just as well be a business flow chart, and these steps happen asynchronously and possibly with user interaction.
    – Bergi
    Commented May 9, 2020 at 16:29
  • 1
    Re, "...what to do is...the same as...how to do it..." I could tell you to "Measure two cups of flour into a bowl, crack two eggs,..." or I could tell you to "bake a cake." But, "bake a cake" could be interpreted as a "desired outcome," or it could be thought of as one step in a larger procedure whose outcome is, "prepare a birthday dinner." How you interpret an instruction like "bake a cake" depends upon the level of abstraction at which you are thinking. Commented May 9, 2020 at 21:56
  • @Solomon Slow I would say the difference is much clearer. "Bake cake" is a command, no matter how you look at it. It is a powerful command yet a command, a step in a control flow. A declaration however is a document that defines state. In case of the cake it would list the properties of the cake. Commented May 10, 2020 at 10:26

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.

  • 6
    As a C# programmer, I don't need to have assembly language skills to be able to tell my the computer how to run my program... So is ALL C# code declarative? Seems like by this definition there is just an arbitrary line in the sand around abstraction
    – NSjonas
    Commented May 8, 2020 at 16:32
  • 2
    If you actually look at declarative code examples in DDD or FP then I don't think this holds up...
    – NSjonas
    Commented May 8, 2020 at 16:33
  • 4
    You're also arguing with a straw man. SalesForce is not using the term in the same way that software developers normally use it. They're co-opting the term to try and make a sales point. Commented May 8, 2020 at 16:38
  • 2
    Instead of asking whether SalesForce is using a particular technical term correctly, a more useful question might be "does this approach work?" SalesForce is rightly criticized for being a big, expensive, monolithic application that requires costly specialists to install and maintain. This "low-code" approach appears to be a response to that criticism. Commented May 8, 2020 at 16:44
  • 3
    Well, the audience for that article is not other programmers; it is people who are considering SalesForce in their own businesses. Playing fast and loose with technical terms like this gives it an air of authority, but it doesn't really have much to do with programming, other than to give potential buyers the impression that they can "do it themselves." Commented May 8, 2020 at 16:49

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.

  • I think this adds some good context to the discussion. Would be curious to get your take on the above.
    – NSjonas
    Commented May 13, 2020 at 2:19

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?

  • for Salesforce flow it would definitely be the former...
    – NSjonas
    Commented Nov 21, 2020 at 3:13

You are absolutely correct that SF Flow is pure imperative programming.

Clicking vs Typing is completely irrelevant to whether a program or construct is imperative vs declarative.

As has been answered here several times, simplistically think of it this way:

Imperative -> How vs. Declarative -> What

Salesforce ( and now Vlocity nee "Salesforce Industries" ) click-and drag tools include some tools that are conceptually declarative as well as some that are conceptually imperative.

Salesforce Flows, and Vlocity Integration procedures ( like any flowchart-ish 4Gl or graphical language) are fundamentally imperative; Do A with input B, and write the result to C. They accumulate and modify internal program state, many of the operations have side effects as they run, and a given implementation or design is just as likely as textual code to be fragile, brittle, or buggy.

They provide a simpler abstraction in which it is easier to get trivial things done, equally difficult to do moderately complex things, and impossible to do difficult things. This has been the fundamental truth of visual programming tools since they were invented half a century ago.

Vlocity FlexCards and to some extent Lightning Components are UI constructs that are largely declarative, in contrast.

Not the answer you're looking for? Browse other questions tagged or ask your own question.