Is it only me but I really dislike "Code Ligations"? I have to mark some chars to count how many consecutive "=" simbols there are... or \/ looking like V without having other chars near it to distinguish. Having to copy paste diamond shape to find out it is <>. arrows with squiggly tails, /> being ugly, <. having dot in the middle...
That could be the maximum I'd like out of font to have "proper" greater/less-equal sign.
They always seemed to me like solutions to a nonexistent problem. They make the code less readable, but ligatures exist and they seemed like a cool tech thing to implement, and they might look cool in screenshots. But in practice, in my opinion, they're worse than just having the normal characters. But I guess it's a matter of opinion, no harm in other people using them.
We have studies since ages ago that consistency in code style is one of the most important requirements for code quality.
This goes down to the details like that you should either use spaces over tabs OR prescribe editor config such that the code looks similar on each machine.
Of course this doesn't automatically mean that code ligatures are harmful, but I would be quite wary of using them. At the very least it introduces some friction, not sure if the arguably lower mental load of using real mathematical symbols instead of the ASCII symbols makes up for it.
I'v been coding now for like 15 years and I'm not old enought to understand the debate between spaces vs tabs :)
I guess my IDE choices never surface the issue for me... visually they just look the same. I cannot say which codebase uses spaces which uses tabs. I never even think about it. I just smash tab character and don't care that there have been spaces. Or enter or { and IDE does the indentation. I just choose not to press space 2-4-8-16 times in a row.
Now I hope I won't get bulldozed over by HN crowd...
Spaces vs. tabs causes a lot of issues for Python programmers who share their code with other programmers. The other place where spaces vs. tabs is an issue is with makefiles, probably one of the most annoying features of POSIX.
> I also remember old school bourne shell wanting tabs in some places (case statements?), but bash doesn't have that issue.
From bash(1):
> If the redirection operator is <<-, then the shell strips all leading tab characters from input lines and the line containing delimiter.
That's also how it works with zsh.
This is why my here-doc delimiters are always un-indented despite surrounding indentation.
Wish bash had something like ruby's `<<~`, which accepts either space or tab indentation of the delimiter and additionally removes the indentation of the block (likely based on the least indented line).
Considering the way `/bin/sh` had a bunch of different implementations before POSIX standardization minimized that in the mid-1990s, I wouldn’t be surprised if one of those distinguished spaces from tabs.
That said, the original UNIX V7 implementation of /bin/sh didn’t distinguish different kinds of whitespace:
You're right. I don't see any evidence of what I claimed. It doesn't look like it was ever whitespace sensitive. This would have been in the 90's, probably Linux. I feel like the compatibility issue involved case statements, maybe it was the parenthesis thing.
One of the main arguments for tabs over spaces was always that people wanted to configure how much space a level of indentation makes up on screen.
With tabs pretty much every editor except something like notepad.exe could do it since ancient times, with spaces the editor needs to do a bit more processing, so you were a bit more restricted in editor choice, if you really were bothered so much by the indents chosen in the project.
So it is actually quite similar to the ligature discussion. It would be good if the code looked the same for everybody but now instead of saying "But 8-space indents waste so much space on the screen :(" some people now go "But I don't like seeing things like != or -> instead of modern Unicode symbols :("
Well, the tabs vs spaces had been mostly resolved and spaces won. But obviously it was never about what physical keys to press, nobody on the spaces side would spam the space bar to indent stuff (except maybe in the unfortunate situations of having to use an editor with no choice of setting the tabulator to emit spaces, or a textfield in a non-editor UI where the tabulator cycles the focus instead).
For a solo project, sure, you do you. But for any meaningful collaboration, deliberately mixing tabs and spaces - and relying on a manual, semantic convention to use them the "right" way - will inevitably lead to a maintenance / consistency nightmare.
To add to your comment, it's kinda common to find projects that have spaces and tabs improperly mixed in the indentation. Making a quick search among the projects I have cloned, I'm seeing indentations like
tab * 4 + space * 7 + tab * 2
tab * 2 + space * 1 + tab * 1
tab * 1 + space * 4 + tab * 2
space * 16 + tab * 3 + space * 4
tab * 4 + space * 2 + tab * 2 + space * 2
tab * 3 + space * 3 + tab * 1 + space * 6
The code ends up looking janked unless you use the particular tab-width of the space/tab-indenter[1], which isn't always 8. It completely defeats the whole purpose of the tab indentation.
[1] On those first 2, given the odd (not even) number of spaces, it's likely that use of spaces was for alignment, but then a tab-indenter added tabs to that...
It's too bad spaces won, tabs is just correct I think, since one can configure the tabstop to use any indent size they would like. I'm quite tired of reading 2-space indent. Seems everything has moved this way now except python. I'm even seeing C with it, which is especially jarring. I think the languages that use braces for indentation particularly need 4. Python needs it least, and I can read Ruby because its blocks are delimited by words and it's bad style to write long methods
I'm in the same boat, I always just press tab and let my IDE or text editor fill in with N spaces.
Granted, I'm also someone who heavily encourages the use of Black as the Python formatter in projects I'm on, specifically because it has no configurable options - can't have a holy war about formats if nothing can be changed.
I feel like tabs could have won if there was a stretchable tab character instead of it looking like a bunch of spaces. Being invisible meant that it was treated as a bunch of spaces. I could see it being visible as a very light gray block with just a tiny right margin. This way it would be easy to see how many indents there are.
When I program or I write maths I see and think of -> >>= <*> etc as a single, semantically meaningful symbols.
Not only do I use a ligature for them, but I make my keyboard to use one single key. For the same reason I have a key emitting “forall” which Emacs then displays as ∀.
I thought I was the only one! I figured I was either crazy or getting old and stuck in my ways. The first I'm I saw a font with them, I thought it was cool and tried it out. I almost immediately hated it. I've tried a few more times for varying lengths of time, and I've decided that I really do hate them.
I have used Fontforge to remove all ligatures from a programming font; e.g. my monospace font of choice is a aggressively subsetted variant of Fira Code with no ligatures whatsoever.
For example, ligatures in Fira Code cannot be disabled when using the Cygwin terminal in Windows (mintty). In that application, for example, “===” looks like three continuous long lines atop each other in Fira Code, with no way to make it look like three equal signs again.
“Fira Code is not only about ligatures. Some fine-tuning is done for punctuation and frequent letter pairs.” Note that without ligature support, a lot of that fine tuning is lost.
I wish editors had the option to disable certain ligatures. I use jetbrains mono, and the >> ligature breaks bracket highlighting in visual studio, making them both the same colour
It is aggressive in its unicode support. You want to use vulgar fractions? Or Mayan numerals? They'll work. You want to use mathematical notation like ∈? It works.
Mostly it strips out ‘math variable names that jerks would use to embolden their spam headlines for emphasis’, which is indeed annoying and results in this:
I wish more languages other than Raku did this. But no, not equal is written as surprised equal. And if something ought to be less or equal, you have to write a fat arrow pointing left. :/
Yes, I was pointing to Raku as the one exception that does have Unicode operators. Other languages (that I know of) unfortunately don’t support them out of the box.
I personally like them because (to me) it makes a few symbols less ambiguous. (I use Victor Mono [0], so in my mind things like == and === in that font makes mistakes more obvious to me at least.)
But also... I know I have the minority opinion on this. It absolutely should be opt-in, not opt-out. I think the past decade, I've been told the font tweaks I enable are incomprehensable to everyone I work with. The way I like my IDE fonts is far outside the bell curve (ligatures, cursive variants for some syntax, proportional variants for prose) so the fact that most new monospace code-focused fonts seem to align with my opinions should be concerning to font makers! I like that I don't have to patch a different font's italics into my code font anymore, but common sense says I SHOULD still have to do that!
The VT-340 didn't support ligatures, therefore, we shouldn't use them ;-)
Now, seriously, a programming font has no (and should never have) awareness of the computer language it's representing. Ligatures make sense if they present meaning in a way easier to read than the non-combined characters. I can't type := in APL and expect the REPL to think it's an attribution arrow (←).
I get APL is a rather extreme language to talk about, but this is one example where ligatures would harm the programmer (unless your editor replaces a ":=" with a "←"). Source code is a very precise language and the choice of characters you use matters a lot. A "<-" doesn't mean "←" unless the language declares so.
I used to hate font ligatures until I discovered Commit Mono (my all time favorite monospace font). They use the ligatures only to adjust spacing and make it look better on a monospace grid. No stupid <=, -> ligatures or anything else.
You and me both. Ligatures are a solution to a problem that monospaced fonts don't have. I don't mind if a mono font uses ligatures to harmonize character spacing/alignment a little bit. But I don't want things like a "proper" greater/less-equal sign; if a font goes so far as to replace >= with ≥, then it's lying to me about what characters are actually present in the file.
They are in the tabs vs spaces camp. Choose your preference and walk away, silently. Unless you consider yourself a Real Programmer, in that case, fight to the death about the matter.
(...I also find them annoying to look at, idk why)
Some fonts use three lines to draw a triple equals ligature. That, and it is, well, triple long. I’ve never had any problems with distinguishing anything with ligatures. They’re nice to look at, and very easy to read once you’re used to them. Skill issue, guys.
It is common knowledge among most - if not all - civilizations that you do, in fact, need to learn to read in order to know how to read.
Anyway, since you want a direct representation of the text - presumably, you configured your editor to render EOL sequences explicitly, to distinguish tabs from spaces, etc?
Code ligatures look like the final desperate attempt of an aging hipster, a Ruby on Rails and Web2.0 early adoptr (sic), the type to wear thick-rimmed fake glasses and a scarf in the middle of summer, to be cool, as he is riding his old Segway, with a glass of soy latte in one hand and an avocado toast in the other, into the void of oblivion.
I don't like them because I never know what they actually stand for in ASCII.
That could be the maximum I'd like out of font to have "proper" greater/less-equal sign.