Physical products: you are buying them for their software. That’s why you choose an iPhone over an Android phone. They’re all rectangles with screens.

When Sonos screwed up its app it was a crisis because: people pay for the software not the hardware.

Is this true about cars? EV design is converging. It will be. CarPlay controversy is a great example: people choose cars that support it.

Vanmoofs have a lot of hardware problems but the reason people bought them was software (like location tracking and e-Shifting).

So “well known when it comes to physical products,” that may be, but all products are software products.

“Software is eating the world” was all about like, replacing human labor or whatever, disruption. Marc Andreesen thinks he was saying something forward looking when it was all backward looking.

The story is differentiation and customer choices. Truly forward looking. But are Japanese firms incapable of that? Of course not.

Once there was a guy on here who said he had the brilliant idea of using a web browser to make an airplane UI. Listen brother, everybody knows how to write good software. It’s a business strategy not execution problem.

By the time software came around, Japan already had a well stablished manufacturing industry that had a reputation for quality (this wasn't always the case).

Software was something totally new and wasn't considered important, why? perhaps management didn't understand it or didn't know how to handle it and did nothing.

The above made a career in software not very attractive compared to other industries. Since then, companies struggle to get good developers, who can move to more attractive sectors or countries than trying to change things within Japan with its rigid hierarchy.

How things move in Japan is generally by someone breaking the status quo and the rest following if it is a success. That was the case with Toyota in manufacturing for example. For software it hasn't happened.

Another problem IMHO is that code is invisible to users. If the app works, people don't care if the code is beautifully made or not, and without consumer pressure, management doesn't care either. Compare that with the complains they'll get if a physical object had the sightless defect.

Finally, there is a higher entry barrier for physical products than software. Any teenager can build an app in her bedroom, it is a different story to develop a bullet train. Inefficiencies and slow decision processes in manufacturing are less obvious than in tech (though manufacturing industries in Japan are struggling as well because of this), and Japan simply isn't competitive in this area, making it less attractive to invest.

And perhaps, the most important: People got used to it and don't have higher expectations.

I remember being a junior engineer and spending time to really make my software good and my first review had a comment that I spent too much time adding "bells and whistles" (which was only partially true). So it gets drilled out of you in US software.

The big difference is capital markets, as SK along with other Asian countries became more attractive for Japanese capital than Japan during the 2000s.

An illuminating question is, is Japan a leader in boutique shop games?

It’s well documented how lenient the U.S. was with enforcing international law on Japans high ranking military and political leaders. The U.S. covered it up and whitewashed Hirohito’s role in WW2. It’s why Japan still has never apologized or even admitted to genociding Chinese and enslaving and raping Korea.

Open up a Japanese textbook on the early 20th century and you will find a glowing portrayal of an Imperial Japanese Empire.

Japanese companies and organizations (and people) love diagrams to present to the public. Whether how to navigate a website, book a ticket, check-in to a hotel, etc. the number of process diagrams in daily life (as a perceived effective way of communicating information) is unseen outside Japan.

Also, the amount of highly detailed posters in public places. For example, the departures board of a train line -- far more information than probably the average US rider knows how to comprehend even. Or is interested in.

https://en.m.wikipedia.org/wiki/File:Stem-and-leaf_time_tabl...

https://www.reddit.com/r/MapPorn/comments/rqaoj3/the_crazy_t...

You have to wonder whether this generates a tolerance or expectation that detail is expected to be understood.

I'm just a happy amateur photographer, but this fact has been annoying the sanity out of me for over a decade now. Mobile phones are taking increasingly large bites out of the camera manufacturers' market share, but companies like Fuji/Canon/Nikon/Olympus, for some unknown reason, are unable to adapt at all. Sure, there is still and will always be a market for larger glass and more pixels, lower noise levels, ergonomics etc. - but why in 2024 GPS, Wi-Fi, uploading to Instagram and similar functions are not standard in ALL cameras is beyond my understanding.

It's like watching the car industry in the early 2000's where manufacturers would pride themselves over finally putting a USB jack in their car.

As an European living in Japan, I can confirm. Japanese advertisement and presentations look like a competition in who can cram the most text in epilepsy-inducing colors in a single page/poster. Bonus points for cramming both horizontal and vertical text in the same page.

I don't know if they really like it, or if they just follow what everybody else does.

Because if you're making something in the US, you have immediate access to a market of 330m[1] people, and they all speak a single language, follow roughly similar laws and regulations, and have relatively similar needs (e.g. software made for schools in Arizona is pretty likely to work well for schools in Kansas, because things like the A-F grade system stay the same).

This rich market gives you plenty of opportunities to grow quickly. Once you grow large enough, you have pretty easy access to other large and rich markets that also speak English, and then you can get into the hard stuff like internationalization.

If you start out as an EU company, you only have access to the population of your own country, and you're not large enough to handle internationalization or the 30 slightly different systems of laws, regulations, agreements with retailers and different store chains etc. It's a lot harder for you to grow at first, because the potential pool of customers able to use your product is much smaller.

You have markets like China and India, which are technically better, but at least historically, they used to be poor enough that the US was a much better option in practice.

I don't think this is the only reason for US domination, but it's definitely one of the reasons.

[edit] [1[] the population was different back then, but the difference in scale was similar

JIS X 0201 was released in 1969 and widely adopted on mainframe systems in the 1970s. It supports a modified form of Katakana (“half-width”) as well as the Latin alphabet in a 7 or 8 bit encoding. 8-bit encodings supported both, for 7-bit you could switch between Katakana and Latin using control characters. So, by the 1970s you could already do Japanese language computing if you limited yourself to katakana and romaji.

Kanji took longer because there are too many characters for a 7/8-bit code and their visual complexity required more advanced display hardware, but already in 1971 IBM was selling their “IBM Kanji System” which contained specialised software, printers and keypunches to support Kanji on IBM S/360 mainframes. In 1979 IBM added support for 3270 terminals (with additional Kanji circuitry) to enable Kanji in interactive as opposed to batch mode punched card computing.

Early systems without kanji support generally used katakana rather than hiragana, because if writing everything in katakana looks weird to Japanese speakers, doing the same thing in hiragana looks even weirder. Also, the “blockier” shape of katakana makes it more legible than hiragana on low resolution displays.

> Or why no EU company came up with an OS that could fight Mac OS or Windows.

In the 1990s, Oracle licensed RISC OS from Acorn in the UK, and sold it in the US as Oracle NCOS (Network Computer Operating System). But the whole “network computer” thing was never as successful as its backers had hoped.

They sort of did. For a while Symbian had two thirds of the smartphone OS market. And the real winner in the global OS marketplace today is Linux (I'm including Android here, though you could debate that), which started out life as European. But I do agree about investment opportunities.

In the 1980s, a major goal of AI research was to make CJK text entry effective and convenient (OCR or alternatives). It didn't pan out in time.

When the necessary tech was reading, emoji was huge in Japan first because it helped mitigate the text entry problem.

I think that program was a good example of a overall inward-facing industrial policy that dominated in Japan in the 1980s.

I'm not sure how much that one program was at fault, but it a great example of many similar misguided policies of the era.

When the feedback from the global markets was removed, most of this kind of planning just stopped working.

LINE is far more popular in Japan than WhatsApp. It's a Korean company, and if you mean why it never took off outside of Asia, I suspect its a matter of network effects, but I have not looked into it in detail.

A priori yes, the fact there's a collision between Japanese and Chinese only tells you one of them is going to win and get the normal experience and the other is going to lose and have Unicode uniquely suck for them - history could conceivably have flipped which was which. Another reply suggests that China had laws requiring products sold there to display Chinese correctly whereas Japan did not, which could be the kind of thing that tips the default/standard.

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

Seems like Wikipedia has a good overview of the issue.

No. They're different languages, and the written forms are similar but distinct, akin to e.g. Fraktur - you can read glyphs from the other language, but it's harder and looks odd. (Yes Unicode doesn't have codepoints for Fraktur either, but no real-life world language uses Fraktur, so it's not a significant issue there).

> What's so special about Japanese that it can't be displayed by Unicode? Unicode seems to work fine for Korean and Chinese, and Japanese is basically a hybrid of those two.

Live everyday Korean is written in Hangul, Hanzi are only for historical documents, which limits the impact. Taiwanese glyphs (which you don't mention, but for completeness) get their own codepoints because the Unicode consortium had a certain amount of geopolitical realism. So the only collision in real-life world languages is between Chinese and Japanese, and everything gets set up to use Chinese glyphs by default (or, more often, to exclusively use Chinese glyphs) and Japanese is the only real-life world language whose glyphs don't have proper codepoints in unicode (and are fobbed off with mumble mumble font selection mumble ranges vaporware).

> If the Unicode standard has space for an ever-expanding list of emojis, they can fix their rendering issues with the Japanese language too.

Oh they absolutely could. They don't want to. Also migration would be difficult - you would have to make a hard compatibility break to ensure that people switched to the new standard, otherwise you'd have old documents that look almost but not quite right and now also where e.g. search doesn't work properly (because searching for the new codepoints wouldn't find characters encoded at the old ones, because no-one actually follows the standards for how to do text search, they just search for byte substrings and call it good).

Blog post I found with some examples: https://blog.skritter.com/2015/06/font-differences-between-j...

Check out the Noto Sans CJK fonts repo[1], as of now it has five variations: Japanese, Korean, Simplified Chinese, Traditional Chinese, Hong Kong. There wouldn't be a need for so many variations if Unicode works perfectly.

But Unicode is already infinitely better than what existed before, so as I said above, we just kind of accept it begrudgingly.

[1] https://github.com/notofonts/noto-cjk

Korean uses Hangul, which is an alphabet and entirely unrelated to Chinese or Japanese.

There was already the Japanese spoken language, and nobody in Japan had personal connections to Chinese people(having a rough sea between two countries tend to do that), so Japanese interpretation of "Chinese language" and its characters is completely its own thing - in China the script is called "Hanzi", pronounced like "kHang-zeh", rather than "knanJI" in Japanese.

With the "Simplified" form created by Chinese communist movement in the mid 20th century, there are currently at least 3 major branches of Chinese scripts: the OG "Traditional" kind, its alternate "Simplified" form, and the Japanese "Kanji" - plus (deprecated)Vietnam Chunom variant, (minor)Hong Kong PRC-traditional variation, Korean Kanji w/o post-war Japanese simplifications, etc.

Each ... has slight variations and significant overlaps. Unicode technically supports a lot of those, some by co-mingling, some by rubberstamped-in duplicates, some by IVS(Ideographic Variation Sequence).

To realistically support all languages in one font or app, there need to be distinctions based on languages rather than bandaging hand-wavy "it's all kanji" approach(the word kanji is Japanese, for starters), but the Unicode Consortium is not doing that.

You have to know the intended locale or the text to disambiguate and select the correct glyphs.

Like, image if coordonner (french), coordinate (English) and coördinate (variant) all were encoded.as the same bytes.

This is prime /r/BadLinguistics fodder but you've ironically hit the head on the problem.

The underlying issue is that Unicode was run by people who thought 16 bits was enough[0], ran into the issue of Chinese characters, and imposed a bunch of very specific unification rules to work around their own self-imposed technical limitation so they could retain 16-bit codepoints. The rule is that characters that only differ in appearance are treated as the same character[1].

To explain how dumb this is, I'm going to invent a concept called UniPhoenician. You see, Latin, Greek, Cyrillic, and a few other phonetic scripts have significant derivation from Phoenician writing, so we're going to just merge the letters that happen to have a shared pedigree. i.e. Latin a, Greek alpha, and Cyrillic a. Of course, once we do that, software now has to be consciously aware of what language text is written in so it can substitute the right set of glyphs to work around UniPho.

To make this even dumber, the limitation that motivated UniHan went away with Unicode 2.0, which went to 20-bit codepoints. Except we didn't fix UniHan, AND we subtly broke old software. You see, 16-bit codepoints was the only encoding for Unicode 1.0. Unicode 2.0 added UTF-8[2] and UTF-16, the latter of which is a series of rules on how to fit 20-bit codepoints into 16-bit text in a way that subtly breaks old software, which hopefully will get updated and then people can just pick what codepoint length they want.

Well, uh... turns out Windows NT and JavaScript already were using 16-bit codepoints, and integrating the new UTF-16 rules into them subtly breaks existing software based on that. So those can never be fixed, and any software built on their text-handling capabilities is subtly broken in the face of emoji, rare characters, and so on. Bonus points is that, because they can't understand UTF-16's special characters, naively written conversion functions working with 16-bit-only software will leak invalid UTF-16 sequences into UTF-8, as documented in WTF-8[3].

[0] Competing proposals for a universal character set, including ISO's UCS, used 4 byte characters, see:

https://en.wikipedia.org/wiki/Universal_Coded_Character_Set#...

[1] Unless the difference is between Simplified and Traditional Chinese, because Unicode didn't wanna piss off Mainland China but was okay with pissing off Japan and Korea

[2] AKA Filesystem Safe Unicode, which shoves Unicode in 8 bits in a way that is mostly acceptable and doesn't impose any Latin-centrism that non-Latin script users need to worry about. Bonus points is that it was originally designed for 32-bit codepoints (anticipating UCS?). If we ever needed 32-bits, UTF-8 could handle them, while UTF-16 would require additional layers of hacks that would spill over into WTF-8.

[3] https://simonsapin.github.io/wtf-8/

What "language setting", and how do you check it? Do your testers know that they have to test this Japan-specific thing, and how to even tell whether it's working or not? And what about users who need to read Japanese, but don't want their UI to be in Japanese - or, worse, users who need to read both Japanese and Chinese?

I need to use Japanese language in a setting outside of the local language setting. Even my wife needs that (she's a native Japanese). Just switching everything to JA is simply not an option, and shouldn't be necessary if just UTF-8 could do the right thing. Granted, it does, to a certain point. But sometimes there are issues which I haven't been able to work around.

[0] https://stockanalysis.com/stocks/nflx/market-cap/ [1] https://companiesmarketcap.com/alphabet-google/marketcap/ [2] https://www.statista.com/statistics/289659/youtube-share-of-...

You also need other people to work with, so even if you have an idea, it’s much easier when there are a lot of people in the area with the right skill set.

With a significant declining trend in population, especially in younger people, there just wouldn’t be as many opportunities.

Japanese software is not the only place where we are seeing a decline in innovation. This is the country that that provided us a lot of modern electronics as well.

35% of people are now over 65 in Japan. A much larger percentage of the economy now has to be dedicated to taking care of the elderly. The percentage of elderly in 1950 was tiny.

So it's no surprise when software companies come in and eat this mentality for lunch when they decide to come up with a competing hardware product.