Live data from Hacker News

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

read.engineerscodex.com

121–130 of 204 posts

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

#121

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…

I've always considered code to be "clever" when its using something in a way it is rarely used, and usually specifically with something very common like an arithmetic operator.

I've seen some really clever code using arithmetic operators to flip variables in ways that look like magic at first. I've also seen, and used myself, a few similar kinds of tricks in JavaScript especially when working with booleans.

I never really considered code "clever" when its just unreadable or incomprehensible. IMO that's just bad code.

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

#122
post #32

Earlier quoted context omitted.

That's terrible! The main operation, addition, is completely hidden magic! But the completely trivial calls to .begin() and .end() are explicit! Why would I want to add by default?

> The main operation, addition, is completely hidden magic the main operation is reduction which is fairly basic computer science and taught in any non-BS curriculum - https://en.wikipedia.org/wiki/Reduction_operator (or https://en.wikipedia.org/wiki/Fold_(higher-order_function) which is the standard way to introduce this concept ; check in particular the table showcasing all the implementations in various languages)…

The reduction is explicit. That's not what the complaint is about. And it's more about implementation than the actual result.

The actual operation is addition. I don't care if it's the first example, that doesn't mean you should hide it.

Imagine if print did hello world by default.

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

#123

Earlier quoted context omitted.

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]

You chose the one example that doesn't need a list comprehension. print(list(range(0, 10, 2)))

Good call.

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

#124
post #54

Earlier quoted context omitted.

This comment makes no sense. You dismissed the C# code, and then wrote the same thing in Rust, but with an extra non-conceptually-meaningful boilerplate step. May as well ask, "where did x come from, and why are you so sure you can iter().sum() it?" C# has generic types, so yes, C# arrays of numbers have a Sum method. https://stackoverflow.com/questions/2419343/how-to-sum-up-an... Don't make bold dismissive comments…

The C# code ends up relying on LINQ, it's interesting how many C# programmers don't even think about that, either anything they work on already uses LINQ or they just reflexively bring it in everywhere they write C# You'll see that a few of those SO comments actually say they're relying on LINQ to make that work. The array type doesn't have such a method itself. So, in reality although many C# programmers will think…

LINQ is just part of .NET standard library along with the very collections we are talking about. I'm not sure why one would care about the distinction.

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

#125

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…

I work with embedded DSPs, and there are certainly points where the maths gets incredibly dense and hard to intuitively parse. Your last point has proven true for me many times. Luckily, with the exception one block of code, the maths is detailed plainly above the implementation. So, while there might be an occasion where I might not fully understand what's going on, I can see where the original author of the code was coming from, and can follow the following code accordingly. Indeed, I believe one of the comment blocks does start with "Here be dragons".

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

#126
post #24

I would argue that what constitutes clever code varies a lot by language. There's always a "cleverness" threshold where being able to read or refactor the code becomes harder, but this threshold isn't universal. Python in particular makes it very easy to be too clever, since its extremely rigid syntax was designed specifically to discourage it, but it ended up giving the user the necessary tools to be clever anyway,…

What would qualify as clever Python? These kind of broad and vague statements make me wonder if I am guilty..

I currently have a dilemma regarding a XML generation code. Should I write it in pure Python with endless nested loops and DOM manipulations. Or should I use a templating engine that is exactly the DSL [:domain specific language] to express declaratively how to generate the output.

Solution 2 is superbly consise and straight to the point, but I am pretty sure noone will ever climb the learning curve that this additional DSL imposes to any newcomer.

I really wonder which final choice I will make for my production code.

[truth is that refactoring solution 2 is painless, but at the same time debugging solution 2 is tricky]

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

#127
post #101

Earlier quoted context omitted.

int sum = 0; for (int i = 0; i Pretty much looks the same in all C-like languages. I've written that in Java, Go, TypeScript, PHP, etc... On the other hand, that second 'clever' example always looks different for every stupid language. It's std::accumulate in C++, streams in Java, list comprehension in python, etc... Clear is better than clever.

> Pretty much looks the same in all C-like languages Because it’s ancient; that doesn’t necessarily make it better or clearer. Look at it like you’ve never seen it before. It has an entire line of boilerplate smack bang in the middle. Sure, your brain filters it out because you’re used to it, but it’s still fugly. And it’s prone to typos/copypaste errors like all boilerplate.

Yes, but it's also not going anywhere.

I don't consider replacing a common loop convention with what amounts to a randomly-generated sentence or two of syntax and letters in each language to be an improvement.

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

#128
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.

If you use C++23's ranges and Boost Lambda and sacrifice your better judgement, you can get it down to:

    fold_left(x, 0, _1 + _2)

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

#129
post #77

Earlier quoted context omitted.

C++98 should be forgotten as a bad dream. C++17 is almost a sane and convenient language (as long as you remember about the boiling depths into which you can fall if you're careless). C++ will live for very long, like Fortran. And also like Fortran, there now must be a serious and uncommon reason to start a new project in it.

Why does one need an uncommon reason to begin development in Fortran?

For instance, the much narrower circle of experts. Usually if you do need Fortran, it means you're going to run numerical code on a huge cluster with RAM in terabytes and cores in the thousands, so the developers you're looking for should understand parallelization very well (and how modern Fortran does it), know words like MPI and Slurm, etc. Beside that, knowledge of the common numerical methods and libraries is expected. This is a relatively unusual setup. Few job listings mention it.

If you just want some highly parallel numerical code, but a GPU with several tens of gigs of RAM would suffice, you just take Numpy, or PyTorch, or other such library, wrapped into Python. You suddenly have a wide circle of developers, plethora of references, and no lower chances to publish in a prestigious journal than if you'd taken Fortran :)

Post reply on HN