Re: No generics, no overloading, and no adding methods to existing types. How....useful.

Showing 1-208 of 208 messages
Re: No generics, no overloading, and no adding methods to existing types. How....useful. James Bardin 5/17/13 1:36 PM
No one is likely to debate this with you: http://golang.org/doc/faq#generics

There may be generics is the future, but in the meantime most of us are happy with no generics vs poor generics.



On Friday, May 17, 2013 3:23:13 PM UTC-4, Sod Almighty wrote:
Hi all.

I'm trying to implement a Linq-alike for Go, mainly for practice but also because I find Enumerables really easy to work with. Unfortunately, I have hit several walls, all due to missing features in the language.

  1. Generics. Yeah, I know Google doesn't like them. But how else are you gonna define a function that takes a parameter of type T along with a function that takes a T and returns a T? Answer: You can't. It must take an interface{} and a function that takes an interface{} and returns an interface{}. And then you can't call this function and pass in an int and a function taking an int and returning an int. No, you have to write a specifically non-type-safe function and pass that in, even if you had a perfectly good int->int function kicking around. Madness!

  2. Overloading. I decided to start by writing Ana, Cata and Bind, a la MinLINQ. Unfortunately, due to the lack of generics, I need to write an Ana() that deals with interface{}s, along with specialised versions for ints, strings and floats. But... you can't have functions with the same name and different parameters, so that's out too.

  3. Methods. So, I figured I'd make each overload of Ana be a method on the relevant type, but the compiler spits out "cannot define new methods on non-local type int". So I can't do that either.

Don't get me wrong: It's great to see the number of modern native-compiled languages exceed "1", but seriously guys, how's a fellow supposed to get anything done without generics?

I want a function like this:

func Ana(seed T, condition func(T) bool, next func(T) T) FEnumerable<T> {
   ... code ...
}

Is that really so unreasonable? Are you seriously telling me that writing out loops and such at the call site is better than having a reusable *cough* "class library"? I don't want to be declaring lists and slices all over the place every time I want to query something. I want to simply say "From(something).Where(filter).Select(transformation)". You can do that in C++, C#, D, VB.NET and pretty much any other modern language. If you're going to have types, you must also have generics. Period. Otherwise we're just back in the dark ages casting everything back and forth, or writing the same code over and over again.

Again, let me say that I'm not knocking Go specifically. I'm sick of being locked into C++ whether I like it or not (yeah, I know there's D, but it's riddled with bugs). But what use are "first-class functions" when you have neither generics nor polymorphism? The whole point of first-class functions is to plug specific strongly-typed sorting or filtering functionality into an otherwise generic untyped process. In other words, the function you're calling doesn't need to know or care what kind of objects its dealing with, because you've provided a function object that can do the type-specific bit of work. But here I can't, because a func(int)int won't be accepted by a function expecting a func(interface{})interface{}.
Re: [go-nuts] No generics, no overloading, and no adding methods to existing types. How....useful. Ian Lance Taylor 5/17/13 1:41 PM
On Fri, May 17, 2013 at 12:23 PM,  <sod.al...@gmail.com> wrote:
>
> Generics. Yeah, I know Google doesn't like them. But how else are you gonna
> define a function that takes a parameter of type T along with a function
> that takes a T and returns a T? Answer: You can't. It must take an
> interface{} and a function that takes an interface{} and returns an
> interface{}. And then you can't call this function and pass in an int and a
> function taking an int and returning an int. No, you have to write a
> specifically non-type-safe function and pass that in, even if you had a
> perfectly good int->int function kicking around. Madness!

I'm not going to pretend that Go is good at this, because it's not.
But you actually can do this: http://play.golang.org/p/emiuPJwfCS .

Ian
Re: [go-nuts] No generics, no overloading, and no adding methods to existing types. How....useful. Aaron France 5/17/13 1:43 PM

Troll detected

--
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.
For more options, visit https://groups.google.com/groups/opt_out.


This message has been hidden because it was flagged for abuse.
This message has been hidden because it was flagged for abuse.
This message has been hidden because it was flagged for abuse.
Re: [go-nuts] No generics, no overloading, and no adding methods to existing types. How....useful. Sean Russell 5/17/13 1:57 PM
Not really.

    http://play.golang.org/p/TgB_pRVBdP

There goes type safety, and, consequently, a core feature.

--- SER
This message has been hidden because it was flagged for abuse.
Re: [go-nuts] No generics, no overloading, and no adding methods to existing types. How....useful. soapboxcicero 5/17/13 2:03 PM
Look at how the standard library does Sort: http://golang.org/pkg/sort/
Re: [go-nuts] No generics, no overloading, and no adding methods to existing types. How....useful. James Bardin 5/17/13 2:07 PM


On Friday, May 17, 2013 4:55:25 PM UTC-4, Sod Almighty wrote:

On Friday, May 17, 2013 9:43:03 PM UTC+1, Aaron France wrote:

Troll detected

Troll yourself. Didn't you read what I wrote? As I said, I'm in favour of new native languages and would like to use Go, but I feel my objections are valid. If you disagree, why not explain why you think generics aren't necessary, rather than just sitting there and hurling insults for no reason.


Oh geez, I was hoping a polite pointer to the FAQ (which covers overloading too BTW) would be enough to prevent this usual progression. 

For the record, though you may not intend too, you are coming off as very antagonistic. It's not going to lead to a useful discussion. Lot's of useful things are done with go without using generics. Maybe there's something we can help with.

Another method for "generifying" code is to wrap things in interfaces. See the code in Sort for an example: http://golang.org/pkg/sort/
Re: [go-nuts] No generics, no overloading, and no adding methods to existing types. How....useful. Gustavo Niemeyer 5/17/13 2:08 PM
On Fri, May 17, 2013 at 6:01 PM, Sod Almighty <sod.al...@gmail.com> wrote:
> That's generics. Period. No generics, no reusable type-safe type-independent
> code. You either have to cast (no type safety) or write extra code (no code
> reuse).

Indeed, but generics do not exist, period. You'll indeed have to write
some boilerplate code every once in a while. Unanimously, though,
everybody would appreciate having a beautiful implementation of
generics in the language, and the reason why that hasn't happened is
that such beautiful design is yet to surface. I'd rather have no
generics, than a rushed implementation as seen elsewhere.


gustavo @ http://niemeyer.net
This message has been hidden because it was flagged for abuse.
This message has been hidden because it was flagged for abuse.
Re: [go-nuts] No generics, no overloading, and no adding methods to existing types. How....useful. thwd 5/17/13 2:23 PM
On Friday, May 17, 2013 10:55:25 PM UTC+2, Sod Almighty wrote:
If nobody ever complained about the shortcomings of anything, nothing would ever get done.

Dude you're like the 3000th person to bring this up. There have been like 100 lengthy discussions about this topic. Answer has always been the same.
There's a reason why this is mentioned in the FAQ.
This message has been hidden because it was flagged for abuse.
Re: [go-nuts] No generics, no overloading, and no adding methods to existing types. How....useful. minux 5/17/13 2:29 PM

On Sat, May 18, 2013 at 5:23 AM, Sod Almighty <sod.al...@gmail.com> wrote:
On Friday, May 17, 2013 10:08:29 PM UTC+1, Gustavo Niemeyer wrote:
Unanimously, though,
everybody would appreciate having a beautiful implementation of
generics in the language,

So explain why people tried to lynch me as soon as I mentioned it.

You think this "beautiful implementation" is going to fall out of the sky? No, it'll happen by people discussing it, and repeatedly
but you don't seems to propose an implementation of generic, only complained the lack of it,
and that's why people consistently refer you to the FAQ.
demanding it on forums, until it gradually filters through the head of the developers.

btw, if you do want to propose an implementation of generic, be sure to read
This message has been hidden because it was flagged for abuse.
This message has been hidden because it was flagged for abuse.
Re: [go-nuts] No generics, no overloading, and no adding methods to existing types. How....useful. thwd 5/17/13 2:35 PM
I'm saying that 3000 people wrote before they read, did before they thought and failed before they started.

They came from other languages, read about Go, realized the "lack" of generics, immediately posted to the list. Left in less than an hour.
This message has been hidden because it was flagged for abuse.
Re: [go-nuts] No generics, no overloading, and no adding methods to existing types. How....useful. Gustavo Niemeyer 5/17/13 2:40 PM
On Fri, May 17, 2013 at 6:23 PM, Sod Almighty <sod.al...@gmail.com> wrote:
> So explain why people tried to lynch me as soon as I mentioned it.

You came in very warmly, and they've corresponded to that. That's all.

I think you're not a troll, but you're too excited to be able to
influence things. Just take a deep breath, experience the language a
bit more, read some previous threads on the topic, and then come back
to help us solve the problem.


gustavo @ http://niemeyer.net
Re: [go-nuts] No generics, no overloading, and no adding methods to existing types. How....useful. thwd 5/17/13 2:41 PM
If you read before you wrote you would have noticed that Aaron France quoted Ian Lance Tailor as a troll. Not you.

Just stick around bro. Read the list - get to know the language, we're a fine community.
Re: [go-nuts] No generics, no overloading, and no adding methods to existing types. How....useful. Ian Lance Taylor 5/17/13 2:43 PM
On Fri, May 17, 2013 at 1:57 PM, Sean Russell <seaner...@gmail.com> wrote:
> Not really.
>
>     http://play.golang.org/p/TgB_pRVBdP
>
> There goes type safety, and, consequently, a core feature.

The language still has type safety, of course--that's why your code panics.

What this approach lacks is compile-time type safety.  It's a serious
problem.  I just want to make sure we give it the right name.

Ian


> On Friday, May 17, 2013 4:41:53 PM UTC-4, Ian Lance Taylor wrote:
>>
>> On Fri, May 17, 2013 at 12:23 PM,  <sod.al...@gmail.com> wrote:
>> >
>> > Generics. Yeah, I know Google doesn't like them. But how else are you
>> > gonna
>> > define a function that takes a parameter of type T along with a function
>> > that takes a T and returns a T? Answer: You can't. It must take an
>> > interface{} and a function that takes an interface{} and returns an
>> > interface{}. And then you can't call this function and pass in an int
>> > and a
>> > function taking an int and returning an int. No, you have to write a
>> > specifically non-type-safe function and pass that in, even if you had a
>> > perfectly good int->int function kicking around. Madness!
>>
>> I'm not going to pretend that Go is good at this, because it's not.
>> But you actually can do this: http://play.golang.org/p/emiuPJwfCS .
>>
>> Ian
>
Re: [go-nuts] No generics, no overloading, and no adding methods to existing types. How....useful. Ziad Hatahet 5/17/13 2:44 PM
On Fri, May 17, 2013 at 12:23 PM, <sod.al...@gmail.com> wrote:
Don't get me wrong: It's great to see the number of modern native-compiled languages exceed "1", but seriously guys, how's a fellow supposed to get anything done without generics?


Out of curiosity, have you looked at Rust (http://rust-lang.org)? It is a native-compiled language, and it has generics, immutability, concurrency, and some other really nice features.

--
Ziad
Re: [go-nuts] No generics, no overloading, and no adding methods to existing types. How....useful. kortschak 5/17/13 2:47 PM
Probably you want to see how embedding can be used here. You can do extremely subtle things by wrapping your type in a struct with additional data and a changed Less method.
Re: [go-nuts] No generics, no overloading, and no adding methods to existing types. How....useful. Ian Lance Taylor 5/17/13 2:51 PM
On Fri, May 17, 2013 at 2:18 PM, Sod Almighty <sod.al...@gmail.com> wrote:
>
> On Friday, May 17, 2013 10:07:18 PM UTC+1, James Bardin wrote:
>>
>> For the record, though you may not intend too, you are coming off as very
>> antagonistic.
>
>
> People often tell me that. But, as I have no idea why, there's not a lot I
> can do about it. I look at my original post, and I see a polite criticism
> and a request for change. I insulted nobody, used no foul language, didn't
> say the language sucked, and gave every impression that I liked it in
> general and would appreciate some added functionality. All I wanted was a
> sensible adult discussion.
>
> It doesn't seem to matter how hard I try to be nice and polite, people
> always jump down my throat and accuse me of being angry or antagonistic. I
> really don't know why I bother.

Do you really not know?  If this has occurred to you multiple times,
and it's not intentional, then perhaps you should investigate your
style of communication.  Much as you said yourself farther down the
thread, if many people tell you something, then perhaps it is true.
Even if it's hard for you to see it yourself.

In this case, since you said it so nicely, I'll give you a couple of tips.

In describing what you have to do in Go to work around the lack of
generics, you said "Madness!"  Exclamation points are seen as
aggressive.  Accusing people and/or projects of insanity is seen as
aggressive.

You said "seriously guys, how's a fellow supposed to get anything done
without generics?"  Here you are posting in a forum for people who use
Go, and saying, not just that one can't use Go without generic, but
that the lack of generics means that the language is not serious.  You
may very well believe that; it may even be true; but when you come
into a forum and tell people that they can not do what they are doing,
it is seen as aggressive.

You said "Is that really so unreasonable? Are you seriously telling me
that...."  Same sort of thing here.  Rather than phrasing the issues
in a neutral or helpful way, you are phrasing them in a way that
implies that the people who use Go are unreasonable and unserious.
This is seen as aggressive.

I hope this helps.

Ian
This message has been hidden because it was flagged for abuse.
Re: [go-nuts] No generics, no overloading, and no adding methods to existing types. How....useful. Tad Glines 5/17/13 2:54 PM
On Fri, May 17, 2013 at 2:38 PM, Sod Almighty <sod.al...@gmail.com> wrote:
I'm not surprised. They were probably called trolls. They probably figured that a language without generics was a poorly designed language. They were probably put off by the "no can't do" attitude.

I'm picking this as a somewhat arbitrary point of insertion.

The language developers WANT to add generics to the language.
However, they don't want to rush it.
If at all possible they would like to avoid the tradeoffs found in C++ and Java:
1. The C++ templates while powerful slow down the compiler.
2. The Java/.NET generics while powerful, slowdown the runtime.

As I see it there is a third way. One that has been taken before.
Create a wrapper/preprocessor language, ala Groovy, coffescript, etc...
Then the developer could choose which tradeoff they want to make (compile speed, executabel size, and runtime speed) and then choose the appropriate wrapper language.

This message has been hidden because it was flagged for abuse.
Re: [go-nuts] No generics, no overloading, and no adding methods to existing types. How....useful. Ziad Hatahet 5/17/13 2:59 PM

On Fri, May 17, 2013 at 2:54 PM, Tad Glines <tad.g...@gmail.com> wrote:

As I see it there is a third way. One that has been taken before.
Create a wrapper/preprocessor language, ala Groovy, coffescript, etc...
Then the developer could choose which tradeoff they want to make (compile speed, executabel size, and runtime speed) and then choose the appropriate wrapper language.


The 3 ways you listed are not the only ones. I noticed that the way that C#, D, or Rust implement generics was never brought up in the group.

--
Ziad

Re: [go-nuts] No generics, no overloading, and no adding methods to existing types. How....useful. Ian Lance Taylor 5/17/13 3:04 PM
On Fri, May 17, 2013 at 2:35 PM, Sod Almighty <sod.al...@gmail.com> wrote:
>
>
> On Friday, May 17, 2013 10:29:23 PM UTC+1, minux wrote:
>>
>>
>> but you don't seems to propose an implementation of generic, only
>> complained the lack of it,
>> and that's why people consistently refer you to the FAQ.
>
>
> Well, as a starting point, what about the .NET implementation? Seems to work
> well enough. Only shortcoming seems to be the lack of partial types. That
> is, the inability to specify a generic type without specifying T.

.NET is a very different sort of system.  In .NET generics are
implemented using just-in-time generation, e.g., to handle types with
unusual sizes in containers.  That aspect wouldn't work with Go.
Also, the .NET approach requires that types, including builtin types,
implement interfaces like IComparable.  Currently in Go builtin types
do not implement methods, so that would have to change, which makes
the approach more complex.  Also, I don't really like the way that
IComparable's CompareTo method takes a parameter of type Object.  In
Go that would be equivalent to a parameter of type interface{}.  That
is not idea in Go, because it requires type conversions which are part
of what we are trying to get away from.  .NET's implementation
partially relies on the concepts of covariance and contravariance,
which are meaningless in Go, because there is no inheritance hierarchy
in Go.

All that said, I agree that the .NET implementation of generics is one
of the better ones, and there is a lot we can learn there.


> I really don't see what's so hard about it. .NET does it. D does it. A bunch
> of other languages do it. Granted, I'm not an expert on language design, but
> it's not exactly a new idea. Surely it can't be beyond the wit of man?

The Go language is intentionally minimal and intentionally tries to
provide a relatively small number of concepts.  Citing D, a language
with a very different philosophy, doesn't get us very far.  That said,
I am not familiar offhand with how D implements generics.  D's
heritage suggests it might be similar to C++ templates, which would
not be a good fit for Go.  But I don't really know.

Ian
This message has been hidden because it was flagged for abuse.
Re: [go-nuts] No generics, no overloading, and no adding methods to existing types. How....useful. Ziad Hatahet 5/17/13 3:04 PM
On Fri, May 17, 2013 at 2:59 PM, Sod Almighty <sod.al...@gmail.com> wrote:
Oooh, another native language! I googled for native languages recently and never encountered Rust. Thanks for pointing it out. I'll take a look.

The only other natives I know of are D (buggy as hell), C++, AutoIt (a bit lacking) and Red (afaik, not yet in a usable condition). Any more?


Objective-C and Haskell, to name a couple.

--
Ziad

Re: [go-nuts] No generics, no overloading, and no adding methods to existing types. How....useful. kortschak 5/17/13 3:15 PM
As an author of a variety of packages that aim at, and hit, generic use, I have to disagree there. There is some set up for that generic use, but this is in my view an honest statement to the client about the cost and a oportunity for type safe flexibility that other forms of generic code don't allow.

As another apporach to your question, similar to Ian's would be to take a pointer to an interface{} and plase the results in that. This is used in a number of places in the standard library. This would depend on reflection, but you could take an interfaced-based approach like Foo(a, b Interface, c SetInterface) where a and b satisfy the behaviours you need to het the inputs and SetInterface satisfies the behaviour of storing that result. Potentially no type assertions are needed under this scheme.
This message has been hidden because it was flagged for abuse.
This message has been hidden because it was flagged for abuse.
This message has been hidden because it was flagged for abuse.
Re: [go-nuts] No generics, no overloading, and no adding methods to existing types. How....useful. Ian Lance Taylor 5/17/13 3:38 PM
On Fri, May 17, 2013 at 3:21 PM, Sod Almighty <sod.al...@gmail.com> wrote:
> On Friday, May 17, 2013 10:51:50 PM UTC+1, Ian Lance Taylor wrote:
>>
>>
>> Do you really not know?  If this has occurred to you multiple times,
>> and it's not intentional, then perhaps you should investigate your
>> style of communication.  Much as you said yourself farther down the
>> thread, if many people tell you something, then perhaps it is true.
>> Even if it's hard for you to see it yourself.
>
>
> I have tried to comprehend why I seem to speak a different language to
> everyone else on the planet; and have got precisely nowhere. I honestly
> cannot see anything wrong with my original post. Granted, some of my other
> posts have been a little snappish, but generally in response to unhelpful
> posts. Occasionally, when someone is helpful, you will notice that I thank
> them.

I encourage you to reflect on your post and how people respond to it.
It's not a matter of what you are trying to say.  It's a matter of how
you say it.


>> In this case, since you said it so nicely, I'll give you a couple of tips.
>>
>> In describing what you have to do in Go to work around the lack of
>> generics, you said "Madness!"  Exclamation points are seen as
>> aggressive.  Accusing people and/or projects of insanity is seen as
>> aggressive.
>
>
> Uh...but having to drop type-safety and pass in a type-agnostic closure is
> madness. I didn't say the language or the developers were insane, just that
> the hoops I'd have to jump through to achieve anything resembling a
> type-independent reusable function were ridiculous. And I stand by that
> assertion.

I'm trying to say something not about what you are saying, but about
how you are saying it.  You are responding by reasserting what you are
trying to say.  That's not the point.  It's not about the content.
It's about the presentation.

Ian
This message has been hidden because it was flagged for abuse.
This message has been hidden because it was flagged for abuse.
Re: [go-nuts] No generics, no overloading, and no adding methods to existing types. How....useful. Volker Dobler 5/17/13 3:59 PM


Am Samstag, 18. Mai 2013 00:51:23 UTC+2 schrieb Sod Almighty:
I get that. However, from my point of view, the content is 99% of the message. If I say "people who use Go are idiots", well, that's rude. If I say "Seriously? I can't even do this?" - well, in my native language, incredulity at the limitations of a system does not equal an insult to the people using it. I call my native language "English". Apparently it's not the same as what everyone else is using, however.

Telling me that the presentation is important, while informative and appreciated, doesn't actually enable me to do anything about it. I look at my "presentation", as you call it, and see nothing wrong. (Except when I'm replying to unhelpful posts, of course.) While I'm aware that the majority of people in this world react badly to how I say things, I honestly can't do anything about it. Or, at least, haven't been able to thus far. Given that I'm in my thirties, I don't see that changing overmuch.

