Clever code is probably the worst code you could write (2023)

Post by zarathustreal » Wed, May 22, 2024, 1:16 AM UTC

vlovich123 wrote: post #95

a_t48 wrote: post #10

Earlier quoted context omitted.

We now have return std::reduce(x.begin(), x.end()); Which is a little cleaner and is even faster (compiler is free to do the additions in any order). https://en.cppreference.com/w/cpp/algorithm/reduce - it looks like even the `accumulate` example can be made simpler with `std::plus`. I prefer the `reduce` option for a number of reasons, but understand why someone might not.

> and is even faster (compiler is free to do the additions in any order) Is that actually true? I'm not even sure how hypothetically removing ordering requirements would help you extract performance, let alone any compilers that could do anything with that today. Unless the standard library were to auto-parallelize the reduction, but I doubt they'd do that because the overhead of starting threads would be quite costl…

Post by glandium » Wed, May 22, 2024, 1:16 AM UTC

sgarland wrote: post #13

porphyra wrote: post #4

I also find that, in C++, int sum = 0; for (int i = 0; i is a lot easier to understand than return std::accumulate(x.begin(), x.end(), 0, [](int a, b) {return a + b;}); Yet, the latter is considered more correct and better, with static analysis like cppcheck telling you to use the latter. It does have many advantages, like no mutable variables lying around, but gee it is annoying to read.

That is somewhat annoying, yes. I'm a huge fan of Python's list comprehension, but it's generally accepted to be a normal part of the language, and IMO, more readable: print([x for x in range(10) if not x % 2]) [0, 2, 4, 6, 8] vs. l = [] for x in range(10): if not x % 2: l.append(x) print(l) [0, 2, 4, 6, 8]

Post by sgarland » Wed, May 22, 2024, 1:20 AM UTC

knome wrote: post #111

sgarland wrote: post #93

Earlier quoted context omitted.

For a simple example, I think the walrus operator (:=) could be considered clever. I like it, and use it, but the fact that you can declare a variable, store a value in it, and then perform actions depending on its value, all in one line, gives me pause. if (foo := bar()) is not None: baz(foo) Whereas the traditionally accepted Python method of dealing with this would be EAFP: try: foo = bar() baz(foo) except Attribu…

What? Those aren't equivalent at all. Where are you expecting an AttributeError to come from? Why are you comfortable catching them from anything inside of the baz(...) invocation? The traditional method would be to just bind it and check for a null outside the expression. foo = bar() if foo is not None: baz(foo) I don't know why people insisted on pretending binding variables before using them was such a difficulty…

Post by jiggawatts » Wed, May 22, 2024, 1:22 AM UTC

HarHarVeryFunny wrote: post #48

jbandela1 wrote: post #22

I think “clever” is more related to unfamiliarity. There is actually a lot of cleverness going on that people just become familiar with. Structured programming is actually very clever if you think about it. Function calls are, when you look at it closely, very clever. It encapsulates how to jump to a function entry point, how to pass on values in registers or in memory, how to adjust stack pointers, and all other sor…

I think there's a difference between "clever" and complex. You can express a complex algorithm or pattern with simple easy to understand code - complexity doesn't have to manifest itself as unreadable or incomprehensible code. To me "clever" code is more about they way you are doing something than the complexity of what you are trying to do. Clever is the opposite of straightforward and easy to comprehend without a d…

Post by knome » Wed, May 22, 2024, 1:25 AM UTC

nine_k wrote: post #71

porphyra wrote: post #4

I also find that, in C++, int sum = 0; for (int i = 0; i is a lot easier to understand than return std::accumulate(x.begin(), x.end(), 0, [](int a, b) {return a + b;}); Yet, the latter is considered more correct and better, with static analysis like cppcheck telling you to use the latter. It does have many advantages, like no mutable variables lying around, but gee it is annoying to read.

It's mostly the problem of the language, and not of the approach. In a more expressive language you can omit the explicit slicing (x.begin(), x.end()) and have the compiler derive the lambda's signature for you, so you'd write something like reduce(x, (a, b) => a + b), or even fold (+) x, with all the same static analysis and efficient compilation guarantees.