I agree! Science is about experiments to verify hypotheses. Design of Experiments seems like a fundamental part of that. That's also why the quote below made me laugh.
> What if you don’t care about efficiency or causality?
"Yeah, what about if you don't care about money/time and are happy with finding a correlation only?!!?"
I like the idea of Gemini and was inspired to write a script to turn my blog posts written in markdown to gemtext. Sadly I still haven't finished that script ...
My main issue with the protocol is that it is requiring creating a new TLS connection for every request. That is indeed a simple approach but I argue that the extra round trip times added due to this are not worth the trade-off for the simplicity gained in this case
Coming up with a simple way to reuse a connection would reduce the round trips needed drastically. If we put our heads together, I feel like we could come up with a way to do that, that doesn't overly complicate the protocol ...
I have only just started out but it feels nice indeed! A hindrance is that I am not very artistically gifted, but as long as I make it mostly for myself, I don't mind too much.
Hm, I am using [dwm](https://dwm.suckless.org/) with a custom keybinding to shift to the left or right workspace. That seems similar enough, other than the fact that changing the split ratio will affect all workspaces on dwm while on Niri it most likely will not ...
I use a variety of DEs and WMs but I still can't find anything better than dwm for my desktop. If I need some extra controls, xfce4-panel runs modularly and neatly covers the main bar for whatever workspace it's on. It handles both tiling and floating perfectly. I hope more software projects pick up the focus on simplicity, especially making programs as easy to reconfigure and compile as dwm.
In general, I think having ligatures in a monospace fonts is a bad idea.
The reason is that in a monospaced font all the glyphs are supposed to the same advance value. This forces the ligatures to always take up the same space as two (or however many glyphs) are involved, which may stretch the ligature glyph in a non-intended way (if it is even possible to rasterise it that way).
Monospace fonts are also often used for programming (because they make sure that the columns line up consistently, regardless of the font being used). I personally don't see the point in showing ligature glyphs that do not correspond to the actual Unicode code points encoded to bytes in the source code.
I thought the same, but when Berkeley Mono got ligatures I gave them a go and never turned them off.
I think the truth is that any good monospace font is designed with an awareness of the grid those characters are laid out in. The rhythm and stability of that grid is a feature of monospace fonts. It lets us line up text, draw shapes and so on.
You would think not having the underlying characters visible would be an issue, but ligatures are just symbols like any other. In a short time you learn to read them, like you would any contracted word.
It is probably a bit easier to start from a language you are familiar with. That image intentionally is a mismatch of random arrows and operators that don't necessarily align to the semantics of real code.
I think that's one of the things Fira Code's Readme [1] does a better job at than Berkeley Mono's page. The top big image breaks down the ligatures in high level categories or the programming language they are most associated with, side by side the version with a ligature. Further down the Readme you can several real examples from programming languages with the ligatures called out, giving you the context clues of what it looks like in a language you may be already familiar with.
Rationally, what you say makes sense, of course. But I love ligatures for programming. First of all, I think they just look nice.
But second, I also feel that for me, they make code a bit more readable. Without ligatures, multiple characters are often used to create one symbol; with ligatures, one symbol is always rendered as one single visual character. So if I read code, it just feels a bit easier for my brain to parse ≥, rather than >=.
> So if I read code, it just feels a bit easier for my brain to parse ≥, rather than >=.
Clearly there's personal preferences involved, so there's no objectively better or worse, but it still blows my mind, because reading ligature symbols like ≥ and ≠ always makes my brain skip a beat, so I need to reread a few times to "get it".
Some of that subjective influence with ≥ and ≠ especially is how much time you've spent in math courses or reading math papers. For some of us those have always been the "real" operators and >= and != the fallback replacements that look "close enough" in easy to type ASCII. We were sort of doing the opposite all along, translating the ASCII breakdowns into the math notation in our heads, and ligatures can feel like a bit of a relief because now you see the "real thing".
At least for programming ligatures, wouldn't they tend to be shown as a single glyph (and occupy the same space)? I don't like them, but for people that do, I expected ≠ to be displayed instead of !=, not a different longer glyph.
In coding fonts with ligatures, ligatures usually have the same width as all of the component characters combined. So if you type !=, you will see a character looking like ≠ that is two advances wide. You will even be able to select the middle of the character, hit backspace, and delete the (invisible) "!".
This is necessary because if all ligatures were one advance wide, you couldn't easily tell the difference between =, ==, and ===, or between != and !==.
I would rather != stay the way it is, and have the language support ≠ as a synonym. 30 years ago, on the mac's HyperCard, the language supported ≠ as an inequality comparator (as well as ≤ and ≥ for <= and >=, respectively). On the mac it's easy to type with the Option key and =.
Back then, those characters weren't easy to type on dos/windows so it seems to be a case of being stuck with the "lowest common denominator" in terms of character input across OSes, reminiscent of C's trigraphs where "??<" was used because keyboards didn't have "{"—thankfully those are long gone. Ligatures are a hack around that but it always struck me as an inelegant solution.
There are one or two advantages over regular GUIs, but that's it.
The biggest is probably that they are lightweight since there are no GUI library dependencies (and if there are TUI ones, they are usually much lighter than their GUI sisters). This also means there are fewer (if any) dependencies to distribute compared to a GUI.
The only other advantage I can come up with is that a TUI will have to be usable by keyboard only (in almost all cases). This is not a given for regular GUI libraries.
I'm not a fan of TUIs either. I think the only one I am using regularly is `tig` (https://jonas.github.io/tig/). I guess the reason is that I don't have to remember the git revision list syntax that way and that `tig` allows for easy commit searching with `/` ...
> What if you don’t care about efficiency or causality?
"Yeah, what about if you don't care about money/time and are happy with finding a correlation only?!!?"