6 ms·

Researchrsc: Gofmt

33 points by bandris 17y ago

aaronblohowiak 17y ago
Why the legacy "fmt" instead of "format" ? Go is a new language, why be held back by the old name conventions?
- tspiteri 17y ago
  Because it's shorter.
  - ThinkWriteMute 17y ago
    We're not on 80 character terminals anymore. Harddrives are larger than 1.4mb. People need to read this stuff. "It's shorter" isn't a reason, it's a legacy.
    - tspiteri 17y ago
      When using the command line, shorter commands are easier to type. I know, two key strokes are not going to take a lot of time, but when you do it repeatedly, it does feel a bit more comfortable. It has nothing to do with 80 character limits. And in what way do people need to read "gofmt"? They need to type it, not read it.
      - ThinkWriteMute 17y ago
        I guess I forgot that newbies never read code to learn from it? Or when someone is updating or maintaining old code? Crazy talk! Look there's no excuse here. goformat isn't that much larger than gofmt, easier to understand on initial read, and doesn't hurt a damn thing. If Computers have no problem reading Brainfuck then they should have no problem reading a Programming Language that reads easily to humans. You know, those things that actually write and develop in these languages? Ruby made a stand in this and it turned out very very well.
        tspiteri 17y ago
        gofmt is not a function name, it does not appear in code, it is a command line tool. In many cases you type something like "gofmt -w filename.go", press Enter, and then it's gone, never to be read. In the language itself, fmt (something completely different from gofmt) is used as a package identifier. In the Go style, package identifiers are typed repeatedly, the identifiers inside a package are not imported into the global namespace. So if code contains many calls to the Printf function, there will be many instances of fmt.Printf. In this case, fmt instead of format is a good decision too. It's a package name (not a function name) and it is typed repeatedly, so the shorter it is, the less visual noise.
        aaronblohowiak 17y ago
        I believe in determining brevity by number of tokens, not the length of the tokens themselves. application names are just as important as function names, especially when you are automating your workflows. fmt.Printf is exactly the kind of crap that I hate. format.PrintFormattedString() is readable. If you are calling it all the time, then i'd suggest you have an output() function local to your class that forwards the call on. This is good practice anyway because you should minimize the tight coupling of your object with a foreign object. If you watch the Go presentations, the examples using fmt are pronounced "fumt". fumt neither expresses the domain meaning or the implementation, and is perpetuating a bad habit.
        jongraehl 17y ago
        Great - you have a preference and gave some principles that define your aesthetic. I find your alternative to fmt.printf to be horrifying, but then, I hate Objective C and plenty of people love it. Fortunately, you can have it your way by using gofmt to show you format.PrintFormattedString() when you edit, but give fmt.printf to the compiler. As for the command name, there's always "ln -s ~/bin/gofmt ~/bin/goformat" or "alias goformat gofmt".
    - mncaudill 17y ago
      It's legacy in the sense that there is a piece of software called "fmt," but I think this is the Go guys basically saying, "Here's our version of that."
      - ThinkWriteMute 17y ago
        I'm talking more about shortening words where they don't need to be shortened. For instance one of my beefs with Ruby (My main language) is: elsif. Would it really have been so difficult to have "elseif"? No.
        mncaudill 17y ago
        Your Ruby example is to help the developer. Let's say you are skimming your code. Are you going to quickly and easily see the difference between "elseif" and "else if"? Creating a new word, while superficially unwieldly, keeps you from wasting valuable time debugging one of those "d'oh!" bugs.
        ThinkWriteMute 17y ago
        And the developer who writes "elseif" instead of "elsif" because "else" is a word and "els" isn't? Sorry that argument works both ways.
        mncaudill 17y ago
        What I'm saying is that if "else" and "elseif" were both in the grammar (and "elsif" didn't exist), you could have typed "else if" when you meant to type "elseif" and vice-versa and the mistake could easily be overlooked as your code would be syntactically correct, parsing and running and doing the wrong thing. Now, in Ruby, if you type "elseif" your code will not run. Problem avoided. The point of Ruby's "elsif" and Python's "elif" is to have visually disparate representations of the two kinds of code blocks (that have different control flows!) that a developer could easily overlook. The difference is there to help out you and every other developer that use languages that don't use a visible token to separate code blocks, I promise.
    - cpr 17y ago
      Yes, it's a legacy style from the old K&R folks themselves. I appreciate it; it's become an aesthetic, actually.
      - ThinkWriteMute 17y ago
        It's the kind of behavior that needs to get left behind. goformat is easier to understand than 'gofmt'. 3 characters.
        gloob 17y ago
        It's the kind of behavior that needs to get left behind. Why? This smacks of religion to me. goformat is easier to understand than 'gofmt'. Only if you can't be arsed to learn the language or tools. If the fact that the tool has a different name than you would like is that troublesome, symlink or alias it. Would it be better if I had to type out 'secure-file-transport-protocol' in the shell instead of 'sftp'?
        ThinkWriteMute 17y ago
        Yes, compare the 31 character to 4 character acronym to something that isnt: An acronym or very long at all.
        aaronblohowiak 17y ago
        "Why? This smacks of religion to me." The dogma of explicit names is preferable to the dogma of legacy. "Only if you can't be arsed to learn the language or tools." I contend that resolving fmt to format increases the complexity in reading and learning Go. Complexity is only tolerable when it provides benefit. The two proposed benefits are token brevity and legacy. I do not believe that preserving the legacy names of commands and packages is a benefit for a "new systems programming language" that is intended to replace the very legacy it is preserving.
        jongraehl 17y ago
        What a fantastic bikeshed* we have here. * http://en.wikipedia.org/wiki/Parkinsons_Law_of_Triviality http://en.wikipedia.org/wiki/Parkinsons_Law_of_Triviality
    - dchest 17y ago
      Why did you write "we're" instead of "we are"? Is this some kind of legacy stuff?
