Live data from Hacker News

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

read.engineerscodex.com

161–170 of 204 posts

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

#161
post #21

Earlier quoted context omitted.

If you think Python is like that, I advise you to never look at Ruby codebase. But seriously, of course you can write Python one-liners or nested comprehensions, but I get the idea that it's not really Pythonic. They still want clear, iterative code. It's just more concise, but the idea is the same, but with less scrolling.

> If you think Python is like that, I advise you to never look at Ruby codebase. Like any other language you can write perfectly expressive and intelligible code in Ruby, and in fact it is quite common to do so. The first layer of a Ruby codebase tends to be approachable, it's only when you get into some of the bigger libraries that you get some tricky metaprogramming. Even then I don't often see Rubyists write trick…

I don't think they're talking about Ruby code golf.

Another way of stating the GP's comment is that a Rubyist looking at a Python codebase will be shocked at all of the verbose boilerplate. Ditto for a Pythonista looking at C++ code.

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

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

In this imaginary example, yes, a False is likely to cause the same issues that None would. But as a sibling comment mentions, it’s not always desirable to drop the explicitness for syntactic sugar.

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

#163
post #146
post #102

Earlier quoted context omitted.

It's not this and there is a test: Judging something assumes at least a minimal level of expertise in both the domain and language. I don't know Ruby, a lot looks obtuse, that's not a sign of clever code. If I see examples like the article in languages I know, it's 'clever code'.

But even then, there's degrees of knowledge and familiarity within that. For example, in Python, is using the `else` block of a for-loop clever? It's a part of the language that I'm familiar with - in principle it's just domain knowledge. But I've worked with plenty of Python devs who've never seen or used that construct before. For them, it's often black magic, and a classic example of "clever" code. The point is th…

Yep. A long time ago I remember using C# delegates to pass methods into a standard error handling wrapper. It's part of the language, but this was before functional programming was part of most OO Devs toolkit. Everyone was completely confused by it.

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

#164

Earlier quoted context omitted.

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…

There is nothing wrong with System.Linq just like there's nothing wrong with Rust's std::iter::Iterator. If anything, this makes writing Rust use the existing muscle memory if you have C# experience and vice versa. The performance profile of LINQ, while much maligned, has been steadily improving over the years and, in the example of Sum itself, you actually do want to use it because it will sum faster than open-coded…

