Nikita Prokopov

First, the font that we are used to has an outsize impact on what we prefer. So, if neither of these 'sit right', don't worry.

Digital font designers have to start out by choosing something called the em-height. This is a nonsense holdover from print days, and is especially infuriating because no one agrees on a standard em-height. Therefore, fonts look different despite being set to the same size. Here is a great rant on this: [1]

Lucida Console has a large x-height, which is generally considered helpful in small-size legibility. But it has that in common with both Consolas and Jetbrains Mono.

For me, I can use Consolas, Lucida Console and Jetbrains Mono all down to Size 10 in Git Bash on a shitty 13" 1080p laptop screen. Hence my comment that the ClearType hinting is glorious.

[1]: https://tonsky.me/blog/font-size/

I will gather a lot of downvotes, but still: I find Swift a very haphazardly designed language with very little foresight and forethought. This is further compounded by its standard libraries which are directly lifted from MacOS with all of their idiosyncrasies and huge incompatible changes from version to version.

For what it's worth, [1] [2] [3] [4]

[1] A type system that can't cope with SwiftUI: https://tonsky.me/blog/swiftui/

[2] More syntax to shake a stick at https://twitter.com/dmitriid/status/1276482336486576133

[3] Even more syntax weirdness https://twitter.com/bradfitz/status/1285302091544576000

[4] Standard library between versions: https://twitter.com/dmitriid/status/1201441652507844608 File manipulation functions on String, great design.

> Usually, what you want is either the byte or the grapheme cluster.

Exactly ! That's what I understood after reading this great post https://tonsky.me/blog/unicode/

"Even in the widest encoding, UTF-32, [some grapheme] will still take three 4-byte units to encode. And it still needs to be treated as a single character. If the analogy helps, we can think of the Unicode itself (without any encodings) as being variable-length."

I tend to think it's the biggest design decision in Unicode (but maybe I just don't fully see the need and use-cases beyond emojis. Of course I read the section saying it's used in actual languages, but the few examples described could have been made with a dedicated 32 bits codepoint...)

This might have been a good example fifteen years ago. These days with high-DPI displays you can't perceive a difference between font smoothing being turned on and off. On macOS for example font smoothing adds some faux bold to the fonts, and it's long been recommended to turn it off. See for example the influential article https://tonsky.me/blog/monitors/ which explains that font smoothing used to do subpixel antialiasing, but the whole feature was removed in 2018. It also explains that this checkbox doesn't even control regular grayscale antialiasing, and I'm guessing it's because downscaling a rendered @2x framebuffer down to the physical resolution inherently introduces antialiasing.

Nikita Prokopov has presented a pretty cohesive vision for front-end programming in the cljs community. Even if you don't agree with all of his opinions, he's one of the only people assembling a big picture about how to write apps in this way. It's worth reading his blog:

http://tonsky.me/

An emphasis on low-level tooling and not enough discussion around high-level architecture/examples has hurt the react+cljs combo adoption from my point of view. It's the nature of Lisp to come up with your own abstractions around application architecture, but the community would be wise to talk more about solving common web patterns and how to cleanly break away from those patterns when necessary.

> knowing that I can't accidentally bungle up the history. I'm always nervous about that when I use git

I just read a great insight yesterday:

> Understanding there’s no harm to be done eases things a lot. It encourages experimenting, which is one of the most effective ways to learn new things and to get familiar with them. Imagine this: you start rebase, mess things up, hit Ctrl+Z several times and try again. Good news is, we can implement Undo/Redo given just ordinary Git implementation. Git already stores all the possible states our repo was in. All Undo/Redo will have to do is to shuffle some branch pointers here and there.

https://tonsky.me/blog/reinventing-git-interface/