I absolutely love having headers in C and stronger notions of compilation units. But in C++ you tend to want to push everything into headers to take advantage of generics. This is another problem where a separate code generation step would have been superior to language generics
I have worked at scale - I have found countless examples of people not believing in simple solutions which eventually prevail and replace the big-complex thing.
Complexity is a learned engineering approach - it takes practice to learn to do it another way. So if all you see is complex solutions how would you learn otherwise?
> I have worked at scale - I have found countless examples of people not believing in simple solutions which eventually prevail and replace the big-complex thing.
I have worked at scale. I have found examples where simple solutions prevail due to inertia and inability or unwillingness to acknowledge the simple solutions failed to adequately address the requirements. The accidental complexity created by those simple solutions is downplayed as it would require reevaluating the simple solution, and thus run books and operations and maintenances are required as part of your daily operations because that's how the system is. And changing it would be too costly.
I don’t want emojis in the headlines please. It makes it difficult to read and becomes an arms race for attention.
Also I’m not even sure it was a good idea to put them in text. Emojis are a special case that breaks a lot. Now you have to worry about multiple colors, etc.
Generally I agree with you, but in rare cases like the article that this one is meta-commentary to it might perhaps have been justifiable to allow it? I see the "slippery slope" risk though.
It definitely wasn't a good idea. Emojis aren't text, they don't belong in Unicode at all. It would be one thing to encode, say, Egyptian hieroglyphics. That would be legitimate. But putting emojis into Unicode was against the purpose of the standard and a huge mistake.
The line is really fuzzy honestly. We have some universal pictograms that are known and reasonably well understood around the world and the way they are used is pretty much a writing system. An icon of a man or women on a bathroom door? Well you may write it in one of a million different styles (fonts) but the general idea is used around the world as a common writing system. I'd say that belongs in unicode.
The real problem is that the alphabets of certain writing systems are unbounded. Emojis are completely unbounded. That's the only reason to have concern with it in unicode. Unicode is a limited set by definition and emojis are an unbounded set.
In my opinion the job of the Unicode Consortium would have been to encode what has significant and organic usage. Similarly to how Wikipedia only includes what has significant organic and externally validated coverage. If they'd stuck to that mission the line would have been a lot less fuzzy.
The problem with that is, of course, that "significant" is subjective.
The modern Western society is very occupied with the questions of racial and gender identity, and it is generally accepted in that society that this topic is "significant". And since it's that society that the Unicode Consortium is working within, this explains how you get six different colors of "man-pregnant" emoji in the world where there possibly haven't been six different-colored pregnant men.
Significant is only subjective in the heat of the moment and not much in retrospect. What I am arguing for is that the Unicode Consortium should only add characters with what Wikipedia would call notability.
I would like to stress that I am not arguing against the addition U+1FAC3 PREGNANT MAN or U+1FAC4 PREGNANT PERSON, there are good reasons to add these, but do we need mundane arbitrary everyday items line U+1FAA9 MIRROR BALL? I'd say no.
Actually, I don't think there's a good argument to add either U+1FAC3 PREGNANT MAN or U+1FAC4 PREGNANT PERSON: expressing gender can already be done with a modifier like how skin/hair color and professions are also expressed, and we already have U+1F930 PREGNANT WOMAN.
For example, this is the unicode sequence for bearded lady:
U+1F9D4 person with beard
U+200D zero width joiner
U+2640 female sign
So a pregnant man could simply be this expression:
U+1F930 pregnant person (woman is implied by lack of modifier)
U+200D zero width joiner
U+2642 male sign
But no, instead we must have this combinatorial explosion of compositions because Unicode can't decide if it wants to be a symbol library or an expression library. So now, we have duplicates like U+1F40F ram and U+1F411 ewe, U+1F404 cow and U+1F402 bull, U+1F9D2 child and U+1F466 boy and U+1F467 girl (but a baby boy must be expressed as U+1F476 U+200D U+2642), U+1F468 man and U+1F469 woman and U+1F9D1 person, and U+1F385 Santa Claus and U+1F936 Mrs Claus but also U+1F9D1 U+200D U+1F384 non-gendered Claus.
The concept of notability is similarly subjective, the issues like the mentioned race/gender identity (or e.g. the Russian-Ukrainian war recently) are perceived as very notable on English Wikipedia.
I admit that it is not perfect. My argument is that Wikipedia at least tries to draw to line. There was a time even for Wikipedia, before the inclusionists vs deletionists conflict, when this was not the case. Unicode is still stuck in this phase and that is what I lament.
Neither are digits, or control characters, strictly speaking. We really shouldn't have been able to have CR and LF explicitly embedded in the text files.
Neither are high and low surrogates - those are big ranges of code points that are illegal except for one specific (and not recommended) encoding (utf-16). Yet, there they will remain in Unicode.
Digits definitely are a form of text though. Unicode is for writing systems, which definitely includes writing numbers
CR & LF are in there for backwards-compatibility with ASCII. Similarly, the first emoji were include in Unicode for compatibility with some encoding systems used for SMS on Japanese mobile carriers. I wish the Unicode folks had drawn a hard line that they weren't going to add any more. If people wanted dingbats, they could go use a dingbats font.
What about "fancy fonts" (foreign characters that look like latin letters)? Japanese / Chinese ideographs? Common pictograms like "stop sign?" Mathematical symbols?
People made emoticons out of ~100 printable ASCII characters. With thousands of "real" Unicode symbols available, they would have gone wild anyway.
As a person with accessibility needs, I'm honestly glad emojis exist. They at least carry semantic meanings (though some people do abuse them in ways inconsistent with those meanings), unlike random combinations of symbols that the internet community has agreed on.
Unicode's original self-declared mission was to encode all characters needed for written communication in the world.
Wikipedia once had a similar issue, where people used it to add all kinds of trivia and original research. There was a fight between the so called inclusionists and deletionists. The latter won and we now have strict guidelines that ensure everything in Wikipedia has to have strong relevant external validation.
In my opinion, the Unicode Consortium would have been well advised to follow Wikipedia's example. If they really only had added characters with significant organic usage we'd seen only a much smaller number of emojis added and in my opinion to nobody's disadvantage.
But this is easy for me to say. I'm curious how emojis help with your accessibility needs. Has it to do with the fact that they take up little screen space or is it something else?
Emojis have names. When somebody sends a "stop sign", "smiling face" or "jack-o lantern" emoji, I know exactly what they mean. Screen readers can (and do) pronounce these.
When somebody sends a bunch of Ancient Egyptian hieroglyphs mixed in with some mathematical symbols, with a little Katakana on top, I have no idea what they mean. The message may encode some visual meaning due to how the characters look and the visual patterns they form when placed in combination, but its semantic meaning isn't clear, so a non-visual technology cannot interpret and pronounce it properly.
This is a very common issue with "fancy font generators", which were common in certain Twitter communities once upon a time.
Honestly, those many duplicates of the Latin alphabet in the Unicode tick me off way more than the emojis. Serif, sans serif (also with bold, italic, and bold italic variants as well), fraktur and bold fraktur, cursive and bold cursive, monospace, and double-struck (which could reasonably count as bold monospace TBF). And there are several more proposed but not yet accepted.
If you hate emojis blame the Japanese telecoms that created it. Unicode strives to digitally encoded all human communication and the Japanese were using pictograms for communication before Unicode.
I'll take a stab as an armchair linguist: Hieroglyphs still represent written language, in the sense that each glyph represents an abstract sound, and glyphs can be composed to form words. Emoji do not represent language, in the sense that they do not have a vocalization, and emoji do not combine to form words.
Take, for example, the various skin colors for faces and persons: if emoji were a real ideographic script, the written representation would be a logograph combined with a determinative, not a set of distinct glyphs. The irony of course is that is exactly how it is encoded within Unicode (an emoji codepoint with a skin color modifier). But doing it this way is exactly why emoji is an illegitimate script: it does not represent any non-digital form of writing, and the emoji modifiers do not have any representation of themselves, neither visual nor audible. Nor is the modifier composable in the way that a real language would be: it does not modify animal colors, for example.
reply