Live data from Hacker News

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

read.engineerscodex.com

151–160 of 204 posts

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

#151
post #126

Earlier quoted context omitted.

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 additio…

Can you write functions and classes in Python that roughly mimic the DSL you're aiming for? This is often called an embedded DSL, and it's a great technique for allowing developers to work with domain objects inside a language that they're still familiar with.

There's a handful of templating languages that do this sort of thing using functions, so in Python you might write

    form(
        {"method": "POST"},
        label(
            "Name",
            input({"type": "text"}),
        ),
    )
The learning curve becomes significantly lighter because you're just using Python constructs in the Python language, which means your IDE can suggest functions to you like it would with any other library.

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

#152
post #88
post #63

Earlier quoted context omitted.

You are making a strong evidence-free claim about what JS compilers don't do. https://stackoverflow.com/questions/9981607/array-foreach-ru...

At $WORK we use Mozilla Rhino for some JavaScript processing. We tested the normal loop vs. the clever loop. Performance-wise, the normal loop blew the doors off the clever loop.

Rhino is a very uncommon engine though. It has its niche, but if you're developing for simpler engines like that, then you typically know that in advance and know what considerations you're going to need to make for that.

When it comes to performance, lessons that apply to Rhino are unlikely to apply to more mainstream engines.

EDIT: That's not to say that everyone should use map and forEach all the time, just that your benchmarks are unlikely to be relevant to most JS devs outside of your specific use-case.

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

#153
post #63
post #43

Earlier quoted context omitted.

Same in JS. I once worked with someone who would use [].forEach and didn't like for loops because functional good, iterative loops bad. It was essentially in the coding style of the project and the for version would be rejected in MRs. I don't miss this. IMHO [].forEach just essentially expresses the same thing as a regular for loop, although in a more verbose and convoluted way that is also likely very inefficient b…

You are making a strong evidence-free claim about what JS compilers don't do. https://stackoverflow.com/questions/9981607/array-foreach-ru...

You call "strong claim" something I prefixed with "probably"?

It seems for loops in your link can be slower because .length (a function in disguise) is repeatedly called. I do save .length when writing JS. .length calls has been hard to optimize and it can't hurt too much to cache it at the start of the loop.

Now it's good news if today's engines are able to optimize most of .forEach. The amount of optimization JS engines can do never ceases to amaze me and yes, any performance claim in JS needs to be constantly reviewed and checked at the time it is discussed.

You can't take a "probably" as gospel. Still, it was a bit lazy of me to not re-check, I guess being called out was warranted.

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

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

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.

Just the '++i' instead of 'i++' brought my reading that code to a halt and I had to start deciphering if it actually changes the operation of the loop.

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

#155
Cleverness is found in grokking a system.

A system of simple code is more easily understood. It's easier to move and impress the system at high-level user interfaces.

At what rational scale does the system become clever? How long is a system considered clever and how often? Can you use diff trees to infer high-level logical migration and evolution patterns within the source files themselves?

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

#156

Earlier quoted context omitted.

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…

We've built modern computing on top of encapsulated cleverness . I don't mind clever code, as long as it's a polished gem set into a nice abstraction hiding away the details. Databases have clever code in them. Network stacks have clever code. Heap allocators have clever code. We've built our simple code on top of these. If you need some clever code, write it in the same style: a self-contained library with clean abs…

> Whatever you do, never "weave" clever code through simple business logic!

Oh I love that blog series.

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

#157
post #145

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…

In your first example I think most people would skip the 'is not None' as None is already falsy and drop the extra braces. I find it visually clearer than the second example where the cause and effect are slightly separated, but I do agree there's an element of cleverness to it.

But that would be a mistake if you need the branch to run for other falsely values like 0 or the empty string.

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

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

sum(x) is easiest to read. If your language doesn't provide that as standard just define it yourself. In general you should always be idiomatic, though. If every C++ developer understands the accumulate version then use that.

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

#160

Earlier quoted context omitted.

I don't think it's accurate, though. Junior devs often write overly complicated code because they don't really understand the problem they're trying to solve. Junior devs write unintentionally complex code, mid-level devs write intentionally complex code, senior devs write simple code.

Sometimes seniour devs write complex code but hide the complexity behind a simple interface.

Hiding complexity behind a simple interface is not clever. It's smart.

It's also the facade design pattern.

https://en.wikipedia.org/wiki/Facade_pattern

Post reply on HN