[go-nuts] Re: Generics and readability

One distinction that might be helpful is the difference between people using a generic data structure and people writing a generic data structure. It's much more important that the code that makes use of generics be readable than it is that the body of the generic be readable; after all, the

Re: [go-nuts] Re: Generics and readability

I don't know I have met many a newbie from university who didn't know their way around the Java world but would happily work with Haskell because their advanced courses used it. On Mon, 28 Aug 2017, 12:30 Wojciech S. Czarnecki wrote: > On Sun, 27 Aug 2017 17:28:07 + >

Re: [go-nuts] Re: Generics and readability

On Sun, 27 Aug 2017 17:28:07 + Jesper Louis Andersen wrote: > The advantage of having the extra syntactic abstraction in a language is > not something you would tend to dismiss too easily I think. While it > filters away some contributors from the code base,

Re: [go-nuts] Re: Generics and readability

Someone who can summarize the lisp experience woud be usefull here: generate-and-execute is that language's equivalent of preprocessors and code generators, and has been around the beginning of the language. -- You received this message because you are subscribed to the Google Groups

Re: [go-nuts] Re: Generics and readability

On Sat, Aug 26, 2017 at 7:03 PM wrote: > > Generics user here, since Bjarne Stroustrup's CFront, the very first C++ > compiler. > > Whenever you use complex idioms you reduce the amount of people able to > understand your code and able to mantain it. The simpler the code, the

Re: [go-nuts] Re: Generics and readability

On Sun, Aug 27, 2017, 18:28 Tristan Colgate wrote: Code generation feels more idiomatic to Go. I'm tempted by some kind of > package level generics, but I'm terrified that the standard library might > end up using them. > Stdlib uses code generation since its first public

Re: [go-nuts] Re: Generics and readability

in my concern i could agree with everyone. so it does not go anywhere, does it ? Axel resumes it well. I d just add one notion, complexity to build the desired generator. Even though a great work has been made so golang compile in go, it is not an easy api to handle. So if go intends to

Re: [go-nuts] Re: Generics and readability

It would be great to hear from those that have written extensive code generation tools as to what changes, if any, Go2 could bring to make code generation easier. Code generation feels more idiomatic to Go. I'm tempted by some kind of package level generics, but I'm terrified that the standard

Re: [go-nuts] Re: Generics and readability

While having generics as part of the language and doing the code-gen in the compiler has definite advantages (ease of use and potentially better optimization of the generated code), doing it as a separate tool *also* has advantages. For example, this way no one is bound to whatever notion of

Re: [go-nuts] Re: Generics and readability

Interchanging the particular example and the general principle it shows, allows to easily conclude almost anything, right. On Sun, Aug 27, 2017, 17:08 wrote: > > That's how C++ started. > > And that's also why C++ is the ugly monster than it is today; with a > design that

Re: [go-nuts] Re: Generics and readability

> That's how C++ started. And that's also why C++ is the ugly monster than it is today; with a design that wasn't quite thought thoroughly. Talking about C++ like it's an example to follow is just preposterous. Le dimanche 27 août 2017 16:25:54 UTC+2, Jan Mercl a écrit : > > And there's

Re: [go-nuts] Re: Generics and readability

And there's nothing wrong in it. That's how C++ started. Codegen allows for easier protoyping throwaway experiments. Writing a full blown compiler and realizing afterwards a better language/feature design costs probably much more work. On Sun, Aug 27, 2017, 15:55 wrote: >

Re: [go-nuts] Re: Generics and readability

Codegen can do 100% of what any compiler can do. On Sun, Aug 27, 2017, 14:54 wrote: > > A lot of people consider code gen a second class solution when compared > to a more traditional generics implementation. I don't think so. Code > generation can be very effective. No

[go-nuts] Re: Generics and readability

> A lot of people consider code gen a second class solution when compared to a more traditional generics implementation. I don't think so. Code generation can be very effective. No major concerns about indecipherable error messages. When in doubt you can inspect the generated code to

[go-nuts] Re: Generics and readability

simplicity is complicated: https://www.youtube.com/watch?v=rFejpH_tAHM needlessly complex: https://youtu.be/IRTfhkiAqPw?t=19m40s because i liked it very much: https://www.youtube.com/watch?v=QM1iUe6IofM About code gen, as we know it in go1, i feel like it is a third class citizen. In its current

[go-nuts] Re: Generics and readability

mhh: >Why would you put generics on a method ? I.e.: I could have a container type and a element type to be contained. myStack.push(myElement) mhh: >type Final notFinal Maybe it is a good idea to require an intermediate type like that, to keep things readable. mhh: > none of

Re: [go-nuts] Re: Generics and readability

mh, what do you think of this quote ? Not to reject the whole work, just an example i stumble upon. ___ Note that type deduction requires types to be identical. This is stronger than the usual requirement when calling a function, namely that the types are assignable.

[go-nuts] Re: Generics and readability

In first example Value can not do Less, its Entry, Entry has not been defined yet, its nothing. Unless you introduce a Lesser interface and specify Node<$Entry:Lesser> Given that specific example this notation looks pretty heavy, and even worse if d that be As

Re: [go-nuts] Re: Generics and readability

Ah yes unfortunate that Ians proposal was rejected. fre 25 aug. 2017 kl 10:39 skrev 'Axel Wagner' via golang-nuts < golang-nuts@googlegroups.com>: > Maybe a loaded question but what is the goal of this thread? Is it to > establish whether or not generics impact readability? In that case it >

Re: [go-nuts] Re: Generics and readability

Maybe a loaded question but what is the goal of this thread? Is it to establish whether or not generics impact readability? In that case it should get a lot more civil and charitable on both sides. Anyway, my take on that: The examples mentioned, in a very real way, are not really suitable to

[go-nuts] Re: Generics and readability

package tree type Node<$Entry> struct { Value $Entry Left *Node<$Entry> Right *Node<$Entry> } func (node *Node) Insert(value node.$Entry) { var side **Node if node.Value.Less(value) { side = } else { side = } if *side == nil { *side = {Value: value} } else {

[go-nuts] Re: Generics and readability

func Foo(in interface{}) { val, ok := in.(someTypeOrInterface) if !ok { // TODO HANDLE ERROR } ... } Wow, this is so much more readable /s On Thursday, August 24, 2017 at 6:14:58 PM UTC+3, JuciÊ Andrade wrote: > > A lot of people like Go

[go-nuts] Re: Generics and readability

Why would you put generics on a method ? The syntax you demonstrate is horrible, indeed. what if generics are type related type notFinal struct { p1 p2 } func (n notFinal) whatever(in ) string { return fmt.Sprintf(in) // anything to interface{}, works. } type Final notFinal

[go-nuts] Re: Generics and readability

Using D syntax: func (r MyType) foo(A, B)(x A, y B) (z B, err error) { ... } result, _ := MyType.foo!(int, int)(10, 20) Also, there's no reason why A and B can't be inferred: result, _ := MyType.foo(10, 20) It looks alright to me and very useful! On Thursday, 24