You might want to try a Snickers. Or a weekend reflecting 
what and why was said.

V. 

This message has been hidden because it was flagged for abuse.
Re: [go-nuts] No generics, no overloading, and no adding methods to existing types. How....useful. Tad Glines 5/17/13 4:04 PM
On Fri, May 17, 2013 at 3:27 PM, Sod Almighty <sod.al...@gmail.com> wrote:
On Friday, May 17, 2013 10:54:57 PM UTC+1, Tad Glines wrote:

The language developers WANT to add generics to the language.
However, they don't want to rush it.

Well bugger me! A sensible rational discussion on the subject! ;)

I have a tendency to be very opinionated. I can recognize the same in others and can adjust accordingly :-)
  
If at all possible they would like to avoid the tradeoffs found in C++ and Java:
1. The C++ templates while powerful slow down the compiler.
2. The Java/.NET generics while powerful, slowdown the runtime.

As I see it there is a third way. One that has been taken before.
Create a wrapper/preprocessor language, ala Groovy, coffescript, etc...
Then the developer could choose which tradeoff they want to make (compile speed, executabel size, and runtime speed) and then choose the appropriate wrapper language.

Hmm...I wasn't aware that generics were that slow. I'll have to write a test program in .NET or something and benchmark it somehow. I'm not familiar with the preprocessors you mention; not being a Java developer. Isn't a preprocessor just another version of option 1, though?

The distinction between option 1 and a preprocessor (or language translator) is that the core language developers don't have to support it. Browsers don't need to know, or care, about coffescript and Oracle (and other JVM developers) don't need to care about Groovy. If the developer doesn't mind the additional compile time/ hassle of using a language preprocessor then that's their choice.

As for options 2, the problem isn't necessarily in the way they are designed but in the way they would translate. For example, Java generics use type erasure. That is, in the source you might have Map<String, String>, but in the byte code you end up with Map<Object,Object>. In the case of Map, this works out ok because the only methods Map needs are available in the Object interface so there is no need to create a separate compiled version like in C++. But, because Go doesn't have a type hierarchy with a root type, and none of the types have methods, the Java style isn't really possible without making significant changes to the language. If a particular function/algorithm needs certain methods (e.g. Equals and Less) then the algorithm can require an interface as input then any type that implements those methods can be passed to that function/algorithm. This is sort of like the way C++ templates work but not quite as expressive because you have to do a bit more explicit casting depending on how the interface is used.

In any language there is a tradeoff between expressiveness and performance. Ruby, for example, is very expressive (and thus its popularity), but isn't very fast. For example, a company recently replaced 30 servers with 2 servers when they re-wrote a ruby service in Go.

The Go language developers have made some very specific and conscious choices about the language design with certain goals in mind.
When languages are created there seem to be two philosophies: consensus (mob rule) and opinionated. Many languages fall somewhere in between, some tend to be more inclined to try and please as many people as possible. Others try and stick to a very strict set of core principles regardless of popular opinion. Go seems to be more on the opinionated end of the spectrum. I'm fine with that.

This message has been hidden because it was flagged for abuse.
Re: [go-nuts] No generics, no overloading, and no adding methods to existing types. How....useful. Sanjay 5/17/13 4:08 PM
I feel obligated to point out the irony that you want to implement LINQ while having the opinion you do about Haskell (and functional languages, more generally). The contrast tickled me.

Cheers,
Sanjay
This message has been hidden because it was flagged for abuse.
Re: [go-nuts] No generics, no overloading, and no adding methods to existing types. How....useful. Ian Lance Taylor 5/17/13 4:15 PM
On Fri, May 17, 2013 at 3:51 PM, Sod Almighty <sod.al...@gmail.com> wrote:
>
>
> On Friday, May 17, 2013 11:38:12 PM UTC+1, Ian Lance Taylor wrote:
>>
>>
>> I encourage you to reflect on your post and how people respond to it.
>> It's not a matter of what you are trying to say.  It's a matter of how
>> you say it.
>>
>> I'm trying to say something not about what you are saying, but about
>> how you are saying it.  You are responding by reasserting what you are
>> trying to say.  That's not the point.  It's not about the content.
>> It's about the presentation.
>
>
> I get that. However, from my point of view, the content is 99% of the
> message. If I say "people who use Go are idiots", well, that's rude. If I
> say "Seriously? I can't even do this?" - well, in my native language,
> incredulity at the limitations of a system does not equal an insult to the
> people using it. I call my native language "English". Apparently it's not
> the same as what everyone else is using, however.

You don't intend an insult.  But you are implying that the system is
not merely deficient but obviously and fragrantly deficient.  You are
implying that no ordinary person would want to use it.  It follows
that you are implying that the people who do use it are not ordinary.
It's a pretty short step from there to think that you are calling the
people who do use it stupid.  The step may not be warranted, but many
people will take it.  And at that point, it's an insult.


> Telling me that the presentation is important, while informative and
> appreciated, doesn't actually enable me to do anything about it. I look at
> my "presentation", as you call it, and see nothing wrong. (Except when I'm
> replying to unhelpful posts, of course.) While I'm aware that the majority
> of people in this world react badly to how I say things, I honestly can't do
> anything about it. Or, at least, haven't been able to thus far. Given that
> I'm in my thirties, I don't see that changing overmuch.

If you really want to learn and change your communication patterns,
you can do so.  If you don't want to, then you must simply accept the
fallout.  There are many things about ourselves we can not change.
This is not one of them.  You can't change how you feel.  But you can
change how you communicate, especially over a medium like e-mail that
permits time for reflection.

One of the simpler techniques for changing is to write a reply but
don't send it.  Then wait ten minutes and throw that reply away.  Then
write another reply, but this time think hard about what the recipient
will read.

Remove any exclamation points.  Remove any sentence that seems to call
for an exclamation point.

Remember that on the Internet people come from many different
backgrounds and cultures.  Sometimes it helps to think of your e-mail
as being written to a timid child.  You want to explain something to
him.  Maybe you want to explain why he shouldn't go out into the
street.  But you want to do it without scaring him.  If you yell he
will start to cry, and moreover he may be afraid to ever leave the
house again, which is not what you want.  What words would you use?
Now pretend that the people reading your e-mail are timid children.
You want to convince them without scaring them.

Ian
This message has been hidden because it was flagged for abuse.
Re: [go-nuts] No generics, no overloading, and no adding methods to existing types. How....useful. Ian Lance Taylor 5/17/13 4:18 PM
On Fri, May 17, 2013 at 3:59 PM, Sod Almighty <sod.al...@gmail.com> wrote:
> As an aside, can anyone explain to me why compilers are always written in
> the languages they compile? The compiler for Red is to be re-written in Red
> once the language is usable. The compiler for Rust is written in Rust, and
> so on. I don't understand why this is important.

Interesting you should ask that.  One of the major Go compilers is
written in C.  The other is in C++.  Neither is in Go.

> It would also appear to be a logical impossibility.

It's called pulling yourself up by your bootstraps, bootstrapping for
short.  It's straightforward enough.

It's normally done because 1) language developers tend to be compiler
writers, and tend to be interested in languages that are good for
writing compilers; 2) writing a compiler in a language ensures that
the language is powerful enough to write a reasonable complex program.

Ian
Re: [go-nuts] No generics, no overloading, and no adding methods to existing types. How....useful. Gustavo Niemeyer 5/17/13 4:18 PM
On Fri, May 17, 2013 at 7:51 PM, Sod Almighty <sod.al...@gmail.com> wrote:
> I get that. However, from my point of view, the content is 99% of the
> message. (...) While I'm aware that the majority of people in this world
> react badly to how I say things, I honestly can't do anything about it.

Have you tried Rust?  It's a brilliant language.


gustavo @ http://niemeyer.net
Re: [go-nuts] No generics, no overloading, and no adding methods to existing types. How....useful. Tad Glines 5/17/13 4:29 PM
On Fri, May 17, 2013 at 4:13 PM, Sod Almighty <sod.al...@gmail.com> wrote:
I don't see the problem. If you have no class hierarchy, then you have no need for covariance or translation. Suppose I declare a function as follows:

func Foo<T>( a T, b T, comparer func(T,T) bool )

It doesn't matter what T is. Just compile a version of Foo where T is whatever type I'm passing:

Foo(1, 2, func(a int, b int) { return a == b })

If we specify a type limitation (e.g. func Foo<T:interface{ ...some methods... }>) then just don't allow a version of that function to be compiled where T doesn't implement the interface. I honestly don't see the problem.

That's the way C++ does it. The compiler has to:
1. Create a separate instance of Foo for each type. This is unavoidable in the case where an interface isn't used.
2. When the compiler/linker has to de-duplicate all the instantiated templates.
3. There is the potential for code bloat (in the non-interface case) and a much slower compile and link times.

I get the impression that the golang developers are trying to avoid any language change that would result in a slower compile time or in code bloat.

Also, the later case you gave "func Foo<T:interface{ ...some methods... }>" is already more or less supported in Go (e.g. func (t *T) Foo(value SomeInterface) SomeOtherInterface).

I think part of the difficulty with Go is that, in many ways, its syntax looks like something familier, but in many ways the language itself is very different. One common problem I see on this forum is people having difficulty switching from inheritance to embedding. Embedding can have some of the same results, but it isn't the same thing at all, and until people adjust to it they will continue to encounter a mental impedance mismatch.

This message has been hidden because it was flagged for abuse.
This message has been hidden because it was flagged for abuse.
This message has been hidden because it was flagged for abuse.
This message has been hidden because it was flagged for abuse.
This message has been hidden because it was flagged for abuse.
Re: [go-nuts] No generics, no overloading, and no adding methods to existing types. How....useful. Ian Lance Taylor 5/17/13 4:50 PM
On Fri, May 17, 2013 at 4:29 PM, Tad Glines <tad.g...@gmail.com> wrote:
>
> I get the impression that the golang developers are trying to avoid any
> language change that would result in a slower compile time or in code bloat.

Yes, see also http://research.swtch.com/generic .

Ian
Re: [go-nuts] No generics, no overloading, and no adding methods to existing types. How....useful. kortschak 5/17/13 4:58 PM
I didn't realise a period was easier to type than a new line.
Re: [go-nuts] No generics, no overloading, and no adding methods to existing types. How....useful. Ian Lance Taylor 5/17/13 5:07 PM
On Fri, May 17, 2013 at 4:32 PM, Sod Almighty <sod.al...@gmail.com> wrote:
> On Saturday, May 18, 2013 12:15:49 AM UTC+1, Ian Lance Taylor wrote:
>>
>> On Fri, May 17, 2013 at 3:51 PM, Sod Almighty <sod.al...@gmail.com> wrote:
>>
>> You don't intend an insult.  But you are implying that the system is
>> not merely deficient but obviously and fragrantly deficient.
>
>
> I think perhaps you mean "flagrantly deficient". I didn't say anything about
> how it smells.

Yes.  Thanks.

>> You are
>> implying that no ordinary person would want to use it.  It follows
>> that you are implying that the people who do use it are not ordinary.
>> It's a pretty short step from there to think that you are calling the
>> people who do use it stupid.  The step may not be warranted, but many
>> people will take it.  And at that point, it's an insult.
>
>
> Well, if you're gonna read several layers of indirection into my words,
> sure.

I tried, and I think I succeeded, in only putting one small step into
what you were saying.

> Thing is, I mean what I say and, conversely, say what I mean. I don't
> imply that people are stupid - if I think they're stupid, I say so. And I
> honestly have no idea how to say exactly what I said in my original post but
> "presented" in a different way that happens to prevent people performing
> indirection on it and ending up insulted.

I'll tell you if you really want to know.

Writing is a two way communication mechanism.  There is the meaning
you intend, and there is the meaning that people receive.  The goal
for most people is that people receive the meaning that they intend.
That requires writing in a way that considers not only what you want
to say, but also how people are going to read it.


