4 ms·

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 Microso

by aidos 12y ago

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 http://www.joelonsoftware.com/articles/Wrong.html

TheLoneWolfling 12y ago
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.)
- NateDad 12y ago
  Go can do this easily: type Radians float type Degrees float func (r Radians) ToDegrees() Degrees { // maths here }
  - sukilot 12y ago
    That's not auto convert. Scala implicit is auto convert.
    - NateDad 12y ago
      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.
  - TheLoneWolfling 12y ago
    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.
- strictfp 12y ago
  Sounds interresting! Could you provide a link? Can't seem to find anything relevant.
  - TheLoneWolfling 12y ago
    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/ http://nathan.ca/2014/02/type-rich-programming/
    - strictfp 12y ago
      Thanks for the response. I was more thinking about languages which have mechanisms for this though. What did you mean by extendable types?
Manishearth 12y ago
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-of-units-in-servo/ https://blog.mozilla.org/research/2014/06/23/static-checking...
- NateDad 12y ago
  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
  - lmm 12y ago
    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.
    - NateDad 12y ago
      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.
nbouscal 12y ago
This is so exactly the argument for a decent type system that seeing it used to argue for a naming convention is downright surreal.
- aidos 12y ago
  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!
  - nbouscal 12y ago
    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.
    - aidos 12y ago

by aidos 12y ago

TheLoneWolfling 12y ago

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.)

NateDad 12y ago
Go can do this easily: type Radians float type Degrees float func (r Radians) ToDegrees() Degrees { // maths here }
- sukilot 12y ago
  That's not auto convert. Scala implicit is auto convert.
  - NateDad 12y ago
    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.
- TheLoneWolfling 12y ago
  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.
strictfp 12y ago
Sounds interresting! Could you provide a link? Can't seem to find anything relevant.
- TheLoneWolfling 12y ago
  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/ http://nathan.ca/2014/02/type-rich-programming/
  - strictfp 12y ago
    Thanks for the response. I was more thinking about languages which have mechanisms for this though. What did you mean by extendable types?

Manishearth 12y ago

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-of-units-in-servo/ https://blog.mozilla.org/research/2014/06/23/static-checking...

NateDad 12y ago
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
- lmm 12y ago
  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.
  - NateDad 12y ago
    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.

nbouscal 12y ago

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

aidos 12y ago
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!
- nbouscal 12y ago
  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.
  - aidos 12y ago