> (I don't understand what you mean by "it won't compile", because it will, in most cases System.Linq namespace is already referenced anyway, either through global usings or at the top of the file)

The "in most cases" is doing all the lifting here. Rust's Iterator is in the prelude. Even if you #![no_std] you get the core prelude which has core::iter::Iterator. You would need to explicitly write code to tell Rust "No, I don't want the prelude" to get rid of it, I'm sure people do that, otherwise it wouldn't be possible, but few enough that I've never seen it.

But in C# there is no such promise. In most (but not all) real world C# projects somebody already brought in LINQ. If you're using a technology that gives you a "ready to go" standard C# project template it undoubtedly folds in LINQ too. But it's not actually provided by the language and that's a meaningful gap.

Notably in several of the playground type tools, since LINQ is not there by default this won't work - like I said it won't compile and it doesn't suggest "Oh you need LINQ" because the C# compiler doesn't provide such suggestions.

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

#165

Kernighan's Law: Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.

Unless you got dumber between writing and debugging, it more likely means that it takes twice as long (or even more if you haven't touched it in a bit). It's unlikely that Kernighan meant it takes someone twice as smart to figure out what you were doing as that would be a nonsensical interpretation (someone twice as smart may not be able to figure out what the stupid person is trying to do in the first place if the c…

Most of the problems I've had to debug the place to look is not clear. Sure I've had to fix "The is not spelled Teh", but most problems are it breaks in some weird situation - step one is figuring out where to even start looking. Once I narrow down the exact place to look it might be easy, but I have to hold a lot of different areas of code in my head while narrowing things down. Even when I narrow it down, sometimes the answer is make the code more complex, and if the code is already on the edge of how complex I can handle I won't know how to make it more complex.

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

#166

Earlier quoted context omitted.

There is nothing wrong with System.Linq just like there's nothing wrong with Rust's std::iter::Iterator. If anything, this makes writing Rust use the existing muscle memory if you have C# experience and vice versa. The performance profile of LINQ, while much maligned, has been steadily improving over the years and, in the example of Sum itself, you actually do want to use it because it will sum faster than open-coded…

> (I don't understand what you mean by "it won't compile", because it will, in most cases System.Linq namespace is already referenced anyway, either through global usings or at the top of the file) The "in most cases" is doing all the lifting here. Rust's Iterator is in the prelude. Even if you #![no_std] you get the core prelude which has core::iter::Iterator. You would need to explicitly write code to tell Rust "No…

It's difficult to talk to someone committed to misreading the replies.

LINQ aka IEnumerable/Iterator methods are usually imported by default, something like with prelude. As others said, they are part of standard library.

I'm not sure what you are arguing against either but whatever your criticism is - it is misplaced as C# and Rust roughly belong to the same Venn diagram of features against commonly held beliefs.

You can test it yourself:

    sudo apt install dotnet-sdk-8.0
    mkdir TestConsole && cd TestConsole
    dotnet new console
And then just paste/echo the following to Program.cs:

    var numbers = Enumerable.Range(0, 10).ToArray();
    var sum = numbers.Sum();
    Console.WriteLine(sum);
This will compile. If that's not enough, then it's likely Rust the language is not for you either and you may want to use something like Go for the time being.

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

#167
post #32
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.

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?

Maybe the idea is that you overload your favored default as a + operator? Even more baffling certainly, but at this point I wouldn’t even be surprised this was considered a compelling argument in the mind of whoever settled this API choice. :D

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

#168
post #147
post #2

Here's an old joke about the progression from junior to mid-level to senior developer: Junior dev: My code is simple, straightforward, and easy to understand. Mid-level dev: My code is clever, innovative, expressive, hyper-optimized, and ingenious. Senior dev: My code is simple, straightforward, and easy to understand. In software development, "clever" solutions are like poems. In the best poems, there are usually mu…

I've seen junior devs write code carefully, putting time and effort into it. The code was ornate and almost too over-commented. mid-level devs become more pragmatic, but can skimp on both elegance and simplicity vs complication. What's interesting is that decent senior dev code sometimes almost looks careless, but really works well in the end. For example, immediately exiting with an error instead of complex error re…

    What's interesting is that decent senior dev code 
    sometimes almost looks careless, but really works 
    well in the end.
I absolutely love this description.

In a lot of ways, YAGNI is what really sets senior code apart. When I was a more junior dev, I thought senior code often looked under-engineered, but in hindsight I realized I was over-engineering things at the time.

    Another thing would be duplicating code instead of doing 
    some complex re-use with complicated conditionals.
God, I wish I could go back in time and burn this into my brain.

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

#169

I’ve been a C++ dev for a couple of decades and know my fair share of unreadable code. I’ve recently started learning Python and holy shit, it’s like you get accolades in this language for doing as much as possible in as few characters as possible. Guess I’m getting too old for these young whippersnappers.

After spending six months with Python so far, the problem with the Python ecosystem is that you have a lot of really smart people (scientists, mathematicians) who are not software engineers by trade writing a lot of these libraries.

I guess it's a good problem to have, in a lot of ways, because it's also why Python has that huge science/datascience/etc ecosystem.

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

#170
post #21

I’ve been a C++ dev for a couple of decades and know my fair share of unreadable code. I’ve recently started learning Python and holy shit, it’s like you get accolades in this language for doing as much as possible in as few characters as possible. Guess I’m getting too old for these young whippersnappers.

If you think Python is like that, I advise you to never look at Ruby codebase. But seriously, of course you can write Python one-liners or nested comprehensions, but I get the idea that it's not really Pythonic. They still want clear, iterative code. It's just more concise, but the idea is the same, but with less scrolling.

    If you think Python is like that, I advise you to 
    never look at Ruby codebase.
The codebase for Ruby itself, or the codebase of your typical Ruby app or library?

I spent about a decade with Ruby and my general impression is that the community really moved away from overly-clever metaprogramming.

The codebase for the Ruby language itself is definitely a challenging read.

Post reply on HN