On Friday, 9 May 2014 at 07:38:46 UTC, Paulo Pinto wrote:
> On Friday, 9 May 2014 at 07:05:59 UTC, Bienlein wrote:
>>
>>> Well, he had previously stated that there would be no breaking changes, and that if there were changes it would have to be called "go version 2 or something". So when generics were brought up he stated that there were no plans for generics and "I said we are going to leave the language, we are done" (with version 1 semantics).
>>>
>>> Ola..
>>
>> Robert Pike says in this thread (https://groups.google.com/forum/?hl=de#!topic/golang-nuts/3fOIZ1VLn1o):
>>
>> "Go has type switches, and therefore no need for the Visitor Pattern.". He has exactly the same mindset as Niklaus Wirth and Oberon never got templates. Future will tell... Would be a nice thing to bet a dime on whether Go will have generics or not. I bet not ;-).
>
> Oberon did eventually get some basic form of templates in Active Oberon, but that was not under Wirth's supervision.
>
> He actually went into the other direction by making a minimalist version of Oberon with Oberon-07.
>
> I had the opportunity to meet Wirth at CERN, when he and a few ETHZ members took part on the Oberon Day, back in 2004.
>
> He is really great guy, but he could not understand why Oberon was being ignored in the industry. As he expected the desire for quality would drive developers to it.
>
> In a similar vein to Rob Pike writing the blog post why he thinks C++ developers don't care for Go, Niklaus Wirth wrote a long article about the industry lack of interest in minimalist languages.
>
>
> The problem they fail to understand, or acknowledge, is that large scale architectures in simple languages usually lead to complex code with lots of boilerplate.
>
> --
> Paulo

With generics you mean templates, right? I started to use templates in D, although I wasn't convinced. But the more I use them the more I appreciate them. If you work with one or two basic types, templates don't seem to make much sense. But when you use the power of D, like having arrays of structs that hold arrays of structs etc., then templates start to make sense.

The thing is, the language has to be designed in a way that templates make sense and can be used throughout the language. If not, better not to introduce them. D, at a certain point in time, started to be designed around templates, or with templates in mind. I think it was Andrei who convinced Walter to do that. But in my view the language has to cater for templates for them to be useful. Introducing them randomly for the sake of having them will not work.

On Friday, 9 May 2014 at 11:46:20 UTC, Chris wrote:
> On Friday, 9 May 2014 at 07:38:46 UTC, Paulo Pinto wrote:
>> On Friday, 9 May 2014 at 07:05:59 UTC, Bienlein wrote:
>>>
>>>> Well, he had previously stated that there would be no breaking changes, and that if there were changes it would have to be called "go version 2 or something". So when generics were brought up he stated that there were no plans for generics and "I said we are going to leave the language, we are done" (with version 1 semantics).
>>>>
>>>> Ola..
>>>
>>> Robert Pike says in this thread (https://groups.google.com/forum/?hl=de#!topic/golang-nuts/3fOIZ1VLn1o):
>>>
>>> "Go has type switches, and therefore no need for the Visitor Pattern.". He has exactly the same mindset as Niklaus Wirth and Oberon never got templates. Future will tell... Would be a nice thing to bet a dime on whether Go will have generics or not. I bet not ;-).
>>
>> Oberon did eventually get some basic form of templates in Active Oberon, but that was not under Wirth's supervision.
>>
>> He actually went into the other direction by making a minimalist version of Oberon with Oberon-07.
>>
>> I had the opportunity to meet Wirth at CERN, when he and a few ETHZ members took part on the Oberon Day, back in 2004.
>>
>> He is really great guy, but he could not understand why Oberon was being ignored in the industry. As he expected the desire for quality would drive developers to it.
>>
>> In a similar vein to Rob Pike writing the blog post why he thinks C++ developers don't care for Go, Niklaus Wirth wrote a long article about the industry lack of interest in minimalist languages.
>>
>>
>> The problem they fail to understand, or acknowledge, is that large scale architectures in simple languages usually lead to complex code with lots of boilerplate.
>>
>> --
>> Paulo
>
> With generics you mean templates, right? I started to use templates in D, although I wasn't convinced. But the more I use them the more I appreciate them. If you work with one or two basic types, templates don't seem to make much sense. But when you use the power of D, like having arrays of structs that hold arrays of structs etc., then templates start to make sense.
>
> The thing is, the language has to be designed in a way that templates make sense and can be used throughout the language. If not, better not to introduce them. D, at a certain point in time, started to be designed around templates, or with templates in mind. I think it was Andrei who convinced Walter to do that. But in my view the language has to cater for templates for them to be useful. Introducing them randomly for the sake of having them will not work.

Agreed.

The issue being that to design a strong typed language in 2007 without support for genericity, does not make much sense. When all other mainstream languages have adopted them.

