Hacker News Reader

Comment by yorwba | Hacker News Reader

The syntax is slightly cumbersome. For example, the function header of the mandelbrot snippet at https://wenyan-snippets.netlify.com/ reads:

吾有一術。名之曰「曼德博」。欲行是術。必先得二數。曰「寬」。曰「高」。乃行是術曰。

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.

View on HN

> Essentially, what gets expressed using punctuation in mainstream programming languages is instead described by a short sentence.

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.

It is terribly verbose in Chinese too. It is verbose because it's straight-up copying the style of ancient books talking about formulas for magic, without trying to optimize for ease of use. A less verbose (but still mostly gramatially correct) version might be like this:

有術曰「曼德博」。先得數曰「寬」，曰「高」。乃行是術曰。

It's more "art" than practical, but that's fine, I find it fun to read!

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

etc =)

http://shakespearelang.sourceforge.net/report/shakespeare/sh...

Arguably a bit more subtle than your sample code.

Nice. Is there a longer Hello World anywhere?

Very impressive, in that it is not mere transcription of terms used by Shakespeare into keywords, but it organizes the whole program as a drama.

That is way better than I thought it would be from other esolangs I've seen.

There's certainly a lot of dross out there that's just search & replace glosses of some other language or a respelling of Brainfuck, but there are some gems out there. Search for "piet language" for another example of something genuinely interesting.

Your description reminds me of Cobol.

It is a lot like COBOL, but oddly with more punctuation (probably because of the lack of consistent use of whitespace in Chinese). I think it may be a fun way to practice my 漢字.

Imperial Chinese COBOL is very natural sounding concept. That's for sure civil service exam material right there.

The punctuation seems extraneous to me. They all come either before or after keywords so they don't seem to be needed to parse the script. IIRC it's very similar to actual Classical Chinese, which relied on words like 曰、乃、也 to indicate when a clause or sentence starts or ends. IIRC typically the punctuation was added as a part of the excercise of reading.[0]

[0] https://zh.m.wikipedia.org/zh-hant/%E5%8F%A5%E8%AE%80

not sure if serious but this sounds like trying to learn english via python syntax

I learned English words like while, for and next from qbasic, for real (it had good help in your local language)

Ok but that is three words, what about the rest? Leaning three words is somewhat far removed from leaning a language. (Btw: I can’t grok your final statement in the parenthesis — it doesn’t make sense in English, what were you trying to say?)

It made sense to me: qbasic had good localized help.

It made sense to me as well but I can see how I got there and how I shamed the meaning of the sentence without thinking

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

Oh right I see, yes it does make sense you’re right. I was really struggling with that last night, cheers.

The rest will come in when reading technical docs for libraries, APIs and such.

It's more like learning American English spelling from the names of DOM methods and interfaces.

Or Shakespeare English or Latin. The Classical Chinese is hard for chinese even. They are crazy. And said it is like cobol. Bye.

> I think it may be a fun way to practice my 漢字.

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

I'm familiar with that sense of 是 (also as 昰) from seeing it in some obscure Japanese text, where it was used to signify これ, which was probably about right when writing was new to Japan. In Japanese, 是 is more commonly used in words that to me seem unrelated to either the old, very old, or modern Chinese use of the character.

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

It's rather curious to plainly see in this decomposition how more basic words have simpler symbols, whereas proper names look like black midi. (I wonder if any of these have four or more simple characters jammed into one.)

> I wonder if any of these have four or more simple characters jammed into one.

yup!

https://en.m.wikipedia.org/wiki/Radical_(Chinese_characters)

> For example, the radical 女 appears on the left side in the characters 姐, 媽, 她, 好 and 姓

That's about what I meant, but so far I've seen three-part characters and am sorta curious how many more get used, in practice. Also afaik some radicals get chopped in the process, and it seems there are some rudimentary ones (in terms of graphics) that aren't ever used on their own—both of which don't present much of a challenge so I'd count them as half a part for my purposes.

11: https://en.wikipedia.org/wiki/Biangbiang_noodles

Impressive. Would pinyin for entering the full symbol also be as elaborate as the sum of the parts, or is just ‘biángbiángmiàn’? Though I suspect that this character is where the ‘in practice’ condition kicks in.

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)

As the readme for Source Han Sans mentions, neither of these characters is encoded in Unicode yet, so writing them isn't supported by most input methods. (Wikipedia uses SVGs to show the characters; the font recognizes the ideographic description sequence.)

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.

Knowing nothing about Chinese, I'm curious how we arrive at 曼德博 being "Mandelbrot". How does the language handle foreign names and loan words?