>> If you really want to learn and change your communication patterns,
>> you can do so.
>
>
> How? And what gives you the right to tell me what I am and am not capable
> of, in direct contradiction of what I said? As a leading authority on me, I
> have to take issue with you there. And, ironically, point out that your
> assertion - after a few indirections - implies that I'm a liar, and lazy,
> and don't give enough of a shit about people to bother being nice. See, I
> can do it too. Fun, isn't it?

I don't think you are lying or lazy, but, you're right, I don't
believe you are describing the only truth, either.  I think you just
don't have enough of a reason to change.  I have no "right" to say
this, any more than you have a "right" to criticize a language that
you don't know well and with no apparent knowledge of the extensive
discussions that have occurred on this very mailing list.  Also, you
are of course correct that I'm being insulting.  I'm just doing it
politely.  The difference between what you wrote and what I wrote is
that you had to think for a bit before you realized the insult,
whereas a number of people spotted that you were being insulting
(which you were, even if you did not mean to be) in your original
post.


> This particular topic is finished.

OK.

Ian
This message has been hidden because it was flagged for abuse.
This message has been hidden because it was flagged for abuse.
Re: [go-nuts] No generics, no overloading, and no adding methods to existing types. How....useful. Ian Lance Taylor 5/17/13 5:13 PM
On Fri, May 17, 2013 at 4:37 PM, Sod Almighty <sod.al...@gmail.com> wrote:
> On Saturday, May 18, 2013 12:15:49 AM UTC+1, Ian Lance Taylor wrote:
>>
>>
>> Remember that on the Internet people come from many different
>> backgrounds and cultures.
>
>
> Oh, and I notice my background and culture counts for fuck-all,
> incidentally. If your (or anyone else's) background and culture means that I
> should take extra care not to "scare" people or use exclamation marks, why
> doesn't my "background and culture" (which, despite being white and English,
> I actually do have) count for a damn thing? Why aren't you telling everyone
> else to take my background and culture into account, and not read shit into
> my words that I didn't put there?

Because you are the newcomer to an existing forum, and as such you are
expected to adopt the prevailing norms of communication.  You can work
to change those norms--but not until you have participated for a
while.

> Because I was brought up to say what I mean, and wasn't taught at an early
> age to couch everything I say in stupid diplomatic language. I was given a
> telling-off at work once for saying "but surely it ought to be this way"
> because "surely" apparently meant "it certainly is, there can be no
> question, and you're an idiot for thinking otherwise". Well it doesn't. Look
> it up. If your "culture" and upbringing and way of speaking is valid, then
> so is mine. When I stoop to name calling and abuse, feel free to call me
> down for it.

"Stupid diplomatic language" is an interesting choice of phrase.  The
language of diplomacy was evolved, over time, specifically so that
nations with radical disagreements, and touchy points of pride, would
be able to communicate about important issues without getting into
fights.  It's awkward and tedious, but it's not stupid.  It's actually
pretty important.

Ian
Re: [go-nuts] No generics, no overloading, and no adding methods to existing types. How....useful. kortschak 5/17/13 5:17 PM
Mayhap, but there is an obvious list of candidates for doing something like what you want just a google away:

https://github.com/astaxie/beedb
https://github.com/coopernurse/gorp
https://github.com/gosexy/db
This message has been hidden because it was flagged for abuse.
Re: [go-nuts] No generics, no overloading, and no adding methods to existing types. How....useful. Ian Lance Taylor 5/17/13 5:23 PM
On Fri, May 17, 2013 at 5:13 PM, Sod Almighty <sod.al...@gmail.com> wrote:
>
>
> On Saturday, May 18, 2013 1:07:04 AM UTC+1, Ian Lance Taylor wrote:
>>
>>
>> Also, you
>> are of course correct that I'm being insulting.  I'm just doing it
>> politely.  The difference between what you wrote and what I wrote is
>> that you had to think for a bit before you realized the insult,
>> whereas a number of people spotted that you were being insulting
>> (which you were, even if you did not mean to be) in your original
>> post.
>
>
> I see. So deliberately insulting me is fine, but using exclamation marks and
> expressing surprise that anyone can use a language without generics is
> unacceptable?

No.  Neither is fine.  At least not if the goal is to actually
communicate ideas.

Ian
This message has been hidden because it was flagged for abuse.
Re: [go-nuts] No generics, no overloading, and no adding methods to existing types. How....useful. Dougx 5/17/13 5:49 PM
I'm not going to discuss it in this thread, which is spiraling out of control, but there's no reason you can't chain methods in go, passing an interface as a return type and doing a type assertion on the result, like:

var blah = package.GetAggregate()
var subset, err = linq.From(blah).Where(func(x T) bool { return x.Value == 10 }).Select(func(x T) []interface{} { return []interface{} { x.Value, x.Name }).OrderBy(func(x1 T, x2 T) bool { return x1.Value > x2.Value }).Result()
var typed_subset = subset.([]int)

Notice you need the .Result() to collect errors and the final result from the data set.

the closure syntax isn't as pretty as in C# or python, where you can x => x.Value == ?, but it *does* work.

You could get pretty far down the road of writing a linq library if you wanted to.

If you want to talk about it practically, start a new thread with a different topic.

~
Doug.

On Saturday, May 18, 2013 6:41:48 AM UTC+8, Sod Almighty wrote:


On Friday, May 17, 2013 11:15:58 PM UTC+1, kortschak wrote:

As another apporach to your question, similar to Ian's would be to take a pointer to an interface{} and plase the results in that. This is used in a number of places in the standard library. This would depend on reflection, but you could take an interfaced-based approach like Foo(a, b Interface, c SetInterface) where a and b satisfy the behaviours you need to het the inputs and SetInterface satisfies the behaviour of storing that result. Potentially no type assertions are needed under this scheme.

Yeah, but you can't do:

results := values.where( ...filter function... ).orderby( ...sorting function... ).select( ...transformation function... )

With your Foo function, it's a laborious job of one-operation-per-line, plus a bunch of typecasts. Yeah, I realise that with enough work and messing about it's possible to write a function Foo(), but that's not what I intended here. My intention was to allow for a simple SQL-like query syntax, in the style of .NET LINQ. Because doing it imperatively is hard work and less readable. Also potentially slower (if it resolves the queries immediately).
Re: [go-nuts] No generics, no overloading, and no adding methods to existing types. How....useful. Chris Bolton 5/17/13 5:49 PM
um.... what? totally useless? seriously? haskell is flourishing and has a huge community behind it, with many general-purpose applications and frameworks out there. #haskell is the 7th largest channel on freenode with over a thousand users in it. Get your head out of the sand.

On Friday, May 17, 2013 3:36:18 PM UTC-7, Sod Almighty wrote:

On Friday, May 17, 2013 11:04:41 PM UTC+1, Ziad Hatahet wrote:
On Fri, May 17, 2013 at 2:59 PM, Sod Almighty <sod.al...@gmail.com> wrote:
Oooh, another native language! I googled for native languages recently and never encountered Rust. Thanks for pointing it out. I'll take a look.

The only other natives I know of are D (buggy as hell), C++, AutoIt (a bit lacking) and Red (afaik, not yet in a usable condition). Any more?

Objective-C and Haskell, to name a couple.

I'm not an expert, but Objective-C would appear (at a casual glance) to suffer from the same problems as C++. For example, it has header files, which I personally consider the absolute most stupid and awkward feature of C/C++. I just googled and apparently it does have a GC, which I didn't realise. But it's primarily a Mac-targeted language. I'm not sure how feasible it'd be to write Windows software in it. Guess I'll take a look. It looks mighty strange at a casual glance, though. Trying to think of it as a parallel universe version of C++ just isn't working for me ;)

Haskell? Are you serious? It's a purely functional language - which in my opinion means it's totally useless - and, as far as I'm aware, totally dead except amongst mathematicians.
Re: [go-nuts] No generics, no overloading, and no adding methods to existing types. How....useful. Sean Russell 5/17/13 5:53 PM
Hi Ian,

On Friday, May 17, 2013 5:43:20 PM UTC-4, Ian Lance Taylor wrote:
On Fri, May 17, 2013 at 1:57 PM, Sean Russell <seaner...@gmail.com> wrote:
> Not really.
>
>     http://play.golang.org/p/TgB_pRVBdP
>
> There goes type safety, and, consequently, a core feature.

The language still has type safety, of course--that's why your code panics.
 
I'm not sure I'd call that type safety.  A run-time panic because of a type error isn't type safety; type safety is supposed to prevent those sorts of errors -- unless you're in the camp that believes type safety is preventing incorrect, continued execution.  I believe this is the same as saying that C prevents pointer errors by segfaulting -- which is to say, it renders the question of "safety" a meaningless question.

What this approach lacks is compile-time type safety.  It's a serious
problem.  I just want to make sure we give it the right name.

Me too, although it's probably not worth quibbling over.  I will cede that it would have been more accurate to say that this sort of programming defeats strong typing.

--- SER
Re: [go-nuts] No generics, no overloading, and no adding methods to existing types. How....useful. Sean Russell 5/17/13 6:00 PM
On Friday, May 17, 2013 5:01:43 PM UTC-4, Sod Almighty wrote:
On Friday, May 17, 2013 9:57:16 PM UTC+1, Sean Russell wrote:
Not really.

    http://play.golang.org/p/TgB_pRVBdP

There goes type safety, and, consequently, a core feature.

What type safety? The type safety that forces you to write a different function for every type you want to use it with; while simultaneously forcing you to give each function a different name?

I think you misunderstood me.  I agree with you.

--- SER
Re: [go-nuts] No generics, no overloading, and no adding methods to existing types. How....useful. Kyle Lemons 5/17/13 6:04 PM
On Fri, May 17, 2013 at 4:32 PM, Sod Almighty <sod.al...@gmail.com> wrote:
On Saturday, May 18, 2013 12:15:49 AM UTC+1, Ian Lance Taylor wrote:
On Fri, May 17, 2013 at 3:51 PM, Sod Almighty <sod.al...@gmail.com> wrote:

You don't intend an insult.  But you are implying that the system is
not merely deficient but obviously and fragrantly deficient.

I think perhaps you mean "flagrantly deficient". I didn't say anything about how it smells.
 
You are
implying that no ordinary person would want to use it.  It follows
that you are implying that the people who do use it are not ordinary.
It's a pretty short step from there to think that you are calling the
people who do use it stupid.  The step may not be warranted, but many
people will take it.  And at that point, it's an insult.

Well, if you're gonna read several layers of indirection into my words, sure. Thing is, I mean what I say and, conversely, say what I mean. I don't imply that people are stupid - if I think they're stupid, I say so. And I honestly have no idea how to say exactly what I said in my original post but "presented" in a different way that happens to prevent people performing indirection on it and ending up insulted.

Hmm.  I would like to try my hand at a rewrite.  Here goes:

Hi all.

I'm trying to implement a Linq-alike for Go.  In the process of doing so, I've run into a few paradigms that I haven't been able to translate clearnly into Go.
  1. Generics. I am used to having generics at my disposal, and I haven't been able to create an API that is able to be as simultaneously concise and type-safe as I would like.

  2. Overloading. One way I'd typically be able to side-step the generics issue is with overloading.

  3. Methods on predefined types.  If I could define methods on the predefined types, I would be able to make them implement interfaces, which might help to create a suitable API.
I'm excited to learn a new compiled systems language, but I haven't been using Go for very long and I would like some tips about what an idiomatic API for a LINQ-alike would be.

As an example, I want a function which is conceptually like this:

func Ana(seed T, condition func(T) bool, next func(T) T) FEnumerable<T> {
   ... code ...
}

I Ideally I would be able to chain statements like "From(something).Where(filter).Select(transformation)".   I've tried a few different approaches:

(1) Return an interface
- ... problems you ran into ...
(2) ... other attempted solution ...

Here is the latest version of my code: http://example.com/foo/linq

If anyone has any tips about how to approach this or pointers to APIs that have done it in an idiomatic way, it would be much appreciated!
 

--
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.
For more options, visit https://groups.google.com/groups/opt_out.

As a bit of an aside, there is a package somewhere (a bit of searching didn't turn up the name, though I'm sure someone around will remember) that allows you to write SQL queries using chained functions in the way you describe by using interfaces.  I feel like it had "pretty" or "simple" in the name, if that jogs anyone's memory.
This message has been hidden because it was flagged for abuse.
Re: [go-nuts] No generics, no overloading, and no adding methods to existing types. How....useful. Ziad Hatahet 5/17/13 6:22 PM
On Fri, May 17, 2013 at 3:36 PM, Sod Almighty <sod.al...@gmail.com> wrote:
Haskell? Are you serious? It's a purely functional language - which in my opinion means it's totally useless - and, as far as I'm aware, totally dead except amongst mathematicians.


Except that Carmack is porting Wolfenstein 3D into it :) It will be an interesting project to follow IMO: https://twitter.com/id_aa_carmack/status/331918309916295168


--
Ziad

Re: [go-nuts] No generics, no overloading, and no adding methods to existing types. How....useful. Sanjay 5/17/13 6:39 PM
C#'s async in Go would be quite superfluous, as far as I can tell. In Go, all blocking operations are implicitly marked async, and whenever you call these operations, you are implicitly calling await. The keyword `go' is roughly equivalent to creating and running a Task.

For instance, this: http://play.golang.org/p/w-MTUDAyCD is a concurrent echo server. 

Note that yield and iterators are a different story; I wouldn't mind seeing coroutines, or more accurately iterators in Go sans-channels, but I don't think the authors are super interested. Discussion for another day, though.

Sanjay
This message has been hidden because it was flagged for abuse.
This message has been hidden because it was flagged for abuse.
Re: [go-nuts] No generics, no overloading, and no adding methods to existing types. How....useful. kortschak 5/17/13 6:53 PM
Are you thinking of gosexy?
Re: [go-nuts] No generics, no overloading, and no adding methods to existing types. How....useful. Sanjay 5/17/13 9:26 PM
You asked about what was wrong with using the C# implementation.

They have a simplifying factor, which is that they can do runtime expansion easily. Since they are running in a VM, they can do compact bytecode generation by having bytecode that is generics-aware, and then at runtime JIT compile specializations for each type, this gives it C++'s speed without C++'s bloat for compiled artifacts. Note that this can pollute CPU caches, so they do some clever things like sharing implementations of generic functions that are similarly sized, etc. This is an excellent implementation; but requires a VM to be easily implementable. Of course, it is possible for Go to do similar things with runtime code generation, but requiring runtime code generation has security implications, and would be quite unfortunate.

Then there's reified generics from Java. i.e. you write list<T>, and the compiler compiles it as list<interface{}>, and writes the casting for you. This is somewhat inefficient and inelegant. In particular, when you write something like List<Integer>, this is a pointer to an array of pointers to integers, rather than what you'd expect (a pointer to a list of integers).

That leaves C++'s generate all the template specializations approach. This is really crappy for C++ because it involves the compiler generating all specializations for object files. Then the linker has to try and throw away duplicates, it has to try and merge redundant implementations and so on. The final runtime code generally is very fast, but the object files tend to be bloated, and this will definitely slow the compilation process.

I think the most promising approach for Go is something like this. The compiler generates object files with a compact generics-aware AST representation. The linker still has to dedupe, but it should be easier because unlike C++, code hasn't been generated yet. It can merely look at what calls to max(T, T) exist in the whole program after eliminating dead code, and then emit specialized code for just those max functions. It would need similar optimizations to C#, such as emitting one type for LinkedList<uint32> and LinkedList<int32> and so on. This model could support the aggressive inlining that makes C++ templates so fast. Major downside is that a lot of work gets shifted to link time; anyone who's timed Go builds in detail can tell you that they are already usually the bottleneck, and this will make them even more so. The corollary is that compiles of packages will become even faster, as it basically just entails type-checking. Also, optimization will get easier, because the linker has a whole-program view, so it can inline cross-package, and so-forth.

Anyways, thats just mechanics of how to make the implementation work, but the other half of the problem is to how to fit it into the language and APIs nicely, and orthogonally. You have to spec out how they interact with interfaces, and what the syntax looks like, and how to make them simple to understand and how to make them predictable for developers. This is probably a non-trivial problem; I believe that this half is much much harder.

Cheers,
Sanjay
Re: [go-nuts] No generics, no overloading, and no adding methods to existing types. How....useful. ksug 5/17/13 4:28 PM
Haskell is not "functional only" anymore once you get to monads. Whether the use of monads makes our life easier or harder is a different story.


On 5/17/2013 6:17 PM, Sod Almighty wrote:
On Saturday, May 18, 2013 12:08:36 AM UTC+1, Sanjay wrote:
I feel obligated to point out the irony that you want to implement LINQ while having the opinion you do about Haskell (and functional languages, more generally). The contrast tickled me.

