4 ms·

> The argument is that simpler is better at scale. Parametric polymorphism is simple and well understood. And not exactly new either: it has been understood fo

> The argument is that simpler is better at scale. Parametric polymorphism is simple and well understood. And not exactly new either: it has been understood for some 40 years already. > I could see an argument for parametric collections and parametric sorting in Go. C++'s <algorithm> header is proof that there are lots of algorithms that benefit from being expressed generically, not just sorting. > In your experience, what kind of "cost" has there been in unsafe casting to use collections? Without type safety, there's a disincentive for decomposing things into smaller parts, because the cost of manually verifying that the parts are compatible is greater than the benefits of decoupling them. Would a Go programmer even dream of bootstrapping fancy data structures from simpler ones? > Even in environments like Smalltalk, where all use of collections amounts to "unsafe casting," I've rarely seen situations where a mistake of this type wasn't found trivially. At scale, the law of large numbers says that even improbable events will occur every now and then. Unfortunately, a program with even one bug is still incorrect.

stcredzero 10y ago
Would a Go programmer even dream of bootstrapping fancy data structures from simpler ones? What use is there for a fancy data structure? In practice, these occasions aren't that common. Many "fancy" data structures tend to exhibit bad cache behaviors if implemented naively. At scale, the law of large numbers says that even improbable events will occur every now and then. Unfortunately, a program with even one bug is still incorrect. Are you an undergraduate? Depending on how you interpret the spec (which isn't cut and dried when business requirements meet the real world) almost every page of production code has some kind of bug in it. Also, the law of large numbers isn't that relevant for most codebases and developer populations -- the numbers aren't that large. The effect of hubris is much larger in practice.
- catnaroek 10y ago
  > What use is there for a fancy data structure? Improving asymptotic bounds. Providing functionality typically not supported by common data structures. (e.g., I want a key-value container that's a priority queue on keys, but concatenates multiple values associated to the same key) > Are you an undergraduate? No. > Also, the law of large numbers isn't that relevant for most codebases and developer populations The law of large numbers certainly applies to >100 KLOC codebases, unless your bug rates are somehow magically two or three orders of magnitude lower than the average.
  - stcredzero 10y ago
    > Improving asymptotic bounds. Providing functionality typically not supported by common data structures. It's nice to know that you remember stuff from the textbook. However, how often do you need to do something like this for real production code? Depending on what it is you normally do, it's entirely possible that you need to do this every other project. It's also possible that you never have a real need to do these things. (It's also possible that you never have a real need to do these things, but you do them anyways, which is far, far worse.) > The law of large numbers certainly applies to >100 KLOC codebases, unless your bug rates are somehow magically two or three orders of magnitude lower than the average. True, which is why I'm pretty confident that 15 years of Smalltalk development on many large code bases without running into a heterogeneous collection debugging conundrum is possibly a valid data point. Contrast that with an endless parade of "hubris coding" in the same timeframe. My impression is that the damage caused by "hubris coding," or the gratuitous worship of "cleverness," far outweighs that caused by insufficient type information by 2 or 3 orders of magnitude. If you're going to be clever about applying your clever, you need to apply it in a fashion where it gives your company's business the biggest bang for the buck. Most coders in their 20's are just trying to impress their fellow programmers.
    - catnaroek 10y ago
      > It's also possible that you never have a real need to do these things. What I don't have a real need for is the ability to destroy the internal invariants of other modules. :-p > True, which is why I'm pretty confident that 15 years of Smalltalk development on many large code bases without running into a heterogeneous collection debugging conundrum is possibly a valid data point. Who says homogeneous collections are the only use case for parametricity? Parametricity is useful whenever you need to make sure that unrelated parts of your program don't accidentally rely on (or, even worse, alter) each other's implementation details. “Modularity”, as they call it elsewhere. Of course, Smalltalk has none of this. > My impression is that the damage caused by "hubris coding," or the gratuitous worship of "cleverness," far outweighs that caused by insufficient type information by 2 or 3 orders of magnitude. I don't separate concerns to be “clever”. Au contraire! I separate concerns to deal with my own brain's limited ability to simultaneously process multiple pieces of information. (And I'll be perfectly honest: I also separate concerns because it's beautiful.) “Hubris” is a term I would reserve for those who write large programs whose constituent parts don't have fixed structure, yet claim they understand what's going on in the code. (Or perhaps they claim “the tests do the understanding”?)

