Hacker News Reader

Comment by magicalhippo | Hacker News Reader

Nice list. I would add, near the top, "don't be clever unless it makes the code significantly easier to read for others".

For example, if your code involves a lot of linear algebra, then operator overloading the sensible operators is probably a good thing. But don't use operator overloading just to save some keystrokes.

Over-abstraction is another such case. Try to avoid adding abstraction layers until you need them.

I'd also add "make the code as self-documenting as possible". That means being verbose at the right times, such as writing meaningful identifier names.

And of course "avoid global variables". I've seen people use singletons with a read/write member, which is as much a global variable as any other.

View on HN

Yes, "avoid global variables".

I forgot to write that one. In fact, I'd say, try to write everything as stateless as possible. That means no shared variables, functional style programming whenever possible (and logical, not for the sake of it).

Debugging a code base with global variables vs. passing what it needs is far easier to reason about when reading the code, but also easier to write tests for. Very good point.

State is evil, but of course you need some otherwise your software doesn't do anything real.

> no shared variables, functional style programming whenever possible

One problem is that saying to write in a "functional style" is not a reliable way to communicate intent today. You must qualify it with an explanation that includes/emphasizes the "no shared variables" part. Otherwise it's ambiguous, because it's not uncommon to come across programmers who make heavy (over)use of closures and refer to it as functional. It's the "literally" vs "figuratively" of the programming world; people say one thing that turns out to be the exact opposite of what it means. This should be called PF ("pseudo-functional") to contrast it with FP (what you're talking about).

We love to hate state, but isn't caching data the key to performance at scale?

> We love to hate state, but isn't caching data the key to performance at scale?

It seems you're mixing things up. "State" in this context doesn't mean caching results. "State" in this case means that your code has internal state that you can't control, thus your components behave unpredictably depending on factors you can't control.

Picking up your caching example, what would you say if your HTTP cache either returned your main page or some random noise in an apparently random way, even though you're always requesting the exact same URL?

You may be correct vis-a-vis OP, but I'll stick to my guns as far as 'state' being any piece of information that has to managed.

If I'm not writing pure functions, then there is some piece of information whose lifecycle suddenly requires care and feeding, especially if there are environmental factors making that state more 'interesting' than the code in view.

The advice is that state is hard to deal with, so you should try to isolate it from the rest of your program. You can even organize stateful components like a cache to isolate the stateful components.

- Make your stateful components "dumb". The cache should just have dumb put,get,delete methods.

- Make your "smart" components stateless. Your component deciding which items to cache or remove or invalidate should be passed all the state they need to make their decisions as immutable parameters. This will make your lifecycle management code much easier to test or log.

- Keep the part gluing the dumb state and the smart functions small

In the end you still have a stateful component, but as a whole it should be easier to work with. For example, it's much easier to test time-based lifecycle decisions if you pass in the current time than if the component grabs the current time from your system clock.

Programming maxims inevitably get compromised by the real world. We just try to do our best.

Using a cache (short of the language tools doing automatic memoization, or memoization hints on a function or procedure maybe) before making the code correct but slow is one of the greatest hallmarks of premature optimization. Remember Knuth said "less than 4 percent of a program typically accounts for more than half of its running time".

Write some simple code that does the thing. Then debug it. Then profile it. Then swap out for some more efficient algorithms if necessary in the hotspots. Then look at microoptimizations. In any case, don't spend more time optimizing that it will save in runtime across the lifecycle of the code.

Typically caching is not supposed to affect correctness, 'only' performance behavior.

hey seriously, i've been grappling with this: what better candidate to be a global variable than a shared cache that otherwise has to be passed through dozens of function calls (which imo adds cognitive load at many places through the stack).

I don't think passing state through functions calls add cognitive load: it just make it visible. Global state has the same cognitive load, except hidden.

If a state is passed through dozens of function calls, this may indicate that it is shared by too many parts of the code, or that it is managed at the wrong layer of the architecture. When using global state, these potential problems are difficult to spot.

> (...) which imo adds cognitive load (...)

Choosing to ignore input data does not reduce cognitive load. You are not supposed to ignore the core function of your work, and call it a good practice.

It's also famously one of the hard problems.

> For example, if your code involves a lot of linear algebra, then operator overloading the sensible operators is probably a good thing.

Operator overloading can be totally useless in linear algebra applications as the algorithms for basic linear algebra operations (read BLAS) aggregate multiple algebraic operations (axpy, gemv,gemm).

True. I was thinking mostly about things like 3d renderers and such, where you do a lot of simple operations on vectors and matrices.

I've written renderers with both operator overloading and without, and the readability of the former is, to me, vastly better.

grug write clever code once, grug need to be clever every day forever.

grug write readable code instead. readable code maybe need clever now, but no need clever in future

Reply on news.ycombinator.com