Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Donkey code

einarwh.wordpress.com

Post reply on HN
Print view View original

51–60 of 64 posts

Re: Donkey code

#51

Post by still_grokking »

akoboldfrying wrote: post #26
gnulinux wrote: post #8

This is why I'm a big fan of "name it Steve" philosophy. When we create a new service many people are inclined to call it something like "rhombus keyboard fibriculator" or "octatonic runner". Usually it's of the form "{verb}er" or "{noun} {verb}er" or "{adj} {noun} {verb}er" or whatever. It's never accurate, and it's super confusing because chances are there is some other "{x} {y} {verb}er" with the same "verb". Not…

>"name it Steve" philosophy I think of these kinds of names as being like primary key fields in a database: Their main purpose is to distinguish the identities of various things, so it's better not to incorporate any functional/behavioural description into them because that way there's never a need to change the name in the future if the behaviour changes. The downside is that the names become arbitrary lumps of data…

Primary keys in DBs should be natural keys in the first place. You use surrogate keys only to optimize things.

So the whole analogy now points in the exact opposite direction as stated.

Re: Donkey code

#52

Post by still_grokking »

mr_mitm wrote: post #23
gnulinux wrote: post #8

This is why I'm a big fan of "name it Steve" philosophy. When we create a new service many people are inclined to call it something like "rhombus keyboard fibriculator" or "octatonic runner". Usually it's of the form "{verb}er" or "{noun} {verb}er" or "{adj} {noun} {verb}er" or whatever. It's never accurate, and it's super confusing because chances are there is some other "{x} {y} {verb}er" with the same "verb". Not…

In my company we resorted to name many internal tools and libs after birds. It becomes a problem though when you want to publish open source tools or libraries. These days it becomes very hard to find a name that isn't already attached to a Github repo. Finding a name that is googlable, unique, somewhat intuitive and descriptive is a problem that does not scale at all. I'm not surprised the NSA ended up generating na…

Wasn't Eternal Blue a reference to the Windows "blue screen" bug it was based on?

I would guess there are also technical references in the other names.

Re: Donkey code

#53

Post by still_grokking »

aldanor wrote: post #36
xanderlewis wrote: post #27

Earlier quoted context omitted.

You think ‘Galois field’ is better than ‘finite field’?

Both are arguably better than 'potato field'

But GP is actually arguing to call all your things "potato".

Imho that's the worst you could possibly do! Indeed.

Re: Donkey code

#54

Post by mr_mitm »

still_grokking wrote: post #52
mr_mitm wrote: post #23

Earlier quoted context omitted.

In my company we resorted to name many internal tools and libs after birds. It becomes a problem though when you want to publish open source tools or libraries. These days it becomes very hard to find a name that isn't already attached to a Github repo. Finding a name that is googlable, unique, somewhat intuitive and descriptive is a problem that does not scale at all. I'm not surprised the NSA ended up generating na…

Wasn't Eternal Blue a reference to the Windows "blue screen" bug it was based on? I would guess there are also technical references in the other names.

To my knowledge the NSA never commented on this, so where is this information supposed to come from?

Re: Donkey code

#55

Post by Asraelite »

robbles wrote: post #39
gnulinux wrote: post #8

This is why I'm a big fan of "name it Steve" philosophy. When we create a new service many people are inclined to call it something like "rhombus keyboard fibriculator" or "octatonic runner". Usually it's of the form "{verb}er" or "{noun} {verb}er" or "{adj} {noun} {verb}er" or whatever. It's never accurate, and it's super confusing because chances are there is some other "{x} {y} {verb}er" with the same "verb". Not…

I once inherited a codebase that did this, and it was a nightmare to learn. All the classes were named after types of alcohol for some reason. Naming things clearly is really hard, but this approach is just giving up completely.

It needs the right balance. 95%+ of classes absolutely should not do this, but it's great for the handful of times when a class is complex, nuanced, and used prolifically.

Assuming good documentation, it just means a few extra minutes learning what some terms mean, and that's worth it in the long run in my experience.

Re: Donkey code

#56

Post by paulddraper »

gnulinux wrote: post #8

This is why I'm a big fan of "name it Steve" philosophy. When we create a new service many people are inclined to call it something like "rhombus keyboard fibriculator" or "octatonic runner". Usually it's of the form "{verb}er" or "{noun} {verb}er" or "{adj} {noun} {verb}er" or whatever. It's never accurate, and it's super confusing because chances are there is some other "{x} {y} {verb}er" with the same "verb". Not…