bmm6o 17y ago
Using a formatter to easily manage breaking language changes is really clever. I was just reading Pike's interview in Coders at Work where he talked about how all the language changes in the early days of C++ drove him off. This should help Google build up a community while still allowing flexibility.
- wglb 17y ago
  Perhaps you mean Ken Thompson?
marketer 17y ago
One problem with this is that it enforces certain styles upon the programmer. For instance, this function won't compile in go: func main() { println("hello world") } Instead, if you run gofmt -w on the above code, you get this: func main() { println("hello world!") } This compiles fine, but it looks ugly.
- omouse 17y ago
  Maybe we can treat Go like assembly language then. Made for a computer to run, not for a person to read. So we'll need a higher level language and less ugly language than Go to write Go.
  - lsb 17y ago
    Yes, but that's hardly an auspicious beginning to a language.
- dchest 17y ago
  Are you sure the first one doesn't compile (provided that you change println to fmt.Println, of course)? I can compile (with 6g) the hello world example from golang.org with any brace indentation style.
  - marketer 17y ago
    Make sure you're running the latest parser code; do an 'hg sync' on the go tree. Or you can read the relevant mailing list thread: http://groups.google.com/group/golang-nuts/browse_thread/thread/9eb0c7c1f20db921 http://groups.google.com/group/golang-nuts/browse_thread/thr...
    - dchest 17y ago
      Ha-ha, you're right, thanks for the link! I think this is really bad.
