Hacker News Reader

Comment by anton_gogolev | Hacker News Reader

Whar bothers me in Go (and Python and Ruby, for that matteR) is that there's a strange mix of human-friendly identifiers like ResponseWriter, ParseInt, etc. and old-style Unix'y ones, like stdout, strconv, Println. Wildly inconsistent.

I wonder if "creat" is a valid function call somewhere.

View on HN

I strongly agree.

That's one of the nice things about the .Net libraries, consistency within the naming and layout. Often times you could guess what something would be called and you would be correct.

Powershell took this one step further with their wonderful Verb-Noun pattern for everything: Get-Service, New-Service, Restart-Service, Start-Service, Stop-Service, and so on...

When I tried Go for the first time it was a marked improvement over for example C++, but the libraries are poorly laid out in my opinion, and the naming is hugely inconsistent. It is starting from a point of weakness, and I actually find classic C libraries a little better (C++ a lot worse), just because at least C is consistent with itself.

Seems like the Go designers thought saving characters was a more important design consideration than clarity. As if tab auto-completion wasn't a "thing."

Why is "ParseInt" OK, and "Println" or "strconv" not? ("strconv" has to be single-case because it's a package name). Both kinds of names are abbreviated. "Int" for "integer" is approximately as intuitive to developers as "str" is for "string".

The other examples you've provided mirror the Unix API; it would be more confusing to rename them, despite their unfortunate terseness.

Ok, ParseInt and Prinln are not as representative; I should've been more clear. Python's dict/getattr/setttr/iter/etc. and Ruby's unintuitive chop/chomp and PHP-style inconsistent readlines/to_i/to_f/String, plus "there's more than one way to do stuff" (next/succ are the only ones that come to mind ATM) are more representative.

As Someone1234 noted, this kind of inconsistency in a relatively new language is very puzzling.

Could you provide an example of the inconsistency in the Golang standard library? "ParseInt" versus "strconv" has a simple explanation: all package names are lowercase.

The inconsistency is, for instance, in abbreviated lowercased package names (is "format" really longer to type than "fmt", same for "bufio") with relatively "humane" camelcased class/function names like ReadLines. This, and an occasional "Itoa", which is neither here nor there.

stdout and friends should make sense to every developer. I don't think you have to have the library functions in sync with system calls and file descriptors.

FWIW, the Golang core developers regret using the old UNIX conventions in packages. I don't think it's viable at this stage to take them back, but they do agree that it doesn't fit the language well.

http://gophercon.sourcegraph.com/post/83845316771/panel-disc...

I think he only regrets having used upper case names for constants (os.O_RDONLY), which is not idiomatic Go.

The keywords thetruthofthematter, notwithstanding, and depiteallobjections are kind of hilarious though.

Old style posix identifiers are harder to learn, but I basically only have to learn them once.

And, honestly, they are not that hard to learn. Compared to the amount of time it takes to understand the semantics of "stdout", the time required to learn the spelling of "stdout" is nothing.

In a world where millions of Chinese programmers have to use keywords written in a foreign language who am I to complain?

There is little reason to expect that reforming POSIX spelling is going to be any more successful than reforming English spelling.

Abbreviations can be human-friendly as well if they are well-established.

This is a question of taste. Personally, I like "Unix'y" identifiers -- though as you say, they should at least be consistent.

Reply on news.ycombinator.com