Hacker News Reader

Comment by jxramos | Hacker News Reader

"...who firmly believed that the terser your code, the faster it ran. The author crammed multiple side effects into a single expression, used ternary operators like they were going out of style, and generally believed that run time was proportional to the number of semicolons executed, and every variable killed a puppy."

How does one go about countering that mentality in some rule of thumb fashion if at all possible? Could a disassembly illuminate identical push/pop operations on the memory stack as explicit intermediate variables would? Maybe a simple intermediate result expansion timing profile side by side the terse code's profile?

View on HN

I once went to a code review in a very, very large (but now defunct) corporation. The author of the code did not allocation the memory they were writing into. There were 8 people at the code review. I could not convince a single person that writing into unallocated memory was a bad idea. "Allocating the memory would be slow", they countered. "And besides, we've tested it and it doesn't crash".

Sometimes you can help people become better programmers. Sometimes you can't. Try not to stick around in positions where you don't have the ability/opportunity to make a positive contribution, is my best advice.

But assuming that the person is willing to listen to you, all of the above seem like good approaches.

What the hell? Why didn't you just initialize the pointer to NULL and ask them to compile and test?

What memory were they using? How did they get a pointer to it? Perhaps there was reason to believe it would not be used but they had lost that reason to time. For example on many micro controllers you can have the linker reserve space for various things (mapping structures over memory mapped peripherals is common) so maybe the memory they were using was guaranteed to be available somehow. Or perhaps they really were clueless.

Keep in mind that this is more than 20 years ago, so my recollection of the details may be (probably are!) completely wrong. But this is what I recall.

It was an embedded system with a proprietary language. The compiler didn't clear the variables when they were created (again, for performance reasons). For some crazy reason, the language allowed you to declare a pointer without initialising it. So what would happen is that the pointer would end up being whatever happened to be on the stack previously. The reason that it didn't crash in testing was because most of the code in the system was essentially copy and pasted from other parts of the system. As long as the previously run function had a pointer in the same location that happened to allocate some memory in the heap, and then deallocate it, this function would end up using the same memory and it would be fine. And this is exactly what happened in this case (because most of the functions had similar shapes and pointers were declared at the top of the stack frame). The main reason they were reluctant to change the code was because they had copied it from somewhere else and didn't understand how it worked. Because it didn't crash, they didn't want to touch it.

OMG that's insane.

Introduce them to the concept of static single assignment form, and how it is an intermediate form that enables a tonne of downstream optimisations. Most of those "wasteful extra variables" would be introduced by the compiler anyway, so it's not a problem.

Alternatively, just ask them to prove it. If it's faster, they can benchmark before and after, and prove that it's faster? No proof means you're full of shit. This is the Right Answer in that it's what you should be doing anyhow to avoid performance regressions, but it's way more combative and can cause problems within the team, so must be done tactfully.

> If it's faster, they can benchmark before and after

That goes bad very fast. I've worked with someone who tried winning arguments with one-line microbenchmarks; They even tried to convince me that I should always use undefined over null in JS since one is faster than the other (forgot which).

> Introduce them to the concept of static single assignment form

I failed with this as well; some coders don't trust the compiler/runtime at all. I had people tell me that garbage collectors don't deal with cyclic dependencies or that "simple comparisons" (<, >, ==) are faster than "compound comparisons" (<=, >=).

Craziest one I remember from my Java years (long long ago) was someone claiming that returning values by throwing exceptions and catching them to extract the return value was faster than simply returning the value....

This was wrong on a number of levels.

To be fair, they must have been full on bats--t insane.

Oh come on, this is obvious. Thrown things are fast. Anyone who's ever rented a VHS tape from Blockbuster knows that returning something can take days. Of course he's right.

Also, I once worked with who someone who mixed up exit() and C return in a library he wrote....

To be fair, in R on my machine > and < seem to be faster than ==, at least for integers. But the difference is miniscule compared to the overhead of doing just about anything else.

At best the benchmark results will be answered with "the compiler got lucky that time." Someone like that needs to understand the details of the error in their thinking along with multiple benchmark examples proving it.

