On Thursday, 23 June 2016 06:41:07 UTC+3, Thomas Bushnell, BSG wrote:
>
> This is why I like this example. Generics induce people to write the wrong
> thing instead of thinking about the right thing. When you start thinking of
> the right thing, you often discover better solutions.
>
*It's also a great example why real-world examples are better for
discussion.*
> I think the sort package's way of doing sorting and binary search are so
> clearly better than almost any generic implementation I've seen, that I
> think generics are a bad idea for this reason alone.
>
To me the major issues with C++/Java/C# generics is that they are too
fine-grained. Often they are declaration scoped with meaningless type
parameter names "T", "K".
The most promising generics idea I've seen is packages with interface
specialization. 1. it's harder to abuse, 2. you end up building packages as
usual with interfaces, 3. minimal change to the language. However it has
some drawbacks - it doesn't solve all the generics problems - only data
structures and algorithms part. The generic "sort" package, with that
approach, wouldn't look any different.
Thomas
>
> On Wed, Jun 22, 2016, 8:07 PM Michael Jones <michae...@gmail.com
> <javascript:>> wrote:
>
>> Yes, for floats with NANs and the like, you must specialize. My
>> replacement for the standard library sort (3x to 10x faster in the common
>> case) had to have more macro generators than expected just to handle the
>> "uncomparables" in float32 and float64.
>>
>> You are right about that issue.
>>
>> P.S. By the way, Hi! Good to hear from you.
>> On Jun 22, 2016 6:32 PM, "Thomas Bushnell, BSG" <tbus...@google.com
>> <javascript:>> wrote:
>>
>> But Michael, that implementation isn't right for floats! Check out the
>> actual source for math.Max.
>>
>> On Wed, Jun 22, 2016, 6:31 PM Michael Jones <michae...@gmail.com
>> <javascript:>> wrote:
>>
>>> The wonderful history of symbolic algebra at IBM (Scratchpad, Scratchpad
>>> II) resulted in a third system, Axiom, that has always seemed to me a
>>> bright lesson in types. It boldly goes into the topic with rigor, using
>>> category theory to decide what relationships make sense and what the nature
>>> of a tensor cross product of types truly is.
>>>
>>> A key part of that is the notion of *more general* and *more specific*
>>> types. This makes it possible to define a function that needs arguments
>>> supporting a less than order relationship so it could be applied to integer
>>> and real arguments, but not to complex numbers. This is just the mechanism
>>> that makes a generic Max() easy to create. Imagine a definition like:
>>>
>>> func {T type, where a,b ∈T allows a<b} Max(a, b T) T {
>>>
>>> if a < b {
>>> return b
>>> }
>>> return a
>>>
>>> }
>>>
>>> This is a nice way to answer the riddle and it is just what Axiom
>>> supports (but expresses differently).
>>> http://axiom-developer.org/axiom-website/bookvol2.pdf
>>>
>>> Michael Jones
>>> michae...@gmail.com <javascript:>
>>>
>>> On Jun 22, 2016, at 6:10 PM, 'Thomas Bushnell, BSG' via golang-nuts <
>>> golan...@googlegroups.com <javascript:>> wrote:
>>>
>>> Really? How would you implement math.Max with generics?
>>>
>>> Thomas
>>>
>>> On Wed, Jun 22, 2016, 5:45 AM Viktor Kojouharov <vkojo...@gmail.com
>>> <javascript:>> wrote:
>>>
>>>> https://golang.org/pkg/math/ and https://golang.org/pkg/container/ are
>>>> just two stdlib packages that would greatly benefit from some kind of
>>>> generics. I'm pretty sure there are more packages in the stdlib that would
>>>> be greatly improved. And that's just the standard library.
>>>>
>>>>
>>>> On Tuesday, June 21, 2016 at 5:29:37 PM UTC+3, Henry wrote:
>>>>>
>>>>> You still haven't provided any argument why generics is indispensable.
>>>>>
>>>>> The reason why I am no longer sure about my position in this issue is
>>>>> because -while I agree that generics is useful- I don't think that
>>>>> generics
>>>>> is essential. In fact, all of C++ features are useful and implemented in
>>>>> a
>>>>> very efficient manner, but take a look what happened when you slab that
>>>>> many features together. If you can do away with less, I think you should
>>>>> go
>>>>> for less. The trouble is deprecating language features is a lot harder
>>>>> than
>>>>> deprecating APIs in the standard library, while programming fads come and
>>>>> go.
>>>>>
>>>>
>>>> --
>>>> 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...@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.
