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

In praise of –dry-run

henrikwarne.com

Post reply on HN
Print view View original

161–170 of 175 posts

Re: In praise of –dry-run

#161

Post by cake-rusk »

awesome_dude wrote: post #143
cake-rusk wrote: post #95

Earlier quoted context omitted.

> I'm using MVC design patterns for some codebases, I'm using DDD plus Event sourcing and Event Driven for others. All examples of OO nonsense. There is only one pattern you need (functions) (tongue-in-cheek): https://fsharpforfunandprofit.com/fppatterns/ Edit: Also consider using the ELM architecture instead of MVC: https://guide.elm-lang.org/architecture/

I typically reach for Go when I am building things, bubbletea, a TUI library uses the Elm architecture and enforces it on people using it. Did not like, Won't use again. MVC is well understood and works perfectly in my experience. edit: Even though you were tongue in cheek about F# - this stood out on the page > The functional programming community has design patterns and principles as well.

IMO the ELM architecture only works with pure functions. It doesn't work with languages which cannot provide this compile time guarantee. Also functional programming needs a different mindset / training. You won't benefit from it until you understand what it actually brings to the table (and what it leaves out).

Re: In praise of –dry-run

#162

Post by rglynn »

mycall wrote: post #14

I like the opposite too, -commit or -execute as it is assumed running it with defaults is immutable as the dry run, simplifying validation complexity and making the go live explicit.

Agree with this tactic, very useful when working in a team. I use a --dry-run=false approach.

Re: In praise of –dry-run

#163

Post by throwaway290 »

TZubiri wrote: post #145
throwaway290 wrote: post #58

Earlier quoted context omitted.

How do you easily diff what changed between Docker and host?

The way OverlayFS works is that there's a base directory. And then there's an overlay directory that only contains the changes. Docker is based on OverlayFS. There's two main ways overlays are used, first at build time, each line/command generates a new overlay based on the previous base, so when you do something like FROM debian RUN apt-get update it creates a base from the debian image , and then creates an overlay…

Thanks!

Re: In praise of –dry-run

#164

Post by michaelcampbell »

mycall wrote: post #14

I like the opposite too, -commit or -execute as it is assumed running it with defaults is immutable as the dry run, simplifying validation complexity and making the go live explicit.

I have a few shell scripts using `getopts` that have a `-!` flag to make it go; the default is dry-run.

And it's pretty nice. The downside is if you get used to that behavior in things that don't have it the consequences can be bad. (Like the common `alias rm='rm -i'`. No, that's just a trap; don't do it.)

Re: In praise of –dry-run

#165

Post by account42 »

Mawr wrote: post #129
IgorPartola wrote: post #36

Earlier quoted context omitted.

I wouldn’t want most things to work this way: $ rm file.bin $ rm —-commit file.bin $ cat foo.txt > bar.txt $ cat foo.txt | tee —-write-for-real bar.txt $ cp balm.mp3 pow.mp3 $ cp —-i-mean-it balm.mp3 pow.mp3 There is a time and a place for it but it should not be the majority of use cases.

Uhuh: $ rm -rf / rm: it is dangerous to operate recursively on '/' rm: use --no-preserve-root to override this failsafe

That's a special case that is a) easy to call accidentally from a script when variables end up being unset and b) almost never a sensible thing to do.

Re: In praise of –dry-run

#166

Post by mpyne »

dabedee wrote: post #128
mpyne wrote: post #125

Earlier quoted context omitted.

I had the equivalent of --dry-run in my kdecvs-build script from 2003 (where it was called --pretend) so it's not that spontaneous an idea that it must have been dreamed up by an AI. Any time you have a script that needs to run for a long time or might involve destructive actions, having a way to run the script in a "tell me what you would do without actually doing it" mode is a fairly obvious user story to throw in.

Again, it's completely possible that OP and you are the wonderful exceptions (untouched and uninspired by coding agents) that have been using these patterns for as long as you can remember. My comment revolved around the psychological phenomenon, not whether dry-run is a clever/novel idea. It's about how we might tell ourselves stories about the origin of our ideas when working with those tools.

And my point is simply that if it were obvious enough an idea that I thought of it after initially using my tool, you probably will want to look for more realistic examples of where a person thinks they came up with an idea that was really prompted back to them in an AI chat.

This isn't something with surprising nuance like how a McDonald's milkshake serves a non-food "job to be done" during a shopper's morning commute. As evidenced by all the others in this thread pointing out other tools that do similar things, it's a fairly obvious idea to come up with after actually using a new tool.

You'd be more likely to learn about it doing product comparisons of other tools, although since there is a lot of common art for AI training to draw from, yes it is also possible to hear about it from your AI first.

Re: In praise of –dry-run

#167

Post by zbentley »

HackerThemAll wrote: post #117
muvlon wrote: post #84

If you're interacting with stateful systems (which you usually are with this kind of command), --dry-run can still have a race condition. The tool tells you what it would do in the current situation, you take a look and confirm that that's alright. Then you run it again without --dry-run, in a potentially different situation. That's why I prefer Terraform's approach of having a "plan" mode. It doesn't just tell you w…

> That's why I prefer Terraform's approach of having a "plan" mode. It doesn't just tell you what it would do but does so in the form of a plan it can later execute programmatically. Then, if any of the assumptions made during planning have changed, it can abort and roll back. And how do you imagine doing that for the "rm" command?

In my case, I’d use a ZFS snapshot. Many equivalent tools exist on different OSes and filesystems as well.

Re: In praise of –dry-run

#168

Post by sharno »

lelanthran wrote: post #103
nlehuen wrote: post #101

Earlier quoted context omitted.

And just like that, you find yourself implementing a compiler (specs to plan) and a virtual machine (plan to actions)!

> And just like that, you find yourself implementing a compiler (specs to plan) and a virtual machine (plan to actions)! Not just any compiler, but a non-typesafe, ad-hoc, informally specified grammar with a bunch of unspecified or under-specified behaviour. Not sure if we can call this a win :-)

It can be type safe and testable with free monads

Re: In praise of –dry-run

#169

Post by GreenWatermelon »

nstart wrote: post #35
segmondy wrote: post #7

Earlier quoted context omitted.

this is where design patterns come in handy even tho folks roll their eyes at it.

Design patterns are one of those things where you have to go through the full cycle to really use it effectively. It goes through the stages: no patterns. -> Everything must follow the gang of four's patterns!!!! -> omg I can't read code anymore I'm just looking at factories. No more patterns!!! -> Patterns are useful as a response to very specific contexts. I remember being religious about strategy patterns on an ap…

Haha you're describing implementing an ORM! It's essentially that: a unified interface over multiple DB adapters.

Re: In praise of –dry-run

#170

Post by HackerThemAll »

zbentley wrote: post #167
HackerThemAll wrote: post #117

Earlier quoted context omitted.

> That's why I prefer Terraform's approach of having a "plan" mode. It doesn't just tell you what it would do but does so in the form of a plan it can later execute programmatically. Then, if any of the assumptions made during planning have changed, it can abort and roll back. And how do you imagine doing that for the "rm" command?

In my case, I’d use a ZFS snapshot. Many equivalent tools exist on different OSes and filesystems as well.

Really? Should I be snapshotting the volume before every "rm"? Even if it's a part of routine file exchanges between machines? (As it happens for many production lines, especially older ones).

I think the current semantic of "rm" works fine. But I understand the new world where we'll perhaps gonna be deleting single files using Terraform or cluster of machines, or possibly LLMs/AI agents.

Post reply on HN