5 ms·

We also have the hard-earned lessons of taking DRY to its extreme (left-pad). Where you draw the "copy a little code" line is subjective.

danellis 10y ago
Exactly what lesson do you think was learned? Do you think that languages that have had left-padding functionality in their standard library since forever (and there are lots of them) are going to remove it now? There was definitely a lesson to be learned there, but it wasn't the one you're implying.
- Ericson2314 10y ago
  Yay sanity! All the anti-code reuses have taken the opportunity to come out of hiding, but they're no less wrong. The aggressive code reuse in the node ecosystem is, and remains, the quality of it I respect the most.
danieldk 10y ago
First of all, generics is hardly DRY to its extreme. I think that everyone agrees that copying e.g. a balancing red-black tree implementation just to specialize it for another value type is a pretty bad idea. So then you either end up with some kind of runtime polymorphism or parametric polymorphism. Some Go users argue that runtime polymorphism is enough, but you often run into cases where you have a func frobber(s []SomeInterface) ... However, you end up having a []ConcreteType where ConcreteType implements SomeInterface. However, you cannot simply pass a []ConcreteType to frobber because the memory representation is different and you have to construct a new slice with the interface type, etc. Also, I don't think left-pad is an example of extreme DRY (though it should be part of a standard library). It's not an example of extreme DRY, because I think a substantial amount of programmers wil implement it incorrectly. As long as many Java-wielding friends still believe that a single char can represent any unicode code point, I have no reason to believe that the average monolingual English-speaking Go programmer will realize that you can't simply do something like: padLen := targetLen - len(str) (BTW, Go's fmt package provides padding.)
- madawan 10y ago
  The way I work is, I make an interface{} red-black-tree, and then when I need to store things in it I create functions around it. Suppose I'm storing Tiles in a Level: the Level struct will contain a (private) RedBlackTree and I'll define GetTile(Pos) Tile and PutTile(Pos, Tile) on Level which do the casting to and from interface{}. I still have type safety since I cannot put/get anything but Tiles in the RedBlackTree. But I didn't need generics.
  - danieldk 10y ago
    From your description, it is not completely clear what you are ordering on, but typically in an RB tree you (at the very least) want to require some interface/function that specifies ordering and equality. Of course, in some cases you can do casting on your interface boundaries. But in many other cases this is not possible, e.g. if you want the API to return an ordered set or map.
  - fauigerzigerk 10y ago
    You can only do that in places where you don't care about memory usage at all.
prodigal_erik 10y ago
The left-pad debacle was due to tools encouraging a badly non-hermetic build process and devs not being wise enough to resist, not DRY. Only depending on one third-party library won't save you if you "upgrade" to a broken version without testing.

danellis 10y ago

Exactly what lesson do you think was learned? Do you think that languages that have had left-padding functionality in their standard library since forever (and there are lots of them) are going to remove it now? There was definitely a lesson to be learned there, but it wasn't the one you're implying.

Ericson2314 10y ago
Yay sanity! All the anti-code reuses have taken the opportunity to come out of hiding, but they're no less wrong. The aggressive code reuse in the node ecosystem is, and remains, the quality of it I respect the most.

danieldk 10y ago

First of all, generics is hardly DRY to its extreme. I think that everyone agrees that copying e.g. a balancing red-black tree implementation just to specialize it for another value type is a pretty bad idea. So then you either end up with some kind of runtime polymorphism or parametric polymorphism. Some Go users argue that runtime polymorphism is enough, but you often run into cases where you have a func frobber(s []SomeInterface) ... However, you end up having a []ConcreteType where ConcreteType implements SomeInterface. However, you cannot simply pass a []ConcreteType to frobber because the memory representation is different and you have to construct a new slice with the interface type, etc. Also, I don't think left-pad is an example of extreme DRY (though it should be part of a standard library). It's not an example of extreme DRY, because I think a substantial amount of programmers wil implement it incorrectly. As long as many Java-wielding friends still believe that a single char can represent any unicode code point, I have no reason to believe that the average monolingual English-speaking Go programmer will realize that you can't simply do something like: padLen := targetLen - len(str) (BTW, Go's fmt package provides padding.)

madawan 10y ago
The way I work is, I make an interface{} red-black-tree, and then when I need to store things in it I create functions around it. Suppose I'm storing Tiles in a Level: the Level struct will contain a (private) RedBlackTree and I'll define GetTile(Pos) Tile and PutTile(Pos, Tile) on Level which do the casting to and from interface{}. I still have type safety since I cannot put/get anything but Tiles in the RedBlackTree. But I didn't need generics.
- danieldk 10y ago
  From your description, it is not completely clear what you are ordering on, but typically in an RB tree you (at the very least) want to require some interface/function that specifies ordering and equality. Of course, in some cases you can do casting on your interface boundaries. But in many other cases this is not possible, e.g. if you want the API to return an ordered set or map.
- fauigerzigerk 10y ago
  You can only do that in places where you don't care about memory usage at all.

prodigal_erik 10y ago

The left-pad debacle was due to tools encouraging a badly non-hermetic build process and devs not being wise enough to resist, not DRY. Only depending on one third-party library won't save you if you "upgrade" to a broken version without testing.