No irony at all. The functional paradigm has its uses - e.g. LINQ - and can make code far more readable. Some programming problems just lend themselves better to the functional style. I never said I didn't approve of the functional style.

The problem with Haskell is - correct me if I'm wrong - it's functional only. And that's neither use nor ornament to anything who isn't a maths prof. Try writing a Windows application in a pure functional language. Even F# supports imperative statements.
--
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.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

Re: [go-nuts] No generics, no overloading, and no adding methods to existing types. How....useful. Ian Lance Taylor 5/17/13 10:44 PM
On Fri, May 17, 2013 at 8:30 PM,  <and...@atoulou.se> wrote:
>
> What I'd like to know is what are the pitfalls of compile-time struct
> mixins? i.e:
>
> import (
>   "io"
>   "code.google.com/p/sneakygophers" `mixin:"ExampleNumber(uint64)"`
> )
>
> where the sneakygophers (made-up name) package is imported with methods on
> the struct type sneakygophers.ExampleNumber aliasing to uint64 *only within
> the mixin package*? Admittedly, I haven't thought through the full
> implications of this, as I am still busy learning the language itself. Does
> this complicate things too much? Does it make sense to have an explicit
> file-local or package-local ability to augment types with methods for the
> purpose of satisfying interfaces? If you have to be explicit, you make it
> extremely obvious when you're abusing templates, because you have to tell
> the source to instantiate the implementation each time you  add one
> (...which is no worse than what we have now?).

The main thing that troubles me about this approach is that it becomes
awkward to have containers of containers.  You need to somehow
specialize the container package for the base type, and then
specialize it again for the container type.  It's a tempting idea but
I don't really think it's the way to go.

Ian
Re: [go-nuts] No generics, no overloading, and no adding methods to existing types. How....useful. Michael Jones 5/18/13 12:33 AM
I propose a rethinking of one of the "getting generics right" tenets -- the focus on making the compile time not just blazingly fast, but as fast as possible, "double blazing" if that was a phrase. 

The Go developers have structured the language to allow amazingly fast compile times. They have implemented it in a way that realizes these amazingly fast compiles. For example, the whole language and libraries bild in a minute on my little notebook computer. Amazing!

That said, there is a point where frugal can become miserly, and I suggest that generics should cause reevaluation of means and end on this very point. Here is the basic a general C++ like template system (user view) but with a magical and fast aspect made possible by Go's structure. The magic is in the importing. We need a flag in there (invisible to the developer) than says "Templates are used in this package or in its dependencies, and these are what they are." 

This allows the the compiler to know a priori which generic specifications need to be instantiated and what type combinations they need to be instantiated for.

This allows the concrete calling sequences to be known when the callers are being compiled.

This allows the compiler to emit the instantiations just once, at its discretion in terms of when.

In spirit, it means "compiling twice" and that's what makes it simple to implement and explain. But the hierarchical nature of the package manifests and their pre-order visitation by the compiler means that you actually only have to do it once since you're building the template and instantiation tree efficiently as part of decoding package data (so you never have to discover a fact twice.)

How fast would this be? Same speed as now when no generics are in use. Similar speed in parse/analyze package headers as now. Extra time to instantiate the minimal set of templated functions, but this is 1:1 with the time to compile the same functions is elaborated manually by the developer, so a tie.

There would be a memory cost in keeping the "for those packages that rely on a template, here are the pointers to definitions of when they need to have instantiated" data structures during that package tree traversal. But at the end of that traversal the necessary functions could be immediately instantiated if desired and then the whole data structure deleted. Everything else in the compile can then proceed as now (with lexical substitution of the expanded template names happening, of course.)

Here is the frugal/miserly as fast as possible argument: if this process adds more than a few percent to the compile time, I would be surprised. But let's be generous and say it costs an extra 5% of the entire time for compiles where even one generic is used. I'm saying that 1 minute and 3 seconds would not be too much of an increase over the existing blazingly-fast one minute. This is a worthy place to spend a tiny bit of our time savings account, yet we'll never even consider it if we keep the initial condition of "as fast as possible." Let's weaken that to just "amazingly, awesomely, astoundingly fast" and be willing to use a percent or two of the peak speed to give developers peak speed in their work.

Michael
(In Amsterdam)


--
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.
For more options, visit https://groups.google.com/groups/opt_out.





--
Michael T. Jones | Chief Technology Advocate  | m...@google.com |  +1 650-335-5765
Re: [go-nuts] No generics, no overloading, and no adding methods to existing types. How....useful. Gerard 5/18/13 2:23 AM
Michael, I like your motivating posts. 

I am not an expert in the subject of generics, however I don't see any real benefit of them. Why? Because they are being misused. A nice example is a first grade C++ chess engine, Stockfish. If you look at the header files, it's template all over. And that's because the types, declared in types.h are enums, so in fact they are all ints. And C++ can't handle the enums. In Go, when you want the types (derived ints), just define an interface with a getter and that's it. So, yes there is some boilerplate, but the code is still compact and, most of all, clear and easy to understand.

Btw, have fun in Amsterdam. And be aware of the dog poo on the sidewalks.

Op zaterdag 18 mei 2013 09:33:02 UTC+2 schreef Michael Jones het volgende:
Re: [go-nuts] No generics, no overloading, and no adding methods to existing types. How....useful. Aram Hăvărneanu 5/18/13 2:33 AM
> you need to [...] cast the slice of Person to a slice of
> PersonSortingByAge

No cast in Go. A potential *conversion* between those two types
means copying 3 words, and it's compile time type safe.

> no generics means no reusable code

Ridiculous claim. You can have reusable code in assembly. You just
can't have the type of reusable code you are accustomed to. Interfaces
allow reusable *code* in Go.

You can't have generic containers in Go, but that's another thing.

> It seems LINQ simply cannot be done in Go.

Great. One of the philosophical principles of Go is to avoid magic
things that have unintuitive or variable space or memory behavior.

--
Aram Hăvărneanu
Re: [go-nuts] No generics, no overloading, and no adding methods to existing types. How....useful. kortschak 5/18/13 2:37 AM
You can't have the type of generic containers you have in other languages in all cases, but you can have some, and then many more if you allow assertions.
Re: [go-nuts] No generics, no overloading, and no adding methods to existing types. How....useful. Andrew Akira Toulouse 5/18/13 2:41 AM
That's funny! I was just writing this email and before I saw your email, "very deep rabbit hole" was exactly my phrasing as well!

After ruminating a bit, I'm thinking the idea that adding generics is a disproportionately and extraordinarily large design challenge given its presumed benefits, and perhaps the issue is best avoided until it can be demonstrably shown that the language has a poor solution to a situation that generics would compellingly solve. So far, I haven't seen it.

I wonder if generics are even the fundamental problem here. The original question's itch that was attempted to be scratched was basically implementing a DSL for LINQ-like behavior. Is there some way we can facilitate the kind of type-safe method composition necessary for this without specifically designing and adding generics into the syntax? I think that a concise method of creating a filtered dataset or filtered pipeline of data would be compelling, and that perhaps the way to think of this is how can we add constructs that facilitate simply and concisely expressed, composable, and typesafe filters/transformers.
Re: [go-nuts] No generics, no overloading, and no adding methods to existing types. How....useful. Russel Winder 5/18/13 3:24 AM
On Fri, 2013-05-17 at 14:59 -0700, Sod Almighty wrote:
[…]
> The only other natives I know of are D (buggy as hell), C++, AutoIt (a bit
> lacking) and Red (afaik, not yet in a usable condition). Any more?

This is the second time you have made the claim that D is unusable due
to bugs. Can I suggest that rather than just making unsubstantiated
claims to go to the D mailing list and debate the actual issues you
have.

C++ / D / Go / Rust is a really interesting situation just now and the
classes and generics issues are interesting ones. I would though prefer
substantiated debate rather than simple off-hand opinion.

--
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russ...@ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Re: [go-nuts] No generics, no overloading, and no adding methods to existing types. How....useful. alco 5/18/13 3:52 AM
If you set up a second ML for Go2 you'll hopefully see less heated discussions about changing Go on this list. Since Go 1.x won't ever get the changes mentioned in the first post and Go2 is years (probably decades) away, discussing it here does not feel that productive.
--
Best regards
Alexei Sholik
Re: [go-nuts] No generics, no overloading, and no adding methods to existing types. How....useful. mpl 5/18/13 5:20 AM
I must say I am really amazed by your patience and selflessness here
Ian. Hat tip to you.

On 18 May 2013 02:13, Ian Lance Taylor <ia...@golang.org> wrote:
> On Fri, May 17, 2013 at 4:37 PM, Sod Almighty <sod.al...@gmail.com> wrote:
>> On Saturday, May 18, 2013 12:15:49 AM UTC+1, Ian Lance Taylor wrote:
>>>
>>>
>>> Remember that on the Internet people come from many different
>>> backgrounds and cultures.
>>
>>
>> Oh, and I notice my background and culture counts for fuck-all,
>> incidentally. If your (or anyone else's) background and culture means that I
>> should take extra care not to "scare" people or use exclamation marks, why
>> doesn't my "background and culture" (which, despite being white and English,
>> I actually do have) count for a damn thing? Why aren't you telling everyone
>> else to take my background and culture into account, and not read shit into
>> my words that I didn't put there?
>
> Because you are the newcomer to an existing forum, and as such you are
> expected to adopt the prevailing norms of communication.  You can work
> to change those norms--but not until you have participated for a
> while.
>
>> Because I was brought up to say what I mean, and wasn't taught at an early
>> age to couch everything I say in stupid diplomatic language. I was given a
>> telling-off at work once for saying "but surely it ought to be this way"
>> because "surely" apparently meant "it certainly is, there can be no
>> question, and you're an idiot for thinking otherwise". Well it doesn't. Look
>> it up. If your "culture" and upbringing and way of speaking is valid, then
>> so is mine. When I stoop to name calling and abuse, feel free to call me
>> down for it.
>
> "Stupid diplomatic language" is an interesting choice of phrase.  The
> language of diplomacy was evolved, over time, specifically so that
> nations with radical disagreements, and touchy points of pride, would
> be able to communicate about important issues without getting into
> fights.  It's awkward and tedious, but it's not stupid.  It's actually
> pretty important.
Re: [go-nuts] No generics, no overloading, and no adding methods to existing types. How....useful. hutch 5/18/13 7:32 AM

On 2013-05-17, at 7:17 PM, Sod Almighty <sod.al...@gmail.com> wrote:

The problem with Haskell is - correct me if I'm wrong - it's functional only. And that's neither use nor ornament to anything who isn't a maths prof. Try writing a Windows application in a pure functional language. Even F# supports imperative statements.


Haskell *is* functional *and* happens to be "the world's finest imperative language" -- or so they say :-) In my opinion, it is very easy and natural to write imperative code in Haskell, and you will remain 100% functional while doing so.

It has generics too :-)

As for it's usefulness to those other than maths profs… I'm no maths prof but I've had rather good success at implementing a very tricky application in Haskell that I could not reasonably write in Go (and I tried).

Have a read of "Tackling the Awkward Squad" at:


Note the author's affiliation. This is the paper where the phrase "the world's finest…" above comes from, and the paper is intended in part to argue the claim. This paper was very important to my 'getting' Haskell. I think it's particularly useful for programmers experienced in other languages and who are coming to Haskell.

This is not to say that Haskell is easy.

Cheers,
Bob

This message has been hidden because it was flagged for abuse.
Re: No generics, no overloading, and no adding methods to existing types. How....useful. suharik 5/19/13 8:21 AM
If you want generics, post your proposal here, and then read to this link: http://goo.gl/1j8Cs
We want to have sane generics in go too.

Also, I'd like to have something like haskell monads to handle errors, instead of code like this: http://stackoverflow.com/a/16127029/2267702

This message has been hidden because it was flagged for abuse.
Re: [go-nuts] Re: No generics, no overloading, and no adding methods to existing types. How....useful. Rémy Oudompheng 5/19/13 11:22 AM
On 2013/5/19 Sod Almighty <sod.al...@gmail.com> wrote:
> Go has some nice features; but I draw the line at writing boilerplate code
> everywhere. That's what we're supposed to be avoiding. Personally, I think
> you should just decide on a damn implementation, and do it. You're never
> gonna find a perfect solution, and having no solution is worse than having a
> less-than-perfect one.

I wrote Go programs for the past year and never felt like it was
boilerplate, and usually didn't feel the need to write boilerplate.

Why are you actually writing boilerplate?

Rémy.
This message has been hidden because it was flagged for abuse.
Re: [go-nuts] Re: No generics, no overloading, and no adding methods to existing types. How....useful. Andreas Krennmair 5/19/13 11:53 AM


On 19.05.2013, at 20:13, Sod Almighty <sod.al...@gmail.com> wrote:


Go has some nice features; but I draw the line at writing boilerplate code everywhere. That's what we're supposed to be avoiding. Personally, I think you should just decide on a damn implementation, and do it. You're never gonna find a perfect solution, and having no solution is worse than having a less-than-perfect one.

Have you ever considered the possibility that your Go experience might be bad because you use Go is exactly like you use a completely different language even though the language features don't match? All your rambling here moved around the topic of not having generics. Instead of trying to get generics into Go with all force and much insulting of developers, you should rather consider trying to embrace Go's language feature set. Most Go users managed to do so without having to produce much or any boilerplate, so you should manage, too.

Andreas
This message has been hidden because it was flagged for abuse.
Re: [go-nuts] Re: No generics, no overloading, and no adding methods to existing types. How....useful. Rémy Oudompheng 5/19/13 12:12 PM
Did you actually try to write it?

Here is an interesting way of doing it in Go:

func main() {
    files, err := ioutil.ReadDir("/usr/lib")
    if err != nil {
        log.Fatal(err)
    }
    var txts []os.FileInfo
    for _, f := range files {
        if strings.HasSuffix(f.Name(), ".so") {
            txts = append(txts, f)
        }
    }
    is := SimpleSort(len(txts), func(i, j int) bool {
        return txts[i].ModTime().After(txts[j].ModTime())
    })
    var s []string
    for _, i := range is[:10] {
        fmt.Println(i)
        n := strings.ToUpper(txts[i].Name())
        s = append(s, n[:len(n)-3])
    }
    DoSomethingWith(s)
}

// Generic sorting function (simple to use and reusable anywhere).
func SimpleSort(length int, less func(i, j int) bool) []int {
    s := simpleSorter{
        LessFunc: less,
        Indices:  make([]int, length),
    }
    for i := range s.Indices {
        s.Indices[i] = i
    }
    sort.Sort(&s)
    return s.Indices
}

type simpleSorter struct {
    LessFunc func(i, j int) bool
    Indices  []int
}

func (s *simpleSorter) Len() int           { return len(s.Indices) }
func (s *simpleSorter) Less(i, j int) bool { return
s.LessFunc(s.Indices[i], s.Indices[j]) }
func (s *simpleSorter) Swap(i, j int)      { s.Indices[i],
s.Indices[j] = s.Indices[j], s.Indices[i] }

Notice how in this code, the SimpleSort function and simpleSorter type
are generic and totally reusable, we can assume it to live in a nice
library. The body of main() contains exactly 375 non-whitespace
characters.

Now here is the LINQ equivalent on that code using your syntax suggestion:

func linq_main() {
    files, err := ioutil.ReadDir("/usr/lib")
    if err != nil {
        log.Fatal(err)
    }
    s := files.Where(func(fi os.FileInfo) bool {
        return strings.HasSuffix(fi.Name(), ".so")
    }).OrderBy(func(a, b os.FileInfo) bool {
        return a.ModTime().After(b.ModTime())
    }).Select(func(fi os.FileInfo) string {
        n := strings.ToUpper(fi.Name())
        return n[:len(n)-3]
    })
    s = s[:10]
    DoSomethingWith(s)
}

That's 325 non-whitespace characters in the body. So less than 15% of
characters are saved, and the code looks like a dense block of
difficult to read things (mostly because of Go's closure syntax, but
the debate is about generics, not closure syntax).

And my version has the advantage of being totally type safe, and not
need any language extensions.

Rémy.
Re: [go-nuts] Re: No generics, no overloading, and no adding methods to existing types. How....useful. Rémy Oudompheng 5/19/13 12:13 PM
On 2013/5/19 Sod Almighty <sod.al...@gmail.com> wrote:
I just sent one.

Rémy.
Re: [go-nuts] Re: No generics, no overloading, and no adding methods to existing types. How....useful. Ziad Hatahet 5/19/13 12:23 PM

