The issue is, that a "KeyValuePair<K, V>" (no matter if you implemented it
via generics or like you mention via interfaces) is a fundamentally useless
type and generics encourage people to add useless types. A "KeyValuePair<K,
V>" is a "struct { Key K, Value V }", plain and simple. It's not an
interface and it's not a generic type, it's simply a struct.
I agree, that generics are useful, but they seem to be mainly useful for
people who write "frameworks", not so much for people who write
"applications" and so far, go is pretty much a language for the latter.
Whenever people try to justify generics, they do it from a "I want to write
a framework" POV - and whenever I miss generics, I do because I'm currently
writing a framework of some kind.
Generics empower abstractions, but most programmers are very bad at
building abstractions, so if you make it easy to build abstractions, you
will end up with a lot of bad abstractions (have a look at java). So, to a
certain degree, the value of go is, to *not* make building abstractions
overly simple. That leads to abstractions being used only where they are
essential and being left out where they are superfluous. This is where
reduced cognitive overhead comes into play - limiting the levels of
abstractions that people need to deal with to the bare essentials. Java is
bloated and hard to use, not because the language is bad, but because it
has a history of programmers building bad abstractions into it which gets
stacked on top of each other. So, yes, if you compare a bad abstraction
using interfaces with a bad abstraction using generics, generics will, in
general, compare very well. But you just shouldn't build the bad
abstraction in the first place.
The second concern with complexity is the spec. The exact behavior and
semantics of generics need to be spec'ed and useful generics need a lot
specification. For example, the current rules for type inference can be
understood completely just by looking at a single expression and it's type
and it's correspondingly simple to implement and spec. Generics usually
need more powerful type inference methods to not be cumbersome, which will
take up a lot of space in the spec. As humans, just like computers, have
very little memory, the time it takes to understand the spec will grow
superlinear with the length of it, due to frequent cache misses, so a long
spec will significantly increase the time needed to learn the language. In
the same vein, to understand a language, you need to know about
interactions between it's different concepts, not just the concepts itself,
so the needed space and time complexity to learn a language also grows
quadratic in the number of concepts in the language (in general). All of
that contributes to why people are wary of adding new concepts to go - the
costs in terms of understanding and learning the language are huge and they
grow very much superlinear in the number of concepts added, so each added
concept must be carefully examined (I know go for years and I still learn
new things about interactions between different concepts all the time).
I sometimes miss generics, yes, but I also believe adding them will make
the language significantly harder to learn and will significantly worsen
the quality of go code in the wild, so it would likely eliminate the
reasons I like go currently (which is that go code is usually of
exceptionally high quality, uniform and easy to understand).
On Tue, Jun 21, 2016 at 5:06 PM, <andrew.mez...@gmail.com> wrote:
> >> What I mean is that most people who have followed the past generics
> discussions already know it's possible to implement them with efficient
> memory use and performance. So they don't need to worry much about that.
>
> Thank you for explanation.
>
> >> can they be implemented without making Go a much more complex language
> than it is now
>
> What is a measure of the syntax complexity in the Go language.
> What this means and how they should be measured such a relative criteria?
> - Much more complex
> - More complex
> - Slightly more complex
> - Little bit more complex
>
> Also how you personally measure these cognitive loads?
>
> 1.Sample (pattern)
>
> type KeyValuePair interafce {
> key interface{}
> val interface{}
> }
>
> 2.Sample (pattern)
>
> type KeyValuePair<K, V> interafce {
> key K
> val V
> }
>
> What about that a value of the #2 sample is more complex than #1 sample on
> the 146%?
> With permissible error of no more than 5%.
>
> I think that possible we should to start a discussion about that problem
> (complexity measurement of the Go language perception).
>
> I'm not kidding.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
