I want to emphasize on that. Why do programmers like plaintext, often to the point of wanting ASCII instead of unicode despite its international awesomeness?
That's because we are called when things break down in the machinery. Monospace ASCII may look boring, but it has a precious characteristic: there is (almost) 1-to-1 mapping between the inner representation of a character and its screen representation.
Most programming fonts make sure 1 l | i I all look different.
We make sure we can spot the difference between `'"
We know of the few remaining pitfalls, like space and tabs, \n and \r, the various escape characters, the infamous \0.
Even on that limited representation, there are many things to be careful of. And thing is: this representation is just the start of our work! all the rest hinge on that!
Unicode is full of invisible character, potential diacritics, similar-looking glyps, control character that can break the display in a lot of annoying ways.
We made a whole ASCII-based ecosystem because this mapping is precious in many debugging cases. Whatever one does in the (and I say that non-sarcastically) really wonderful and awesome world of unicode, remember that we are going to often only see it as a bunch of 0xF0 0x9F 0x92 0xA9 (<- ASCII rendition of the "pile of poo"" emoji).
Emoji are great to make some apps prettier, some chat concise, to add non verbal communication to online chat. They are not a tool to help developers' life.
As someone who grew up bilingual in a country where it's not uncommon for people to speak three or more languages, I hate the idea of being prevented from using one of the languages I speak while doing my job. Especially when I'm building products that eventually get translated into five or six different languages, all using different scripts.
This is one reason I prefer using GUI applications over CLI applications: Unicode support is terrible across terminals and CLI apps, while most of the commonly used GUI frameworks are okay.
If your app has no issues rendering हैकर न्यूज़ (Hacker News), then it should have no issues rendering Emoji. If your app cannot render that bit of Hindi text, then the problem is your app and not Unicode.
The ability to do that is precious.
> If your app has no issues rendering हैकर न्यूज़ (Hacker News), then it should have no issues rendering Emoji
First, that's not true. Many fonts have partial support or an app may have an issue with displaying mutli-colored glyphs. There are many possibilities for this partial failure.
> then the problem is your app and not Unicode.
Yes. Precisely. I don't think unicode or emojis are problematic per se. But they belong to a higher layer than the one a lot of (non-web) programmers spend their times in. Unicode support is HARD. ASCII support is easy. Making ASCII tools is easy and promises an ecosystem full of useful tools.
> This is one reason I prefer using GUI applications over CLI applications: Unicode support is terrible across terminals and CLI apps, while most of the commonly used GUI frameworks are okay.
And that's fine, but realize that by doing so, you depend on a layer that relies on an ASCII layer. Tools that require unicode can't be used there.
As someone who develops multi-lingual web sites, I can say that the vast majority of the people who visit the sites and then request a language other than English still have their computer/browser configured for English.
The one thing English has going for it is the ease of typing it on any keyboard everywhere. Romanizations are fine too. Heck, even Russian is a bit problematic. Much more CJK, Hebrew, Arabic and Indian languages.
Emoji are easier to type in.
Is that an inherent property of English, or because we haven't invested enough effort into making non-English keyboards better?
Here's an interesting bit of data: ever since Google added support for Hindi in Google Assistant, it has become the second most used language used for voice search globally [1]. I don't know about other countries, but there's definitely a demand for non-English languages on computers in India.
> Romanizations are fine too.
No they're not. It implies you have knowledge of two separate languages, two separate writing systems, and the ability to convert between them. This is not always the case. People do write Romanized Hindi (and Tamil, Kannada, etc) in India, but that has more to do with the lack of native keyboards than anything else. With the rise of mobile devices, more people are writing Indian languages in their native scripts, thanks of the excellent work Google and Apple have done with their keyboards.
I'm as much a native English speaker as I am a Hindi speaker, and I'm entirely unwilling to accept a worse experience for either of these languages on my devices. Language is part of people's identities, and you can't really divorce language from script without losing something of its character in the process. People across the world have protested and rioted for their right to use their own languages. Governments are elected based on language issues. Supporting your target audience's primary language is part of your job as a good engineer, whether your target audience is non-tech people or other developers.
Where is this unwillingness to support multiple languages in software coming from, anyway?
[1] https://economictimes.indiatimes.com/tech/internet/hindi-sec...
It is an inherent property of English, at least in some way. English doesn't use diacritics or letters like the German "ß". It is the least common denominator of western languages.
AFAIK, languages that don't have English letters use an entirely different script, and considering that most programming languages, command lines, etc... use English, you need to be able to write English in addition to your native language.
English also have the interesting property that it is really simple to render, which makes it ideal for embedded software, low resolution screens, etc... Chinese a much too complicated, and even Hindi requires you to combine things.
Not of English inherently, more a feature of a language that uses a small set of symbols with many different combinations. The simplest and easiest approach is to give each button a symbol; it's also typically faster than typing on, say, some sort of touch-input keyboard. I agree that there is demand, but English still makes sense for development.
> People do write Romanized Hindi... in India, but that has more to do with the lack of native keyboards than anything else.
And I am stuck using SI units for science, even though I have a preference for American units. Compatibility is important, and as you just stated, people have adapted.
> Where is this unwillingness to support multiple languages in software coming from, anyway?
Immense difficulty for minimal return. About two months ago, and article was posted about just how difficult it can be: https://gankra.github.io/blah/text-hates-you/
Even if many programmers aren't dealing directly with the rendering, UI design is a huge pain. Coupled with the fact that many countries with languages more difficult to support have fewer users, it can be a simple business decision.
I can see why a consumer-friendly interface probably should have multi-lingual support (especially if it has a large, non-English user-base), but development tooling operates at a lower level where more computer-friendly representations are necessary. It also has to be able to all work together under the hood, which requires a common language. English ended up the lingua franca, partly because computers were developed largely in America and partly because English text happens to simply be easier to represent than other languages, at least for computers.
Even popular films released with Latin-alphabet names don't use the International Alphabet of Sanskrit Transliteration (IAST) for example.
It makes it hard as someone learning Hindi, because I might read or someone tells it's spelt 'k, u, l', but actually it's 'ka, la', i.e. kal or कल (yesterday/tomorrow) for example.
(And that's a common example, becauss IAST uses 'a' for inherent vowel, but many people write 'u', which is arguably often closer to the right sound if read as English, but that's probably not a high priority goal of IAST.)
It works without setting $LANG, $LC_ALL, ':set enc=utf-8', 'use utf8' and who knows what else.
Buggy software is buggy. Saying "who cares about accents?" only sweeps the problem under the rug.
EDIT: I guess then that also "café", "façade" and "señor" can retain their original spelling. The question is: where does it stop? will latin-1 suffice?
What other characters are "widely used" in English texts that are missing from ASCII
And - is not a dash, it is a minus. It does not suffice as a replacement for a real en or em dash in a properly typeset text. This is also not "specialised", it is how English is correctly typeset.
I respectfully suggest you read my posts in this subthread because I don't believe you have. Instead, you appear to have taken my comment on accents in English completely out of context.
I think you'd have to pretty deliberately misinterpret my comment about accents being uncommon in English to somehow think I was suggesting you change your name.
What do I do when I want to take a break and go to a café?
How can I write about that cornerstone of English myth and legend, Bēowulf?
I wouldn't base a paper on it, but (fiancé versus fiance): https://books.google.com/ngrams/graph?content=fianc%C3%A9%2C...
café versus cafe: https://books.google.com/ngrams/graph?content=caf%C3%A9%2Cca...
I argue "Bēowulf" is does not fall under "widely used." Even my high school version of it it was printed "Beowulf." I'm not claiming "ASCII contains all characters used at all in English," just refuting the claim that you can't "write proper English" with ASCII and that it is missing "widely used" characters.
We have café all the way from McDonalds up to Buckingham Palace.
McCafe and Buckingham Palace would want the "sophistication angle". Both spellings work obviously, but IMO (and the majority of English books) "cafe" is the "correct" spelling.
https://books.google.com/ngrams/graph?content=caf%C3%A9%2Cca...
If a Chinese person adopts an English name, they'll put it first, however. Eg "Jake Ma".
Variants: cafe
Now multiply this by a thousand with Unicode exact lookalike glyphs.
Arabic is written from right to left. Which emoji is the first character of this sequence? It actually depends on the position of invisible LTR control characters.
علامة يمين-إلى-يسا
EDIT: BTW, HN does not support emojis apparently
Although I do agree the one character to one codepoint mapping of ASCII is useful, things like terminal escape codes already add a layer of complexity that makes it hard for me to imagine a scenario where you can't render U+1F4A9 but can still render things like ^[[31m found in almost every cli tool.
`:bug: Fix login modal`
It doesn't break anything and when interpreted (github, gitlab, gitkraken, etc...) it displays a nice looking emoji.
`:lipstick: Revamp login modal`
Read this: https://stackoverflow.com/questions/3580013/should-i-use-pas...
TLDR from the Git repo: Describe your changes in imperative mood, e.g. "make xyzzy do frotz" instead of "[This patch] makes xyzzy do frotz" or "[I] changed xyzzy to do frotz", as if you are giving orders to the codebase to change its behavior.
People have different opinions on what tense to use, but the one that scales better would be in imperative mood. See example here: https://github.com/facebook/react
Edit: Nevermind. I must have been tired yesterday. User wasn't questioning the tense, but pointing out that the part of the message "fix" making the :emoji: redundant.
On Windows they are easy: <Windows key> + .
Finding the right emoji is easier than on my Android phone as Windows lets me type the emoji name. Why emoji search is missing on Android... who knows.
Tbh that's a very weak consideration, as it's ingrained through standardization throughout the codebase. And if this is for codebases you're not familiar with, then PERF is hardly gauranteed to.produce useful results (it certainly isn't standard in my own codebases).
Much more dangerous is people expanding on emoji-tagging with things like COLOR and similar VARIANTS, or an explosion of tags like being suggested in this article, making it even harder to use/memorize the system
But worst of all is that emoji are ugly and ruin the aesthetic of anything they come in contact with
If I'm an Android dev, it might bother me that application suspend is deliberately mishandled on tons of lower-end devices to improve battery life. Should I just ignore those users? If I'm making an email client, it might bother me that Gmail's IMAP support is crap. Should I stop supporting Gmail in my client?
Tools make concessions for the platforms and environments that they'll run in. They always have, and they always will. You get to ignore platforms if you're comfortable saying, "my stuff isn't for the users of those platforms." But so many programmers are on Linux, it probably isn't feasible for most OS projects to ignore them.
None of that means that Linux shouldn't have better emoji support. It should. It's embarrassing that it doesn't. But, you have to deal with the world as it exists today.
Some MacBooks famously also have a TouchBar that makes emoji easy to type.
I can't remember the last time I had issues rendering emoji, and I have no idea why they'd be difficult to search for or how they would pose any accessibility issues.
I had no idea it was usable from the keyboard until I read this comment. There's a search box but it's invisible and hidden until you type blindly at a window that doesn't look like it accepts keys.
Terminal mostly supports emoji, but has many bugs. Some emoji, after being typed and deleted, don't properly restore the cursor to its original position.
ASCII may be ugly but works 100% of the time for me. I tried using emoji on macOS 10.14.5 Terminal just now and ran into every issue you said you don't encounter.
https://en.wikipedia.org/wiki/Usage_share_of_operating_syste...
https://en.wikipedia.org/wiki/Languages_used_on_the_Internet
They are plaintext. They’re Unicode characters just like abc. There’s nothing special about them!
It’s like the second derivative of the floppy-disk-means-save problem, but pushed into our terminals where despite their drawbacks things must generally have a relatively fixed meaning devoid of the context required to interpret purely visual signifiers.
If you mean that performance improved just write PERF instead of :lightning-bolt:
On macOS, emojis are actually easier: Control+Command+Space in any text field, then type a word to filter/search the emoji list [0], or expand the popup to a full-blown Unicode browser [1].
While I agree that emoji shouldn't be used in git, it's worth noting that the limitations you point out are platform-specific, and not universal.
in macOS, emoji work very well in any app that chooses to allow them, including the terminal. Typing emoji is as simple as double-clicking on the character you want from the pane that pops down from the menu bar.
Linux may not have first-class support for emoji, and Windows may not have first-class support for emoji. But those are limitations of the operating systems, and not of the emoji, themselves.
… Which means getting your hands off the keyboard. That is why I don't like being forced to type emoji; it requires a (physical) context switch.
I generally find those against emoji to be unintentionally racist since other cultures have been using various characters for decades if not longer
Further, they've been using emoji for the last 20 years. So telling them they can't is basically telling all of Japan they're 2nd class. Their standards and ways of communicating don't matter. Lots of programmers from cultures where emoji and symbols were not in common use dismiss them because in their culture they were not in common use just a few years ago but other cultures have been using them much much longer. As such, banning them is unintentionally racist.
It’s the same property that applies to the people who, 20 years ago, initially argued for UTF-8 specifically because of how efficiently it encodes from-ASCII codepoints, ignoring that for most text in most languages on Earth, UTF-8 is less efficient than UTF-16. (Of course, UTF-8 won out anyway, but more because it’s easier to parse, auto-resynchronizing, not limited to the first 16 planes, and because we ended up inventing all sorts of XML/JSON-based document formats, like ePub and OfficeXML, that cause even documents in other languages to be mostly from-ASCII codepoints by weight.)
It’s also the relevant property for Americans who complain about large downloads for games, or who have cellphone service but don’t have data, and think “the world” needs solutions to these problems, when really, North American ISPs are uniquely horrible (to the point that a game developed excluding North America as a potential target market could probably do things we’d think of as “impossible” right now, like live-streaming mesh co-AR or something.)
Sure. Some writing systems use singular glyphs to represent an entire word. We're not talking about those. We're talking about using using a picture of lipstick to represent updating UI and style files and other silly suggestions. I'm not sure how you confused the two.
Emoji are hard to type on non-mobile platforms, and are difficult to search for in logs or files. Often they don't render properly. They're near impossible to deal with from the command-line.
Not to mention the accessibility issues.
I see no reason why these cannot be accomplished with tags/flairs such as [critical], [bug], etc. These would also make sense to those not familiar with the Gitmoji system.
Don't make stuff harder than it needs to be. Emoji look flashy, but that's about it. Please use good ol' plaintext.