On Sun, May 19, 2013 at 12:12 PM, Rémy Oudompheng <remyoud...@gmail.com> wrote:
    s := simpleSorter{
        LessFunc: less,
        Indices:  make([]int, length),
    }


This solution might be more generic, but now you are introducing a huge memory overhead with the Indices slice. Unless I am missing something, it is proportional to the number of elements you want to sort, correct?
 

and the code looks like a dense block of
difficult to read things (mostly because of Go's closure syntax, but
the debate is about generics, not closure syntax).


True. A language that does type inference on closure/lambda syntax (I think even Java is getting this in the next release) would make this much more compact, elegant, and easier to read.

--
Ziad

Re: [go-nuts] Re: No generics, no overloading, and no adding methods to existing types. How....useful. Andreas Krennmair 5/19/13 12:27 PM


On 19.05.2013, at 20:57, Sod Almighty <sod.al...@gmail.com> wrote:


Alright. How would I go about filtering, sorting and transforming a list of arbitrary objects without all this faffing about? Is there some nifty Go solution that I'm missing? Some way to avoid having to write a new type every time I want to change how something is sorted, perhaps?


writing functions to operate on arbitrary data by using interfaces and type assertions is surprisingly low-overhead in terms of boiler plate. I admit, this is not the optimal solution because it moves some type safety from compilation to runtimr, but I dare to claim that this won't be a bottleneck in any of your programs anytime soon, and reasonable automated test coverage can alleviate the type safety issue.

IIRC, there was also another library published recently that solved the problem in a similar and type-safer fashion using reflection internally.

Also, what Rémy sent you.

Andreas

Re: [go-nuts] Re: No generics, no overloading, and no adding methods to existing types. How....useful. Rémy Oudompheng 5/19/13 12:36 PM
On 2013/5/19 Ziad Hatahet <hat...@gmail.com> wrote:
>
> On Sun, May 19, 2013 at 12:12 PM, Rémy Oudompheng <remyoud...@gmail.com>
> wrote:
>>
>>     s := simpleSorter{
>>         LessFunc: less,
>>         Indices:  make([]int, length),
>>     }
>>
>
> This solution might be more generic, but now you are introducing a huge
> memory overhead with the Indices slice. Unless I am missing something, it is
> proportional to the number of elements you want to sort, correct?

Yes, but it may not necessarily be a problem. A language with generics
that requires that everything is a pointer would have a larger
overhead. Also the overhead is very small compared to the extra memory
required by the usage of ioutil.ReadAll.

Rémy.
Re: No generics, no overloading, and no adding methods to existing types. How....useful. Andrew Gallant 5/19/13 12:47 PM
> IIRC, there was also another library published recently that solved the problem in a similar and type-safer fashion using reflection internally.

Probably mine. https://github.com/BurntSushi/ty

Here's a working (semi-ugly) adaptation of Remy's code using my
package: http://play.golang.org/p/CUzYeiQDzI

With some work, it could be adapted into a chaining API I imagine.

- Andrew
Re: No generics, no overloading, and no adding methods to existing types. How....useful. Andrew Gallant 5/19/13 12:51 PM
The downfalls are manifest. I had a type error. Revised:
http://play.golang.org/p/EtTZ5gfd1T

On May 19, 3:47 pm, Andrew Gallant <jams...@gmail.com> wrote:
> > IIRC, there was also another library published recently that solved the problem in a similar and type-safer fashion using reflection internally.
>
> Probably mine.https://github.com/BurntSushi/ty
Re: No generics, no overloading, and no adding methods to existing types. How....useful. Andrew Gallant 5/19/13 1:22 PM
Apologies for the triple post, but I got curious. Here's a simple way
to chain calls like the OP wants. http://play.golang.org/p/_qI-hnw_JU
--- Note that the only burden on the caller is a single type
assertion.

I encourage you to try and subvert the types. My hope is that you'll
get a run-time error that is somewhat comprehensible (but still pretty
sucky).

- Andrew
Re: No generics, no overloading, and no adding methods to existing types. How....useful. Volker Dobler 5/19/13 1:50 PM


Am Sonntag, 19. Mai 2013 20:13:01 UTC+2 schrieb Sod Almighty:
On Sunday, 19 May 2013 16:21:36 UTC+1, suharik wrote:
If you want generics, post your proposal here, and then read to this link: http://goo.gl/1j8Cs
We want to have sane generics in go too.

Apparently you don't. The form at that link essentially boils down to "there are only a finite number of ways to implement generics, and we will accept none of them".

No, this just means that you should come up with the one gödelesque beta function
trick for implementing generics before posting e.g. syntax proposals or implementations
which suffer from the usual issues.

V.

Re: [go-nuts] Re: No generics, no overloading, and no adding methods to existing types. How....useful. Andreas Krennmair 5/19/13 2:27 PM
Exactly the library that I meant. Thank you!

(and now I'll bookmark it so that I'll find it the next time...)

Cheers
Andreas
This message has been hidden because it was flagged for abuse.
Re: [go-nuts] Re: No generics, no overloading, and no adding methods to existing types. How....useful. Rémy Oudompheng 5/19/13 3:43 PM
This is not something I call readable.

>
> And it's more readable in its native .NET implementation, of course:
>
> s = From fi in files
> Where fi.Name.EndsWith(".txt")
> Order By fi.ModTime()
> Select name = fi.Name.ToUpper
> Select IO.Path.TrimExtension(name)

It's readable because it's included in the language.

> A loop can be anything. You have to examine it closely to figure out the
> intent. Whereas a call to OrderBy or Where is obviously a query. And there
> are no temporaries or other clutter, and it's done in a functional (fluent)
> style.

LINQ is a very interesting thing. But Go aims explicitly at having not
many features.
You already have Scala, Haskell and C# for featureful programming and
they fit well the role.

What's the point of having Go if it's identical to these languages? Go
is low-level and imperative, and having no features is also something
valuable, because usable languages with that property are quite rare.
What's wrong with having different languages with different features?

Rémy.
This message has been hidden because it was flagged for abuse.
Re: [go-nuts] Re: No generics, no overloading, and no adding methods to existing types. How....useful. Jesse McNelis 5/19/13 5:31 PM
On Mon, May 20, 2013 at 9:38 AM, Sod Almighty <sod.al...@gmail.com> wrote:
I prefer to have a language (or more than one) with all the features.

Many features a programming language can have can't exist in the same language at the same time.
You can't have a purely functional language that also as shared mutable state. 
A lot of the subsets of C++ that people use is due avoiding problems that exist between conflicting features in C++.

Features are trade offs, you trade one for another. Sometimes you're trading 'time to learn' with 'time to write'.
Readability and writability are often traded against each other. Go trades a lot of writabilty to be more readable.
Go trades some more advanced features to reduce the 'time to learn' and increase cohesion between developers.
Ruby,Python etc. trade a lot of readability for writability.

LINQ is a language within C#, a lot of projects won't use it and any developers not using it will have trouble reading the code that does use it.
C# is a big language. It's unlikely that all the people on a large team will have the same level of understanding of the language. 

The fact that you can't implement a sub-language in Go is actually an advantage. Developers can get up to speed with Go in a few days.
 Once up to speed the number of weird edge cases is small and easy to remember. 

 
.NET would just about qualify, if it weren't for [a] the speed and [b] the runtime library. If I could compile a .NET app into a standalone exe, that'd be alright. Except for games. .NET just isn't fast enough for 'GL, whatever M$ claim.

--
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.
For more options, visit https://groups.google.com/groups/opt_out.
 
 



--
=====================
http://jessta.id.au

Re: [go-nuts] Re: No generics, no overloading, and no adding methods to existing types. How....useful. Dougx 5/19/13 8:37 PM
This is pretty unrelated but:


> LINQ is a language within C#, a lot of projects won't use it and any developers not using it will have trouble reading the code that does use it.

Um. You probably want to go back and do some reading before making a sweeping statement like that.
Linq is a fundamental construct in c#; you would literally fire any developer who couldn't read it.

...and yes, that is perhaps another reason why perhaps it's not suited in go; go wasn't written with it in mind; but it's universal inside C# for everything from for loops to sql queries.

~
Doug.
Re: [go-nuts] Re: No generics, no overloading, and no adding methods to existing types. How....useful. ksug 5/19/13 8:50 PM
Good for you, but I prefer to have a language without all the features, one that is designed with the right restraints. If you want a language that can do virtually all sort of syntax acrobat, there's already Haskell for that. You can write your own your own sub-language/DSL with it. And it's "fast" too, if you use the right compilation option/tools.


On 5/19/2013 6:38 PM, Sod Almighty wrote:

I prefer to have a language (or more than one) with all the features. .NET would just about qualify, if it weren't for [a] the speed and [b] the runtime library. If I could compile a .NET app into a standalone exe, that'd be alright. Except for games. .NET just isn't fast enough for 'GL, whatever M$ claim.


Re: [go-nuts] Re: No generics, no overloading, and no adding methods to existing types. How....useful. Gerard 5/19/13 11:05 PM
Ada is also a very feature rich, incl generics, type-safe language. See wiki.

Op maandag 20 mei 2013 05:50:12 UTC+2 schreef ksug het volgende:
This message has been hidden because it was flagged for abuse.
This message has been hidden because it was flagged for abuse.
Re: [go-nuts] Re: No generics, no overloading, and no adding methods to existing types. How....useful. Jan Mercl 5/20/13 6:12 AM
No offense intended, but I honestly wonder what are you looking for at
golang-nuts? The language unfortunately doesn't suit your needs.
That's sad, but no single language is a solution to everyone's goals.

I, for one, would never, for example, touch C#. What could I gain from
posting on some see-sharp mailing list?

-j
Re: [go-nuts] Re: No generics, no overloading, and no adding methods to existing types. How....useful. Eric Palmer 5/20/13 6:16 AM
Ada appeared in 1980. The c language was circa 1972. At least that was when K&R book was published. 

Sent from my iPhone
--
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.
For more options, visit https://groups.google.com/groups/opt_out.
 
 
This message has been hidden because it was flagged for abuse.
Re: [go-nuts] Re: No generics, no overloading, and no adding methods to existing types. How....useful. Jan Mercl 5/20/13 6:14 AM
You are.

-j
Re: [go-nuts] Re: No generics, no overloading, and no adding methods to existing types. How....useful. Jan Mercl 5/20/13 6:28 AM
On Mon, May 20, 2013 at 3:18 PM, Sod Almighty <sod.al...@gmail.com> wrote:
> A valid question. At the time of posting, however, I didn't realise that Go
> wasn't suitable. It's only after several days and many insults that I have
> realised that Go intentionally has almost no features and is useful
> therefore only for small projects.

Glad you're asking, for example:

jnml@fsc-r630:~/src/code.google.com/p/vitess$ find -name \*.go -exec
cat {} \; | wc
  50131  174497 1393349
jnml@fsc-r630:~/src/code.google.com/p/vitess$

One can probably find also bigger fishes.

-j
Re: [go-nuts] Re: No generics, no overloading, and no adding methods to existing types. How....useful. Rémy Oudompheng 5/20/13 6:31 AM
On 2013/5/20 Sod Almighty <sod.al...@gmail.com> wrote:
It's exactly the contrary: when you are doing small unimportant
projects it is more useful and less time-consuming to use a feature
rich language so that you do not end up with 70% of error-checking and
boilerplate. You don't necessarily want to spend 80 lines of source
code instead of writing a one-shot 10-line Python script.

Conversely, if you are doing a large project, you want
well-structured, homogeneous code, that doesn't constantly mixes up 7
abstractions in the various possible permutations, that doesn't end up
with multiple dialects due to each developer using a subset of the 70
language keywords, or where each module uses its own (of course
incompatible) containers because it's so easy to define new ones.

Also you want code to be accessible to non-specialists, *because* it
is a large project and all parts of the logic cannot be understood by
all developers, so a non-specialist should be able to review code
without asking 10 times a minute "hey, what does ~mut list<&int,
map&&@> means actually?".

I'm not saying that Go is the only language that helps with that. Some
featureful languages may also correctly achieve this. But Go achieves
correctly this goal, and there are quite many large projects written
in Go out there. Go has intentionnally few features *because* it
targets software engineering and complex projects.

Rémy.
Re: [go-nuts] Re: No generics, no overloading, and no adding methods to existing types. How....useful. John Asmuth 5/20/13 6:33 AM


On Monday, May 20, 2013 9:18:57 AM UTC-4, Sod Almighty wrote:
A valid question. At the time of posting, however, I didn't realise that Go wasn't suitable. It's only after several days and many insults

Yes, you did level quite a few insults.
 
that I have realised that Go intentionally has almost no features

A better way to say it would be the minimal set of orthogonal features.
 
and is useful therefore only for small projects.

And you wonder why people think your posts are insulting? This is an absurd and baseless statement that leads me to suspect that you don't have much experience writing useful software.
 
Re: [go-nuts] Re: No generics, no overloading, and no adding methods to existing types. How....useful. chris dollin 5/20/13 6:36 AM

On 20 May 2013 14:11, Sod Almighty <sod.al...@gmail.com> wrote:
On Monday, 20 May 2013 07:05:17 UTC+1, Gerard wrote:
Ada is also a very feature rich, incl generics, type-safe language. See wiki.

Ada!!?? That thing that predates BCPL and C by a considerable margin?

Erm, no: it post-dates both of them. By non-trivial amounts.

Chris

--
Chris "allusive" Dollin
Re: [go-nuts] Re: No generics, no overloading, and no adding methods to existing types. How....useful. rocky 5/20/13 6:39 AM
You are wrong. Someone else mentioned that C came before Ada. So did BCPL.  
Re: [go-nuts] No generics, no overloading, and no adding methods to existing types. How....useful. Nico 5/20/13 6:49 AM
Dear Sod Almighty,


I'm really enjoying this thread, mostly because of some of the
high-quality replies you've been given:

1) Ian Lance Taylor
https://groups.google.com/d/msg/golang-nuts/fmmmgg3B1Ic/XLQtzz-iyY0J

2) R�my Oudompheng
https://groups.google.com/d/msg/golang-nuts/fmmmgg3B1Ic/0nTY0YI0BgUJ

3) Andrew Gallant
https://groups.google.com/d/msg/golang-nuts/fmmmgg3B1Ic/oUJctwt75wUJ

I thought 2) and 3) were brilliant solutions that require no change in
the language.

Is it not possible to implement a LINQ-like package using either
solution? What functionality is missing?


All the best,


Nico
Re: [go-nuts] Re: No generics, no overloading, and no adding methods to existing types. How....useful. chris dollin 5/20/13 6:54 AM
On 20 May 2013 14:39, rocky <rocky.b...@gmail.com> wrote:

Ada!!?? That thing that predates BCPL and C by a considerable margin? I always assumed it was dead and buried. And presumably lacking in features, what with being practically the first ever programming language.

You may have been thinking of Autocode or Algol 60 (although Fortran
 was earlier than the latter). Ada is ... something different.

Chris

--
Chris "allusive" Dollin
Re: [go-nuts] Re: No generics, no overloading, and no adding methods to existing types. How....useful. nvcnvn 5/20/13 6:56 AM
Vào 20:18:57 UTC+7 Thứ hai, ngày 20 tháng năm năm 2013, Sod Almighty đã viết:

almost no features and is useful therefore only for small projects.

An interesting topic.
I've watched this article past few days to learn from everyone.
IMHO, I think there are many out there big projects do not use SQL, so also there are many large projects do not use LINQ, and there could be some pretty big projects do not need Generic...maybe...
Re: [go-nuts] Re: No generics, no overloading, and no adding methods to existing types. How....useful. Gerard 5/20/13 7:02 AM

Ada is ... something different. 

I only said it's feature rich. I didn't say it's perfect. It's quite a beast to be honest. 
 
Re: No generics, no overloading, and no adding methods to existing types. How....useful. Ryan Leavengood 5/20/13 8:22 AM
You say you aren't trolling, but really you are, whether you intend to or not. The fact that your visible name is "Sod Almighty" doesn't help your case either. I suppose you will argue that people shouldn't judge you by your name, but if I posted to some C# mailing lists as M$CanSuckIt, I doubt the programmers there would be particularly helpful.

I'm a Ruby programmer who has been learning Go for a little while and so far I've been quite happy with the simplicity of the language. I've been able to write real usable code without months of training. I've repeatedly tried to learn Haskell and still couldn't write anything productive in it. The prospect of teaching Ruby to someone new is daunting, even though I've been using it for 12 years. Heck I don't even know everything about Ruby after 12 years. C++ isn't one language but 3 or 4 cobbled together into one.

