4 ms·

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?

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?