This is HN Big Brain approach to the problem of naming things.

Re: Donkey code

#57

Post by karmakaze »

sleet_spotter wrote: post #3
karmakaze wrote: post #2

Besides the naming, the code examples because it uses an ask-then-do-different-things anti-pattern rather than Tell-Dont-Ask which implies defining distinct classes (or property values that define behaviors in the thing itself) rather than strewn across the codebase by interpretation, ie. there was no factoring only use-site decisions. The problem wasn't lack of naming , it was incomplete defining of the thing . If i…

This is a helpful way to think about it. Though, is the problem of having an incomplete definition the same as lacking a unique name? Maybe the solutions are different, and the author points out that made-up names don't cut it. Is it instead more of a catch-22 situation? The other dimension implied here is the timing of when variety is introduced. If all the options were known when the system was originally designed,…

Think about how physicists talk about particles, they can pick any name, rename them but everyone knows what's what because the names are defined by the set of properties not the other way around. If they find distinct sets of properties they want to talk about then they know they need another name.

I ran into this same scenario talking about names for different states of inventory. Every person/company I talked to had different names or meanings of special 'reserved'/set-aside states. I kept telling everyone to define what they mean by that name, list the expected behaviors of it. Then it doesn't matter what anyone calls anything, I can match them up by properties/behaviors or find out they're distinct things.

Things became clear you can't trust names when I saw the formula: on-hand = available + unavailable + committed. Shouldn't available + unavailable form some complete total?

Re: Donkey code

#58

Post by karmakaze »

knallfrosch wrote: post #19
karmakaze wrote: post #2

Besides the naming, the code examples because it uses an ask-then-do-different-things anti-pattern rather than Tell-Dont-Ask which implies defining distinct classes (or property values that define behaviors in the thing itself) rather than strewn across the codebase by interpretation, ie. there was no factoring only use-site decisions. The problem wasn't lack of naming , it was incomplete defining of the thing . If i…

> If it had a definition that everyone agreed upon And there's your problem.

...and the proposed solution is to go about it by listing properties/behaviors/etc rather than agreeing on a set of names and hoping for the best.

Re: Donkey code

#59

Post by karmakaze »

sleet_spotter wrote: post #3
karmakaze wrote: post #2

Besides the naming, the code examples because it uses an ask-then-do-different-things anti-pattern rather than Tell-Dont-Ask which implies defining distinct classes (or property values that define behaviors in the thing itself) rather than strewn across the codebase by interpretation, ie. there was no factoring only use-site decisions. The problem wasn't lack of naming , it was incomplete defining of the thing . If i…

This is a helpful way to think about it. Though, is the problem of having an incomplete definition the same as lacking a unique name? Maybe the solutions are different, and the author points out that made-up names don't cut it. Is it instead more of a catch-22 situation? The other dimension implied here is the timing of when variety is introduced. If all the options were known when the system was originally designed,…

> The solution to this incremental scope problem is a lot less clear to me and something I struggle with personally in scientific computing projects. When variety #2 pops up, how does one decide whether to restructure everything in case of a variety #3, or take the quicker (potentially more efficient) path and avoid unnecessary complexity?

Short-answer rule-of-three (but really it depends).

I get what you mean, but this is more about implementation choices than identification of variety. Varieties can be grouped different ways that makes sense for implementation challenges or development timelines and later refactored to be more effective. The identification of the varieties themselves is distinct from the choice of grouping/implementation. Things that have little effect on behaviors (eg. color only affects one aspect of rendering) can be a property of a thing. More complex/varied characteristics may be better served by separating into distinct things.

Sometimes a 'bag of properties' can serve for all things (similar to JS Object). That's how I believe reddit's data model evolved at one time. I think HN isn't much different as it seems that id's of posts, comments, etc share numbering.

Re: Donkey code

#60

Post by karmakaze »

6510 wrote: post #6
sleet_spotter wrote: post #3

Earlier quoted context omitted.

This is a helpful way to think about it. Though, is the problem of having an incomplete definition the same as lacking a unique name? Maybe the solutions are different, and the author points out that made-up names don't cut it. Is it instead more of a catch-22 situation? The other dimension implied here is the timing of when variety is introduced. If all the options were known when the system was originally designed,…

First you have to make things worse. You just proudly {horse breed: zebra} then {horses breed: sofa} and so on.

I didn't know (or maybe forgot) that zorce and hebra are a-things. Certainly don't know of the sofa kind--google shows me mini-hinny laying cozily.
Post reply on HN