On Tuesday, June 21, 2016 at 9:56:01 PM UTC+3, Axel Wagner wrote:
>
> 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.
>
And yet the 'K' and 'V' within the struct are generic types. A struct is
never simple. That's its whole point.
>
> 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.
>
A lot of these 'applications' that you think are the language's main target
are built on top of libraries, including stdlib, written by that same
language. And these same libraries can benefit from having generics, once
again, including stdlib.
>
> 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.
>
I've found this type of thinking quite poisonous. The "lets bereave
ourselves of something universally lauded as useful, because it _might_ be
used in the wrong manner by some people" mentality is just wrong and
prevents any kind of useful evolution under any context.
>
> 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).
>
And yet this hasn't stopped people from successfully learning and utilizing
languages that have generics are part of their specifications. The fact
still remains that unlike a lot of other proposed languages additions that
are immediately dropped, generics are still open for discussion by the
language developers themselves.
>
>
> 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).
>
I'm sorry, but that's just fearmongering. Unless you have some kind of
magic crystal ball, there's now way you'd know how the quality of go code
will change. You don't even know what the implementation will look like ...
>
> On Tue, Jun 21, 2016 at 5:06 PM, <andrew...@gmail.com <javascript:>>
> 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...@googlegroups.com <javascript:>.
>> 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.
