It's not too different from what you'd find in a mathematical proof, or even in actual descriptions of algorithms from old mathematical texts. In that context, usually "word" descriptions are appropriate at the highest structural level of a proof or algorithm, while symbols are handy for the most detailed steps. Of course, this is a claim about what humans are comfortable with; a compiler can deal with any formalized text, whether textual or symbolic.
有術曰「曼德博」。先得數曰「寬」，曰「高」。乃行是術曰。
The equivalent in English is like if someone wrote a programming language with Shakespearean english syntax and keywords:
I have a function, thou named "mandelbrot".
Arguably a bit more subtle than your sample code.
> I learned English words like while, for and next from qbasic, for real (it had good help in your local language)
I replaced the word your with the word my in my head without conscious effort. I don't know if it is correct but it is kind of what I expected as I skimmed through the sentence.
There was an article or something saying when we read we can read fast because we don't read every word but rather try to auto complete as we go.
Bear in mind that this is Classical Chinese, not modern Mandarin. For example, as you can see in the helpful gloss a couple levels up, 是 in Classical Chinese is the demonstrative "this". (Whereas in modern Mandarin, 是 is the copula "to be [equating two nouns]", and "this" is 这 or perhaps 本.)
It's amazing how durable some of this stuff is, especially if you look at it from the perspective of recipients of Middle and Classical Chinese culture (such as Japan).
yup!
https://en.m.wikipedia.org/wiki/Radical_(Chinese_characters)
> For example, the radical 女 appears on the left side in the characters 姐, 媽, 她, 好 and 姓
Notably, in the mnemonic for the character I see another one that has four parts, exceeding my previous experience: 彎.
Also the PDF for the Source Han Sans font, linked in the Wikipedia article, has right under the biángbiángmiàn some other monstrosity, consisting of 18 parts if I'm seeing them right. Of course, it's likely another novelty thing: https://raw.githubusercontent.com/adobe-fonts/source-han-san...
Seems that the latter if ‘Taito’: https://en.wikipedia.org/wiki/Taito_(kanji)
However, once support arrives, it will be as easy as typing "biang", since there's currently no character with that pronunciation. It could be confused with a two-syllable word "bi ang", but there's no such word in Mandarin.
Wenyan-lang does this, but it's not really common in normal texts. The reader is just expected to figure it out themselves.
Also note that màn dé bó is the Pinyin transcription of 曼德博 and only reflects the Mandarin pronunciation. In Zhengzhang Shangfang's reconstructed Old Chinese pronunciation, it would be more like moːn tɯːɡ paːɡ. Those syllable-final consonants are preserved in many other Sinitic languages, like Cantonese (that's how they were reconstructed) so Mandarin-based transliterations don't work well for those. As an alternative, 勃 (also Mandarin bó) has the reconstructed Old Chinese pronunciation bɯːd, which is a closer approximation of the "brot" in "mandelbrot".
曼德博 sounds like man de bwo (man4de2bo2 in pinyin). 迈克 (Mike) sounds like my ke
曼德博術寬高也 (ie. Mandlebrot is a function of width and height.)
In terms of concision, actual keystrokes required to type that are mandeboshukuangaoye (19). Compared to function mandlebrot(width,height){} (35).
術means something closer to "method," "procedure," or "way to do something." It's not a function or something that takes arguments in the modern sense.
This programming language is following the style of ancient Chinese mathematical treatises very closely, which are all of the form
X术曰：……
Now there is a way to make your construction work with a wider context, for example in one where you've established 术 as the notion of a function.
Your general impression is correct that earlier texts tend to get more concise and that Classical Chinese is quite grammatically flexible. But there's still limits.
Moreover ancient mathematical texts tended to be far more explicit and written in a far more direct style. Ending particles such as 也 are actually fairly rare in such texts.
1. Ignoring prediction, you need more than three keystrokes to type 事 ("shi"). You type the s, the h, and the i, and then you select the character you want from a menu of suggestions. If you're typing a rarer character (which 事 is not), you'll need additional keystrokes to page through the suggestions.
2. If you're serious about minimizing keystrokes, you'd use double pinyin input, not pinyin input. Two keys per syllable; probably three per character since a lot of repetition means the characters you want are likely to be top suggestions.
Notably, anything reasonable that lets the user just keep mashing the keys is gonna be faster than selecting stuff on the screen, assuming the user is experienced with typing. Because seeing a wrong predicted character, then looking at the menu, then—crucially—locating the necessary character and then selecting it will be way slower than punching keys in without interaction. Making choices and, separately, selecting stuff on the screen are both slower than just jerking the fingers from muscle memory. More so if the user is a touch-typist.
If you know that your ‘事’ is something like ‘shi down-down-enter’, it would still be faster than the same thing with unfamiliar choices in the menu—or if the prediction and the choices change between invocations. Though this handicap would diminish after the choices settle on the user's typical most-used characters and the user in turn gets used to them.
Examples: dnxb would input 东南西北.
Then there is learning. While on OSX's pinyin input 曼德波 requires mandebo the first time, it then becomes the first result for all subsequent inputs. We may assume that most multi-character function names would quickly benefit from similar prioritization.
Yes, that's why I started out by saying "ignoring prediction".
However, it's perfectly fair to note that you can and should enter phrases all at once as opposed to one character at a time, which would reduce the double pinyin input from 3 keystrokes per character to two per character plus one per "input unit".
> Then there is learning. While on OSX's pinyin input 曼德波 requires mandebo the first time, it then becomes the first result for all subsequent inputs. We may assume that most multi-character function names would quickly benefit from similar prioritization.
Yes, I noted this specifically:
>> a lot of repetition means the characters you want are likely to be top suggestions
Looks like the author decided to make the syntax more concise with their object parser/serializer.
The placed number system without Arabic numerals is weird to me. I get that it's probably not all that efficient decoding long-form Chinese myriadic numbers, but it's still weird to see 「九〇〇」instead of 九百 and 「六一」instead of 六十一; though maybe I'm the weird one for thinking that looks weird.
Imagine if the computing revolution were in China instead of USA... we might all be coding using Chinese characters instead of Latin characters right now.
Nah. We would all be using a binary language based on I-Ching trigrams for "octal" representation, and 6-bit (hexagram) "words". A hacker's dream right there.
It doesn’t matter as long as I can do my work.
I would agree that Han characters are a suboptimal technology for everyday written communication due to its large character inventory but this is not a topic where that seems to pose a problem.
吾有一術。名之曰「曼德博」。欲行是術。必先得二數。曰「寬」。曰「高」。乃行是術曰。
Decomposed:
吾有一術。I have a function.
名之曰「曼德博」。 Named "mandelbrot".
欲行是術。必先得 Who wants to run this function, must first get
二數。two numbers.
曰「寬」。Called "width".
曰「高」。Called "height"
乃行是術曰。 Then run this function as follows:
Essentially, what gets expressed using punctuation in mainstream programming languages is instead described by a short sentence. This would be terribly verbose in English, but it's kind of bearable in Classical Chinese, because each word is only a single character.