How many man years are wasted with western naming convensions?(games.greggman.com) |
How many man years are wasted with western naming convensions?(games.greggman.com) |
None if you use sanename.org conventions.
The article does not provide an alternative solution, or a discussion of the upsides of different naming conventions (e.g. knowing that ALL_CAPS is almost surely a compile-time constant). "How many man years are wasted..." - compared to what?
I'm sure you know this, but for readers who aren't familiar with Japanese, it might be worth saying that hiragana, katakana and kanji aren't strictly interchangeable. Sure you can use hiragana and katakana as a fallback when you cannot or don't want to use the kanji for various reasons, but normally in every situation there's a recommended script to use in order to write correct Japanese.
Some contexts might call for all hiragana variables, some all katakana, and some using the most likely/appropriate form of the word, including kanji. And in the third case, you’re still going to end up with discrepancies since not everyone agrees on when to use kanji.
I fail to see how the fact that the Latin alphabet has upper and lower case is to blame for this. This is more about the coding standards the author has to abide to than anything else.
If your coding standard would require you to name the property MMAXTEXTURESIZE instead of mMaxTextureSize, would there be any less busy work?
Notice all this busy work
Also is author pushing for everyone should follow one standard? Hard to say what he is asking for.
And yes, all this can be fixed by using a context aware IDE, but so can OP's original problem.
[1] https://www.joelonsoftware.com/2005/05/11/making-wrong-code-...
If I write a sentence in ALL CAPS, I’M YELLING AT YOU. if i write a sentence in lowercase i am maybe laid back or aloof.
A sentence written in all hiragana might represent a toddler speaking. A sentence written in all katakana might represent a foreigner speaking broken Japanese (ouch!).
Usually, hiragana is used for grammatical purposes, such as particles and conjugations. But for some reason, laws and contracts use katakana instead. In a hypothetical Japanese programming language, which one should they pick? In university I had to learn this strange language called Doolittle[1] which uses Japanese but dodges the grammar particle issue by using spaces and symbols, which I found to be terribly confusing. I would love to see an attempt at a Japanese programming language that is closer to how the spoken language works.
This only scratches the surface. There are even more ways to represent arbitrary syllables, such as with arbitrary kanji (ateji) or even more complex systems like Kanbun. And of course there are many levels of simplification and variation within Chinese characters.
My point is that I don’t think this is inherently a Western thing, even if it ended up that way. It’s interesting to ponder how a non-Western language’s programming conventions could look like. Sometimes it’s even a real issue: see languages like Go where uppercase is semantically meaningful and therefore it is impossible to export Eastern symbols.
[1]: https://en.wikipedia.org/wiki/Dolittle_(programming_language...
All in all, the upper/lower case problem does not seem to be that much of a waste of man-years.
Right, because that's the difficult part. Memorizing 100 alphabets is significantly easier than memorizing the relevant Chinese characters. The syllabaries are zero percent of the difficulty of learning to read Japanese.
Eh? What context-dependent-shape-changing are you referring to? Hindi has a very normal alphabet. There are vowels, consonants, and a bunch of special ligatures for some combinations of those that are technically optional and could be done without. Nothing changes according to "context".
My bad, I thought those were mandatory.
In reality the ask is maybe: let us use 25 characters english without uppercase? Which we have in Basic and dozens of old style programming language however typically upper case.
Research has shown that the lowest hanging fruit in programming language design would be to make names case-insensitive - allowing you to have two variables that differ only in case causes far more problems than it solves. But, programming being a pop culture, no-one dares.
Then codgen tools work properly.
By the way, Arabic has 4 letter forms, Japanese has 3 sets of characters, Chinese has 2 character forms, Vietnamese and some other romanized Asian languages have many diacritics (for the tones) which change the meaning of words,... Latin alphabet as it is used in English is by far the simplest of all (to use, teach or learn).
basic vocabulary such as time/test/thread/doc/… might be used along with Pinyin as well, so you will see things like dingdan_time, testJieguo, as a Chinese myself, I found this really hard to understand without a broader context since Chinese is a tonal language..
You could avoid stuff like get/set, but that's pretty low-hanging fruit compared to the explosion of things when you have 3 components referencing from top to bottom, each with a 8+ character variable. Preserving context is expensive in writing and reading. Assuming the reader has a shared context is required to shorten many things, however. This can backfire and make things worse than writing things fully.
Example, you could shorten mMaxTextureSize to maxSize or maxTexture or something. It entirely depends on what the reader knows coming in and what other variables exist or may exist in the future. In the other example, "getCurrentContext()->getLimits()" could be shortened to "Context()->Limits()" assuming there is only context property available is the current one. In both examples, I have to make assumptions on what the reader knows and both the existing and future code which, as mentioned before, can backfire completely.
Koreans use sillabic bigrams, in the west we use mostly letters in a handful of variation per country and two main alphabet (how many remember that in Europe we have various letters not only in Cyrillic and it's national variations? Like þ, Ð, ȝ, ...), Japanese have even three alphabets (hiragana, katakana and kanji) often mixed for kanji reading aids, ... we have invented the concept of International Auxiliary Languages, with their alphabets, the most well-known is Esperanto but they never took off because pushing their own language give advantage to the successful push-er and so a war at a time we see winners and looser...
Computer time does not count much in that game.
And then there is the hyphen in CSS for example background-color which in js is backgroundColor. (Colour spelt wrong to me in both cases!)
As much as I like Go, I really dislike the use of upper case to make things public. About the only thing I miss about Java is the convention of using capitalised words for types and lowercase for fields, methods and variables.
I must hit a name conflict in Go every second week.
number-input-wrapper { background-color: goldenrod; }
Oh, and whoever uses lower case snake case in any circumstance needs a slap on the wrist IMO.
I suppose they could design programming languages using the Chinese alphabet (maybe they already have? I wouldn't know) that use different conventions[0].
[0] Convention is with a 't', by the way.
The Latin alphabet is used as a stepping stone towards learning how to write, and as an input method for computers and phones (you type the pronunciation of the character you want to write, and then select from a list of characters that are homophones).
For what it's worth, we've had quite a few languages that only used upper case. Off the top of my head, FORTRAN or COBOL, but I believe it was pretty much the standard up until a point. Was it beneficial? Was there a detectable drop in productivity among programmers of Japanese/Korean/... origin once this trend reverted, and case-sensitive languages took over?
The article offers some food for thought, but objectively it does a better job riding the wave of current intellectual climate (inadvertently, perhaps) than producing a convincing argument in favor of the hypothesis.
The distinction began as a mixing of different writing styles (called “hands” in calligraphy), something similar to how we today will mix fonts in a document.
“Lower case” was the newer, more common font. (What wed today call uncial or Carolingian)
“Upper case” was a font based on older, Roman-era designs. This is why Roman monuments like the Trajan column appear to us as being in all capitals.
Using the older “font” at the beginning of sentences seems to have begun as stylistic choice, but perhaps with some purpose as a reading aid to identify sentence starts, somewhat in the same way we’ll use different fonts for headings. Note that punctuation (periods, question marks, commas, etc) was also evolving at around the same time and didn’t exist in Roman times.
Bold and italic also evolved from the mixing of different “fonts” within one text.
Wish I could find a better source, but this is what I’ve learned as a calligrapher over the years.
Some more info here: https://www.babbel.com/en/magazine/history-of-capital-letter...
Edit: the codification of upper/lower case took place in the Italian classical revival during the Renaissance. See: https://www.primidi.com/history_of_western_typography/classi...
Other conventions were added: e.g., a capital for a type name, m as a prefix for class members, and of course a leading _ as an indication of not being public (which comes from the unix linker/, IIRC).
Anyway, I think the answer to OP's question is a negative number.
English underuses it
変数
へんすう
ヘンスウ (or even ﾍﾝｽｳ)
ｖａｒｉａｂｌｅ
ＶＡＲＩＡＢＬＥ
variable
VARIABLE
It's a short article but maybe capitals have been useful overall
Please correct Me if I’m wrong.
(Except for my Capitalisation, which is all over the place because I’m trying to illustrate to English readers why I find German really hard to read)
It’s just a convention. Early English writing sometimes also capitalized all nouns.
I imagine the capitalization of Latin alphabets must seem crazy to someone whose native language doesn’t have them.
You can't write adam, you have to write Adam. This is because the letters don't carry enough information; you need to know the context that names are capitalized, which is information that is extrinsic to the text itself.
Similarly, you can't render a unified Han glyph without knowing the context of which language the text is in. This information is again extrinsic to the text itself - it is metadata about the text.
In comparison, when you can't write Hindi ru as r and u as you usually would but instead you have to write the letter ru as its own glyph, there is no extrinsic information needed. The letters are right there, so all the information for knowing how to render the letters is right there. There is no context needed.
But yes, if you define context to include surrounding letters, then yes you need "context" to render Hindi letters. But since the original context of this was the difficulty of supporting this context for programming identifiers, I'd say that this kind of "adjacent codepoints context" would not be something special to worry about anyway, because text renderers today already have to deal with this kind of "adjacent codepoints context" for emojis, etc.