Hacker News Reader

Comment by dilap | Hacker News Reader

Native english speaker, math major.

This seems really awesome! I feel like descriptive, long variable names have both an advantage and a disadvantage: advantage, obviously, that they're clear, but disadvantage that simply having all that filler text everywhere begins to make the code harder to follow in a serious way. So there's always this tug-of-war between short variable names that make flow easy to follow but require a lot of context or guessing to decipher and long variable names that obscure flow.

Math (and languages like APL, K) are extreme examples of this: as an aid to thinking really hard, they go to extremes of dense notation requiring lots of context/previous to even begin to understand what's going on.

Using Chinese characters in normal code seems like it could fairly painlessly (once you knew Chinese!) get you a lot of the advantages of small-space characters while still encoding a lot more helpful context than a single latin letter.

View on HN

I read Japanese (I think this is Japanese in this case - it just happens to use a subset that is also Chinese - maybe).

This code is definitely easier to parse visually for me. It's really satisfying. As a character set, it is much more information dense, it just requires a lot of upfront study making it less efficient in the short to medium term (~10 years or so).

However, I would hate to work on a codebase like this. It is a key press to switch between input methods (languages), or a key combination on different keyboards.

When combining this with vim I find it incredibly frustrating to type. You have to mentally keep track of which language you are in, as well as which vim mode you are in, 4 options instead of 2. Plus you have to be in English language mode for vim commands to work correctly.

Although it is true that you spend more time reading code than writing code, it would obviously exclude those that don't read Japanese.

It would be a nice-to-have to be able to have Japanese variables only for the reading phase of a project when you are getting up to speed. Then swapping them out for English words when editing. Can't see how it would work in practice and a really limited market too.

But yeah, it's satisfying to look at.

Well, as an emacs user, I guess I could make the jump to two modes to get the benefits... ;)

But in all seriousness, thanks for a very interesting perspective.

I use long variable names all the time and it's never actually made the code harder to follow. You generally parse a whole word as a shape rather than one letter at a time anyway once you know the word, so effectively the only difference is a bit more horizontal space. If someone grew up using whole words as variables in math I doubt they'd find single characters easier to work with.

For programming, using characters not available on a standard QWERTY keyboard is bad international code shareability.

I'll just say this definitely doesn't agree with my experience, though it's certainly the kind of thing that might differ from person to person, brain to brain.

Here's one thought experiment: imagine variables get longer and longer and longer. Clearly, at some point, they become so long that they're much more unwieldy to work with. Now it's just a question of, as they get shorter, when do the gains start to become insignificant?

(Re QWERTY: Ease of input is certainly a consideration, but hardly an insurmountable problem. We should not forever restrict ourselves to basic latin because that's what happens to be printed on many physical keyboards at this moment.)

In the kinds of jobs I've gotten, I spend more time reading code than writing code. As such long variable names are very helpful as I have less information I need to commit into my mental working memory.

It's definitely a trade-off, that's why the idea of ideographic variables is so interesting.

Even when reading code you wrote yourself, long variable names can be immensely helpful.

I was working on some code today which I wrote a couple of months ago and came across some fields in a struct I had made, two of the fields were named like something_d_foo and something_d_bar (with something, foo and bar being strings which I've replaced in this comment). These names describe a relationship of something to foo and bar. When I read the name I had given it, I thought these were the somethings DISCONNECTED from their foos and bars but a comment I had written beside each of them informed me that they were the DEFAULT somethings of the foos and bars. I promptly renamed the fields as something_default_foo and something_default_bar.

I doubt anyone can really parse grails.plugin.searchable.internal.compass.mapping.SearchableGrailsDomainClassCompassClassMapperFactory [1] as a shape.

[1] https://github.com/gpc/searchable/blob/master/src/java/grail...

😱

It does say a lot about what it is

This is obviously code that solves a very real problem.

I think long names are relative. Jokes like these[1] don't come from a vacuum. I've seen serious code with sentence-long variable names before, and it does make it hard for me to read at a glance.

[1] https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...

I bet it'd be fun to just choose characters at random, with reckless disregard for inadvertent meanings downstream.

Somewhere down the line, watching someone read a blog peppered with snippets of your code inducing incongruously deep belly laughs across the gulf of a langage barrier would be fulfilling in its own weird way.

Reply on news.ycombinator.com