might be some good points in here but it's sooo hard to read.
The medium is the message though.
The Grug Brained Developer (2022)
71–80 of 603 posts
Re: The Grug Brained Developer (2022)
#72Re: The Grug Brained Developer (2022)
#73> given choice between complexity or one on one against t-rex, grug take t-rex: at least grug see t-rex I think about this line at least once a week
grug obviously never took on invisible t-rex
this grug keeps one on one invisible t-rex, grug cursed
Re: The Grug Brained Developer (2022)
#74[dead]
Re: The Grug Brained Developer (2022)
#75This has by far the best discussion of the visitor pattern I've yet to come across.
I don't work in typical OO codebases, so I wasn't aware of what the visitor pattern even is. But there's an _excellent_ book about building an interpreter (and vm) "crafting interpreters". It has a section where it uses the visitor pattern. https://craftinginterpreters.com/representing-code.html#the-... I remember reading through it and not understanding why it had to be this complicated and then just used a tagged u…
I love crafting interpreters and mention it on grugbrain:
https://grugbrain.dev/#grug-on-parsing
but the visitor pattern is nearly always a bad idea IMO: you should just encode the operation in the tree if you control it or create a recursive function that manually dispatches on the argument type if you don't
Re: The Grug Brained Developer (2022)
#76Earlier quoted context omitted.
I keep trying to explain this to tiny dev teams (1-2 people) that will cheerfully take a trivial web app with maybe five forms and split it up into “microservices” that share a database, an API Management layer, a queue for batch jobs to process “huge” volumes (megabytes) of data, an email notification system, an observablity platform (bespoke!) and then… and then… turn the trivial web forms into a SPA app because “t…
>I keep trying to explain this to tiny dev teams I'm curious what role you have where you're doing this repeatedly
The customer is a government department formed by the merger of a bunch of only vaguely related agencies. They have “inherited” dozens of developers from these mergers, maybe over a hundred if you count the random foreign outsourcers. As you can imagine there’s no consistency or organisational structure because it wasn’t built up as a cohesive team from the beginning.
The agencies are similarly uncoordinated and will pick up their metaphorical credit card and just throw it at random small dev teams, internally, external, or a mix.
Those people will happily take the credit! The money just… disappears. It’s like a magic trick, or one of those street urchins that rips you off when you’re on holiday in some backwards part of the world like Paris.
I get brought in as “the cloud consultant” for a week or two at the end to deploy the latest ball of mud with live wires sticking out of it to production.
This invariably becomes an argument because the ball of mud the street urchins have sold to the customer is not fit for… anything… certainly not for handling PII or money, but they spent the budget and the status reports were all green ticks for years.
Fundamentally, the issue is that they're "going into the cloud" with platform as a service, IaC, and everything, but at some level they don't fully grok what that means and the type of oversight required to make that work at a reasonable cost.
"But the nice sales person from Microsoft assured me the cloud is cheaper!"
Re: The Grug Brained Developer (2022)
#77This has by far the best discussion of the visitor pattern I've yet to come across.
I care about naming, and I find the name of the visitor pattern infuriatingly bad. Very clubbable. I think I have never created one called "Visitor" in my life.
Given the syntax tree example from Wikipedia, I think I'd call it AstWalker, AstItem::dispatch(AstWalker) and AstWalker::process(AstItem) instead of Visitor, AstItem::accept(AstVisitor) and AstVisitor::visit(AstItem).
"The walker walks the AST, each items sends it to the next ones, and the walker processes them". That means something. "The visitor visits the AST items, which accept it" means basically nothing. It's more general, but also contains very little useful information. So the visitor might need different names in different situations. Fine. Just add a comment "visitor pattern" for recognizability.
I remember a situation where I needed to walk two object trees for a data comparison and import operation. I created an AbstractImporter that walked the two trees in lockstep in a guaranteed order and invoked virtual methods for each difference. It had a non-virtual doImport() for the ordered data walk, and doImport() called virtual methods like importUserAccount(), importUserAccountGrouMemberships() etc. There were two subclasses of AbstractImporter: ImportAnalyzer collected differences to display them, then there was a selection step implemented by a kind of list model + a bit of controller logic, then an ImportWorker to make the selected changes. All rather specific terminology and not exactly the visitor pattern.
Re: The Grug Brained Developer (2022)
#78Content 1, Style 0 Thinking you are too smart leads to all sorts of trouble, like using C++ and being proud of it. If you think your intelligence is a limited resource however you'll conserve it and not waste it on tools, process and the wrong sort of design.
C++ called and filed a complaint about receiving a haymaker of a suckerpunch out of nowhere.
Honestly, burn.
Re: The Grug Brained Developer (2022)
#79Earlier quoted context omitted.
Being at a firm where the decision to use C++ was made, the thought process went something like this: "We're going to need to fit parts of this into very constrained architectures." "Right, so we need a language that compiles directly to machine code with no runtime interpretation." "Which one should we use?" "What about Rust?" "I know zero Rust developers." "What about C++?" "I know twenty C++ developers and am conf…
How does someone know twenty C++ developers and zero C developers though?
Born in the 80s.
Re: The Grug Brained Developer (2022)
#80Earlier quoted context omitted.
htmx sucks: https://htmx.org/essays/htmx-sucks/
well, at least he is (you are?) consistent in this style of criticizing others' ideas with satirical sarcasm fueled prose focused on tearing down straw men.
exactly!
get the mug!