Hacker News Reader

Comment by EdwardCoffin | Hacker News Reader

I'm partial to this non-jokey take on two hard things:

Phil Karlton famously said there are only two hard things in Computer Science: cache invalidation and naming things. I gather many folks suppose "naming things" is about whether to use camel-case or not, or picking specific symbols we use to name things, which is obviously trivial and mundane. But I always assumed Karlton meant the problem of making references work: the task of relating intension (names and ideas) and extension (things designated) in a reliable way, which is also the same topic as cache invalidation when that's about when to stop the association once invalid.

https://web.archive.org/web/20130805122711/http://lambda-the...

View on HN

While switching to terminology unfamiliar to me (intension vs extension of a word), I never heard anyone misinterpret "naming things being hard" as whether to use camelCase or symbols to use.

It was actually about coming up with short but sufficiently expressive names that greatly improve code legibility, so certainly names that would sufficiently well represent the intent and avoid confusion.

But I am not sure how it relates to "stopping association once invalid"? Is this about renaming things when the names are not suitable anymore? That's only a very special case of "naming is hard", but I do believe naming is hard even when starting from scratch (having seen many a junior engineer come up with what they thought were descriptive names, but which mostly explained how their understanding developed over time and not the synthesised understanding once they had it fully).

ah, ye olde two hard things, namely:

  1) cache invalidation
  2) naming things
  0) off-by-one

Credit where credit is due. https://x.com/secretGeek/status/7269997868

with apologies to Leon, I think I first saw it from Martin (he gives full credit to the sources), so I'll post to link here for completeness:

https://martinfowler.com/bliki/TwoHardThings.html

That's the title link, too.

Note that link credits Leon. (I’d swear I heard this variation much earlier, but maybe I’m totally wrong.)

I like telling it as 3 hard things: caches and naming things.

In the interest of DRY, naming things is hard because when you want to reuse code in a method or library, it should be easy and intuitive to find what you need.

Most, since, many devs name by what it does, rather than how it might be found.

For example naming a function calculateHaversine won't help someone looking for a function that calculates the distance between 2 latlongs unless they know the haversine does that.

Or they default to shortest name. Atan, asin, Pow for example.

At some point you just have to browse the library, and learn conventional names for algorithms.

If you want to synthesize this type of knowledge on the fly because you don't like learning other people's conventions, just feed the docs to chatgpt and ask if there's a function that solves your problem.

This is why a formal education is so important, and why books like "gang of Four" are some sort of standard. They've given a name to some common patterns, allowing a more efficient form of communication and higher level of thinking. Are the patterns actually good? Are the names actually good? That is besides the point.

As counter-inspired by a fellow HNer, the encoding of this problem (cribbed from Dirac/von Neumann, so any inanity is all mine!) ought to be:

  f[<Intension|Extension>] == 0

What are <A|B> and f[C]?

The solution to the problem would reveal their identities :)

Just in case: https://en.wikipedia.org/wiki/Bra%E2%80%93ket_notation#Hermi...

More seriously.. https://en.wikipedia.org/wiki/Binding_(linguistics)

And its derivatives in CS

Etc

I've come to understand 'naning things' to be glossing over many actual difficult things: knowing the concepts you're working with, explicitly, choosing where and when to use abstractions, knowing CS foundational terminology, and maybe the most common not following single responsibility principle. There's many others I'm sure. Failure to name a thing indicates you may not actually know what you're doing or why.

TL:DR "naming things" itself was the joke all along.

I always interpreted the hard part was not looking at something and naming it accurately, but the impossible ask of predicting future use & context (much of it not in your control) and somehow getting that right.

True. We make a best guess and if it turns out to be ineffective, refactor which means to choose a new factor. The other common cause of difficult naming is 'refactoring' without knowing what the new factor is, ie. blind deduplication or along arbitrary seams. My strategy is to delay abstraction if possible until we have an opinion one way or another. Some others like to have clean/abstracted code beyond current understanding.

Not being able to make a good guess is a lack of understanding of problem domain, nicely rolled up into this catch all term.

About naming things, in the computer science world, there is this often repeated saying, as well as countless books and articles about naming things, often contradicting each others. From coding style guides to URL schemes.

But on the other side, there is administration. I work on projects with names like FRPPX21, in category PX23, same idea for tax forms, and just about everything administrative. Should I write code with variable names like that, I would be yelled at by the unfortunate guy who gets to read it.

Reply on news.ycombinator.com