stcredzero 10y ago

Would a Go programmer even dream of bootstrapping fancy data structures from simpler ones? What use is there for a fancy data structure? In practice, these occasions aren't that common. Many "fancy" data structures tend to exhibit bad cache behaviors if implemented naively. At scale, the law of large numbers says that even improbable events will occur every now and then. Unfortunately, a program with even one bug is still incorrect. Are you an undergraduate? Depending on how you interpret the spec (which isn't cut and dried when business requirements meet the real world) almost every page of production code has some kind of bug in it. Also, the law of large numbers isn't that relevant for most codebases and developer populations -- the numbers aren't that large. The effect of hubris is much larger in practice.

catnaroek 10y ago
> What use is there for a fancy data structure? Improving asymptotic bounds. Providing functionality typically not supported by common data structures. (e.g., I want a key-value container that's a priority queue on keys, but concatenates multiple values associated to the same key) > Are you an undergraduate? No. > Also, the law of large numbers isn't that relevant for most codebases and developer populations The law of large numbers certainly applies to >100 KLOC codebases, unless your bug rates are somehow magically two or three orders of magnitude lower than the average.
- stcredzero 10y ago
  > Improving asymptotic bounds. Providing functionality typically not supported by common data structures. It's nice to know that you remember stuff from the textbook. However, how often do you need to do something like this for real production code? Depending on what it is you normally do, it's entirely possible that you need to do this every other project. It's also possible that you never have a real need to do these things. (It's also possible that you never have a real need to do these things, but you do them anyways, which is far, far worse.) > The law of large numbers certainly applies to >100 KLOC codebases, unless your bug rates are somehow magically two or three orders of magnitude lower than the average. True, which is why I'm pretty confident that 15 years of Smalltalk development on many large code bases without running into a heterogeneous collection debugging conundrum is possibly a valid data point. Contrast that with an endless parade of "hubris coding" in the same timeframe. My impression is that the damage caused by "hubris coding," or the gratuitous worship of "cleverness," far outweighs that caused by insufficient type information by 2 or 3 orders of magnitude. If you're going to be clever about applying your clever, you need to apply it in a fashion where it gives your company's business the biggest bang for the buck. Most coders in their 20's are just trying to impress their fellow programmers.
  - catnaroek 10y ago
    > It's also possible that you never have a real need to do these things. What I don't have a real need for is the ability to destroy the internal invariants of other modules. :-p > True, which is why I'm pretty confident that 15 years of Smalltalk development on many large code bases without running into a heterogeneous collection debugging conundrum is possibly a valid data point. Who says homogeneous collections are the only use case for parametricity? Parametricity is useful whenever you need to make sure that unrelated parts of your program don't accidentally rely on (or, even worse, alter) each other's implementation details. “Modularity”, as they call it elsewhere. Of course, Smalltalk has none of this. > My impression is that the damage caused by "hubris coding," or the gratuitous worship of "cleverness," far outweighs that caused by insufficient type information by 2 or 3 orders of magnitude. I don't separate concerns to be “clever”. Au contraire! I separate concerns to deal with my own brain's limited ability to simultaneously process multiple pieces of information. (And I'll be perfectly honest: I also separate concerns because it's beautiful.) “Hubris” is a term I would reserve for those who write large programs whose constituent parts don't have fixed structure, yet claim they understand what's going on in the code. (Or perhaps they claim “the tests do the understanding”?)