For some microcomputer basics that was true, as they implemented the 'find that line' part of goto and gosub by a linear search from the start of the program, skipping from line to line.

Having fewer lines, or having the most often called routines at the start of the program would speed up programs, potentially a lot.

Also various constrained environments (calculators and whatnot) where variables were significantly faster to access if they were declared locally than if they were global, or were faster if the name was shorter, etc.

Not to mention the simple fact that, for old interpreted languages, the entire program text had to fit inside memory and so terseness literally saved you working memory.

In CPython, local function calls are still much faster than global function calls.

Similarly, in CPython function-local variables are faster to access than class or module attributes (with the usual bunch of exceptions you always have in Python).

This probably applies to similar languages (like Ruby) as well.

I've seen people recommend shorter names for MongoDB keys for faster querying.

In C64 BASIC, iirc, only the first two characters of the [case-insensitive] variable name mattered - so "vacuum" and "vacation" were the same, since the 'real' variable name was "va"

"Here are our coding guidelines. If you don't like them, the door is over there."

Yes, but what happens when the person in question wrote the guidelines and that's his attitude. Depressingly this is something that happens.

Then it's you who takes said door and starts looking for a more sane place to work at

That doesn't work when you're handed a team of lazy idiots.

Or even someone who is fast and/or good. He just goes and does it whatever way he wants, then because it's done it just stays that way forever.

I think the problem is, to some degree, psychological. While the rational me knows there is very rarely any reason to prefer terseness over clarity of expression, the emotional me still gets a little thrill from one-liners and unconventional solutions (it can sometimes last right up until the point where I have to modify or debug code containing the damn things.)

I think it is a pathological corner-case in an otherwise generally useful interest in, and appreciation of, innovative and economical problem solving.

"Show me a benchmark."

"Show me that this micro optimization is actually needed."

I like both of those and would like to add "Write a working implementation with a sane interface and unit tests first!" :-)

"Make it work, make it right, make it fast".

and then: make it distributed, make it serverless :D

At which point you get to re-do the "make it right, make it fast" steps. :D

It's the programming equivalent of the people who try to put as many complex word in a sentence as possible to look clever.

I met some people who were trying their best to make everything a oneliner because "shorter is better" or whatever reason they had at the time. The real reason I always saw was that it was making the code "hacker-like" (and completly unreadable) and they could brag about how clever they were.

On the flip side, I met people who thought Python list comprehensions were "magic" and should be avoided at all costs

I've met people who have created entire programs out of nested list comprehensions; "they're faster than for loops!". I don't avoid them myself, but you would be hard pressed to convince me to nest them, or do anything that takes more than one line to express.

I think that's called Scheme.

Same goes e.g. for Linq. I know of people who would prefer screen-filling methods of multiple nested loops with throwaway datastructures and various checks sprinkled on top to a simple three-liner Linq expression.

Funnily enough, their argument always seems to be "it's easier to read this, since I'm accustomed to

  for (x;y;z) if (foo ||(bar && baz)) lorem = ipsum;

as a pattern."

I can only imagine they got scared after seeing the SQL performance of Linq to SQL and all Linq to ORM based stuff after that.

Agreed.

But on the other hand I also find that writing code is the same as speaking normal language. We each have our preferences, vocabulary, diction, style etc. I also jumped on the Linq wagon, but cringe when I see for example a Swift etc. reducer. So as long as that person writes his page of code at a decent pace with limited/no bugs I won't hold it against him.

Write a small program that uses a well-established compiler, then "optimize it" with all manner of clever tricks. Look at the assembly produced and you'll find nearly identical machine instructions with even more clever optimizations than you could have imagined.

If wouldn't even discuss this. If that the of code is that performance-critical just implement it in assembler.

IMO it does not necessarily need an assembler implementation, only if that is more clear.

For performance enhancements where code readability suffers big time, I always want /proof/ by comparing the instructions (and some benchmarks help too).

You don't. You reward that developer by allowing them to persue other interests. Or stick them on writing one off tools that will never be customer facing.

Reply on news.ycombinator.com