Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The plan-execute pattern

mmapped.blog

Post reply on HN
Print view View original

21–30 of 81 posts

Re: The plan-execute pattern

#21

Post by trealira »

hollerith wrote: post #7
Spivak wrote: post #5

Earlier quoted context omitted.

> Scheme isn’t special because it has closures, it is special because you can write functions that write functions. I swear this informational parasite will never die, any language with eval can write functions that write functions. What makes Scheme and other homoiconic languages special is that the code that is currently executing can be manipulated live like any other data structure and it works.

>What makes Scheme and other homoiconic languages special is that the code that is currently executing can be manipulated live like any other data structure I think I know Scheme well, and I don't catch your meaning. Most Scheme implementations are compilers that output a machine-language executable. How can this executable be "manipulated live" in a way that differs from an executable produced by any other language?…

> the code that is currently executing can be manipulated live

Typically when people say this about Lisp, they mean that they can redefine functions and objects live, having all the code adapt to use the new definitions, or when their code hits an error, they can not only redefine functions and objects live, but also examine the state of the call stack and change the values of variables live, and then let the code run again. This[0] is a clear explanation that I found. There's also a video[1] that shows the same thing.

However, I don't know if those apply to Scheme. Also, I am pretty sure it is unrelated to Lisp being homoiconic, and that it's more about it being dynamically typed and interpretable.

[0]: https://malisper.me/debugging-lisp-part-1-recompilation/

[1]: https://youtu.be/jBBS4FeY7XM

Re: The plan-execute pattern

#22

Post by DougBTX »

JohnMakin wrote: post #17

This is a similar pattern to Terraform, correct? (Plan/Apply). I like this pattern, however, when implementing it into automation it presents a conundrum. Often, code will be checked into a repository with a "plan" attached to it. Great. Merge after plan is approved, then automation executes the plan. However, lots of providers will only show errors on the "execute" phase (e.g., on apply, "resource already exists" er…

I’d recommend testing the Apply step in a staging environment before rolling out.

For releases, the plans don’t need to be committed to version control. Instead they can be generated in CI just before release, then put reviewing the plan on the checklist before confirming the release to prod.

Re: The plan-execute pattern

#23

Post by PaulHoule »

kazinator wrote: post #19
PaulHoule wrote: post #14

Earlier quoted context omitted.

How about monkey patching in languages like Javascript and Python? I'd also say "homoiconic" is a less important concept than people would think. A while back I was writing a lodash-like library for Java because I don't like the Streams API (though in the end I just used the collectors from the Stream API because they were easy to fit into my system) One thing I found frustrating about that was that I didn't want to…

Now suppose three of you are working on the same project, and each brings their own code generator like this. You can take Common Lisp macros from multiple sources and use them in the same expression, in any pattern of nesting.

In principle. Most people find somebody else's metaprogramming-heavy Common Lisp difficult to work with. When you look at classic programs from the golden age of AI you find they either rewrote their Lisp prototype in C++ for speed or the Lisp program (like an expert system shell) is much smaller than you imagine possible but it looks like the engine of a UFO.

Re: The plan-execute pattern

#24

Post by bradleybuda »

I use this pattern a lot (and I often find myself wishing I used it more). Another way to think about this is "noun-ification" (aka the Command pattern) - instead of invoking a function directly, capture all of its arguments, serialize them to some "store", then provide the ability to rehydrate them and actually run it.

Re: The plan-execute pattern

#25

Post by andai »

Spivak wrote: post #5
PaulHoule wrote: post #2

There are a wide range of “patterns” that derive from compilers that are the higher teachings behind functional programming and OO patterns. People don’t usually call them patterns. (Scheme isn’t special because it has closures, it is special because you can write functions that write functions.) Reminds me of a thread a few days back when someone was talking about state machines as if they were obscure. At a systems…

> Scheme isn’t special because it has closures, it is special because you can write functions that write functions. I swear this informational parasite will never die, any language with eval can write functions that write functions. What makes Scheme and other homoiconic languages special is that the code that is currently executing can be manipulated live like any other data structure and it works.

>code that is currently executing can be manipulated live like any other data structure and it works.

I heard from someone who did this with x86(-64?) assembly in production code, but I don't know the details.

Re: The plan-execute pattern

#26

Post by tomberek »

This is an excellent pattern. Nix uses it to allow one to create a full transitive build graph, serialized that plan, move it around, and execute it in a distributed and reproducible fashion.

There are always temptations to loosen the constraints this imposes, but they nearly always come at a cost of undermining the value of the pattern.

Re: The plan-execute pattern

#27

Post by caseyohara »

bradleybuda wrote: post #24

I use this pattern a lot (and I often find myself wishing I used it more). Another way to think about this is "noun-ification" (aka the Command pattern) - instead of invoking a function directly, capture all of its arguments, serialize them to some "store", then provide the ability to rehydrate them and actually run it.

Interesting you used the term hydrate because I only hear that used when talking about front-end web development (specifically Next and React) and it's a relatively new term. The "Hydration (web development)" Wikipedia article was only created in December 2020. https://en.wikipedia.org/wiki/Hydration_(web_development)

I feel like serialize/deserialize or marshal/demarshal are more common in broader computer science contexts.

Re: The plan-execute pattern

#29

Post by jkaptur »

> I feel uneasy about design patterns. ... they solve problems that a choice of programming language or paradigm creates.

I don't understand the ambivalence. I have to make some choice of language and paradigm, and then I have to solve problems using it.

Great article and description of the plan-execute pattern, though!

Re: The plan-execute pattern

#30

Post by rnubel »

JohnMakin wrote: post #17

This is a similar pattern to Terraform, correct? (Plan/Apply). I like this pattern, however, when implementing it into automation it presents a conundrum. Often, code will be checked into a repository with a "plan" attached to it. Great. Merge after plan is approved, then automation executes the plan. However, lots of providers will only show errors on the "execute" phase (e.g., on apply, "resource already exists" er…

It's more manageable to have automation (i.e., Atlantis) do the apply on the open PR and then only merge if it succeeds. You have to rely on the locking feature of Atlantis to avoid conflicts, but it's worked pretty well at scale at Enova (~50 Terraform changes a day).
Post reply on HN