[bb88]

> Every rule can be used to argue anything.

Unless it's a rule prohibiting complexity by removing technologies. Here's a set of rules I have in my head.

1. No multithreading. (See Mozilla's "You must be this high" sign)

2. No visitor pattern. (See grug oriented development)

3. No observer pattern. (See django when signals need to run in a particular order)

4. No custom DSL's. (I need to add a new operator, damnit, and I can't parse your badly written LALR(1) schema).

5. No XML. (Fight me, I have battle scars.)

[ferguess_k]

> 2. No visitor pattern. (See grug oriented development)

This one is my particular pet-peeve. But I often think that the reason is because I suck. I'm going to read "grug".

I also hate one-liner functions.

[bb88]

The real geniuses of our times can convert complexity into simplicity. The subgeniuses use complexity to flex over the common developer.

Sometimes things need to be complex -- well that's okay. The real trick is to not put complexity into places it doesn't belong.

[chanux]

Complexity has to live somewhere. The genius is in putting in places that make things manageable, I guess.

https://ferd.ca/complexity-has-to-live-somewhere.html

[cyberax]

Visitor pattern is extremely useful in some areas, such as compiler development.

[brabel]

That’s only true in languages that do not have Algebraic Data Types and pattern matching, which nowadays is a minority of languages (even Java has it).

[cyberax]

Visitors additionally allow you to decouple graph traversal from the processing. It is still needed even in the languages with pattern matching.

There's also the question of exhaustiveness checking. With visitors, you can typically opt-in to either checking that you handle everything. Or use the default no-ops for anything that you're not interested in.

So if you look at compilers for languages with pattern matching (e.g. Rust), you still see... visitors! E.g.: https://github.com/rust-lang/rust/blob/64a99db105f45ea330473...

[brabel]

The example you posted is very interesting as it used both a visitor and ADTs. It seems the need for the Visitor comes from the generics in this case? Probably a Rust specific limitation. I don’t understand why you mention exhaustiveness though, it’s obviously easy have comprehensive or partial matching with ADT.

[cyberax]

No. The code can be rewritten without visitors using iterators for traversal, for example). But it'll look badly.

Visitors in the linked example are real classic visitors. The code _within_ the visitor methods, of course, uses pattern matching, but the pattern itself is not materially different from C++.

Exhaustiveness checking for pattern matching is also "best effort" for complex matching.