6 ms·

Go is very contrarian, and I applaud this. It takes more than reversing the order of parameters and using known-braindead ideas like codified tabs-are-good syn

by seiji 11y ago

Go is very contrarian, and I applaud this. It takes more than reversing the order of parameters and using known-braindead ideas like codified tabs-are-good syntax to make contrarian ideas valuable. Just because you change green lights to mean stop and red lights to mean continue doesn't make contrarian suddenly better than the way things were.

rudolf0 11y ago
While I think your comment is unconstructive, I do have to say that I don't quite understand why Go decided to force hard tabs. Even more confusingly to me, I really don't understand why they seem to standardize on tabs expanding to 8 spaces rather than 4. The 2 spaces (of soft or hard tabs) favored by some Ruby and CoffeeScript programmers is too little, but 8 spaces is way too much.
- trevorstrohman 11y ago
  A significant fraction of the Go core engineers use proportional fonts when programming. On their screens, hard tabs are the only tabs that work. Spaces on proportional fonts are too tiny to be useful for moving code around.
  - seiji 11y ago
    What? Really? Who in the world would do that?
    - trevorstrohman 11y ago
      Users of Acme, written by Rob Pike. See screenshots on this page and note that the font used is not monospaced. http://acme.cat-v.org/ http://acme.cat-v.org/
      - pconner 11y ago
        Is there a reason why Acme doesn't use a monospace font? I couldn't find any justification on that site.
        trevorstrohman 11y ago
        In this message I'm trying to make the argument I think they would make (I personally use monospaced fonts). It's not that Acme can't use monospaced fonts, it's that Rob/Russ/others don't want to use them. Proportional fonts are better fonts, so why not use them instead? One possible reason is that existing code formatting conventions assume that text is lined up in columns, but we have a tab key that magically lines things up: it's the whole job of the tab key. So, why not forget about space-based alignment, use the tab key for the job it was built to do, and get the advantage of using pretty fonts?
        rbonvall 11y ago
        The use of proportional fonts is the least weird thing about Acme :) I'm really intrigued by that editor. Some day I'll give it a honest try.
        catenate 11y ago
        I used Emacs from 1993-2004, and switched to Acme for the 11 years to present. I don't miss trying to memorize all the key combinations from Emacs. I like that Acme presents a clean, simple, and direct Unicode interface to what I work with: mostly editing shell scripts, and running shell commands, as a build engineer. It takes a while to get used to mouse-button chording, but I don't even think about it now. I constantly use guide files, in many directories, to store and modify commonly used commands to highlight and run, so I make many fewer typos now, and don't forget which commands to run or how I run them. I can also switch contexts a lot faster, both because commands are laid out in the directories where I use them, and because the Dump and Load commands store and retrieve sets of files in the tiled editor subwindows. When I had to work on Windows I enjoyed having a pared-down unixy userland that I could write scripts in, to use also in my Linux Inferno instance (mostly communicated from one instance to the other through a github repo for backup and version control). The biggest drawback to me with Inferno is that so few other people run it, that I have to compile it myself on any new platform on which I run it (there are not really rpms/debs/etc available to just install it). But your experience with Plan 9 Acme might be better, I just prefer also working with the Inferno OS improvements, such as bind, /env, sh, etc.