Simplicity is good. The paradox of choice is a real problem. Go's designers made certain choices and decided not to include every kitchen sink feature you could think of. This is a good thing. From what I've seen no one claims Go is perfect or "done". Maybe generics will be added at some point, but I think it is a good thing that the Go developers don't want to release some half-baked form of generics.

If having something like LINQ is really important to you, then Go probably isn't a good choice right now. As another person suggested, you may want to check out Rust. It might be exactly what you are looking for, and given that it is a young language, maybe you could make some nice contributions to it.

Regards,
Ryan
Re: [go-nuts] Re: No generics, no overloading, and no adding methods to existing types. How....useful. Ian Lance Taylor 5/20/13 8:24 AM
On Sun, May 19, 2013 at 1:22 PM, Andrew Gallant <jam...@gmail.com> wrote:
> Apologies for the triple post, but I got curious. Here's a simple way
> to chain calls like the OP wants. http://play.golang.org/p/_qI-hnw_JU
> --- Note that the only burden on the caller is a single type
> assertion.
>
> I encourage you to try and subvert the types. My hope is that you'll
> get a run-time error that is somewhat comprehensible (but still pretty
> sucky).

It might be possible to build on these ideas to construct a pipeline
that does not do anything at initialization time.

var pipeline = Where(func(fi os.FileInfo) bool {
                return strings.HasSuffix(fi.Name(), ".so")
        }).OrderBy(func(a, b os.FileInfo) bool {
                return a.ModTime().After(b.ModTime())
        }).Select(func(fi os.FileInfo) string {
                n := strings.ToUpper(fi.Name())
                return n[:len(n)-3]
        }).Result()

It would still not be compile-time type checked, but it would be
type-checked at program startup.  Then in your code you would do
something like

    pipeline.Start(args).(type)

Ian
This message has been hidden because it was flagged for abuse.
Re: [go-nuts] Re: No generics, no overloading, and no adding methods to existing types. How....useful. Thomas Bushnell, BSG 5/20/13 8:30 AM
This is an interesting guess to make, I suppose, but it turns out that some impressively large projects have been build in languages that lack generic types, generic functions (what you call "overloading"), or methods on remote types. Including in Go.

So, while you may say it's not suited to them, the authors of Go have a lot of experience with large projects, and their judgment disagrees with yours.

I checked to see how many large projects Sod Almighty has written, and I couldn't find any, so I'm going to go with the judgment of the Go authors on this one.

Thomas



--
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.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

Re: [go-nuts] Re: No generics, no overloading, and no adding methods to existing types. How....useful. Ian Lance Taylor 5/20/13 8:34 AM
On Mon, May 20, 2013 at 8:24 AM, Sod Almighty <sod.al...@gmail.com> wrote:
>
> I didn't say larger projects hadn't been written in Go. I said it wasn't
> suited to large projects.

I think I have to respectfully disagree.  Go has a number of features
specifically designed for large projects.  They aren't language
features like generics.  They are features like the lack of transitive
imports (that is, no header files), and automatic unique namespaces
for every imported package, and fast compilation.  These features are
not unique to Go, of course.

You (and many others) have identified an omission in Go: the lack of
generics means the lack of compile-time type-checking of code that
works on values of different types.  That lack does indeed cause many
people to seek other languages, as presumably you will do.

I (and many others) think it would be a good idea to add some form of
generics to Go.  But that is not a simple task.  Go was not designed
as a collection of features that people want.  It was designed by
starting with very little and adding features as they were required,
required based on writing real programs.  To simply say that we should
add generics as in .NET is only to start the process.  I replied
earlier on this thread with a number of issues that would need to be
considered and addressed before such a system could be adopted into
Go.

If you want to contribute to this process, then take the time to read
past discussions on the list, including many past proposals for how to
add generics, think about the objections that were raised, and think
about how to address them in ways that fit into the language.

If you just want to say that Go is useless without generics, then,
fine.  We get it.  It's a new idea to you, but it's not a new idea to
us.  Let's move on.

Ian
Re: [go-nuts] Re: No generics, no overloading, and no adding methods to existing types. How....useful. Daniel Jo 5/20/13 8:36 AM
On Mon, May 20, 2013 at 9:24 AM, Sod Almighty <sod.al...@gmail.com> wrote:
I didn't say larger projects hadn't been written in Go. I said it wasn't suited to large projects.


I think that if Go was not suited for large projects, people would not use it for such. That it is used indicates either that we're all fanatical, deluded, and possibly masochistic, or simply that Go is a fine language suitable for a wide variety of projects in a broad range of sizes.

-Daniel
Re: [go-nuts] Re: No generics, no overloading, and no adding methods to existing types. How....useful. Jeremy Wall 5/20/13 8:35 AM



On Mon, May 20, 2013 at 10:22 AM, Ryan Leavengood <leave...@gmail.com> wrote:
You say you aren't trolling, but really you are, whether you intend to or not. The fact that your visible name is "Sod Almighty" doesn't help your case either. I suppose you will argue that people shouldn't judge you by your name, but if I posted to some C# mailing lists as M$CanSuckIt, I doubt the programmers there would be particularly helpful.

I get the sense that he is much more of the Street Preacher type than a troll. That or he is a very very good troll.
 

I'm a Ruby programmer who has been learning Go for a little while and so far I've been quite happy with the simplicity of the language. I've been able to write real usable code without months of training. I've repeatedly tried to learn Haskell and still couldn't write anything productive in it. The prospect of teaching Ruby to someone new is daunting, even though I've been using it for 12 years. Heck I don't even know everything about Ruby after 12 years. C++ isn't one language but 3 or 4 cobbled together into one.

Simplicity is good. The paradox of choice is a real problem. Go's designers made certain choices and decided not to include every kitchen sink feature you could think of. This is a good thing. From what I've seen no one claims Go is perfect or "done". Maybe generics will be added at some point, but I think it is a good thing that the Go developers don't want to release some half-baked form of generics.

If having something like LINQ is really important to you, then Go probably isn't a good choice right now. As another person suggested, you may want to check out Rust. It might be exactly what you are looking for, and given that it is a young language, maybe you could make some nice contributions to it.

Regards,
Ryan

--
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.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

Re: [go-nuts] Re: No generics, no overloading, and no adding methods to existing types. How....useful. Aaron France 5/20/13 8:45 AM
Can we just close this thread now? It's clear that no good discussion is coming of it and the OP clearly doesn't have the smarts to actually take any advice given here.

Regards,
Aaron
Re: [go-nuts] No generics, no overloading, and no adding methods to existing types. How....useful. DV 5/20/13 8:48 AM
The .NET implementation is not without its shortcomings. E.g, this is *not* possible in .NET, but possible in C++. Java  has its own quirks, too. 

public T Add<T>(T one, T two)
{
   return one + two;
}

I don't think the Go developers are *against* generics. What they are against is just adding every little feature people ever requested to the language. That's how you end up with C++ - "it can do everything!" - but it does nothing well. The reason people kind of "jumped" at your throat is because every 2-3 weeks, someone like you comes along and basically says "You boys got a nice cute little language there; Now, how about you add these 5 C++ features, and these two Java features oh and some Haskell and maybe then people will take it seriously. Nice try, though, cute little experiment!". What's worse is, those people *usually* haven't even given the language a fair shot - they just see 2-3 typical features other languages have and Go lack and dismiss it off-the-bat. You can see how it gets....tiring. 

You can't just take all your existing C++/Java/.NET experience and try to apply it to Go. You have to *think* in Go. When you start thinking in Go, the lack of generics becomes a nuisance, not a show-stopper. Really. 

I'm 100% positive that given an implementation of generics that *fits* the general philosophy and design of Go - simplicity and clarity and no huge performance sacrifices - the Go devs would add it in. It's just that nobody has proposed anything that met all those goals. Yet. 

On Friday, May 17, 2013 3:35:31 PM UTC-6, Sod Almighty wrote:


On Friday, May 17, 2013 10:29:23 PM UTC+1, minux wrote:

but you don't seems to propose an implementation of generic, only complained the lack of it,
and that's why people consistently refer you to the FAQ.

Well, as a starting point, what about the .NET implementation? Seems to work well enough. Only shortcoming seems to be the lack of partial types. That is, the inability to specify a generic type without specifying T.

I really don't see what's so hard about it. .NET does it. D does it. A bunch of other languages do it. Granted, I'm not an expert on language design, but it's not exactly a new idea. Surely it can't be beyond the wit of man?
Re: [go-nuts] Re: No generics, no overloading, and no adding methods to existing types. How....useful. rog 5/20/13 9:05 AM
this is potentially a nice use-case for reflect.MakeFunc.

var run func([]os.FileInfo) string
err := Where(func(fi os.FileInfo) bool {
}).OrderBy(func(a, b os.FileInfo) bool {
     return a.ModTime().After(b.ModTime())
}).Select(func(fi os.FileInfo) string {
    n := strings.ToUpper(fi.Name())
    return n[:len(n)-3]
 }).Func(&run)
if err != nil {
    // type checking failed
} else {
    result := run(myFileInfoSlice)
    ...
}

that way you end up with a nice statically typed function
that hides all the dynamic stuff inside.
Re: [go-nuts] Re: No generics, no overloading, and no adding methods to existing types. How....useful. rog 5/20/13 9:12 AM
On 20 May 2013 17:05, roger peppe <rogp...@gmail.com> wrote:
> that way you end up with a nice statically typed function
> that hides all the dynamic stuff inside.

(and you can potentially do all the dynamic type checking at init
time too, so you know that if tests pass, you won't get a dynamic
type failure when running for real).
Re: [go-nuts] Re: No generics, no overloading, and no adding methods to existing types. How....useful. Steven Blenkinsop 5/20/13 9:19 AM
On Mon, May 20, 2013 at 11:34 AM, Ian Lance Taylor <ia...@golang.org> wrote:

If you want to contribute to this process, then take the time to read
past discussions on the list, including many past proposals for how to
add generics, think about the objections that were raised, and think
about how to address them in ways that fit into the language.

Looking at this objection:

On Fri, May 17, 2013 at 6:04 PM, Ian Lance Taylor <ia...@golang.org> wrote:

Currently in Go builtin types do not implement methods, so that would have to change, which makes the approach more complex.

The problem with built-in types having methods is that either the methods would have to themselves be built-in, or you'd need to be able to add methods to a type from a package that doesn't own the type. The primary option is undesirably adding things to the language that should be in a library. The latter can come with all the problems associated with having an open namespace. However, this is only true for exported methods. Unexported methods are properly namespaced separately from the type they're bound to. 

This highlights a concept that already exists in the language: global methods vs package methods. With global methods, it doesn't matter where the method is defined when it comes to satisfying an interface method. This covers all exported methods. With package methods, however, the method is associated with a specific package, and will only satisfy interface methods that are also associated with that package. This covers unexported methods.

Thus, expanding on this, in order to allow extension methods on built-in types (and more generally, on any type belonging to a different package), these methods would have to be package methods. These methods would not be compatible with ordinary exported interface methods, so none of the problems regarding method sets arise. These methods could be called using normal syntax assuming there are no conflicts. It might be useful to have a more fine-grained syntax as well.

In order for this to be really useful, there would have to be some way for interfaces to have exported package methods as well. This could be done with syntax like:
type I interface {
    Foo()                   // exported global method
    . Bar()                 // exported package method for this package
    fmt.String() string // exported package method for fmt
    baz()                   // unexported package method for this package
}

Then comes the question of how other packages could implement an interface containing exported package methods for their own types. One way would be to make global exported methods automatically implement any interface exported package method that is spelled the same way. This would make implementing these methods very general, but you wouldn't be able to implement the same method differently for different packages on your own type. Also, it would mean that package methods cannot have the same name as global methods on the same type, which might be a good rule anyways.

The other, not entirely incompatible, option would be to let people extend other packages with methods for their own types. This gives greater control, but also means a lot of duplication in order to make a type satisfy interfaces from a variety of packages. This may not arise much and could be mitigated by having a form of package inheritance, where the methods associated with a given package are also associated with the inheriting package. Of course, this opens the door to static conflicts, which could either be an error, or force the inheriting package to redefine the conflicting methods so that there is a canonical version for the package. 

Such inheritance would also be useful for the first approach, though not nearly as essential. I can imagine a pattern where a library defines extension methods in a bunch of packages, and then has another package inherit from them all which acts as the target package for interface methods. Without this, each interface method would have to have a canonical package within the library, which doesn't seem too burdensome either.
This message has been hidden because it was flagged for abuse.
Re: [go-nuts] Re: No generics, no overloading, and no adding methods to existing types. How....useful. Ian Lance Taylor 5/20/13 10:01 AM
On Mon, May 20, 2013 at 9:19 AM, Steven Blenkinsop <stev...@gmail.com> wrote:
>
> The problem with built-in types having methods is that either the methods
> would have to themselves be built-in, or you'd need to be able to add
> methods to a type from a package that doesn't own the type. The primary
> option is undesirably adding things to the language that should be in a
> library. The latter can come with all the problems associated with having an
> open namespace. However, this is only true for exported methods. Unexported
> methods are properly namespaced separately from the type they're bound to.

Also for "type I int" we would need to have type I somehow inherit the
builtin methods of int, which does not currently happen.

> In order for this to be really useful, there would have to be some way for
> interfaces to have exported package methods as well.

At this point it sounds like we are getting into having the same
(exported) name mean different things in different packages, and that
seems troubling.

Ian
Re: [go-nuts] Re: No generics, no overloading, and no adding methods to existing types. How....useful. Steven Blenkinsop 5/20/13 12:35 PM
On Monday, 20 May 2013, Ian Lance Taylor wrote:

Also for "type I int" we would need to have type I somehow inherit the
builtin methods of int, which does not currently happen.

Yeah, that's the other concern. Right now you have to choose between losing methods via `type T1 int` or losing operator support via `type T2 struct { int }`. There are a few ways to address this that I can see right away, all of which have their issues. The first is to add yet another way to create a derived type, which seems unappealing. Another is to add operator overloading based on method sets, so operators can work in the `T2` case, but this opens the operator overloading can of worms. The third is to add a class of built-in types (like `_int`) which the normal built-in types (like `int`) are considered to embed, which seems complicated and tacked on.

At this point it sounds like we are getting into having the same
(exported) name mean different things in different packages, and that
seems troubling.

