3 ms·

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

aidos 11y 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 11y 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 11y ago
  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.

lmm 11y ago

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.