Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Follow the wormhole through a path of communities !webdev@programming.dev
TLDR:
What the author baptizes "do-nothing scripts" are interactive scripts that print out the steps of some procedure one by one and wait for you to confirm each step (eg. "1. do this. press enter when done" "2. do something else. press enter when done" and so forth).
PS:
@OP (if you are the author)
I HATE those sites where popups come up when you are halfway reading something.
What's the idea behind it, besides annoying your users as much as possible?
They kind of glossed over the real value, which is using it as a template to automate a step at a time:
"Each step of the procedure is now encapsulated in a function, which makes it possible to replace the text in any given step with code that performs the action automatically."
It breaks the work down into more manageable tasks. I probably wouldn't give it to users until it was done, but putting placeholder functions is a common strategy.
Not my site, just sharing a link I saw on HN.
I HATE those sites where popups come up when you are halfway reading something.
Agreed, if I did want to sign up it would be when I've finished, not when I'm trying to read your own bloody content. I often sign up using their own domain with something like sales@ or something ruder. Petty, but it's a small vent. and if one person stops because of it I can die happy.
I have nothing to add except: man's really wrote like 7 classes to just have 1 function each
That is what makes it Enterprise-grade!
Honestly, if they want to go full enterprise at least use the javabeanfactoryfactoryfactory pattern
It's probably to allow for added complexity as they expand on each task. Makes it simpler to import elsewhere too.
"grug try watch patiently as cut points emerge from code and slowly refactor, with code base taking shape over time along with experience. no hard/ fast rule for this: grug know cut point when grug see cut point, just take time to build skill in seeing, patience
sometimes grug go too early and get abstractions wrong, so grug bias towards waiting
big brain developers often not like this at all and invent many abstractions start of project
grug tempted to reach for club and yell “big brain no maintain code! big brain move on next architecture committee leave code for grug deal with!”
Pretty nice way to bridge the gap between documentation and automation.
It’s an interactive checklist.