21–26 of 26 posts
It's worth noting that "slow compilation" often translates directly into "slow programmers".
What's wrong with using both approaches: debug binaries get compiled with boxing generics, while release compiles using macros?
I'd like to hear a compelling justification for generics in a language where you can add methods to any type, and every type implements an interface just by implementing all of the methods. I suspect that all of the reasons have to do with compile-time checks. (But in the domains where I do my work, it's fine to get by with runtime checking, so I admit I don't have complete in-depth knowledge on the subject.) How abo…
Having a vector or map collection where you can call methods etc. on elements without having to do a typecast, and know that the method call will work (i.e. is statically typed), is useful. It also stops you (or more likely, someone else on the team) from adding the wrong kind of thing to the collection. If you don't understand the benefits of static typing, it's likely that you won't understand why generics can be p…
Well, thanks. I do understand the benefits modulo refactoring. How about answering the question?
It also stops you (or more likely, someone else on the team) from adding the wrong kind of thing to the collection.
I just don't see this sort of thing. Maybe I've been lucky. But I've worked as a consultant for the vendor of a couple of Smalltalk implementations. I've been at many dozens of sites. I've worked as a programmer in 5 different development shops. I just don't see this happening a whole lot. If anything, I see unexpected things shoved into instance variables sometimes, but that's it, and it's just not that common.
It's not that I don't see the potential benefits of static typing. I just don't see the cost-benefit being that compelling.
Now, back to refactoring. I've often cursed not having the type annotations in the middle of a refactoring. But that's always been not knowing what's in some instance variable or temporary. With one exception, I've never cursed about not knowing what's in some collection -- and that had nothing to do with the collection! Maybe I've just been lucky and worked in shops where everyone knew heterogeneous collections aren't that great an idea?
Earlier quoted context omitted.
Having a vector or map collection where you can call methods etc. on elements without having to do a typecast, and know that the method call will work (i.e. is statically typed), is useful. It also stops you (or more likely, someone else on the team) from adding the wrong kind of thing to the collection. If you don't understand the benefits of static typing, it's likely that you won't understand why generics can be p…
If you don't understand the benefits of static typing, it's likely that you won't understand why generics can be preferable to polymorphism in containers. Well, thanks. I do understand the benefits modulo refactoring. How about answering the question? It also stops you (or more likely, someone else on the team) from adding the wrong kind of thing to the collection. I just don't see this sort of thing. Maybe I've been…
Now you are not talking about generics in Go, but a major philosophical position in programming language theory. I think your question is disingenuous. It is because you don't understand why some people prefer static typing that you don't understand the need for generics. Until you do understand that, you'll remain unenlightened with respect to generics.
Earlier quoted context omitted.
If you don't understand the benefits of static typing, it's likely that you won't understand why generics can be preferable to polymorphism in containers. Well, thanks. I do understand the benefits modulo refactoring. How about answering the question? It also stops you (or more likely, someone else on the team) from adding the wrong kind of thing to the collection. I just don't see this sort of thing. Maybe I've been…
> It's not that I don't see the potential benefits of static typing. I just don't see the cost-benefit being that compelling. Now you are not talking about generics in Go, but a major philosophical position in programming language theory. I think your question is disingenuous. It is because you don't understand why some people prefer static typing that you don't understand the need for generics. Until you do understa…
Specifically, I'm asking about people's actual experience. My question is sincere. I am not interested in people's preferences or their "philosophy". What is their experience? Also note that I allude above to having cursed the lack of types in Smalltalk at times. This doesn't seem so significant for collections.
I'm asking: Is putting the wrong thing into a collection really such a big deal? What is the actual experience? I gave mine. What's yours?
EDIT: Wow, it seems like just mentioning "static typing" should now be included in "Godwin's Law"! Rational discussion has become impossible!
Earlier quoted context omitted.
There are a whole host of ways that Haskell supports (or has been extended to support) generic programming. There's a big overview here: http://www.haskell.org/haskellwiki/Research_papers/Generics In the simplest case, generic programming in Haskell is done using type classes (similar to OO "interfaces"), often with the GHC extension for derivable type classes. If I understand correctly, this is generally implemented…
No, the simplest case for Haskell would be type variables. For example, the map function doesn't need typeclasses at all: map :: (a -> b) -> [a] -> [b] For the record, in Go+generics, this might look something like: func map (f func (A) B, xs A[]) B[] { ... }