It's more like having namespaced method names, essentially duplicating the current behaviour of unexported methods for exported methods. Obviously which ones are visible would depend on which packages you've imported. If this seems insufficiently obvious, you could make it more explicit which namespace you're working with through syntax. However, the same exported name can mean different things in different packages anyways, for example, with functions. The call site might say `sort.Sort`, but depending on what package is imported as `sort`, that could mean different things. A certain degree of context awareness on the part of the reader is always going to be necessary.
Re: [go-nuts] No generics, no overloading, and no adding methods to existing types. How....useful. Sean Russell 5/20/13 6:13 PM
On Sunday, May 19, 2013 6:54:09 PM UTC-4, voidl...@gmail.com wrote:
When people talk about why getting generics "right" is hard and the feature is not part of Go yet, Java and C++ and legitimately used as examples (http://research.swtch.com/generic). Based on those arguments I see and understand the flaws in those two implementations of generics (Java and C++).

Oh, I laughed when I saw this, because it's so true.  You can basically use Java as an example of how not to do almost anything, but especially generics.

I'm secretly hoping that if and when the Go devs figure out how to add support for generics in Go, the syntactic sugar will be something really clever and useful, like Go interfaces.
 
--- SER
Re: [go-nuts] No generics, no overloading, and no adding methods to existing types. How....useful. Nathan Youngman 5/20/13 10:49 PM

The Go language is intentionally minimal and intentionally tries to
provide a relatively small number of concepts.  Citing D, a language
with a very different philosophy, doesn't get us very far.  That said,
I am not familiar offhand with how D implements generics.  D's
heritage suggests it might be similar to C++ templates, which would
not be a good fit for Go.  But I don't really know.

Ian

I recall reading about D having an interpreter built into the compiler, a sort of metaprogramming facility for a compiled language. I believe that's related to how D does generics, but I don't know for sure. There are a few other interesting things about D, such as the concept of pure functions (which can still be imperative internally). Indeed it is a very different language, and I've also heard that it is rather buggy. Last I checked only the front-end is open source.

The sort package was mentioned, but I wonder if something should be added to the FAQ/Documentation on this approach? Nate Finch has a write up: http://blog.natefinch.com/2013/04/statically-typed-generic-data.html

Nathan.







This message has been hidden because it was flagged for abuse.
Re: No generics, no overloading, and no adding methods to existing types. How....useful. Paulo Pinto 5/21/13 4:21 AM
Maybe the first step could be instead of focusing so much in .NET/C++/
Java models
of genericity, to broaden the horizons and look at the myriad of
languages and their
available implementations, that offer support for generics?
Re: [go-nuts] Re: No generics, no overloading, and no adding methods to existing types. How....useful. rog 5/21/13 4:39 AM
On 21 May 2013 12:21, Paulo Pinto <paulo....@gmail.com> wrote:
> Maybe the first step could be instead of focusing so much in .NET/C++/
> Java models
> of genericity, to broaden the horizons and look at the myriad of
> languages and their
> available implementations, that offer support for generics?

I'd like to know how many of the myriads do not  conform to the "box everything"
model.

In particular do you know of any language that implements generics that:
- doesn't dynamically compile code (.Net)
- doesn't box everything (haskell, ML etc)
- doesn't type-erase? (Java)
- doesn't result in combinatorial code explosion (C++)

?
Re: No generics, no overloading, and no adding methods to existing types. How....useful. Paulo Pinto 5/21/13 4:59 AM
I know that Dylan, Eiffel, Beta, Sather, Modula-3, Ada also offer
generics, and you failed to mention them, I
just don't have information about their canonical implementations.

Many of those also compile quite fast.

.NET also has ahead of time compilation available, ngen, mono, bartok
and Windows Phone 8 compilers.

Keeping the talk all the time about .NET/C++/Java, gives the message
that other language
implementations are being ignored, even if that is not the case.


--
Paulo

On 21 Mai, 13:39, roger peppe <rogpe...@gmail.com> wrote:
Re: [go-nuts] Re: No generics, no overloading, and no adding methods to existing types. How....useful. rog 5/21/13 6:26 AM
On 21 May 2013 12:59, Paulo Pinto <paulo....@gmail.com> wrote:
> I know that Dylan, Eiffel, Beta, Sather, Modula-3, Ada also offer
> generics, and you failed to mention them, I
> just don't have information about their canonical implementations.

Yes, there probably hundreds of languages that implement generics.
It might be nice to have a survey to see how each one fits into
the implementation landscape. I don't have the information either,
and it's not trivial to find out.

There are other things it's good to know about other implementations
too. For example, on a random browse, I found this:
"Last but not least: Although all code presented here is 100% legal
Eiffel, do not try to compile this code with any other compiler than
EiffelStudio. And do not store nats larger than 1000 using NAT. Bad
things will happen ... we are here definitely at the border of what
Eiffel compilers can handle."

(from http://community.eiffel.com/room/article/fun_with_generics )

It would be nice if Go did not become a language with dark spots like that.

> Keeping the talk all the time about .NET/C++/Java, gives the message
> that other language
> implementations are being ignored, even if that is not the case.

The names are used as archetypes of particular implementation
techniques rather than an exhaustive list, I think. If there's a particular
language that uses some substantially different technique, we should
talk about that too.
Re: [go-nuts] Re: No generics, no overloading, and no adding methods to existing types. How....useful. Michael Jones 5/21/13 6:38 AM

On Tue, May 21, 2013 at 9:39 PM, roger peppe <rogp...@gmail.com> wrote:
doesn't result in combinatorial code explosion (C++)

But I *want* combinatorial code explosion! Please don't see this as a precondition for the golden fleece of generic designs. I want literal/optimal/best runtime code for every distinct combination of function argument types. If there is to be any run-time test and switch then I can do that now with interfaces.
Michael T. Jones | Chief Technology Advocate  | m...@google.com |  +1 650-335-5765
Re: [go-nuts] Re: No generics, no overloading, and no adding methods to existing types. How....useful. Ian Lance Taylor 5/21/13 6:54 AM
On Tue, May 21, 2013 at 6:26 AM, roger peppe <rogp...@gmail.com> wrote:
>
> The names are used as archetypes of particular implementation
> techniques rather than an exhaustive list, I think. If there's a particular
> language that uses some substantially different technique, we should
> talk about that too.

Yes, I agree.  In particular it's natural to talk about C++/Java/.NET
because those are three different styles of generics, and each could
be adapted to Go.  Most compiled languages adopt one of those three
approaches.

A significant language with a different approach to generics is
Haskell, which actually has two different kinds of generics:
datatype-generic and type classes.  Also, ML has a rather complex
concept called functors; this may be the most sophisticated form of
generics in a well-known programming language.

Ian
This message has been hidden because it was flagged for abuse.
Re: [go-nuts] Re: No generics, no overloading, and no adding methods to existing types. How....useful. Nico 5/21/13 8:37 AM
On 21/05/13 16:31, Sod Almighty wrote:
> On Tuesday, 21 May 2013 08:17:06 UTC+1, Bienlein wrote:
> I disagree. Closures are not covariant, and there are no generics.
> Therefore you can't write (for example) a sort function that takes a
> closure telling it how to implement the sort. At least not in a
> type-safe manner.

I think you've already been given two examples that implement a
type-safe sort using closures:


2) R�my Oudompheng
https://groups.google.com/d/msg/golang-nuts/fmmmgg3B1Ic/0nTY0YI0BgUJ

3) Andrew Gallant
https://groups.google.com/d/msg/golang-nuts/fmmmgg3B1Ic/oUJctwt75wUJ
This message has been hidden because it was flagged for abuse.
Re: [go-nuts] Re: No generics, no overloading, and no adding methods to existing types. How....useful. minux 5/21/13 10:00 AM
Re: [go-nuts] Re: No generics, no overloading, and no adding methods to existing types. How....useful. Nico 5/21/13 10:03 AM
OK. I got it. You mean, instead of:


sfiles = fun.QuickSort(func(a, b os.FileInfo) bool {
                return a.ModTime().After(b.ModTime())
        }, sfiles)


something like this:


sfiles = fun.QuickSort(func(a, b Afterer) bool {
                return a.After(b)
        }, sfiles)

where after would be an interface. Would that do the trick?
This message has been hidden because it was flagged for abuse.
This message has been hidden because it was flagged for abuse.
Re: [go-nuts] Re: No generics, no overloading, and no adding methods to existing types. How....useful. kortschak 5/21/13 2:17 PM
Type embedding.
Re: [go-nuts] Re: No generics, no overloading, and no adding methods to existing types. How....useful. minux 5/21/13 2:20 PM

On Wed, May 22, 2013 at 5:10 AM, Sod Almighty <sod.al...@gmail.com> wrote:
!(generics) && !(overloading) && !(extending existing types) == !(type-agnostic code)
let's negate both sides, and then what you said is equivalent to:
(generics) || (overloading) || (extending existing types) == (type-agnostic code).

however, Go can use struct embedding to extend existing types, so by your definition,
one can write type-agnostic code in Go. Seems a self-contradiction.
Re: [go-nuts] No generics, no overloading, and no adding methods to existing types. How....useful. Monnand 5/21/13 2:21 PM
On 05/17/2013 06:51 PM, Sod Almighty wrote:
> well, in my native
> language, incredulity at the limitations of a system does not equal an
> insult to the people using it. I call my native language "English".
> Apparently it's not the same as what everyone else is using, however.
>

Well. It seems that you are good at using a language in a "mad way" and
it is really not surprise to me that you are using Go in that way as well.

I'm not a native speaker but I think your original post is, well, rude.
You can translate it into any language and no one will say it's a
"polite" request.

If you are unable to use a language in a good way, then any language
sucks and it's your problem.

Am I rude? I'm a troll.

To any reader:

Please ignore my message and keep doing your important work.
This message has been hidden because it was flagged for abuse.
Re: [go-nuts] Re: No generics, no overloading, and no adding methods to existing types. How....useful. kortschak 5/21/13 2:42 PM
Insanity: doing the same thing over and over again and expecting different results.

You have found that Go cannot do what you want. Others are quite happy with how it works for them without the tools you deem necessary. Why do you continue this?
Re: [go-nuts] Re: No generics, no overloading, and no adding methods to existing types. How....useful. Eric Palmer 5/21/13 2:43 PM
http://cis.hfcc.edu/faq/cobol

Cobol is used a lot and cobol programmers are in demand. Not a pretty language, not one I would use but your assertion is not grounded about cobol.




--
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.
For more options, visit https://groups.google.com/groups/opt_out.
 
 



--
KK4MWM (Ham Radio)
About Me
http://www.thingiverse.com/DaddyOh
Join the 3DPrinter Revolution
http://makerbot.com
This message has been hidden because it was flagged for abuse.
Re: [go-nuts] Re: No generics, no overloading, and no adding methods to existing types. How....useful. Thomas Bushnell, BSG 5/21/13 3:02 PM
Typeclasses seem elegantly similar to Go's interfaces in just the right ways. For a generic, you want a way to say "any type that can do this and this and that".

Thomas




--
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.
For more options, visit https://groups.google.com/groups/opt_out.



Re: [go-nuts] Re: No generics, no overloading, and no adding methods to existing types. How....useful. Brendan Tracey 5/21/13 4:10 PM


Bollocks. Extending existing types with embedding is not writing type-agnostic code. And it doesn't count as "extending" in the way I meant it, because I was referring to adding new methods to existing types, as you well know.

Why isn't embedding extending? Yes, it creates a new type, but so what? You can have a simple package that contains the implementation of your extended type, and use it over and over again. If the only thing go allowed were types, I agree that this would be a problem, but it's not actually, because Go has interfaces. So, if your functions use interfaces (say, takes in a Stringer, or a Linqable), you can use the extended type as in input to your linqable function. The interaction of types and interfaces is really quite powerful. I agree, it's not identical to generics, but it goes a long way. In addition, if I have created a type such that it does implement your linqable, you can use it without anyone having to declare it can. See, for example, GobEncode. It can encode any type that has a GobEncode method with the proper signature. My type does not need to be a subclass of a GobEncodable in order to do so, it just works.
Re: [go-nuts] Re: No generics, no overloading, and no adding methods to existing types. How....useful. alco 5/21/13 4:25 PM
Typeclasses seem elegantly similar to Go's interfaces in just the right ways. For a generic, you want a way to say "any type that can do this and this and that".

The full power of type classes is only possible with type-generic functions. Go doesn't have the latter.

data MyType a = One a | Two a deriving Show

instance Functor MyType where
    fmap f (One a) = One $ f a
    fmap f (Two a) = Two $ f a

*Main> fmap (+1) $ One 1
One 2

*Main> fmap (++" world") $ Two "Hello"
Two "Hello world"

In the example above, how would you define an instance of Functor if there were no generics? You wouldn't be able to define fmap as taking a function (a -> b). Essentially, you would need to write a separate fmap implementation for each type. And each type would need to implement a certain interface.

Other than that, type classes are indeed similar to Go's and Java's interfaces, and C++'s abstract classes.
--
Best regards
Alexei Sholik
Re: [go-nuts] Re: No generics, no overloading, and no adding methods to existing types. How....useful. Thomas Bushnell, BSG 5/21/13 4:33 PM
I agree. I wasn't suggesting that Go's interfaces are a substitute for typeclasses, only that I think the similarities suggest that they are the right place to look for where generics might fit in. 
Re: No generics, no overloading, and no adding methods to existing types. How....useful. Andrew Gallant 5/21/13 4:36 PM
> prog.go:10: can't find import: "github.com/BurntSushi/ty/fun"

The Go playground cannot import third party packages. If you save the
source code to `sushi.go` then you can run it with:

    go get github.com/BurntSushi/ty/fun
    go run sushi.go

> Besides, as I recall, someone pointed out that the BurntSushi code was type-unsafe

Yes, at compile time. Others have suggested some tweaks that will push
the type checking to program initialization.

> Not to mention begging the question "how the fuck do you burn something that's served raw?"

Indeed, although that's not what "begging the question" means.

- Andrew
Re: [go-nuts] Re: No generics, no overloading, and no adding methods to existing types. How....useful. kortschak 5/21/13 4:38 PM
On Tue, 2013-05-21 at 16:36 -0700, Andrew Gallant wrote:
> Indeed, although that's not what "begging the question" means.

Thank you. Now I don't need to say it.

Re: [go-nuts] Re: No generics, no overloading, and no adding methods to existing types. How....useful. Dougx 5/21/13 4:50 PM
I agree with this.

I've thought before a third 'type' construct based on properties would alleviate a lot of issues, similar to python duck typing.

Specifically, if you could do this:

type Sorter pmap {
   X int
   Y int
}

and this, as a valid type assertion on any type that had those properties, without creating a dummy class:

func sort(t Sorter) { ... }

sort((&instance).(Sorter))

I know there a couple of things wrong with this, but it does achieve the basic goals:

1) Type safe

2) Any type with a given 'property interface' can be passed into a generic function without an extra class

3) Doesn't interfere with interfaces and try to 'add properties' to interfaces (discussed else where)

Down sides:

1) Ambiguous in grammar how you distinguish between a property interface type assert and a normal interface type assert.

2) Doesn't address return types (how would you write func ApplyTransform(blah TValue) (TResult, error)? Cast the property interface?)

3) People will use property maps instead of interfaces for convenience sake

Just idle thoughts; but this seems a lot more low-impact on the existing go type system than full blown generics.

~
Doug.
Re: [go-nuts] Re: No generics, no overloading, and no adding methods to existing types. How....useful. Nico 5/22/13 4:45 AM
On 21/05/13 22:10, Sod Almighty wrote:
> On Tuesday, 21 May 2013 18:03:20 UTC+1, Nico wrote:
> Sure. Except that a type might not implement the Afterer interface. For
> example, if it's an integral type, or a third-party type that I didn't
> write. See point 3: You can't add methods to existing types. See, I
> thought about all this before I went and opened my mouth in the first place.
>
> !(generics) && !(overloading) && !(extending existing types) ==
> !(type-agnostic code)

I think I didn't do a brilliant job explaining my last point.

I'm not trying to negate that Go has no generics nor overloading. I
won't argue that.

One of the points I was trying to make with my first email is that
Andrew Gallant's approach seems to offer all the functionality one would
expect from a LINQ package.

To this point, I understood you raised the difficulty that closures
would need to be written for each type, for instance

        func (a, b int) int {return a+b}
        func (a, b float64) float {return a+b}

I understand you'd like to be able to write something like:

        func (a, b T) T {return a+b}

And this is the point I wanted to make yesterday: if we want to apply
such a closure to a LINQ collection in a type-safe manner, we need to
ensure all the objects in the LINQ collection can accept the + operator.
A way to ensure this in Go is to work with interfaces (others have
suggested embedding). Instead of having a collection of ints, float64s,
Xs... we would have a collection of Adders and would define the closure as:

        func (a, b Adder) Adder {return a.Add(b)}


Maybe this example is not very realistic, but the general idea is still
valid, if we want a type-safe LINQ collection, we need to ensure the
objects in the collection are able to accept the methods we plan to use
in our closures.

Using Andrew's example:

        sfiles = fun.QuickSort(func(a, b os.FileInfo) bool {
                 return a.ModTime().After(b.ModTime())
        }, sfiles)

it only makes sense to process the collection sfiles using closures that
access these objects in a well-defined manner. You can do this, by
ensuring all the objects in sfiles are of a given type (to this end,
embedding can help as Dan suggested), or by ensuring the objects in
sfiles are an interface that implements the methods expected by your
closures.


I think one can achieve the same functionality that C# offers via LINQ
without forcing Go to look like C#.

Re: [go-nuts] Re: No generics, no overloading, and no adding methods to existing types. How....useful. Pieter Droogendijk 5/22/13 6:38 AM

On Wednesday, 22 May 2013 13:45:33 UTC+2, Nico wrote:
On 21/05/13 22:10, Sod Almighty wrote:

        func (a, b Adder) Adder {return a.Add(b)}

Maybe this example is not very realistic, but the general idea is still
valid, if we want a type-safe LINQ collection, we need to ensure the
objects in the collection are able to accept the methods we plan to use
in our closures.

Perhaps I misunderstand your point, in which case I apologize.
 
This is not as type-safe as we normally want (that is, not compile-time safe, as mentioned before) and it suffers from type explosion.

After all, what would the Add method look like?

import strconv

type String string
type Integer int
type Complex struct {
        real, imag float64
}
type Adder interface {
        Add(Adder) Adder
}

func (s String) Add(a Adder) Adder {
        switch cast := a.(type) {
        case String:
                return s + cast
        case Integer:
                return s + strconv.Atoi(cast)
        case Complex:
                return fmt.Sprintf("%s%f + i%f", s, cast.real, cast.imag)
        default:
                panic("HELP")
        }
}

func (i Integer) Add(a Adder) {
...
}

...

