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

61–70 of 81 posts

Re: The plan-execute pattern

#61

Post by lispm »

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.

> 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.

That would be true for source level interpreters, but not for compiled implementations.

Re: The plan-execute pattern

#62

Post by kazinator »

PaulHoule wrote: post #23
kazinator wrote: post #19

Earlier quoted context omitted.

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.

> Most people find somebody else's metaprogramming-heavy Common Lisp difficult to work with.

Citation needed. Org names, projects, numbers.

Also, how easy do people find someone's Java metaprogramming? Where the whole metaprogramming system is locally invented, not just its application to the problem?

Re: The plan-execute pattern

#63

Post by lmm »

trealira wrote: post #52
codeflo wrote: post #35

Earlier quoted context omitted.

Descriptive of the kinds of workarounds that a lack of proper abstraction capabilities made necessary in ancient Java.

I have heard this said, mainly because some patterns can be made unnecessary with first-class functions and pattern matching. Closures are emulated with explicit objects, and the visitor pattern is equivalent to pattern matching. Something that's pretty interesting, though, is that it's a transform called defunctionalization. There's an article about it [1] that has been shared before on HN. One form of defunctionali…

There are definitely cases where a structured value is clearer than a function. But at that point you're just modelling your domain and it's not really a "command pattern" at all. The point of the command pattern is that you have an object that really and truly is just a function, you're only representing it as an object because you need to pass it around - but in that case it really is just a workaround for your language lacking first-class functions.

A good language makes it easy to use both functions-as-values and structured-objects-as-callables, and use whichever representation is appropriate to the situation.

Re: The plan-execute pattern

#64

Post by WhyNotHugo »

I really like this pattern and have been using it in the rewrite for vdirsyncer.

One nice advantage is that an application can show me the whole plan for me to review before executing it. This is basically what terraform did too.

This pattern also makes coding and testing much much easier.

Re: The plan-execute pattern

#65

Post by trealira »

lmm wrote: post #63
trealira wrote: post #52

Earlier quoted context omitted.

I have heard this said, mainly because some patterns can be made unnecessary with first-class functions and pattern matching. Closures are emulated with explicit objects, and the visitor pattern is equivalent to pattern matching. Something that's pretty interesting, though, is that it's a transform called defunctionalization. There's an article about it [1] that has been shared before on HN. One form of defunctionali…

There are definitely cases where a structured value is clearer than a function. But at that point you're just modelling your domain and it's not really a "command pattern" at all. The point of the command pattern is that you have an object that really and truly is just a function, you're only representing it as an object because you need to pass it around - but in that case it really is just a workaround for your lan…

That's a fair point; not having first-class functions is a flaw for a high-level programming language, and the command pattern is just making up for a deficiency in the case that it would never need to be anything more than a closure in a language that does have one.

Re: The plan-execute pattern

#66

Post by klysm »

evmar wrote: post #43

[ninja author] I like how their example is a build system, given Ninja constructs an object literally called "Plan"[1]. However, when I later revisited the design of Ninja I found that removing the separate planning phase better reflected the dynamic nature of how builds end up working out, where you discover information during the build that impacts what work you have planned. See the "Single pass" discussion in my…

Indeed plans get hard when the plan has to be dynamic. Pulumi and terraform have similar troubles.

Re: The plan-execute pattern

#67

Post by qsort »

layer8 wrote: post #60
qsort wrote: post #54

Earlier quoted context omitted.

Neither of them is a fundamental idea about programming in general, unless the only languages we are considering are Java, C#, and Python spoken with a thick Java accent. Adapter is an OOP-ism. If you take, for example, any ML-family language, you won't find anything of the sort. Even staying in OOP-land, in a language where inheritance goes on the prototypal chain, you wouldn't solve the problem like that. Proxy is…

> Adapter is an OOP-ism. If you take, for example, any ML-family language, you won't find anything of the sort. This is incorrect. For example in SML you have signatures and structures, which are roughly analogous to interfaces and implementing classes in OOP. And SML functors are adapters that can adapt a structure of one signature to a different signature. Or they may create a proxy structure for a given structure.…

I would argue that ML functors are significantly more general than Adapter as presented in Design Patterns, the transferable "big idea" being the underlying type theory (functors as high-kindered types) as opposed to the pattern.

> you could easily imagine a derived language where functors are just regular functions and structures are regular values

I'm pretty sure someone taught me this some time ago but I have forgotten it, can you do it that easily? Aren't you at least supposed to make a distinction about types and kinds? I really don't remember, I'm genuinely asking.

Re: The plan-execute pattern

#68

Post by trealira »

PaulHoule wrote: post #23
kazinator wrote: post #19

Earlier quoted context omitted.

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.

Though I've only seen other people's Lisp projects online and in books, I haven't seen metaprogramming that made it less readable - usually, it makes the program more readable. At most, it defines a DSL, e.g. COMFY 6502, which is a thin wrapper over 6502 assembly implemented as a DSL in Emacs Lisp. But most of the time, macros provide a readable interface over a bunch of hard-to-understand boilerplate generated code.

[0]: https://dl.acm.org/doi/pdf/10.1145/270941.270947

Re: The plan-execute pattern

#69

Post by [deleted] »

rmckayfleming wrote: post #13

"I feel uneasy about design patterns. On the one hand, my university class on design patterns revived my interest in programming. On the other hand, I find most patterns in the Gang of Four book to be irrelevant to my daily work; they solve problems that a choice of programming language or paradigm creates." My relationship with design patterns changed when I stopped viewing them as prescriptive and started viewing t…

[deleted]

Re: The plan-execute pattern

#70

Post by [deleted] »

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…

[deleted]
Post reply on HN