Comment by tomkwok | Hacker News Reader

Comment by tomkwok | Hacker News Reader

View page source.

  <script>
  $(function () {
  	var 火 = new Firebase("https://hacker-news.firebaseio.com/");
  	var ໆ = "http://news.ycombinator.com/";
  	$("#誤").hide();
  	$("form").submit(function () {
  		火.child("v0/user/" + $("#username").val()).on("value", function(結果) { 
  			var 人 = 結果.val();
  			if (人 && 人.created) {
  				var 時 = new Date(人.created * 1e3);
  				var YYYYMMDDhhmmss = 時.toISOString().slice(0,19).replace(/[-T:]/g,"");
  				var ꜛ = "https://web.archive.org/web/".concat(YYYYMMDDhhmmss, "/", ໆ);
  				$('body').fadeOut();
  				location = ꜛ;
  			} else {
  				$("#誤").show();
  			}
  		});
  		return false;
  	});
  });

  /* ASCII art omitted to save space */
  </script>

Wow, non-latin characters for variable names.

And if you'd like to learn some Chinese, here is the definition of all Chinese characters appeared above.

    火 = fire
    誤 = error / mistake
    時 = time
    結果 = result (a term / expression with figurative meaning)
    果 = fruit
    人 = human / person

---

My pick: 'HNSearch – old HN search engine – will be shut down later today'.

https://news.ycombinator.com/item?id=7404972

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.

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 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 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.

結果 = result (a term / expression with figurative meaning)

https://en.wiktionary.org/wiki/%E7%B5%90%E6%9E%9C

It looks like those characters literally mean "to bear fruit" - and in English, fruit is also used figuratively to mean a result, e.g. "fruits of labour", so I wonder if either English or Chinese was inspired by the other, or if they independently came up with the concept relating fruit and result.

My bet is independently. Spanish also has the same expression and I bet lots of other languages do too.

The Spanish and English dual meaning both comes from latin, so the similarity in other languages with influence from latin does not provide any evidence in support of this idea developing independently (nor does it provide evidence against it).

Looking up the Chinese etymology seems to imply both the Latin and Chinese probably came to have the dual use for the same reason (agriculture leading to equating labour with resulting in fruit/produce), without any obvious direct connection.

Who knows... It does seem a quite logical step for new agricultural societies to make that connection.

Large crop yields = good thing. Seems like a reasonable connection.

Neato! Given that Bemmu live in Japan, I think he intended using the Kanji characters as Japanese characters, although they were originally derived from traditional Chinese (still used in Taiwan).

> I think he intended using the Kanji characters as Japanese characters, although they were originally derived from traditional Chinese (still used in Taiwan).

And in Hong Kong where I live.

I can't read Japanese, so the characters above just happened to retain its meaning after being imported to the Japanese language. I know that many don't.

ໆ = Lao repetition indicator, named 'ko la' (probably pronounced more like 'koh-laa' than 'cola', but quaint anyway. https://en.wiktionary.org/wiki/%E0%BB%86

I heard about http://recursivecharacters.com last week at a lisp meetup. Just an art project, doesn't actually have an evaluator, but the author went to some detail to describe how an evaluator might work.

The entire library in the name of the library? Crazy! How would you input that on the computer when you wanted to reference it, though?

Heh, that's cool :) However, it makes my Firefox crash about a second after the page loads :( I feel a bug report coming on, after checking the latest nightly build...

Latest nightly doesn't show the problem. Go firefox!

Reply on news.ycombinator.com