Re: [go-nuts] Re: No generics, no overloading, and no adding methods to existing types. How....useful. Nico 5/22/13 7:01 AM
On 22/05/13 14:38, Pieter Droogendijk wrote:
>
> On Wednesday, 22 May 2013 13:45:33 UTC+2, Nico wrote:
> func (s String) Add(a Adder) Adder {
>          switch cast := a.(type) {
>          case String:
>                  return s + cast
>          case Integer:
>                  return s + strconv.Atoi(cast)
>          case Complex:
>                  return fmt.Sprintf("%s%f + i%f", s, cast.real, cast.imag)
>          default:
>                  panic("HELP")
>          }
> }

yes, it potentially leads to a type explosion. This is necessary because
the compiler cannot guess what we mean by Add()

But in practice, this rarely happens, because the kind of methods we
define actually look like:

        func (m myType) DoSomething()
        func (m myType) GiveMeAName(n string)
        func (m myType) areYouPaintedInBlue() bool

Even when we need methods like Add, one could come up with some
interface that defines a set of methods to implement a general Add, for
instance:

        func (m myType) Add(a myInterface) {
                m.SetNumber(m.GetNumber() + a.GetNumber())
        }


Re: [go-nuts] Re: No generics, no overloading, and no adding methods to existing types. How....useful. Pieter Droogendijk 5/22/13 7:06 AM

On Wednesday, 22 May 2013 16:01:45 UTC+2, Nico wrote:
But in practice, this rarely happens, because the kind of methods we
define actually look like:

        func (m myType) DoSomething()
        func (m myType) GiveMeAName(n string)
        func (m myType) areYouPaintedInBlue() bool

Even when we need methods like Add, one could come up with some
interface that defines a set of methods to implement a general Add, for
instance:

        func (m myType) Add(a myInterface) {
                m.SetNumber(m.GetNumber() + a.GetNumber())
        }


Very true. Whenever I find myself writing code like I posted, I think "Oh, I'm trying to do generics again", slap myself, and change my design.
 
Re: [go-nuts] Re: No generics, no overloading, and no adding methods to existing types. How....useful. Brendan Tracey 5/22/13 8:39 AM


yes, it potentially leads to a type explosion. This is necessary because
the compiler cannot guess what we mean by Add()

But in practice, this rarely happens, because the kind of methods we
define actually look like:

        func (m myType) DoSomething()
        func (m myType) GiveMeAName(n string)
        func (m myType) areYouPaintedInBlue() bool


Maybe for you this rarely happens, but if you start writing code that could take in a couple different types of numeric arguments often what happens is you just support float64 and []float64. At gonum (https://groups.google.com/forum/?fromgroups#!forum/gonum-dev), we are doing the adder interface like you said for matrices, but the additional function call cost is negligible. Start doing that for float64s and you're code time is going to go up a lot. I realize that scientific-style computing is a niche environment in Go, but there are still some cases where it would be super useful. 

That said, you can go a long way with interfaces, and writing the code a couple times to support the main numeric types isn't that big of a deal.
Re: [go-nuts] Re: No generics, no overloading, and no adding methods to existing types. How....useful. Nico 5/22/13 8:59 AM
On 22/05/13 16:39, Brendan Tracey wrote:
> Maybe for you this rarely happens, but if you start writing code that
> could take in a couple different types of numeric arguments often what
> happens is you just support float64 and []float64. At gonum
> (https://groups.google.com/forum/?fromgroups#!forum/gonum-dev), we are
> doing the adder interface like you said for matrices, but the additional
> function call cost is negligible. Start doing that for float64s and
> you're code time is going to go up a lot. I realize that
> scientific-style computing is a niche environment in Go, but there are
> still some cases where it would be super useful.

Touche... I didn't want to bring up gonum to this thread.

I'm still making up my mind about gonum's Matrix interface. At first
sight, it seems to me very ambitious to support:

        type Adder {
                Add(m,n Matrix)
        }

when Matrix m may be a dense matrix and n sparse:
- do we panic is the receiver is sparse?
- if we panic, why do we support so general an interface?
- if we don't panic, is this really efficient?

As a I said, I haven't made up my mind about gonum's Matrix yet. I think
only experimenting with different approaches will give us the answer. I
can't tell whether the current draft is the best approach. I just don't
know.
Re: [go-nuts] Re: No generics, no overloading, and no adding methods to existing types. How....useful. Henry Heikkinen 5/22/13 9:18 AM
Hi Brendan,

Have you considered automatically generating the code for different types? It isn't the prettiest way though.

Regards,
Henry Heikkinen


2013/5/22 Brendan Tracey <tracey....@gmail.com>

--
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.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

Re: [go-nuts] Re: No generics, no overloading, and no adding methods to existing types. How....useful. Brendan Tracey 5/22/13 9:23 AM
Thought about it. In the stuff we're working on for gonum (and the other stuff I've been working on), there isn't a good use case yet. For the stuff where I really think it would benefit, my current plan is to implement the most common use cases and then have one where the algorithm takes in an interface{} and let people with bizarre types do the type casting themselves. If they really want to implement it for their specific type, the autogen / copy+paste wouldn't be too bad. 
Re: [go-nuts] No generics, no overloading, and no adding methods to existing types. How....useful. Matt Joiner 5/22/13 9:27 AM
This is true. This conversation needs to rage, and has raged before.

I for one need generics, it's hte #1 missing feature. It doesn't even have to perform well, and from the oft-quoted options regarding generics, I'll gladly take the "slow" variant.

On Saturday, May 18, 2013 7:23:58 AM UTC+10, Sod Almighty wrote:

On Friday, May 17, 2013 10:08:29 PM UTC+1, Gustavo Niemeyer wrote:

Unanimously, though,
everybody would appreciate having a beautiful implementation of
generics in the language,

So explain why people tried to lynch me as soon as I mentioned it.

You think this "beautiful implementation" is going to fall out of the sky? No, it'll happen by people discussing it, and repeatedly demanding it on forums, until it gradually filters through the head of the developers.

Unless people get called trolls right from the get-go, that is.
Re: [go-nuts] No generics, no overloading, and no adding methods to existing types. How....useful. Paul Ruane 5/22/13 9:27 AM
My biggest irritation with C#/.NET generics is there's no way to have a variable strongly typed to multiple interfaces:

    class Platypuss : IMammal, IHasBeak, ILaysEggs {}

    var animals = new [] { new Gull(), new Sheep(), new Platypuss() };
    var critters = animals.OfType<IMammal>()
                                  .OfType<IHasBeak>()
                                  .OfType<ILaysEggs>();

critters is of type IEnumerable<ILaysEggs> rather than IEnumerable<IMammal&IHasBeak&ILaysEggs>.

This means the following does not work:

    foreach (object critter in critters) { DoSomething(critter); }

    void DoSomething<T>(T critter) where T : IMammal, IHasBeak, ILaysEggs { ... }

This makes it very hard to do any kind of trait based inheritance without cracking out the 'dynamic' keyword and paying the static type checking and performance penalties.

On Friday, 17 May 2013 22:35:31 UTC+1, Sod Almighty wrote:


On Friday, May 17, 2013 10:29:23 PM UTC+1, minux wrote:

but you don't seems to propose an implementation of generic, only complained the lack of it,
and that's why people consistently refer you to the FAQ.

Well, as a starting point, what about the .NET implementation? Seems to work well enough. Only shortcoming seems to be the lack of partial types. That is, the inability to specify a generic type without specifying T.

I really don't see what's so hard about it. .NET does it. D does it. A bunch of other languages do it. Granted, I'm not an expert on language design, but it's not exactly a new idea. Surely it can't be beyond the wit of man?
Re: [go-nuts] Re: No generics, no overloading, and no adding methods to existing types. How....useful. Florian Weimer 5/22/13 10:04 AM
* roger peppe:

> In particular do you know of any language that implements generics that:
> - doesn't dynamically compile code (.Net)
> - doesn't box everything (haskell, ML etc)
> - doesn't type-erase? (Java)
> - doesn't result in combinatorial code explosion (C++)

Ada has explicit instantiation of generics, which tends to contain the
explosion effect somewhat.  It makes certain coding patterns rather
unattractive, such as combinator libraries, but in my eyes at least,
this is a good thing.

Generics in ML aren't always implemented with boxing, see MLton.
Re: [go-nuts] Re: No generics, no overloading, and no adding methods to existing types. How....useful. Jeremy Wall 5/22/13 10:33 AM



I can't believe I'm responding again in this thread but that statement is wrong for multiple reasons.

You say you want to add methods to existing types. There are two ways to do this in Go. Each having different pros and cons. You can create a new type from an existing type and attach your own methods to it.

type Foo Bar

func (f Foo) FooMethod() {
  Bar(f).BarMethod()
}

It's more typing but allows you to redefine the method set for an existing type with your own. Use this when you don't care about keeping access to the previous methods around.

You can embedd a Type or even an interface in a wrapper type.

type Foo struct {
  Bar
}

func (f Foo) FooMethod() {
}

f.FooMethod() // entirely valid
f.BarMethod() // Also entirely valid.

For each of these you can hid most of the boilerplate of construction in a construction function.

You're arguments against this seem to boil down to "I don't want to type so much". Fine use a different language but don't spread misinformation about 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.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

This message has been hidden because it was flagged for abuse.
This message has been hidden because it was flagged for abuse.
Re: [go-nuts] Re: No generics, no overloading, and no adding methods to existing types. How....useful. kortschak 5/22/13 4:48 PM
On Wed, 2013-05-22 at 16:44 -0700, Sod Almighty wrote:
> Meh. I'm not interested enough to piss about.
>
All evidence appears to point to the contrary.

This message has been hidden because it was flagged for abuse.
This message has been hidden because it was flagged for abuse.
This message has been hidden because it was flagged for abuse.
Re: [go-nuts] Re: No generics, no overloading, and no adding methods to existing types. How....useful. Rémy Oudompheng 5/22/13 5:04 PM
2013/5/23 Sod Almighty <sod.al...@gmail.com>:
> The second problem is that closures are not covariant. If you don't have
> covariant closures, and you also don't have generics, you can't pass an
> closure into a type-agnostic function to tell it how to deal with a concrete
> type. Look, I've been through all this once already. More than once, I
> daresay.

This assertion is wrong and ridiculous. Haskell certain allows for
generic programming and it doesn't have a notion of closure covariance
(it just wouldn't make any sense), and it just doesn't need it. You
could say a similar concept exists for type classes but it's not
really the same thing.

By the way, inheritance and covariance/contravariance just make the
type system awful to understand. I hope nobody wants to have that in a
generics implementation for Go.

Rémy.
This message has been hidden because it was flagged for abuse.
This message has been hidden because it was flagged for abuse.
Re: [go-nuts] Re: No generics, no overloading, and no adding methods to existing types. How....useful. Rémy Oudompheng 5/22/13 5:08 PM
No, you have been essentially complaining, using C++ and C# as
references (frankly, do you *honestly* think a parameterised interface
IComparable<T> is the correct way to make a type sortable?), and
saying that Haskell is useless (well, real life powerful and efficient
programs are written in Haskell and Java, C++ and C# have a vastly
less powerful, less safe and horribly verbose type system).

Rémy.
Re: [go-nuts] Re: No generics, no overloading, and no adding methods to existing types. How....useful. Rémy Oudompheng 5/22/13 5:10 PM
On 2013/5/23 Sod Almighty <sod.al...@gmail.com> wrote:
>
> Lacking generics, Go essentially expects the programmer to derive a new type
> whenever he wants to get anything done. Need a new method? Derive a type.
> Need a reusable function? Implement an interface and derive a new type that
> implements it and embeds the original type. Christ! Am I the only one here
> who thinks that's way too much boilerplate?

Yes, because the correct reaction to "hey, Go is not meant to do
this!" is not "oh, let's write hundreds of LoC of boilerplate to do it
anyway" but "hey, I should code differently to fit the language spirit
and keep my program concise and non-redundant!".

Rémy.
This message has been hidden because it was flagged for abuse.
Re: [go-nuts] Re: No generics, no overloading, and no adding methods to existing types. How....useful. Dave Cheney 5/22/13 5:12 PM
How many times do I need to mute this bloody thread!
This message has been hidden because it was flagged for abuse.
This message has been hidden because it was flagged for abuse.
This message has been hidden because it was flagged for abuse.
Re: [go-nuts] Re: No generics, no overloading, and no adding methods to existing types. How....useful. suharik 5/23/13 12:36 AM
среда, 22 мая 2013 г., 0:37:23 UTC+3 пользователь Sod Almighty написал:
The need for generics should be self-evident to every programmer, everywhere.
No cargo cult here, please. But yes, we still need something for parametric polymorphism.

Re: [go-nuts] Re: No generics, no overloading, and no adding methods to existing types. How....useful. Brendan Tracey 5/23/13 1:09 AM
You don't necessarily need to define functions on every type; embedding can take care of many of them.

type Foo struct{}

func (f *Foo) Bar()


type Baz struct{
Foo
}

The Baz type has the Bar() method.
Re: [go-nuts] No generics, no overloading, and no adding methods to existing types. How....useful. John Arbash Meinel 5/23/13 1:54 AM
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2013-05-18 7:30, and...@atoulou.se wrote:

> In my opinion, it seems that with Go, magic doesn't get imported
> into your source file, ever: any magic you do can be traced from
> the name to the import, and the import to the source. In my mind,
> the lack of generics means that the developer must explicitly
> implement any code bridging the generally-implemented algorithm
> with their own custom data types. This is, to me, equivalent to
> declaring "I know what I'm doing and want to apply X method to Y
> type. It'll work. I promise (in a compiled, typesafe way)". It also
> happens to be a very verbose way of doing it, because you have to
> declare a type that wraps it and supports the methods. Is there a
> middle ground somewhere, or is it that automatically wrapping types
> just another way of expressing something functionally equivalent to
> C++ style method copying or boxing things at runtime, Java-style?
>
> What I'd like to know is what are the pitfalls of compile-time
> struct mixins? i.e:
>
> import ( "io" "code.google.com/p/sneakygophers"
> `mixin:"ExampleNumber(uint64)"` )
>

Note that there is gotgo:
https://github.com/droundy/gotgo

Which predates 'go build' to back when there were Makefiles. But it
used a variant on this specific syntax to transform".got" files into
".go" files. .got files were syntactically go, but had a bit of
template definitions.

This works for macro-based templating, and defining container types.
It doesn't work quite as well when you want to nest templates (I want
a type T1<T2<T3>>>).

The code is probably a bit old, and I'm guessing it doesn't integrate
into the current build system. But it was *an* answer that people have
investigated.

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlGd2TAACgkQJdeBCYSNAAPSsACggicwJyg6DVNYDbs8Zd/kG2p1
HLUAnikOPc3+0arLIVZjUaPs3CmbGMGK
=qbD7
-----END PGP SIGNATURE-----
Re: [go-nuts] No generics, no overloading, and no adding methods to existing types. How....useful. hutch 5/23/13 4:31 AM

As long as you remember that the Bar method can know *nothing* about what it's embedded in. And I'd think that this is a serious kind of limitation for what you're proposing them as a solution to.

Cheers,
Bob


--
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.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

Re: [go-nuts] No generics, no overloading, and no adding methods to existing types. How....useful. Brendan Tracey 5/23/13 7:21 AM
Yea, I could see how that could be true. It hasn't been a problem for me, for example, you do get access to the internals if it's in the same package, but I realize that's not necessarily what we're talking about. On the other hand, if you just want to inherit methods, so that you don't have to "write them for every type", it doesn't matter that you can't see the internals, because the goal was to inherit the method without changing anything.
Re: No generics, no overloading, and no adding methods to existing types. How....useful. Paulo Pinto 5/23/13 7:55 AM
Sadly it resembles the tools some C++ compilers (Borland C++) were
offering
back in the day templates were still not available.

Time travel back to 1993, when I used such tools.

However, an interesting research topic would be to fork go compiler
and integrate gotgo
into the compiler itself and see how that could work out.

--
Paulo

On May 23, 10:54 am, John Arbash Meinel <j...@arbash-meinel.com>
wrote:
> Comment: Using GnuPG with Thunderbird -http://www.enigmail.net/
Re: No generics, no overloading, and no adding methods to existing types. How....useful. Sugu Sougoumarane 5/23/13 11:31 AM
Sod,
Have you looked at gofix?

It is a generic tool that can be customized to transform any go source into another. What you could do is define your original source using type T, and use gofix to generate new files that substitute T into the type(s) you need.
I've customized gofix to do other work for me (like refactoring, etc). It's very handy.

It is a solution that's outside the language, but it's a solution. It's practically as effective as C++ templates.
More topics »