I do. I cannot use dark themed text editors for a long time even though I fully understand and feel that over time it becomes tiring to the eye. I can't explain the reasons why I keep using the white background because I don't exactly know, but I think I find it a bit difficult to keep my focus on what I'm reading (or writing). Feels like I'm getting lost in the code that I'm editing, can find the relevant part as quickly as I can with a bright background. Maybe it has something to do with habit, which can change upon forcing myself, I don't know.
From the outset Unicode's goal (more so than ISO 10646 though now they're one and the same) was to unify all existing character sets, so you'd only need one.
Necessarily then, there should not be other sets that encode things you can't in Unicode, since then you can't displace those with Unicode.
So, particularly in the early life of Unicode the goal was collect stuff that already exists and add it to Unicode. (These days we're finished with that and most new work is on adding things that weren't previously in any character set)
Two controversial things were done, at opposite ends of the spectrum, during this period of consolidation:
What you're seeing here is adding copies of the entire Latin alphabet, but with some particular property that Latin users would not really consider part of the character, such as "bold" or "italic" but which _was_ preserved in some character set being used somewhere. Without this choice, if we converted a text file encoded in a way that distinguished bold and italic characters, we'd lose that bold/ italic and it might be significant. This would be like when you get a black & white photocopy of a sheet that says
"Ignore any text below shown in red"
Um, but none of this text is red? Oh. Probably some of it was before it was photocopied. Oops.
At the far end of the spectrum, a process called CJK unification took place in which scholars of the languages using characters from the Han ("Chinese") writing system decided that although say, a Japanese character set and a Chinese character set both had a particular character, and the Chinese and Japanese would not draw this character the same way, actually in some linguistic sense it's the same character (and in many cases the visual differences are quite small) and so Unicode should not encode both separately.
There's a coherent technical argument for why both these types of decisions made sense, but they were nonetheless controversial.
You should not use weird characters like italic Latin letters in new documents, but you also should not transform these characters without warning when processing an existing document as you may lose important meaning.
Both had always bothered me deeply, but I'd never stopped to think that they're also essentially opposed in philosophy to each other. So now that I'm aware of that, I'm triply annoyed :S
One of the reason for these sets is mathematics ℜ <> ℝ in a math text (and BTW the math symbols ℂℍℕℙℚℝ in the double strike set are "out of sequence" which can be a nasty surprise if you do naive incrementation.
And ℤ. The reason these double-struck symbols are in a weird place (U+2100-214f, separate from the rest in U+1d400-1d7ff) is because they all have commonly used special meanings in mathematics -- they're used to represent the sets of all numbers of various types. ℂ = complex numbers, ℍ = quaternions, ℕ = natural numbers, ℚ = rational numbers, ℝ = real numbers, ℤ = integers.
There are three slightly different things going on.
The first line, Ｔｈｅ ｑｕｉｃｋ ｂｒｏｗｎ ｆｏｘ, originates with east-Asian character based terminals, on which ideographic characters occupied twice the space of alphabetic characters, and there was also a desire to have latin characters that were also double width. See https://en.wikipedia.org/wiki/Halfwidth_and_fullwidth_forms
The middle lines are included as mathematical symbols. The justification is that 𝑖 is a mathematical symbol that has its own independent meaning, which only coincidentally looks like italicized i. (I think this is silly, and naturally leads to a bloody mess as people misuse these symbols as letters, and in this case there is no backwards-compatbility excuse.) https://en.wikipedia.org/wiki/Mathematical_Alphanumeric_Symb...
Interesting. This is the first thing I thought, but when I fed "lazy" into google, it happily accepted and displayed the results, so I thought there might be something else. But teh text editors that I tried indeed don't match the characters when I search them.
google is using unicode equivalence[1] to remap back to "standard" latin characters. this is important because, e.g., professional type-setting software may replace two adjacent "f" characters with a double-F ligature "ff" depending on kerning. without unicode equivalence, google would fail on a lot of copy-paste queries.
Because smoking as a habit has very little to do with nicotine addiction. The psychological addiction is the key. After a long period of smoking it takes only a few days to fully overcome nicotine withdrawal whereas it takes much longer time and effort to get rid of the habit itself. Smoke, gestures, the ritual, everything related to smoking becomes a part of your identity, so replacing the whole package is easier compared to eliminating everything but the chemical aspect.
Unless you live in SF, which just banned flavored vape juice. SF -- a place where you can buy pure THC crystal, but banana flavored nicotine is banned.
`After extensive troubleshooting, IT personnel figured out they had to change several settings on Internet Explorer so ALIS users could log into the system. This included lowering security settings, which DOT&E noted with commendable understatement was “an action that may not be compatible with required cybersecurity and network protection standards.”`
I successfully learned Esperanto, extensively studying solely on duolingo for 3 weeks, then jumping on to other material. It was one of best things that I did for myself. I particularly recommend Esperanto to HN readers as the language itself is "hackable".
Mi forte rekomandas ke vi legu Gerda Malaperis ĉe lernu.net. Fakte, mi trovis ĉiu materialo sur lernu.net tre utila. Kaj tiam vi povas provi legi rakontojn de Fratoj Grimm, denove sur lernu.net. Alie, vi povas vidi videojn de Evildea sur Jutubo kaj aŭskulti podkastojn ĉe kern.punkto.info. Ne forgesu aniĝi al Duolingo Esperanto Learners ĉe Fejsbuko, se vi havas konton tie. Bonŝanson :)
Someone already mentioned about the co library. My personal experience is that it is excellent and massively simplifies async calls. The API resembles the async/await pattern: you use the keyword "yield" instead of "await". Async calls look as if they are sync. The code that includes heavy use of async methods such as in a database application greatly benefits from co in terms of code readability.
I don't think it can be considered syntactic sugar. For one, writing .then( .. => return ..) everywhere is too verbose and using co means that you are using a library to achieve something that the language should have first class support in the first place. Moreover, async/await will have different semantics than generators, the runtime will have native support and no generators will be involved. Calling these solutions "we already had it", IMHO, is like saying we didn't need functional programming features like .filter, .map etc, or newer features like Object.create, Object.assign etc we already had polyfills or other ways to a achieve their functionality. For that matter, even a simple "for loop" is redundant as you can use a while loop and use your own counter to achieve the same results. Async/await as a language construct feels so much better and fulfills a very common pattern than verbose solutions or solutions with different semantics using libraries.
I'm not positive, but I'm pretty sure that async/await is currently implemented on top of generators in all major engines. I know it's true of at least some engines.
Which makes sense. It's not a perf critical feature, so transpiling is the smart move.
I really like KDE and installed Neon a few weeks ago. However, I encountered bunch of issues, sudden chain-crashes of software, some settings not being saved, plasmoids and wallpapers not being downloaded and most notably the digital clock displaying incorrect time (tried everything to no avail). For some reason it didn't work properly on my laptop. I ended up installing Kubuntu.
I, as an author of such library, am a bit biased but still...
For one, you may get massive, massive developer productivity by eliminating loads of queries. In a lot of ORMs you do things like myObject.save() instead of generating a insert/update query for the particular state of myObject without taking into consideration which fields of the object is currently set. This reason alone enough for me to use them.
Second, bunch of additional functionality usually come out of the box with ORMs, such as JSON or arbitrary (de)serialization of columns, caching, logging etc which you would have to spend time on custom implementations of these otherwise.
Third, like you mentioned, some allow very easy change of database vendor.
Fourth, mental abstraction from the underlying data storage (you stay in your language's domain) which again contributes to the productivity.
Some other benefits include not seeing large SQL strings in your code which make it more difficult to read and maintain, security and ability to easily reason about what the code intends to do.
I don't want to sound arrogant (not my intention at all) but I believe those who don't understand or downright rejects the benefits of a decent ORM system are either the ones that never used one to see the productivity benefit or those who work on projects that need to squeeze the last bit of optimization. In a large enough project it is seriously pain and time consuming writing all those queries which could be elegantly avoided.
