6 ms·
"My dad switched from working with a map printout without knowing real-time conditions, the imperative flow, to Google Maps with turn-by-turn directions, the de
by 0xbadcafebee 4y ago
"My dad switched from working with a map printout without knowing real-time conditions, the imperative flow, to Google Maps with turn-by-turn directions, the declarative flow."
There is no such thing as an imperative or declarative "flow". By its very definition, declarative does not have "flow". It is just a statement. Imperative (in programming) literally means "describing steps that change state". Declarative (in programming) literally means "describing a state which is desired".
Declarative would be "I want a cheeseburger." Imperative would be "Get me a bun, and some lettuce, and tomato, and mayo, and raw meat. Cook the meat on a grill at high heat, flipping half way. Put the mayo on the bottom of the bun, then the meat, then the lettuce, then the tomato, then put on the top of the bun. Give it to me."
It's still strange to me how people learn about "magic words" like declarative and imperative, and then try to ssstttrrreeeeettttttcccccccchhhhhhhhhhh their meaning into some new paradigm that they have just thought up.
There is no such thing as an imperative configuration file. A configuration file describes how a program should be configured. Even when the configuration file "describes a series of steps to change state", it's still declarative, because the configuration file is still declaring to the program how to operate. It's the program that is imperative or declarative, depending on how it interprets and acts on the configuration file. (This is made clearer in programs like Ansible, which, within the exact same configuration file, supports both declarative and imperative statements)
Before you say "what about template files! jinja2! go templates! hcl!", that is merely a DSL, which is no longer a configuration file; it is effectively a program in a crude programming language, interpreted by an interpreter (the program loading the file).
(edit: I agree with the author's point! But I suggest we stop using these terms 'declarative' and 'imperative', and instead say "let's write programs that are functional enough that we don't need to write configuration files that are mini-programs")
- geuis 4y agoVery good breakdown. Couldn't agree more. Except that mayo should go on top.
- 0xbadcafebee 4y agoI don't disagree, but a lot of burgers end up dry, so the bottom bun stays dry and bland, which makes me sad. Sauce on the bottom solves that, and the top bun gets wet from the tomato. Optimizing for the 80% burger.
- jdminhbg 4y agoThe oil in the mayo acts as an aquaphobic barrier between the tomato and the bun. You don't want a "dry" bun but a soggy bun is structurally deficient on top of being bad tasting.
- tzs 4y agoAlton Brown recommends mayo on the bottom to create a barrier to keep the bun from getting soggy from burger juices. But forget about the mayo...regardless of where one stands on proper mayo position there is a much bigger issue with the imperative cheeseburger instructions given: there was no cheese!
- 0xbadcafebee 4y agoI was waiting for someone to catch that bug xD
- WastingMyTime89 4y agoYou are missing the forest for the trees by confusing the end result with its implementation. The idea between having a declarative configuration vs a traditional one is well understood in the context of a machine. In one case, you describe how you want the final machine to look like and let the system decides how to reach that states, in the other you yourself input how the state will be changed step by step to reach the final stage. Sure the declarative configuration really is a DSL and there is an interpreter somewhere turning it into a step by step list of actions but that’s invisible to the end user. It’s not magic just abstracted. That’s the good old Wheeler aphorism: “ There is no problem in computer science that can't be solved using another level of indirection.”
- ClumsyPilot 4y ago> It's still strange to me how people learn about "magic words" like declarative and imperative, and then try to ssstttrrreeeeettttttcccccccchhhhhhhhhhh their meaning into some new paradigm that they have just thought up. Develipera make fun of how project managers call anything Agile without understanding what it means, then go and commit the same sin themselves.
- eternityforest 4y agoThe common meaning of imperative means you tell a computer something step by step. If a config file does that, it's imperative. Declarative in practice usually means that an intelligent solver works backwards from a description of a final state Make a file is imperative. There should be a file here is delarative. Making a file may fail depending on implementation if it already exists. "This file should exist" likely will not because it will do whatever is needed, including nothing, to ensure constraints are met. The best configuration file in my opinion, though, is to keep it trivial, and just have one factory config with very few options. Need to log in and think you need to set a username and password? Linux has that already, lots of apps use the user accounts instead of their own nonsense layer or even directly use SSH as their transport. Need to enable optional modules? Can you just make them enable and disable themselves on demand? Network settings? I hope there's at least the option to just discover everything automatically.
- 1letterunixname 4y agoIf felt as hand-waving as reading that "Clean Code" guy. > Before you say "what about template files! jinja2! go templates! hcl!", that is merely a DSL, which is no longer a configuration file; it is effectively a program in a crude programming language, interpreted by an interpreter (the program loading the file). It will devolve into messy "imperative" code writing "declarative" "configuration"? or whatever using templates, so there's no point in being a purist about The One True Way.
- wruza 4y agoDeclarative would be "I want a cheeseburger." Imperative would be "Get me a bun, and some lettuce, and tomato, and mayo, and raw Is there a reason it couldn’t be “Give me a cheeseburger”? This declarative camp narrative kills me sometimes.
- thriftwy 4y agoMost Java configuration files are a series of method calls laid out in XML or YAML. These are clearly imperative, the bun-and-patty imperative.
- raxxorraxor 4y ago> let's write programs that are functional enough that we don't need to write configuration files that are mini-programs ...or procedural programs while we are at it. I don't disagree with your argument, but the definition can be extended in this use case. If we assume the "configuration" of the software is the target destination. What you can configure imperatively perhaps is in contrast to that what roads to take or not and I believe the term fits reasonably well without it losing precision.
- sly010 4y agoIndeed. Reading SICP should be a requirement for starting a YAML company.
- phailhaus 4y ago> Even when the configuration file "describes a series of steps to change state", it's still declarative, because the configuration file is still declaring to the program how to operate Not sure I buy that logic. With that reasoning, all code is declarative because it's "declaring to the interpreter/compiler" how to operate. I think he's making the same point you did. In one case, the config file is laying out a sequence of steps like you did for how to make a burger (imperative). In the second case, the file just defines the end state (declarative). Sure, you could say that the first case is declarative because the "end state" being defined is pipeline itself. But the point is that we're talking about how to get a burger, not define how to make one.
- lrem 4y agoThis is an important concept in my work. From experience, there is a pretty simple litmus test. It is pretty well understood that the word “imperative" denotes a system where the user describes a series of steps. The system executes the steps, in the end result bringing its universe to a desired state. The user does not need to describe what that is to the system, but a proof of correctness would decide whether that has been reached. Now, a declarative system is one where the user describes the desired end state and invariants on the admissible intermediate states of the universe. The system needs to figure out the current state of the universe, find the difference and find an admissible path to eliminate the difference. The litmus test to discern the two types of systems is whether the system concerns itself with the difference as a primary concept. To give an example familiar to this forum: imagine we’re building a package. This can be set up imperatively with a shell script, or declaratively with GNU Make. Make will figure out which output files are missing or older than their input files, constituting a difference. It will figure out (topological sorting) an admissible path through computing a new up to date file from input files that are already up to date (re their own input files). Now that’s cool and all. But the same end result can be achieved way simpler if you can skip the diffing bit. If you assume you’re doing a clean build, you can order your build steps optimally in a shell script, skipping the now useless complexity. If there has been an abandoned rub that had some successful steps, your shell script will waste their results, but still end in a correct state.
- 4y ago
- taeric 4y ago> There is no such thing as an imperative configuration file My Emacs config would like a word with you. :D
- thfuran 4y ago>There is no such thing as an imperative configuration file. Clearly you haven't seen the gradle files I have been subjected to.
- rising-sky 4y agoI had the same thought when I read that paragraph and anecdotal tortured "lost with map printout" description, immediately thought, not sure this author knows quite what they are talking about, but kept reading to see what the configuration would look like... > ssstttrrreeeeettttttcccccccchhhhhhhhhhh apt
- eurasiantiger 4y ago”There is no such thing as an imperative configuration file.” My babel.config.js would like to disagree.