Design patterns are algorithms without loops 🤓

Explain yourself...

@beggarboy
it's just that all algorithms depend on a loop and you probably never find an algorithm without a loop.
And design patterns are the same idea as algorithms in that they try to solve a problem but without any loops and just classes.

So they both have this shared core that they build on.

I don't know it might sound stupid but it's stuck in my head the underlying connection between them

You can obfuscate the loops by hiding them behind some iterator shit, which is what design patterns folks are often also fond of because it makes the code even less readable.

Just so you know i havent used a loop in ~5 months

@Fast-Nop
Well same goes for iterators they're still abstract loops and recursion is a loop too

@ganjaman what do you do exactly?

@Fast-Nop would you say a long loop statement full of index juggling and tons of possible errors is more readable than a bunch of chained functions that have clearly defined roles? Also, iterators allow you to hide the data structures behind the implementation, so, for example, you can use the same kind of syntax for both BSTs and vectors. Also it allows the compiler to do things like loop fusion, simple parallelization, and polyhedral reordering. It's the old declarative vs imperative argument, really.

@Hope an algorithm is defined as a finitely terminating series of steps that carry out some computation (or something of the sort). I don't really think design patterns are in any way related to that, they're just meant to rearrange code to make it nicer to work with (and avoid errors etc).

@RememberMe yeah I hate all that stuff that I have to track down a 1000 miles through call trees to find out what's actually going on. Abstraction comes always at this price and is only good if the benefit outweighs the obfuscation cost.

The compiler may eliminate all the useless layers (at the price of ridiculous compile times), but when hunting bugs, I have to go through the whole sewer system - if need be, down to the machine code. With over-abstracted code that some people make, that's sometimes like undressing a mummy.

In layman terms yup!

@Hope functional system programming

Also loops are just numbered gotos

@Fast-Nop I actually agree about over-abstraction, but almost anything is bad if you use too much of it. That's not really an argument against the thing.

And good abstraction prevents large swathes of bugs that you'd otherwise have to spend tons of hours hunting for. (Case in point: iterators and ranges. No more loop range bugs, yay.).

take that back.

@RememberMe I don't remember having loop range bugs, so that's an example of a lot of additional obfuscation for no gain. Where the bugs are, that's misunderstood requirements, missed dependencies on other requirements, or missing cases of requirements.

Range bugs would be most likely when iterating over an enum, and I prevent this by having a NUM_OF_TYPE as last item so that the loop limit will automatically be correct after adding new stuff.

@Fast-Nop haha, don't you see, you've actually just implemented something similar to a range-based for loop, which in this context could be taken as a design pattern. (Calling container.end() on a C++ STL container returns an iterator that does the same thing as your NUM_OF_TYPE)

The C++ equivalent is:

for (auto it = container.begin(); it != container.end(); it++) {
//blah
}

Or, to use the range based syntax that does the same thing:

for (auto item : container/range) {
//Blah
}

Why not just use that and other abstractions instead of implementing them yourself? (I'm not talking about you in particular, I know you are a C person).

Neat trick with enums, though, going to file that one away for when I need to use C, thanks.

@RememberMe Well yeah but that C++ loop is still a for loop.

While thinking about it, a use case where more abstraction really makes sense if you have a loop over a lot of elements that takes very long, but can easily be parallelised, either on the same machine or even across clusters. Then it makes sense to use a language, framework or library that allows you to tuck away that loop including the split/join operations.