Hacker News Reader

Comment by rmcpherson | Hacker News Reader

> Visibility (public/private) is done via the capitalization of the field, method, or type name. This sort of restriction doesn't hinder usability, but it's quite annoying.

While the capitalization of identifiers may be surprising, in practice it is one of the best features of go in my experience because no additional context is needed to know whether an identifier is exported. In rust, as far as I can tell, it is not possible without referring to the declaration.

As far as globally changing whether an identifier is exported, it is easy with the gorename tool, no search and replace necessary. Gorename also updates any references to the identifier in other packages in $GOPATH. https://godoc.org/golang.org/x/tools/cmd/gorename

View on HN

no additional context is needed to know whether an identifier is exported

Isn't this the same as the argument for Hungarian Notation? And isn't it a bit of a slippery slope? Why not add an 'i' for integers, so that no additional context is needed to know whether a variable is an integer. Etc.

There is a lot of information about a particular identifier that it would be nice to know at any given time, and in my opinion it's arbitrary to pick just one and make it a language rule. A much better solution is for to use IDEs or text editor plugins to visually show (using color, formatting, bits of UI) that information in a user-configurable and context-dependent way.

In defence of hungarian notation, the way Joel tells it makes a lot of sense [0]:

"Simonyi’s original concept for Hungarian notation was called, inside Microsoft, Apps Hungarian, because it was used in the Applications Division, to wit, Word and Excel. In Excel’s source code you see a lot of rw and col and when you see those you know that they refer to rows and columns. Yep, they’re both integers, but it never makes sense to assign between them. In Word, I'm told, you see a lot of xl and xw, where xl means “horizontal coordinates relative to the layout” and xw means “horizontal coordinates relative to the window.” Both ints. Not interchangeable. In both apps you see a lot of cb meaning “count of bytes.” Yep, it’s an int again, but you know so much more about it just by looking at the variable name. It’s a count of bytes: a buffer size. And if you see xl = cb, well, blow the Bad Code Whistle, that is obviously wrong code, because even though xl and cb are both integers, it’s completely crazy to set a horizontal offset in pixels to a count of bytes."

It's actually a practice I now use myself in certain contexts.

[0] http://www.joelonsoftware.com/articles/Wrong.html

Aside: Instead of hungarian notation in Rust we do this[0]. Free compile time unit safety :)

[0]: https://blog.mozilla.org/research/2014/06/23/static-checking...

Note, you can do this easily in Go, too:

    type Kelvin int
    type Celcius int

    func SetReactorTemp(temp Celcius) {}

    func GetOperatingTemp() Kelvin {}
 
    temp := GetOperatingTemp()
    SetReactorTemp(temp) // compile error

You can, but it quickly becomes infuriating in a language without generics, because you have to repeat any data structure that you want to potentially contain different kinds of temperatures.

I won't get into it on generics other than to say, in my 2 years of full time development in Go, not having them has not been a big deal.... and no I don't use type unsafe code everywhere either.

This is so exactly the argument for a decent type system that seeing it used to argue for a naming convention is downright surreal.

Yes, a good type system would help with these issues, but that's not the only way to crack this egg. I mostly work in Python, so it's not an option, but even if it were, using types for this stuff is probably a pretty heavy solution in some cases. Obviously, that depends on your type system, but for most of them having to define new types for different types of array indexes would bre really clumsy.

As soon as you open the types basket you have quite a lot of overhead that you didn't have before (it's a tradeoff, as ever). Not only that, but types won't help you on the readability front - not without an IDE. Spolskey's argument is that a naming convention can make the code look obviously wrong, and there's nothing wrong with that.

Hungarian notation has its place. I've used it before, and I'll do it again. Used correctly it can make the code safer and clearer. Types give you that too, but a naming convention is as simple as it gets, and it's free!

Why do you need the code to look obviously wrong when you have a compiler capable of telling you that it's wrong? It doesn't require a full-blown IDE to get fast feedback; I use a fairly lightweight vim config that gives me type-checking every time I save a file.

I also disagree about overhead. Defining new types is an O(1) cost, and decent modern languages should have type inference so that there isn't a recurring annotation cost either. Even accounting for the cost, if the benefit is 10 units and the cost is 1 unit, saying only that “it's a tradeoff” is a bit absurd. When there are tradeoffs, engineers don't throw up their hands and flip a coin, they calculate the costs and benefits and use the best solution. Types easily win in that calculation.

I don't disagree with using notation to fill the gaps when you must work in a weaker language, but we shouldn't pretend that it isn't a weakness.

I think maybe my comment sounded like I was advocating notation over types. I'm not, and I agree with everything you're saying.

I stand by my assertion that there are situations where a little notation is a good thing.

A better argument for notation is the readability of the code (which I place a high value on). That's a place where the types don't help as much, but the notation does.

That post was what put me on the road to functional programming. I started using the Checkers Framework after reading it, and then graduated to Scala.

This is one of the cases where I like languages that allow extendable types.

Being able to declare that a variable is in radians, for example. (Bonus points if it can auto-convert.)

Go can do this easily:

    type Radians float
    type Degrees float

    func (r Radians) ToDegrees() Degrees {
        // maths here
    }

That's not what I mean by autoconverting.

I meant as in quite literally being able to use something of type Radians in something that expects Degrees and it "just works", and vice versa.

I dislike Go's overuse of "explicit being better than implicit", and this is no exception. It's supposedly to prevent bugs, but it adds so much more verbosity that half the time you're adding more bugs by the additional verbosity than you're fixing via the reduction of magic.

That's not auto convert. Scala implicit is auto convert.

Auto converting is an anti pattern. Explicit is better than implicit. Auto conversion is how mistakes get made. This is why modern languages don't let you implicitly convert from a string to an int, for example.

Sounds interresting! Could you provide a link? Can't seem to find anything relevant.

For a quick example, take C:

    typedef rad_f float;
    typedef degree_f float;

Although in C there's no way that I know of to do implicit conversion between the two.

The closest thing I've found to what I mean is C#'s implicit cast system:

http://nathan.ca/2014/02/type-rich-programming/

Thanks for the response. I was more thinking about languages which have mechanisms for this though. What did you mean by extendable types?

It's not the same.

In Hungarian Notation, the type is enforced by a declaration, but it's documented by the prefix.

In go, the enforcement and documentation are one and the same.

The Hungarian notation is informal and not enforced by compilers. You can easily do

>> bool iMyInt;

It's obviously wrong, but the compiler will happily compile it. When you declare the following in go:

>> type NotExported struct {}

You still know it's exported, no matter what BS the programmer writes.

I really like the idea of capitalization selecting public and private scope. However, how do they use protected scope?

There is no protected. There's no inheritance anyway.

Note that everything in the same package can access all the private stuff... so you do have some flexibility. You can write two types that reference each other's private data/functionality... they just need to be in the same package.

Reply on news.ycombinator.com