Lets not forget that CLU (1975) and Ada (1980) were among the first ones to support it.

The initial version of C++ STL was actually based on a preliminary version done in Ada.

Even .NET was actually designed with generics support in mind (1999):

http://blogs.msdn.com/b/dsyme/archive/2011/03/15/net-c-generics-history-some-photos-from-feb-1999.aspx


--
Paulo

On Friday, 9 May 2014 at 07:38:46 UTC, Paulo Pinto wrote:
> I had the opportunity to meet Wirth at CERN, when he and a few ETHZ members took part on the Oberon Day, back in 2004.
>
> He is really great guy, but he could not understand why Oberon was being ignored in the industry. As he expected the desire for quality would drive developers to it.

From Wirth published books and known projects I have an impression that he is a brilliant scientist who has an extremely basic understanding of what engineers need. His languages are all about proposing academical solutions to practical problems.

On Friday, 9 May 2014 at 13:59:38 UTC, Dicebot wrote:
> On Friday, 9 May 2014 at 07:38:46 UTC, Paulo Pinto wrote:
>> I had the opportunity to meet Wirth at CERN, when he and a few ETHZ members took part on the Oberon Day, back in 2004.
>>
>> He is really great guy, but he could not understand why Oberon was being ignored in the industry. As he expected the desire for quality would drive developers to it.
>
> From Wirth published books and known projects I have an impression that he is a brilliant scientist who has an extremely basic understanding of what engineers need. His languages are all about proposing academical solutions to practical problems.

There is this conflict between textbooks and real world (hardware / software interaction). Walter once said on this forum that when he sees textbook examples, he says that things don't really work that way. Through D, I've learned a lot about that, because the language was designed on hindsight and with the machine in mind.

Beyond being fodder for people who don't write Go but hate it for some reason, this seems to be an ongoing non-event. The official mailing list has practically no mention of generics anymore.

On Friday, 9 May 2014 at 11:46:20 UTC, Chris wrote:
> If not, better not to introduce them. D, at a certain point in time, started to be designed around templates, or with templates in mind. I think it was Andrei who convinced Walter to do that.

It wasn't Andrei, but I don't remember who Walter gave credit to.

On 5/9/2014 7:18 AM, Chris wrote:
> There is this conflict between textbooks and real world (hardware / software
> interaction). Walter once said on this forum that when he sees textbook
> examples, he says that things don't really work that way.

Found that out when implementing textbook optimization algorithms.

It's sort of like watching those miracle cleaning products on an infomercial, and then trying them out yourself :-)

On Friday, 9 May 2014 at 11:38:13 UTC, Bruno Medeiros wrote:
> I find this aspect much more interesting than the "get generics or not" one. So Rob Pike and the other guy is leaving the language then?

No, the context around what he said is very important. Google isn't leaving Go development, generics are not nixed for Go 2.0, the language will continue to see bug fixes. This is all very clear with context.

I don't expect the will look to add generics in Go 2.0 (others will, but not them).

On Friday, 9 May 2014 at 19:07:24 UTC, Jesse Phillips wrote:

> No, the context around what he said is very important. Google isn't leaving Go development, generics are not nixed for Go 2.0, the language will continue to see bug fixes. This is all very clear with context.

I see this as a good. What would you rather use - a third party library written against abstractions or one written against concrete types? I would rather use a library based on concrete types. My observation is that the more abstraction people indulge, the greater the chance I will regard one of their abstractions as a code smell.

And it isn't the the case that the lack of generics is inhibiting participation. Go's library selection is already very good and getting better daily. Just yesterday I needed a Go lz4 compression library and was able to find three distinct implementations. Go is not hurting for third-party libraries.

On Friday, 9 May 2014 at 21:03:06 UTC, brad clawsie wrote:
> On Friday, 9 May 2014 at 19:07:24 UTC, Jesse Phillips wrote:
>
>> No, the context around what he said is very important. Google isn't leaving Go development, generics are not nixed for Go 2.0, the language will continue to see bug fixes. This is all very clear with context.
>
> I see this as a good. What would you rather use - a third party library written against abstractions or one written against concrete types? I would rather use a library based on concrete types. My observation is that the more abstraction people indulge, the greater the chance I will regard one of their abstractions as a code smell.

Quite likely you won't be able to use that 3d party library with your types at all and will need runtime conversion between library types and your own. std.algorithm is prime example of how generalization improves code reuse.

> And it isn't the the case that the lack of generics is inhibiting participation. Go's library selection is already very good and getting better daily. Just yesterday I needed a Go lz4 compression library and was able to find three distinct implementations. Go is not hurting for third-party libraries.

This has nothing to do with the language. Existing mainstream languages are so bad that people will contribute to anything that is backed by solid brand and has enough fuss about. I clearly remember seeing several articles about crazy library design that is forced by Go lack of generics of any sort.