3 ms·

> Every declaration defines a new immutable layer with its own unique hash... This blurs the meaning of "declarative" to the point of meaningless. Consider th

> Every declaration defines a new immutable layer with its own unique hash... This blurs the meaning of "declarative" to the point of meaningless. Consider the following pseudocode: x = 5 print x x = 10 print x This is clearly 'imperative'. But from the perspective of 'each line of code declares a new program', then we consider the code snippet a declaration of a program. > Just as in Ansible you can use “declarative” YAML in a very imperative lasagna of a setup One of the things which makes Dockerfiles imperative is the sequence of Dockerfile commands is significant; if you swap the order of a COPY, RUN to a RUN, COPY, the result changes significantly.

strogonoff 3y ago
> This blurs the meaning of "declarative" to the point of meaningless The alternative is to draw a clear line where there is none. > One of the things which makes Dockerfiles imperative is the sequence of Dockerfile commands is significant; if you swap the order of a COPY, RUN to a RUN, COPY, the result changes significantly. By that logic you can call every Nix program “imperative”. They are sequences of strings, the order of which matters. The horror! A Docker image is a stack of layers. Every layer points to a preceding layer. It’s not a huge leap from that structure to a fairly elegant sugar of a string array, where each string is a declaration that applies to preceding layer thus describing the next one. I don’t see anything fundamentally imperative about it; it can be used in imperative ways, but anything can.
- rgoulter 3y ago
  > The alternative is to draw a clear line where there is none. I'd say that more/less "imperative" refers to describing sequences of actions that take place (especially those which might modify some state), whereas "declarative" is more about a structure of what the result should be. I can agree that a Docker image can be considered as a structure, and that it's possible to construct one declaratively. Whereas I'd say a Dockerfile is an imperative construction of that.
  - strogonoff 3y ago
    Dockerfile describes a set of immutable layers. Whether you model it in your head as a sequence of commands or as a description of a set of immutable layers, is up to you.
kdmccormick 3y ago
I also would to call Dockerfiles imperative on syntactic grounds alone, but I feel they have decalartive semantics in a way that's noteworthy. > But from the perspective of 'each line of code declares a new program', then we consider the code snippet a declaration of a program. The critical difference is that each line in a Dockerfile yields (declares) a filesystem state which can be referenced and recreated. In contrast, in your example, I have no way to say "give me a snapshot of the system between the third and fourth instructions". Dockerfiles have all sorts of rules and restrictions that make these semantics possible. You cannot create loops; there is nothing like a "function", at least within the context of one Dockerfile. > One of the things which makes Dockerfiles imperative is the sequence of Dockerfile commands is significant; if you swap the order of a COPY, RUN to a RUN, COPY, the result changes significantly. I reject this line of reasoning, simply because decalative languages are indeed order-dependent: let y = f(g(x)) is different than: let x = g(f(x)) Much in the same way that these are different: FROM x AS y RUN g RUN f vs FROM x AS y RUN f RUN g
- rgoulter 3y ago
  > I reject this line of reasoning, simply because decalative languages are indeed order-dependent Eh, I can kinda see that. -- It's possible to imagine a declaration where the order of items in a list has consequence. Still, I'd Dockerfiles as a sequence of statements more akin to a bash script than to an SQL expression.
  - strogonoff 3y ago
    This is a deeply mistaken view informed by the cargo-culting devops traditions of yore. A Dockerfile is a declaration of layers that does not resist being used in imperative way, in which sense it’s no different from YAML or any functional language you can think of.
    - kdmccormick 3y ago
      Yeah, to pile on, I often see this line of thinking: > Still, I'd Dockerfiles as a sequence of statements more akin to a bash script than to an SQL expression. lead to some quite inefficient and poorly-factored Dockerfiles.

strogonoff 3y ago

> This blurs the meaning of "declarative" to the point of meaningless The alternative is to draw a clear line where there is none. > One of the things which makes Dockerfiles imperative is the sequence of Dockerfile commands is significant; if you swap the order of a COPY, RUN to a RUN, COPY, the result changes significantly. By that logic you can call every Nix program “imperative”. They are sequences of strings, the order of which matters. The horror! A Docker image is a stack of layers. Every layer points to a preceding layer. It’s not a huge leap from that structure to a fairly elegant sugar of a string array, where each string is a declaration that applies to preceding layer thus describing the next one. I don’t see anything fundamentally imperative about it; it can be used in imperative ways, but anything can.

rgoulter 3y ago
> The alternative is to draw a clear line where there is none. I'd say that more/less "imperative" refers to describing sequences of actions that take place (especially those which might modify some state), whereas "declarative" is more about a structure of what the result should be. I can agree that a Docker image can be considered as a structure, and that it's possible to construct one declaratively. Whereas I'd say a Dockerfile is an imperative construction of that.
- strogonoff 3y ago
  Dockerfile describes a set of immutable layers. Whether you model it in your head as a sequence of commands or as a description of a set of immutable layers, is up to you.

kdmccormick 3y ago

I also would to call Dockerfiles imperative on syntactic grounds alone, but I feel they have decalartive semantics in a way that's noteworthy. > But from the perspective of 'each line of code declares a new program', then we consider the code snippet a declaration of a program. The critical difference is that each line in a Dockerfile yields (declares) a filesystem state which can be referenced and recreated. In contrast, in your example, I have no way to say "give me a snapshot of the system between the third and fourth instructions". Dockerfiles have all sorts of rules and restrictions that make these semantics possible. You cannot create loops; there is nothing like a "function", at least within the context of one Dockerfile. > One of the things which makes Dockerfiles imperative is the sequence of Dockerfile commands is significant; if you swap the order of a COPY, RUN to a RUN, COPY, the result changes significantly. I reject this line of reasoning, simply because decalative languages are indeed order-dependent: let y = f(g(x)) is different than: let x = g(f(x)) Much in the same way that these are different: FROM x AS y RUN g RUN f vs FROM x AS y RUN f RUN g

rgoulter 3y ago
> I reject this line of reasoning, simply because decalative languages are indeed order-dependent Eh, I can kinda see that. -- It's possible to imagine a declaration where the order of items in a list has consequence. Still, I'd Dockerfiles as a sequence of statements more akin to a bash script than to an SQL expression.
- strogonoff 3y ago
  This is a deeply mistaken view informed by the cargo-culting devops traditions of yore. A Dockerfile is a declaration of layers that does not resist being used in imperative way, in which sense it’s no different from YAML or any functional language you can think of.
  - kdmccormick 3y ago
    Yeah, to pile on, I often see this line of thinking: > Still, I'd Dockerfiles as a sequence of statements more akin to a bash script than to an SQL expression. lead to some quite inefficient and poorly-factored Dockerfiles.