Hacker News Reader

Comment by lmm | Hacker News Reader

I find this kind of exhortation to be useless in practice, because while everyone agrees that code shouldn't be too clever, no-one agrees on what kind of code is being too clever.

For example, I'd argue that using C/C++ at all is probably "too clever" - humans are good at simulating the happy path, but very bad at simulating all the possible different ways such code might actually be executed. But all too often people are seen as smart and rewarded for "using such an efficient low-level language".

Conversely, I'd argue that exposing a business constraint as an algebraic datatype that forces you to use it correctly reduces the cleverness required to understand the code.

But I'm sure there'll be someone here who thinks the exact opposite, and bringing "cleverness" into the conversation doesn't actually bring us any closer to agreement.

View on HN

If building something new, there are good alternatives to C/C++ that end up being more manageable for the human writing it.

That said, if you're stuck with C/C++, there are still many grades of complexity within that that can be tackled. Write boring code, instead of writing something complicated to save a few lines of code.

I think “too clever” often equates to “too short.” There is real intellectual pleasure in figuring out how to express an algorithm in as few lines as possible. I personally love doing this. And, usually, shorter code is better code. But I have seen many cases where people take this too far. People reduce their code so much that it becomes incomprehensible. (No doubt I have been guilty of this.) So to your question of what is “too clever” I would say that I would prefer 10 lines of readable code to 1 line of unreadable code.

"We're not a development shop"

OK, so I've inherited a Single File App with multi-screen a multi screen main() function. I can tell what it's doing at a glance, except that there is a bug report, and something may be wrong.

First instinct "make the problem smaller". But how?

People who put effort into avoiding effort frequently succeed in moving effort.

Yeah, I agree, it's the old complex/complicated conundrum. What's easier: a super compact representation of the problem that uses high-level concepts, or a verbose listing of dumb procedural code? Chances are it depends on both who you ask and the problem at hand.

> Chances are it depends on both who you ask and the problem at hand.

100% this. Code runs on people but people differ dramatically. A more compact solution that leans on some more advanced language features might be totally acceptable in a team of people fluent with the language. The same problem in a team of generalists working across different tech stacks day-to-day might benefit from a more verbose solution.

As with most things in software it depends on context.

Be nice if there was a convenient way to have both.

I once read a HN comment the made an analogy to reading levels in a newspaper or other natural language. I found this very apt.

If you have a rich vocabulary and so does your audience, you can explain an idea succinctly. Imagine a chain of function compositions in one line, very declarative. You grasp it near immediately or else its very difficult.

If you don't, you use simpler words and need more of them. Imagine a few nested for loops in something like Go that you need to execute in your head to realize what's going on, but anyone can figure it out given a little time.

People frequently talk past each other on this topic. It can be very frustrating.

There's something I always thought about but haven't been able to express clearly, and that's about "shared mental models". For example, with Go, the standard library is huge, people tend to not use many libraries, especially ones that change the language, and most people write code the same way. That means that for any two people writing Go code, they share a big part of their mental model about what code should be. That makes it "boring" when one reads the other.

On the opposite end of the spectrum, you could put Scala. There are already a few ways to use Scala as a language: Java with better types, OO all the way, functional all the way. And then there are ecosystems. Zio, cats, Akka. All of that means that for two people writing Scala code, the shared mental model is going to be small unless they use it the exact same way.

You can infer some things from that. Languages with big standard libraries that are somewhat good will allow people to share a bigger part of their mental model compared to languages with bad standard libraries (people will create replacements) or languages with very small standard libraries. Languages with a lot of features that are actually used will have a low amount of shared mental models, but also languages with not many features as people will reimplement things themselves.

Actually, I am a big fan of C++ code. Smart code may cause problems and I agree with that. You know what else causes problems? Tool churn and language churn. At any time of the night and day I very much prefer figuring out somebody elses smart code than figuring out yet another tool that we apparently need. It may not necessarily be that one thing wastes more time than the other but I am 100% sure where my preference is as far as what kind of problem I like to work with.

Doesn't C++ have a lot of churn recently? The transition to C++11, best practices evolving, new features in C++14/17/20?

C++ is notorious for each new version introducing a new way of doing things, so I don't think it's a good anti-churn language (plain C is more defensible for that, though I wouldn't use it for other reasons). And there's certainly tool churn in the C++ world. And frankly C++ has been a poor choice for long enough that I don't think "churn" is a good reason to keep using it - I'm not exactly thrilled when I pick up a TCL codebase from 1996, but you can do it and it'll work.

I'd argue the opposite really, re: 'using C/C++ at all is probably "too clever"'. By using modern C++ features it is possible to enforce a Rust-like model of ownership, without any memory management (eg. we don't use 'new' or 'delete' anywhere in our codebase). This helps reduce what the author calls "complicated, Klein-bottle-wannabe tricks", labyrinthine Java classes of GC goodness where you don't know where the code begins/ends.

> By using modern C++ features it is possible to enforce a Rust-like model of ownership, without any memory management

C++ fans always claim this is possible, but can never say how to determine whether any given codebase follows their rules, or give examples of e.g. popular open-source libraries that follow that approach. So I've stopped believing in it, personally.

> This helps reduce what the author calls "complicated, Klein-bottle-wannabe tricks", labyrinthine Java classes of GC goodness where you don't know where the code begins/ends.

I find that claim extremely dubious. The problems of such code are very rarely due to not having clear directions on any local ownership relationship, and lifetimes are not actually visible in C++ in any case.

Reply on news.ycombinator.com