- Vendan 11y ago
  I am vastly in favor of hard tabs, as it doesn't enforce tab size. Question, why do you say that the standardize on tabs as 8 spaces? I've done all my golang programming with 4 tab spaces.
  - seiji 11y ago
    Hard tabs make "pretty/readable indent" formatting difficult too. If you want to line up certain arguments across lines, you just can't because you're forced to an unknown width of alignment chosen by the reader. So, all your code will just be indents that ignore the specific visual alignment intentions of the author, and that reduces readability and understandability in multi-person teams (and programming is a team sport, not a one-person-does-it-all game).
    - masklinn 11y ago
      > Hard tabs make "pretty/readable indent" formatting difficult too. That's alignment not indentation. AFAIK gofmt uses spaces for vertical alignment
      - seiji 11y ago
        But, that's arguing two points, right? That's like saying ASCII has 8 built in non-visual field separators, so people should use those instead of CSV/TSV for text tables. Sure, it's technically the right distinction, but it's not practical in any reality in which we live. Trying to say "alignment" is distinct from "indent" and that tabs and spaces can be mixed depending on your intention is just crazy talk. The only place tabs should be used is in Makefiles, and Makefiles should be autogenerated by CMake these days, never written by hand.
        masklinn 11y ago
        > But, that's arguing two points, right? No? > Sure, it's technically the right distinction, but it's not practical in any reality in which we live. It's not practical to do by hand (because most people can't be arsed to configure their editor to do it, or their editor is incapable of it in the first place), why would it not be practical when a tool takes care of it for you and everybody uses that tool? > Trying to say "alignment" is distinct from "indent" and that tabs and spaces can be mixed depending on your intention is just crazy talk. And yet gofmt seems to work. > The only place tabs should be used is in Makefiles, and Makefiles should be autogenerated by CMake these days, never written by hand. Why? If the distinction between indentation and alignment can be made and can be made correctly, it means anyone can pick the tabwidth they prefer and things will just look right for everybody, that's strictly superior to either tabs or spaces. That's been advocated for decades, it just doesn't work when you leave it to people, which gofmt doesn't. I'm quite far from a go fan, but achieving the ideal of "tabs for indentation, spaces for alignment" is definitely praiseworthy, whatever you think of other formatting rules.
- masklinn 11y ago
  > While I think your comment is unconstructive, I do have to say that I don't quite understand why Go decided to force hard tabs. Since you're using goftm which imposes a strict discipline, tab-indents and space-align allows configuring tabwidth however you want locally without imposing that on other collaborators. The issue with the idea is usually doing it consistently and people properly configuring their editor (if the editor allows tab-indent+space-align at all), when the code is being hard-reformatted it's not an issue. > Even more confusingly to me, I really don't understand why they seem to standardize on tabs expanding to 8 spaces rather than 4. 8 is the historical/default tabwidth on Unices (unconfigurable environments generally have a tabwidth of 8), using hard tabs but defaulting to anything else would be odd. And since it's tabs, you can configure your environment to whichever tabwidth you prefer (like 3 or 6, I've not seen editors with support for tabwidths in half-spaces or pixels but in theory that's also an option) (well technically the CSS tab-size property supports arbitrary <length> tabsizes but only Chrome >= 42 supports that, the rest only supports <integer> spaces, except for IE which has no support whatsoever). A claimed benefit of 8 tabwidth is also that rightsward drift becomes a problem extremely early, the tabwidth thus acts as a check against over-nesting. Now that's inconvenient in languages with significant "natural drift" like C# (where your code lives in a method in a class in a namespace so you're already 3 indents deep before you've writing anything, class-in-files languages tend to have a tabwidth of 4 or even 2 probably for that reason), but IIRC Go only has a single "natural ident" the rest is all yours, so a tabwidth of 8 serves as a check against nesting code too much.
  - seiji 11y ago
    people properly configuring their editor A lot of coding is reading examples online these days. Trying to read Go code on GitHub is awful since three forced tab indents feels like you're 50% across the screen already (and forget trying to read it on mobile). Browsers don't really have a "set tab width" option that I've found (and forget trying to set user options on mobile browsers). a check against nesting code too much. For expert programmers coding for long-term correctness, then yes. But beginners and lean "we just gotta ship this shit" startups will just create 9 levels of unreadable cruft.
    - 11y ago
- vectorpush 11y ago
  I love two spaces. I used to use four but switched a few years back and now anything more than two looks strange to me. It's just a preference, but it does keep your line length shorter, which is nice if you like to adhere to a maximum line length throughout your code.

by seiji 11y ago

rudolf0 11y ago

While I think your comment is unconstructive, I do have to say that I don't quite understand why Go decided to force hard tabs. Even more confusingly to me, I really don't understand why they seem to standardize on tabs expanding to 8 spaces rather than 4. The 2 spaces (of soft or hard tabs) favored by some Ruby and CoffeeScript programmers is too little, but 8 spaces is way too much.

trevorstrohman 11y ago
A significant fraction of the Go core engineers use proportional fonts when programming. On their screens, hard tabs are the only tabs that work. Spaces on proportional fonts are too tiny to be useful for moving code around.
- seiji 11y ago
  What? Really? Who in the world would do that?
  - trevorstrohman 11y ago
    Users of Acme, written by Rob Pike. See screenshots on this page and note that the font used is not monospaced. http://acme.cat-v.org/ http://acme.cat-v.org/
    - pconner 11y ago
      Is there a reason why Acme doesn't use a monospace font? I couldn't find any justification on that site.
      - trevorstrohman 11y ago
        In this message I'm trying to make the argument I think they would make (I personally use monospaced fonts). It's not that Acme can't use monospaced fonts, it's that Rob/Russ/others don't want to use them. Proportional fonts are better fonts, so why not use them instead? One possible reason is that existing code formatting conventions assume that text is lined up in columns, but we have a tab key that magically lines things up: it's the whole job of the tab key. So, why not forget about space-based alignment, use the tab key for the job it was built to do, and get the advantage of using pretty fonts?
      - rbonvall 11y ago
        The use of proportional fonts is the least weird thing about Acme :) I'm really intrigued by that editor. Some day I'll give it a honest try.
        catenate 11y ago
        I used Emacs from 1993-2004, and switched to Acme for the 11 years to present. I don't miss trying to memorize all the key combinations from Emacs. I like that Acme presents a clean, simple, and direct Unicode interface to what I work with: mostly editing shell scripts, and running shell commands, as a build engineer. It takes a while to get used to mouse-button chording, but I don't even think about it now. I constantly use guide files, in many directories, to store and modify commonly used commands to highlight and run, so I make many fewer typos now, and don't forget which commands to run or how I run them. I can also switch contexts a lot faster, both because commands are laid out in the directories where I use them, and because the Dump and Load commands store and retrieve sets of files in the tiled editor subwindows. When I had to work on Windows I enjoyed having a pared-down unixy userland that I could write scripts in, to use also in my Linux Inferno instance (mostly communicated from one instance to the other through a github repo for backup and version control). The biggest drawback to me with Inferno is that so few other people run it, that I have to compile it myself on any new platform on which I run it (there are not really rpms/debs/etc available to just install it). But your experience with Plan 9 Acme might be better, I just prefer also working with the Inferno OS improvements, such as bind, /env, sh, etc.
