7 ms·
> because all existing implementations are bad I'm also not sure why in OOP-land, generics are this crazy experimental weird feature, when in functional langua
by grumdan 7y ago
> because all existing implementations are bad
I'm also not sure why in OOP-land, generics are this crazy experimental weird feature, when in functional languages, people figured out how to implement parametric polymorphism (the original term for generics) in quite reasonable ways. I get that subtyping adds some complexity, but overall I don't understand why such a basic way to build abstractions is so controversial in (some) OOP languages. If anyone has some context on why this is more difficult to have in Java-like languages, I'd be curious to hear it.
- RivieraKid 7y ago> I'm also not sure why in OOP-land, generics are this crazy experimental weird feature It's not, it's an essential, basic feature.
- evmar 7y agoThat's a really great question! One other factor is that functional languages typically are theory first, implementation second, while non-functional languages tend to more often have the language features follow whatever the implementation admits. I know for Go they fretted a lot about how you'd efficiently compile generics, which is not something that comes up when you're designing System F or whatever. But I believe that subtyping has a massive impact on generics, particularly in OOP languages where people expect to use lots of subtypes. There are all of these new questions around not only bounded polymorphism but also variance and mutability and how inference works. Even TypeScript, which is following a lot of the design decisions already established by C# with the same person behind both, is still kinda just meandering around the design space and continuing to make changes to the semantics in new versions.
- iainmerrick 7y agoJust to be clear, I don’t think all existing implementations are bad, that was my (possibly unfair) caricature of the Go devs’ position.
- deleted 7y ago[deleted]
- pvg 7y agoI can't think of a popular OO language where they are considered a crazy experimental feature. One historical reason for a certain reticence early on was people were unhappy with C++ templates.
- baby 7y agoIt makes code unreadable. void lol<A, <B, C<D>>, E>()
- Negitivefrags 7y agoThat isn't even close to valid C++.
- username90 7y agoIt is a valid template specialization declaration if you add template<> in front, like this: template<> void lol<A, <B, C<D>>, E>()
- filleduchaos 7y agoPretty much all syntax is unreadable if you don't know the lingo. For example, try presenting the ubiquitous for (int i = 0; i < 10; i++) {} to ten random people without prior programming experience and see how many of them can correctly tell you what all that means. Similarly, { a, b in a > b } is probably not very clear to people who don't write Swift and perfectly lovely closure syntax to people who do. There's language syntax that's actually unreadable, for instance due to using names that obscure or otherwise don't clearly express what a construct is/does or using the same operator/keyword for too many different context-dependent purposes. I don't quite think the sheer presence of angle brackets makes code unreadable, any more than the sheer presence of curly braces or parentheses do.
- baby 7y agoYou’re missing my point. While other syntactic elements can be learned, generics can be abused to make the code unreadable.
- Const-me 7y ago> generics can be abused to make the code unreadable All features can be abused to make the code unreadable. E.g. all modern languages have regular expressions in their standard libraries, despite complex regular expressions are essentially write-only code.
- gizmo686 7y agoInheritance makes generics difficult. For instance, if A < B (B extends A), What is the relationship betwern Array[A] and Array[B]? If you are just reading the array, you would want Array[A] < Array[B]. If you are writing to the array, you would want Array[B]<Array[A]. If you are doing both, you want Array[A] to have no relation to Array[B]. This problem doesn't come up in ML style languages because they do not make use of inheritence.
- justinhj 7y agoIt comes up in Scala. The solution is to have notation to specify the variance of types.
- gchpaco 7y agoAnd said notation causes the generic type system to be Turing complete, as in the Java case.
- norswap 7y agoI think it is Gilad Bracha that said, when the decision was made to include only covariance in Dart, that variance flies in the face of programmer's intuition. He's right. It's easy to understand one level of variance: you can replace a return type by a subtype and a parameter type by a supertype. (I wouldn't be surprised that many programmer don't undestand this.) Two levels already requires some deep thinking (assuming definition-site variance: `List<Object>` or `List<String>` as a return type / parameter type, was is allowed to replace it? More than that? (`List<List<String>>`) Hahaha, good luck. And by the way, Java has notations to specify the variance of type, but only at the use-site, which is different from doing it at the definition site (both enable expressing things the other can't do... but you can actually have both, as I think is the case in Kotlin, though there are some limitations).
- clhodapp 7y agoI'm not really sure what you mean. Variance just changes what is and is not a subtype/supertype. If List is covariant then List<T> is a subtype of List<U> if T is a subtype of U. So then, by induction, List<List<T>> is a subtype of List<List<U>> if T is a subtype of U. I'm not sure what's hilariously hard to follow here...
- hajile 7y agoIf go ever showed people the awesomeness of StandardML or Ocaml/ReasonML (and their amazing type systems), I think the language would lose a lot of users.
- weberc2 7y agoThis is confusingly phrased. Do you mean "If Go people were ever shown ... ML"? I would totally drop Go for an ML language if any of them had a sane syntax, usable build tooling (including native, static compilation by default), and a (single) decent standard library. A super awesome type system is worthless without the basic requirements for scalable software development.
- hajile 7y agoIf StandardML had even a fraction of the money behind go, there would simply be no contest. Ocaml is billed as the pragmatic ML, but the syntax really sucks and nominally typed structs aren't nearly as good. They also have 3 competing standard libraries. Haskell is too ivory tower. Most devs simply can't be bothered. StandardML is that awesome middle. The language choices are pragmatic compared to haskell (mutable refs, side effects, and not lazy). The syntax is super simple and consistent (unlike ocaml). The concurrent ML extensions offer good multi-threading (still waiting on ocaml). The mlton compiler is very fast. There's only one standard library and it's decent. The big thing holding the language back is third-party libraries. If Google threw their millions at SML instead of go, SML really would be better in every way.
- ernst_klim 7y ago>nominally typed structs aren't nearly as good OCaml structs are structurally typed. > They also have 3 competing standard libraries. There is only one standard library, stdlib.
- rndmio 7y agoYou know what he meant, if you want functionality comparable to the Go stdlib you are going to have to choose between Core or Batteries, then for async do you choose Async or Lwt? And as said the build system (when you're used to Go) is poor. I like a lot of what OCaml offers, but there's a lot of friction.
- idnefju 7y agoad-hoc polymorphism is where it shines. Such as the typeclass in Haskell or modules in OCaml
- kragen 7y agoGolang doesn't have subtyping.