There are essentially two methods: phonetic transliterations (Mandelbrot = 曼德博 = man de bo) and translation (computer = 电脑 = diannao = 'electric brain'). As the former tend to look weird, and are most often proper names, they are often especially punctuated to distinguish them from the rest of a paragraph.

> they are often especially punctuated to distinguish them from the rest of a paragraph.

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

it's not really common in normal texts

https://en.wikipedia.org/wiki/Chinese_punctuation

And which of these punctuation marks is used to mark something as a transliteration? The middle dot • serves as spacing in multi-part names, but that doesn't tell you where the transliteration begins or ends.

Very often 《…》/ <…> / 「…」are used to delimit transliterated proper names.

I've only seen angle brackets used to indicate titles of books, movies, etc., and regardless of whether the name is transliterated or not. The corner bracket quotation marks are more typical of Traditional Chinese typography, which I don't see as often, since I mostly read writing by mainlanders.

Given that "Mandelbrot" is German for "almond bread", the translation approach would also be possible... except that almonds don't seem to have been known in China in the classical period.

It's transliteration. There are characters and sounds that are used to mimic the sound of foreign words.

曼德博 sounds like man de bwo (man4de2bo2 in pinyin). 迈克 (Mike) sounds like my ke

Couldn't the whole thing be shortened as follows, or to something very similarly concise?

曼德博術寬高也 (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).

Could be far fewer keystrokes with character prediction. First would be 7 instead of 19, ignoring Enter/arrow/mouse clicks.

You could also treat 也 as ; in some other language syntaxes (eg. ruby), so newline could be semi-synonymous, so the use of 也 becomes superfluous unless you are writing one liners. So that's down further to 6 characters. Even if 'f mandelbrot(width,height' was used in an autocompletion IDE, the traditional syntax weighs in at 24 characters or 4x.

A couple notes on keystrokes:

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.

This is not strictly true. On modern IMEs, usually the first character is enough if the compound you are typing is predictable.

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.

> dnxb would input 东南西北.

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

Apologies I mentally switched off when you mentioned 'double pinyin'. Maybe I use that anyway.

> and then you select the character you want from a menu of 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.

In idiomatic Wenyanwen, yeah, but you need to somehow delimit the token boundaries between 寬 and 高.

For the parsing problem, you can just enforce single character variable names.

That doesn't really make sense as a Classical Chinese sentence. 曼德博术使以广纵二数也。 is a bit closer to how you might see it in a non-mathematical text.

術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术曰：……

FYI I studied ancient Chinese history and some classical Chinese. I believe you have a blinkered view of valid grammatical constructions, perhaps due to focus on later period texts. IMHO in gross simplification, the earlier you go the less grammatical fluff is required, and the more is open to interpretation. I am not an expert but compare, say, a Three Kingdoms period text to a Tang text. In my impression your construction is far more explicit and latter-day. Nobody wrote like that early on, especially for content tending toward the philosophical.

I'm writing in a style somewhat following a Warring States to Han Dynasty text (the 九章算术). The problem isn't the concision per se, it's that that's just not what 术 means here; it's not something that takes arguments. I'm being slightly verbose but I can't think of a construction that doesn't involve 以 or 数 (or synonyms thereof). It's true you don't need both.

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.

https://github.com/wenyan-lang/wenyan/issues/560

Looks like the author decided to make the syntax more concise with their object parser/serializer.

Depends on what kind of concise we're talking. Those are in the BMP, so two bytes a piece. The keys are fairly short though, 2-3 bytes is pretty compact for useful keys in most JSON.

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.

Do you prefer 丗 than 三十/三〇

That would be a bit more obscure, but very classical!

Sounds quite poetic actually.

That sounds similar to what Knuth had in mind with literate programming:

https://en.m.wikipedia.org/wiki/Literate_programming

Not really: ‘literate programming’ is an inversion where free-form documentation is at the front while the code is embedded, instead of docs being swept into comments and readmes. What's described above is just regular syntax, only verbose—no arbitrary extra bits.

It sounds like HyperTalk, “writing code in natural language”.

APL

I'm super glad programming languages were invented in a country with an alphabet.

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.

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

I wouldn’t care so much, actually. After all, I am not even using my native language to write programs in, but English.

It doesn’t matter as long as I can do my work.

Well, my point is that Latin characters are much easier to learn than Chinese. You only have to memorize 26 characters, half a dozen punctuation symbols, and a dozen keywords vs. thousands of pictograms.

Chinese characters can be typed on non Latin keyboards like zhuyin. And maybe only somewhat relatedly, the fastest texters of Japanese I’ve seen don’t use a Latin keyboard but some crazy 9 button input grid.

This really isn't a problem for the task of learning PLs in Chinese where the number of keywords is bounded...

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.

For this reason I dont think it would ever have happened in China

Reply on news.ycombinator.com