And thats all the argument i need. I dont understand why people argue with consistent text layout for all-spaces. You can use tabs to indent and spaces to align after that, in most cases.
> You can use tabs to indent and spaces to align after that, in most cases.
In practice this is difficult; since the characters are invisible by default, people will inevitably mix up the two. Looks like the industry standard is to give up and use spaces everywhere, unless strict and mandatory tooling exists.
I am very much against any alignment with spaces, just not needed, and adding a lot of unnecessary complexity to code formatting. Just use tabs for indentation, and don't mix them with spaces.
You can't use spaces to align because you can't assume a monospaced font will always be used. You can't use tabs either for that matter. If you need structure, use the language's punctuation and line breaks.
You can use tabs, that’s exactly their role, but only in theory since in practice elastic tab stops that would work with proportional fonts aren’t implemented anywhere in code, only word processors
no, i can't. i want to be able to align on arbitrary columns, not on tab stops. and when i add or remove character that break the alignment, tabs mess everything up. spaces don't.
No, you can't do that with spaces because spaces have a fixed width, which can't always be aligned to a variable width column. Only in the primitive environment of fixed width fonts does this work, but even there the tabstops can also be placed at an arbitrary column position, check Word out
Sticking to historical limitations can be kind of silly. I used to have a computer with 40-column text display, and I don't feel any need to limit myself to that anymore.
i agree with you in principle, but i am not sure that this is simply a technical limitation. it feels to me more than just a preference. i can't explain it, but looking at the apple systems font example in this article: https://storck.io/posts/proportional-programming-code-fonts/ i find it much harder to parse (visually scanning the structure) than the monospace one below. perhaps it is simply what i am used to. but i feel like i am having a more violent reaction than i should have if mere preference and habit were the issue.
one issue is that of distinguishing similar characters, which the above projects try to address while some people claim it's not an issue at all: https://alexkutas.com/posts/non-monospace-font
there is also the issue of alignment mentioned in the first article, that could possibly be addressed by limiting character widths to multiples of the smallest width.
but there is still the issue of interacting with other programmers, mentioned in this article: https://nelsonslog.wordpress.com/2021/09/12/proportional-fon...
we would all have to agree on the same font if there is any kind of alignment needed apart from indentation. right now we can say that you can choose any monospace font, and things will look as intended, but with a proportional font things will look different depending on the font choice. whether that is an issue or not needs further study i think.
I definitely do not enjoy the font choice in your first link. The Go font has been pretty good for me. My editor is configured to use "Go" (not "Go Mono"), I don't even notice when I switch from editing prose to editing code.
"Distinguishing similar characters" is just as much of a concern for me when I'm editing technical documentation as when I'm editing source code. Once again, the Go font has served me well. Previously I used some other humanist style font from from the Ubuntu people that had that classic IBM slash-through zero. Some fonts have overly-aggressive ligatures and such, but those fonts should not be used in any technical context, source code is not special.
Alignment is a non-issue because wanting alignment is bad. There, solved that ;-) Arbitrary diff noise over multiple lines because you added one line at the end is a problem, not a goal!
I interact with other programmers just fine. Your linked article seems to be re-engaging in the tabs-vs-spaces flamewar in an era of gofmt rustfmt et al. It's a total non-issue.
honestly, spaces shouldn't be used; it's a design issue- use tabs only for indentation, then the language should ideally support not having to use spaces for manual alignment.
You use line feeds (\n) to instruct your teletype machine to feed in one more line of paper. Unless you're trying to argue that your text editor is a teletype machine, then line feeds are the wrong thing to use.
I think most people are pretty amenable to the argument that text editors are teletype machines.
Nobody cares that phone calls happen over fiber now instead of telephone lines. So, same should apply to teletype. Nobody is going to care you're reading this over fiber instead of a telephone line.
Now, people do care if they're trying to read a csv document and somebody didn't quote their commas within strings and now the values are in the wrong columns which could've been avoided by using tabs to store tabular data.
> How wide should the indentation be? 2 spaces? 4? 8? Something else?
> By making the indent be a tab, you get to decide the answer to that question and everyone will see code indented as wide (or not) as they prefer.
> In short, this is what the tab character is for.
0: https://groups.google.com/g/golang-nuts/c/iHGLTFalb54/m/zqMo...