塔 can be pronounced as tou, too, or somewhere between the two. It depends on the speaker, speaking style, and possibly dialect. Either way, Japanese speakers rely more on context and pitch accent than actual pronunciation, so it communicates fine.
No it can't, unless someone is spelling it out, or singing it in a song where it is given two notes, or just hyper-correcting their speech based on their knowledge of writing.
Annoyed speech and such can break words into their morae for empahsis, which breaks up dipthongs.
E.g. angry Japanese five-year-old:
ga kkō ni i ki ta ku nā i!!! (I don't wanna go to school!!!)
"nā i" is not the regular way of saying "nai". The idea that "nai" has that as an alternative pronunciation is a strawman.
You're right. I looked up 現代仮名遣いの告示 [0] for the first time, and it says 塔（とう） is officially pronounced as "too". I had it backwards - I thought that 塔 is "tou", but due to the varying sounds of う, people could (and often preferred to) pronounce it as "too" in everyday speech.
This kind of misconception seems not uncommon. There's an FAQ on NHK's website [1] that addresses the question of whether 言う（いう） is pronounced "iu" or "yuu". The answer is "yuu", and the article make it clear that: "It's not that [iu] is used for polite/careful speech and [yuu] for casual speech - there is no such distinction."
I think native speakers learn words by hearing them and seeing them written in hiragana, before learning the underlying rules, so they know "too" is written as とう, but might not realize that とう shouldn't be pronounced as "tou" or いう as "iu". These are at least less obvious than cases like は in こんにちは never being "ha".
Personally, if I heard someone say 塔 as "tou" or 言う as "iu", I probably wouldn't count it as incorrect, nor would I even notice the phonetic difference.
FWIW I think 言う is a different phenomenon entirely, because おう is pronounced as two vowels when it has grammatical meaning (in this case, as the verb ending), or between different words/morphemes. But my (non-native) understanding was that for nouns and such, or within the main morpheme of a verb (e.g. 葬る), “ou” is (usually) indistinguishable from “oo”.
As a native Japanese speaker, this example is eye-opening. I hadn't even realized that the u in 方 is pronounced as /o:/ — I believe most Japanese people haven't either, despite unknowingly pronounce it that way.
Also, I have no idea how to Hepburn-romanize 方 vs 頬, 負う vs 王, and 塔 vs 遠. If I had to romanize, I would just write it as whatever the romaji input method understands correctly (hou/hoo, ou/ou, and tou/too, in this case).
If you know the word 方, that it is /ho:/, and you know that it has a う in it when written out, how can you not know that う stands for making the o long? The only vowel is the long o.
Japanese kindergarten kids can recognize hiragana words with "おう", correctly identifying it as /o:/. By the time they learn the 方 kanji they would have seen it written in hiragana upmpteen times, like AよりBのほうがいい and whatnot.
Well, speaking for myself, I internalized how う is pronounced differently in different contexts when I was young, and by now I've almost forgotten there's a difference I need to be conscious of.
When I hear /ho:/ in a certain context, "ほう(方)" immediately comes to mind, without noticing that what I heard was a long o. To me it's just the う sound. And if someone pointed to their face while saying /ho:/, I'd think it's the お sound as in "ほお(頬)".
Because they're a native speaker. Native speakers are often utterly oblivious to the 'rules' of their own languages.
Every time I read a rule about my mother tongue (Mandarin) online I was like, lol what nonsense foreigners made up... And then I realize that rule does exist. I just have internalized it for so long.
Adjective order in English is basically that most essential qualities of the object go closest to the head. There are lists out there that try to break this down into categories of adjective ("opinion-size-age-shape-colour-origin-material-purpose"), and to some extent the anglo intuitions on which sorts of properties are more or less essential are not trivial, but it's not as arbitrary as people want to make it out to be.
This. People act like it's a hyper-complicated rule that English speakers magically infer, when in reality, a) other languages do it, and b) it's a much simpler rule (that you've given) which someone overcomplicated.
As a counterexample (in line with your explanation), consider someone snarking on the WallStreetBets forum: "Come on, guys, this is supposed to be Wall Street bets, not Wall Street prudent hedges!" Adjective order changes because the intended significance changes. (Normally it would be "prudent Wall Street hedges".)
Side note: please don't nitpick about whether "Wall Street" is functionally an adjective here. The same thing would happen if the forum had been named "FinancialBets".
People "overcomplicate" the rule because they find counterexamples to the simple rule.
It's a fool's errand because the way human language works is that people happily accept odd exceptions by rote memory. So the rule simply says that there exist these exceptions. Also, there is something called euphony: speakers find utterances questionable if they are not in some canonical form they are used to hearing. For instance "black & white" is preferred over "white & black".
The rules boil down to "what people are used to hearing, regardless of the underlying grammar offering other possibilities".
In compound noun phrases, nouns serve as adjective-like modifiers.
By the way, modifying compounds generally must not be plurals, to the extent that even pluralia tantum words like scissors and pants get forced into a pseudo-singular form in order to serve as modifiers, giving us scissor lift and pant leg, which must not be scissors lift and pants leg.
An example of a noun phrase containing many modifying nouns is something like: law school entrance examination grading procedure workflow.
The order among modifying nouns is semantically critical and different from euphonic adjective order; examples in which modifying nouns are permuted, resulting in strange or nonsensical interpretations, or bad grammar, are not valid for demonstrating constraintsa mong the order of true adjectives which independently apply to their subject.
For instance, red, big house is strange and wants to be big, red house. The house is independently big and red.
This is not related to why entrance examination grading procedure cannot be changed to examination entrance grading procedure. The modifiers do not target the head, but each other. "entrance" applies to "examination", not to "procedure" or "grading".
Did you read the second sentence of that paragraph? The same thing would happen with a legit adjective, like if the forum had been named "FinancialBets": "Guys, this is financial bets, not financial prudent hedges."
Although many kanjis can be algorithmically composed, manual adjustment of each character's shape is still necessary for production-grade fonts. For example, if you closely compare the 彳 radical between 徧, 行, and 桁, you'll notice subtle differences in width, stroke length, angle, and margin.
Thunderbird is no different than Electron apps, though. It's built on a browser engine, renders UI written in HTML + CSS (+ XUL partially), consumes ~500MB of RAM on idle, etc.
That's because thunderbird is a full featured application. It contains a browser because you can actually use that browser. It's not using the browser as a mere presentation engine.
Java is ten years younger than Erlang. When Java was marketed into the new hot thing in 1996-1997 Erlang was widely used within Ericsson, and in 1997-1998 someone in Ericsson had swallowed the Sun bait and forced the start of a transition to Java. Joe Armstrong and others went to management and convinced them that since Erlang was now useless it should be released as free software, and it surprisingly was.
Which meant that some of them promptly resigned from their jobs and started a company doing freedom Erlang. It took until 2005 or so for Ericsson to confess that they had made a mistake in trying to Java all the things and got around to using Erlang again.
> it took until 2005 or so for Ericsson to confess that they had made a mistake
Impressive that someone was able to make that call and accept the situation, after investing half a decade moving to Java. Also says something about the staying power of Erlang and its paradigm, that the company was able to re-adopt it again.
Well, the IT bubble had burst and Sun was basically two thirds down the sewer at the time. Re-adopting something you had built and proven in the early days of cell phones probably looked like very reasonable risk management.
Patchwork robes and non-orange clothes are common in Japanese Buddhism. The styles and colors vary significantly depending on the sect and one’s rank.[1]
The author uses something like `list.push(...objects)` in his demo code, and I believe this is the culprit. Passing many (~100,000) arguments to a method at once using the spread operator is known to cause a stack overflow, because, in JavaScript, each argument is placed on the call stack.
I see a number of issues, but don't have time to look into them.
1. Spreading when you probably don't need a copy: sortEntries. Sorting is probably where the overflow happens. Just sort in place or use Array.from or slice.
2. Excessive use of array functions. In my experience, a C style for loop performs better when you need performance. Create an empty array before, perform your business logic inside the block, and push to the array.
3. I don't know how filter is called, but it potentially loops through all of the events three times in the worst case.
4. paginate manually creates a JSON string from the returned entries. I don't know why, it seems inefficient.
`events.push(...arr)` puts all arguments on the call stack before calling the method, which causes the error. Don't push tens of thousands of items at once.
It has nothing to do with architecture, but rather understanding how the DOM works. The DOM is notoriously slow, so you should never render a huge number of rows at once. You can render millions of rows in plain JavaScript without impacting performance.
Here, I have recreated your JS example with searching and filtering and it does not crash. It's trivial to reuse a similar approach with the real backend and real events from the event source.
The point should not be using the spread operator at all costs. There are other ways in javascript to push multiple elements in an array that are more efficient than the spread operator.
The fact you didn't even stop to wonder why the error was a stack overflow when you weren't using recursive functions is also telling.
reply