Vendan 11y ago
I am vastly in favor of hard tabs, as it doesn't enforce tab size. Question, why do you say that the standardize on tabs as 8 spaces? I've done all my golang programming with 4 tab spaces.
- seiji 11y ago
  Hard tabs make "pretty/readable indent" formatting difficult too. If you want to line up certain arguments across lines, you just can't because you're forced to an unknown width of alignment chosen by the reader. So, all your code will just be indents that ignore the specific visual alignment intentions of the author, and that reduces readability and understandability in multi-person teams (and programming is a team sport, not a one-person-does-it-all game).
  - masklinn 11y ago
    > Hard tabs make "pretty/readable indent" formatting difficult too. That's alignment not indentation. AFAIK gofmt uses spaces for vertical alignment
    - seiji 11y ago
      But, that's arguing two points, right? That's like saying ASCII has 8 built in non-visual field separators, so people should use those instead of CSV/TSV for text tables. Sure, it's technically the right distinction, but it's not practical in any reality in which we live. Trying to say "alignment" is distinct from "indent" and that tabs and spaces can be mixed depending on your intention is just crazy talk. The only place tabs should be used is in Makefiles, and Makefiles should be autogenerated by CMake these days, never written by hand.
      - masklinn 11y ago
        > But, that's arguing two points, right? No? > Sure, it's technically the right distinction, but it's not practical in any reality in which we live. It's not practical to do by hand (because most people can't be arsed to configure their editor to do it, or their editor is incapable of it in the first place), why would it not be practical when a tool takes care of it for you and everybody uses that tool? > Trying to say "alignment" is distinct from "indent" and that tabs and spaces can be mixed depending on your intention is just crazy talk. And yet gofmt seems to work. > The only place tabs should be used is in Makefiles, and Makefiles should be autogenerated by CMake these days, never written by hand. Why? If the distinction between indentation and alignment can be made and can be made correctly, it means anyone can pick the tabwidth they prefer and things will just look right for everybody, that's strictly superior to either tabs or spaces. That's been advocated for decades, it just doesn't work when you leave it to people, which gofmt doesn't. I'm quite far from a go fan, but achieving the ideal of "tabs for indentation, spaces for alignment" is definitely praiseworthy, whatever you think of other formatting rules.
masklinn 11y ago
> While I think your comment is unconstructive, I do have to say that I don't quite understand why Go decided to force hard tabs. Since you're using goftm which imposes a strict discipline, tab-indents and space-align allows configuring tabwidth however you want locally without imposing that on other collaborators. The issue with the idea is usually doing it consistently and people properly configuring their editor (if the editor allows tab-indent+space-align at all), when the code is being hard-reformatted it's not an issue. > Even more confusingly to me, I really don't understand why they seem to standardize on tabs expanding to 8 spaces rather than 4. 8 is the historical/default tabwidth on Unices (unconfigurable environments generally have a tabwidth of 8), using hard tabs but defaulting to anything else would be odd. And since it's tabs, you can configure your environment to whichever tabwidth you prefer (like 3 or 6, I've not seen editors with support for tabwidths in half-spaces or pixels but in theory that's also an option) (well technically the CSS tab-size property supports arbitrary <length> tabsizes but only Chrome >= 42 supports that, the rest only supports <integer> spaces, except for IE which has no support whatsoever). A claimed benefit of 8 tabwidth is also that rightsward drift becomes a problem extremely early, the tabwidth thus acts as a check against over-nesting. Now that's inconvenient in languages with significant "natural drift" like C# (where your code lives in a method in a class in a namespace so you're already 3 indents deep before you've writing anything, class-in-files languages tend to have a tabwidth of 4 or even 2 probably for that reason), but IIRC Go only has a single "natural ident" the rest is all yours, so a tabwidth of 8 serves as a check against nesting code too much.
- seiji 11y ago
  people properly configuring their editor A lot of coding is reading examples online these days. Trying to read Go code on GitHub is awful since three forced tab indents feels like you're 50% across the screen already (and forget trying to read it on mobile). Browsers don't really have a "set tab width" option that I've found (and forget trying to set user options on mobile browsers). a check against nesting code too much. For expert programmers coding for long-term correctness, then yes. But beginners and lean "we just gotta ship this shit" startups will just create 9 levels of unreadable cruft.
  - 11y ago
vectorpush 11y ago
I love two spaces. I used to use four but switched a few years back and now anything more than two looks strange to me. It's just a preference, but it does keep your line length shorter, which is nice if you like to adhere to a maximum line length throughout your code.