https://thecollectivehk.com/%e7%a7%91%e6%8a%80%e5%88%b8%e8%a...

As an 外國人 who learned Cantonese as an adult (I moved to HK) I'm jealous of the quantity and quality of materials that exist for learning (not Cantonese). That being said, there are _enough_ materials so it's nowhere near as rough as e.g. Shanghainese.

My opinions on hard language reduces to "is this the first language you're learning from a particular language family?" If so, it's hard to learn. But "is ontologically hard" isn't something that I think is really worth ranking. Any four year old can speak their mother tongue just fine.

But the perception of "hard to learn" did work in my favor for learning Cantonese: as a 鬼佬 who speaks Cantonese I was given lots of latitude to be bad while learning because of that perception. And now I could go back and learn Mandarin now and it would be _much_ simpler than the task that I had in learning Cantonese.

That being said I still write in 口語. Slowly learning 書面語 as I read more and more of it.

Ideographic Description Characters: https://www.unicode.org/charts/PDF/U2FF0.pdf

The fine people over at Wenlin actually have a renderer that generates characters based on this sort of programmatic definition, their Character Description Language: https://guide.wenlininstitute.org/wenlin4.3/Character_Descri... ... in many cases, they are the first digital renderer for new characters that don't yet have font support.

Another interesting bit, the Cantonese linguist community I regularly interface with generally doesn't mind unification. It's treated the same as a "single-storey a" (the one you write by hand) and a "two-storey a" (the one in this font). Sinitic languages fractured into families in part because the graphemes don't explicitly encode the phonetics + physical distance, and the graphemes themselves fractured because somebody's uncle had terrible handwriting.

I'm in Hong Kong, so we use 説 (8AAC, normalized to 8AAA) while Taiwan would use 說 (8AAA). This is a case my linguist friends consider a mistake, but it happened early enough that it was only retroactively normalized. Same word, same meaning, grapheme distinct by regional divergence. (I think we actually have three codepoints that normalize to 8AAA because of radical variations.)

The argument basically reduces "should we encode distinct graphemes, or distinct meanings." Unicode has never been fully-consistent on either side of that. The latest example, we're getting ready to do Seal Script as a separate non-unified code point. https://www.unicode.org/roadmaps/tip/

In Hong Kong, some old government files just don't work unless you have the font that has the specific author's Private Use Area mapping (or happen to know the source encoding and can re-encode it). I've regularly had to pull up old Windows in a VM to grab data about old code pages.

In short: it's a beautiful mess.

- Reasonable English corollary. (Doesn't have to be 1:1.)

- English-pronounceable Cantonese romanization.

- English-pronounceable Mandarin romanization.

- Doesn't diverge too much between the three.

- Characters that are identical in Traditional and Simplified.

- Pleasing to the relatives.

Comments URL: https://news.ycombinator.com/item?id=20702742

Points: 3

# Comments: 0

We're making Ember accessible by default.

Monthly Goals:

  - Support Ember.js' internal upgrade to the new rendering engine.
  - Adopt dynamically scoped variables to make ember-a11y function.

Slack: https://ember-community-slackin.herokuapp.com/

Ember A11y: https://github.com/ember-a11y Ember A11y Addon: https://github.com/ember-a11y/ember-a11y

License: MIT

We're building a tool that makes it easy to build and maintain Ember applications.

Monthly Goals:

  - Finish moving off of Bower and onto our npm infrastructure.
  - Upgrade our internal npm usage from 2.X to 3.X.
  - Make our story for caching using Broccoli far more efficient.
  - Improve the Node ecosystem's publishing patterns for the projects we use.

Slack: https://ember-community-slackin.herokuapp.com/

Ember CLI: https://github.com/ember-cli/ember-cli

License: MIT

Comments URL: https://news.ycombinator.com/item?id=8938718

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=8868504

Points: 6

# Comments: 1

Comments URL: https://news.ycombinator.com/item?id=8862826

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=8642215

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=8581211

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=8359976

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=8245658

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=8229796

Points: 6

# Comments: 0

2. The typical pattern is lots of computed properties. They're lazily calculated, so that makes them pretty cheap.

https://docs.google.com/document/d/1ZWYq3gwkPTzUiyqr4x_asSj8...

    how much code the browser needs to parse and execute on every page load

    weight of execution payloads across operations in your app

EDIT: With regards to the "independent test," that is in no way a realistic use case. You would never add items to the DOM individually when you're in that tight of a loop. You would instead build up a cache and write once. The only thing of consequence that is being measured in that benchmark is each framework's DOM insertion speed.