On Tuesday, June 21, 2016 at 2:56:01 PM UTC-4, 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.
>
> 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 would greatly reduce the work required to reproduce or possibly
eliminate all work when building container types.
>
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.
>
this is true with almost every feature of the language, so its absurd to
even use this as an argument. generics would greatly reduced computational
complexity.
>
> 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).
>
this comment is more mumbo-jumbo
>
>
> 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).
>
another absurd comment. generics would greater benefits and reduce the
complexity of code.
>
> 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.
