Comment by devjab | Hacker News Reader

Comment by devjab | Hacker News Reader

Parent Full thread

It depends on which parts of software engineering you work in. If you work anywhere where performance matters people tend to know how computers work. If you work in 90% of software engineering you’re likely actively writing code which is terrible from an engineering perspective. Look at how popular things like SOLID and Clean Code in general are. When they are a direct path to horrible performance as you enter the area of L1 cache misses and vtavles on even an extremely simple function. It’s so weird to switch between working close to the hardware and working high above. Especially because Clean Code doesn’t actually seem easier to read or indeed maintain.

As an external examiner for CS students I can’t say I’m surprised. They aren’t taught science anymore, they’re taught practices and patterns, and since nobody knows how a computer actually works or how to write performant code it’s easy for various grifters to sell them nonsense.

I mean, how well would Clean Code, SOLID and to some degree Agile really sell if people knew the key people behind these things haven’t worked in software engineering since 20 years before Python was even invented? Probably not so well.

When they are a direct path to horrible performance as you enter the area of L1 cache misses and vtavles on even an extremely simple function. It’s so weird to switch between working close to the hardware and working high above. Especially because Clean Code doesn’t actually seem easier to read or indeed maintain.

If it's not on the critical path, what difference does it make? Code outside the critical path should be optimizing for something and maintainability is as good as anything.

GP said

> Especially because Clean Code doesn’t actually seem easier to read or indeed maintain

If that is true, then there is indeed no point in applying Clean Code. But I disagree with GP that Clean Code leads automatically to bad performing code. That depends on your language and execution environment. A JVM is very good at effectively removing vtable indirection if they are not needed at runtime.

I'd also argue that even if vtable indirection can't be removed, it's unlikely to be a notable part of your performance profile, at least in the general case. Profile! You might instead see the hasher for your hash table has a much bigger.

I don't think a compiler could ever reliably transpose an array-of-structs representation to a struct-of-arrays one.

There's also other issues with this paradigm, like creating objects out of the arguments to a function. That not only makes your code less maintainable (what if you need a subset of the variables), but now you'll have to drag all that data to each function you create.

Clean code is, IMO, worthless, data- and domain-driven design practices accomplish the goals of clean code better than it the paradigm itself does, and also improve other considerations like correctness and performance.

>I don't think a compiler could ever reliably transpose an array-of-structs representation to a struct-of-arrays one.

An interesting question, but a SoA isn't necessarily better than an AoS: it depends on the access pattern, so the question is whether this optimisation could be added as a part of PGO..

The critical path can often be very wide and long and is not some small for loop deep down. Not all software is a video codec. Maintainability also does not necessarily exclude performance, smaller code can be easier to grasp and fit better into caches.

I’d argue that splitting what is essentially a four line check or default into something like three different functions makes it a lot harder to grasp.

I think my issue with clean code is primarily that it doesn’t actually make code more maintainable. As another poster mentioned, data or domain driven design does the same thing better.

Reply on news.ycombinator.com