HN user

jffhn

393 karma
Posts3
Comments164
View on HN

We don't experience the sun going up and down, we experience its direction changing relative to the horizontal plane, and it is not an illusion: it matches planetary motion. The mistake arises when interpreting the raw experience. Sensations don't lie. Another example: Metal feels colder than plastic, but the sensation is right again: you are loosing more heat when touching metal.

Bounded collections still allow for useless reachings of their bounds, and corresponding memory and CPU wastes (and possibly functional/domain issues).

The main reason I saw around me for memory leaks in GC'ed languages, is devs only thinking about the 'add' part, not the 'when-to-remove' part. I always think of both and the only leaks I got were from slowdowns causing events to pile up in scheduler queues (deliberately not bounded).

Do people really argue about variable names?

Of course they do. A program's code is mostly a graph of names; they can be cornerstones of its clarity, or sources of confusion and bugs.

The first thing I do when debugging is ensuring proper names, sometimes that's enough to make the bug obvious.

where each line is extracted into its own method

As John Carmack said: "if a lot of operations are supposed to happen in a sequential fashion, their code should follow sequentially" (https://cbarrete.com/carmack.html).

A single method with a few lines is easy to read, like the processor reading a single cache line, while having to jump around between methods is distracting and slow, like the processor having to read various RAM locations.

Depending on the language you can also have very good reasons to have many lines, for example in Java a method can't return multiple primitive values, so if you want to stick to primitives for performances you inline it and use curly braces to limit the scope of its internals.

I can guarantee you that I have been doing just that for 20 years, creating and working on the same codebase, and that it only got better with time (cleaner code and more robust execution), though more complex because the domain itself did. We would have been stuck in the accidental complexity of messy hacks and their buggy side effects if we had not continuously adapted and improved things.

When I do functional unit tests, they tend to include the same functional logic as the code to test. What I strive for is then to express it in a different and possibly clearer way, and I see the testing as mutual testing of two implementations, one more easily humanly checkable.

Agreed. A program is made of names, these names are of the utmost importance. For understanding, and also for searchability.

I do a lot of code reviews, and one of the main things I ask for, after bug fixes, is renaming things for readers to understand at first read unambiguously and to match the various conventions we use throughout the codebase.

Ex: new dev wrote "updateFoo()" for a method converting a domain thing "foo" from its type in layer "a" to its type in layer "b", so I asked him to use "convertFoo_aToB()" instead.

I only use "TODO" eventually followed by a sub-classification like "TODO bug": it maximizes discoverability by other devs and tools, and allows for a lot of variants (both technical and/or functional) while still permitting a complete scan with a single grep.

Or: the hardware that generates beliefs about how things should be - whether based on religious or ideological dogma -, as opposed to science which is not prescriptive and can only describe how things are.

Domains are often not very deep, as a lot of people need to understand them.

I've seen smart people quickly figure things out and propose upgrades in a matter of weeks, on points lifelong experts overlooked, or were too lazy to dig.

Reminds me of a company that was looking for people good in both the domain and software, to bridge the experts/devs gap (which is often a bottleneck, information flow between brains being slow and unreliable). They found out that it was much easier to teach the domain to devs, than to teach software to domain experts, i.e. that software was the hard skill.

burnout from having to deal with bloated software and the deadlines associated with that

I did not have the deadlines, but to bear having to deal with bloated software, my solution was vodka: since it has no color, I filled mineral water bottles with it and everyone thought I was drinking water.

Jujutsu - I like the name.

I often see programming as going MMA with data, until you get what you want out of it.

Using brute force algorithms is going berserk, vibe coding is spamming summons in hope they get the job done, etc.

My largest source of sanity in this career is to spend extra time at work doing the things that I love in my position. Ironically, I get high performance ratings because of this - but have to fight to spend my time on it.

Why do you have to fight if it's extra time? And couldn't you avoid the fighting by just doing it on regular time?

dozens of crocodiles attacking the soldiers en masse, and appearing out of seemingly nowhere to drag off some poor soul. The nights were said to have been filled with dire screams, gunfire, and the sounds of animal attacks.

Sounds like a metaphor for a team of unknowledgeable developpers stepping into the realm of concurrent code.

the most weird thing they said

Reminds me of a quote from Jean Cocteau, of which I could not find the exact words, but which roughly says that if the public knew what thoughts geniuses can have, it would be more terrified than admiring.

"programs should treat any unrecognized values as if they were “Other”"

Having such an "Other" value does not prevent from considering that the enum is open-ended, and it simplifies a lot all the code that has to deal with potentially invalid or unknown values (no need for a validity flag or null).

That's probably why in DIS (Distributed Interactive Simulation) standard, which defines many enums, all start with OTHER, which has the value zero.

In STANAGs (NATO standards), the value zero is used for NO_STATEMENT, which can also be used when the actual value is in the enum but you can't or don't need to indicate it.

I remember an "architecture astronaut" who claimed that NO_STATEMENT was not a domain value, and removed it from all the enums in its application. That did not last long.

That also reminds me of Philippe Khan (Bordland) having in some presentation the ellipse extend the circle, to add a radius. A scientist said he would do the other way around, and Khan replied: "This is exactly the difference between research and industry".

I believe I'm unsuitable to be a parent, yet everyone around me assured me it would be ok

They might just have said that not to sound alarming, and to close the subject.

You know yourself infinitely better than anyone else does, so if you have even the slightest doubt, you should never rely on others to decide what's best for you.

Be especially wary of people close to you, as proximity increases the belief of knowledge much more easily than actual knowledge.

Reminds me of a Philip Roth quote: "The fact remains that getting people right is not what living is all about anyway. It's getting them wrong that is living, getting them wrong and wrong and wrong and then, on careful reconsideration, getting them wrong again."

any recommendations for a low latency work queue (with in a jvm)?

I toyed around the ring buffer pattern a decade ago, creating a unicast one (using CAS on entries, and eventually a logarithmic scan for next readable entry, not to brute-force-scan them all), but I'm not sure that its latency is much better than that of a regular ThreadPoolExecutor (the throughput could be better though).

Latency also depends on whether it spins or blocks when waiting for a slot to read or write.

If you want to give it a try: https://github.com/jeffhain/jodk/blob/master/src/net/jodk/th...