- JulianMorrison 17y ago
  func main() { is read as: func main(); { due to the new semicolon-inserting lexer rules. If you use the gofmt style, you won't notice this breaking change.
DannoHung 17y ago
I don't get it. It's a parser that does the output in a particular pretty printed format? If you knew that you wanted to do that from the start, wouldn't you write your compiler parser to be a separate piece of code? Also, banner indenting style is superior!
- gnosis 17y ago
  I also wonder what all the hoopla is about. So Go now has a prettyprinter. Big f'ing deal. Welcome to the 1980's.
JulianMorrison 17y ago
I love gofmt. I love specifically that in any silly bikeshed-painting argument about code styles, the answer will be "gofmt is definitive, and this conversation is over". If you think it makes mistakes, file a bug. If you don't like it, soldier on. Familiarity will dull the pain. Oh and, that -r pattern-matching search-and-replace is nice.

Researchrsc: Gofmt

33 points by bandris 17y ago

aaronblohowiak 17y ago

Why the legacy "fmt" instead of "format" ? Go is a new language, why be held back by the old name conventions?

tspiteri 17y ago
Because it's shorter.
- ThinkWriteMute 17y ago
  We're not on 80 character terminals anymore. Harddrives are larger than 1.4mb. People need to read this stuff. "It's shorter" isn't a reason, it's a legacy.
  - tspiteri 17y ago
    When using the command line, shorter commands are easier to type. I know, two key strokes are not going to take a lot of time, but when you do it repeatedly, it does feel a bit more comfortable. It has nothing to do with 80 character limits. And in what way do people need to read "gofmt"? They need to type it, not read it.
    - ThinkWriteMute 17y ago
      I guess I forgot that newbies never read code to learn from it? Or when someone is updating or maintaining old code? Crazy talk! Look there's no excuse here. goformat isn't that much larger than gofmt, easier to understand on initial read, and doesn't hurt a damn thing. If Computers have no problem reading Brainfuck then they should have no problem reading a Programming Language that reads easily to humans. You know, those things that actually write and develop in these languages? Ruby made a stand in this and it turned out very very well.
      - tspiteri 17y ago
        gofmt is not a function name, it does not appear in code, it is a command line tool. In many cases you type something like "gofmt -w filename.go", press Enter, and then it's gone, never to be read. In the language itself, fmt (something completely different from gofmt) is used as a package identifier. In the Go style, package identifiers are typed repeatedly, the identifiers inside a package are not imported into the global namespace. So if code contains many calls to the Printf function, there will be many instances of fmt.Printf. In this case, fmt instead of format is a good decision too. It's a package name (not a function name) and it is typed repeatedly, so the shorter it is, the less visual noise.
        aaronblohowiak 17y ago
        I believe in determining brevity by number of tokens, not the length of the tokens themselves. application names are just as important as function names, especially when you are automating your workflows. fmt.Printf is exactly the kind of crap that I hate. format.PrintFormattedString() is readable. If you are calling it all the time, then i'd suggest you have an output() function local to your class that forwards the call on. This is good practice anyway because you should minimize the tight coupling of your object with a foreign object. If you watch the Go presentations, the examples using fmt are pronounced "fumt". fumt neither expresses the domain meaning or the implementation, and is perpetuating a bad habit.
        jongraehl 17y ago
        Great - you have a preference and gave some principles that define your aesthetic. I find your alternative to fmt.printf to be horrifying, but then, I hate Objective C and plenty of people love it. Fortunately, you can have it your way by using gofmt to show you format.PrintFormattedString() when you edit, but give fmt.printf to the compiler. As for the command name, there's always "ln -s ~/bin/gofmt ~/bin/goformat" or "alias goformat gofmt".
  - mncaudill 17y ago
    It's legacy in the sense that there is a piece of software called "fmt," but I think this is the Go guys basically saying, "Here's our version of that."
    - ThinkWriteMute 17y ago
      I'm talking more about shortening words where they don't need to be shortened. For instance one of my beefs with Ruby (My main language) is: elsif. Would it really have been so difficult to have "elseif"? No.
      - mncaudill 17y ago
        Your Ruby example is to help the developer. Let's say you are skimming your code. Are you going to quickly and easily see the difference between "elseif" and "else if"? Creating a new word, while superficially unwieldly, keeps you from wasting valuable time debugging one of those "d'oh!" bugs.
        ThinkWriteMute 17y ago
        And the developer who writes "elseif" instead of "elsif" because "else" is a word and "els" isn't? Sorry that argument works both ways.
        mncaudill 17y ago
        What I'm saying is that if "else" and "elseif" were both in the grammar (and "elsif" didn't exist), you could have typed "else if" when you meant to type "elseif" and vice-versa and the mistake could easily be overlooked as your code would be syntactically correct, parsing and running and doing the wrong thing. Now, in Ruby, if you type "elseif" your code will not run. Problem avoided. The point of Ruby's "elsif" and Python's "elif" is to have visually disparate representations of the two kinds of code blocks (that have different control flows!) that a developer could easily overlook. The difference is there to help out you and every other developer that use languages that don't use a visible token to separate code blocks, I promise.
  - cpr 17y ago
    Yes, it's a legacy style from the old K&R folks themselves. I appreciate it; it's become an aesthetic, actually.
    - ThinkWriteMute 17y ago
      It's the kind of behavior that needs to get left behind. goformat is easier to understand than 'gofmt'. 3 characters.
      - gloob 17y ago
        It's the kind of behavior that needs to get left behind. Why? This smacks of religion to me. goformat is easier to understand than 'gofmt'. Only if you can't be arsed to learn the language or tools. If the fact that the tool has a different name than you would like is that troublesome, symlink or alias it. Would it be better if I had to type out 'secure-file-transport-protocol' in the shell instead of 'sftp'?
        ThinkWriteMute 17y ago
        Yes, compare the 31 character to 4 character acronym to something that isnt: An acronym or very long at all.
        aaronblohowiak 17y ago
        "Why? This smacks of religion to me." The dogma of explicit names is preferable to the dogma of legacy. "Only if you can't be arsed to learn the language or tools." I contend that resolving fmt to format increases the complexity in reading and learning Go. Complexity is only tolerable when it provides benefit. The two proposed benefits are token brevity and legacy. I do not believe that preserving the legacy names of commands and packages is a benefit for a "new systems programming language" that is intended to replace the very legacy it is preserving.
        jongraehl 17y ago
        What a fantastic bikeshed* we have here. * http://en.wikipedia.org/wiki/Parkinsons_Law_of_Triviality http://en.wikipedia.org/wiki/Parkinsons_Law_of_Triviality
  - dchest 17y ago
    Why did you write "we're" instead of "we are"? Is this some kind of legacy stuff?

bmm6o 17y ago

Using a formatter to easily manage breaking language changes is really clever. I was just reading Pike's interview in Coders at Work where he talked about how all the language changes in the early days of C++ drove him off. This should help Google build up a community while still allowing flexibility.

wglb 17y ago
Perhaps you mean Ken Thompson?

marketer 17y ago

One problem with this is that it enforces certain styles upon the programmer. For instance, this function won't compile in go: func main() { println("hello world") } Instead, if you run gofmt -w on the above code, you get this: func main() { println("hello world!") } This compiles fine, but it looks ugly.

omouse 17y ago
Maybe we can treat Go like assembly language then. Made for a computer to run, not for a person to read. So we'll need a higher level language and less ugly language than Go to write Go.
- lsb 17y ago
  Yes, but that's hardly an auspicious beginning to a language.
dchest 17y ago
Are you sure the first one doesn't compile (provided that you change println to fmt.Println, of course)? I can compile (with 6g) the hello world example from golang.org with any brace indentation style.
- marketer 17y ago
  Make sure you're running the latest parser code; do an 'hg sync' on the go tree. Or you can read the relevant mailing list thread: http://groups.google.com/group/golang-nuts/browse_thread/thread/9eb0c7c1f20db921 http://groups.google.com/group/golang-nuts/browse_thread/thr...
  - dchest 17y ago
    Ha-ha, you're right, thanks for the link! I think this is really bad.
JulianMorrison 17y ago
func main() { is read as: func main(); { due to the new semicolon-inserting lexer rules. If you use the gofmt style, you won't notice this breaking change.

DannoHung 17y ago

I don't get it. It's a parser that does the output in a particular pretty printed format? If you knew that you wanted to do that from the start, wouldn't you write your compiler parser to be a separate piece of code? Also, banner indenting style is superior!

gnosis 17y ago
I also wonder what all the hoopla is about. So Go now has a prettyprinter. Big f'ing deal. Welcome to the 1980's.

JulianMorrison 17y ago

I love gofmt. I love specifically that in any silly bikeshed-painting argument about code styles, the answer will be "gofmt is definitive, and this conversation is over". If you think it makes mistakes, file a bug. If you don't like it, soldier on. Familiarity will dull the pain. Oh and, that -r pattern-matching search-and-replace is nice.