On Tuesday, 9 April 2013 at 16:54:30 UTC, Peter Alexander wrote:
> On Tuesday, 9 April 2013 at 15:50:11 UTC, Andrei Alexandrescu wrote:
>> Lack of generics makes it very tenuous to do meaningful work on algorithms and their associated data structures.
>
> Why?

I think the answer to that is working on implementing an algorithm to work on a data structure not provided by the language can only reach as far as the type you implemented the algorithm for. Thus the work done to implement that algorithm wasn't very meaningful as it isn't reusable.

On a similar note. Earlier I was having a discussion with someone who was stating, "The problem with the whole generics complaint is that people tend to focus on Go's lack of generics to mean Go lacks any safe polymorphism at all." He was quite aware "What Go doesn't have is parametric polymorphism."

I was kind of worried that it would be impossible to specify a different sort for a data type. I ended up writing some code to sort a slice of Time[1]. I was glad to find out I was wrong, but also very concerned with what I did find.

1. http://ideone.com/eVWfnk

- There is a built in function make which takes a type! That was interesting.
- Data doesn't provide a default means to sort.
- I had to write the data access of the array!
- I also couldn't get the functions to take a slice of time, instead I had to define a TimeSlice which was a slice of time.

Needless to say WTF! That was with a built in data structure, at least I know it will work with any custom structure.

On Tuesday, April 09, 2013 18:00:43 Nick Sabalausky wrote:
> On Tue, 09 Apr 2013 14:22:21 -0400
> 
> "Jonathan M Davis" <jmdavisProg@gmx.com> wrote:
> > If it's something that has to be
> > fixed, it should be an error, and if it doesn't have to be fix, don't
> > warn about it, because any good programmer is going to have to fix
> > all of the warnings anyway, ultimately making it not much different
> > from an error anyway. Stuff like you're suggesting really should be
> > left up to lint-like tools.
> 
> The way I see it, warnings *are* a lint tool. (Which is part of why I've always disliked -w and use -wi instead.)

Except that with a lint tool, you can ignore some of them and usually can adjust what it outputs, possibly have suppression files, etc. Such tools are far more flexible than simply turning all warnings on or turn them all off. And with compiler warnings, you need to fix them all - even if they really don't need to be fixed - or you risk missing the ones that _do_ matter among all the ones that don't. It's bad practice for a project to have any warnings at all. So, the situation with compiler warnings and lint tools is really quite different, especially when the compiler has no flags to control warnings except to turn them all on or off. I really wish that dmd had never had warnings in the first place. I think that we would have been better off without them. This is one area where I'm actually in full agreement with Walter.

- Jonathan M Davis

On 4/9/2013 7:34 PM, Jonathan M Davis wrote:
> This is one area where I'm actually in full agreement with Walter.

I'm glad there's at least one!

On 4/9/2013 1:17 AM, Russel Winder wrote:
> I have yet to find anyone who can tell me why Go must have generics with
> a cogent argument that makes sense to me.

I was strongly opposed to generics for a long time, but finally changed my mind.

One thing I learned about templates from Andrei and Scott Meyers is that one can write programs that manipulate types. For example, for a variadic function an array of types represents the types of the actual arguments. This can then be used to create a typesafe printf, which is what we have in std.stdio.

Another thing we can do with templates that is hard to imagine doing with other means is the compiler's hook into making a precise GC. In object.d, there's a template named RTInfo(T). For each call to new(), the compiler passes along a static value generated by RTInfo!T, where T is the type of the data being allocated.

What this means is the compiler (and language) needs NO KNOWLEDGE of what the GC needs. The library implementer is free to innovate whatever kind of tables are necessary. It means that radically different GCs can be built and swapped in and out without change to the compiler or language. It means that anyone who wants to build a better GC can do so without forking the compiler.

On Tuesday, 9 April 2013 at 15:50:11 UTC, Andrei Alexandrescu wrote:
> I have some material for an article entitled "Why Go is not my favorite programming language". I decided in the end to cease work on that because it would be too controversial.
>
> Andrei

Probably a good idea. People might accuse you of having an axe to grind, even if you didn't. Besides, being negative is often an indication of insecurity. My goal is only to be negative when it's personal. And for it never to be personal, if I can help it.

On Tuesday, 9 April 2013 at 18:22:33 UTC, Jonathan M Davis wrote:
>> Is there any work on that?
>
> No. As I understand it, Walter is against adding flags like that to dmd. He
> doesn't want a lot of stray flags which affect what is and isn't a warning and
> the like. He doesn't even like the fact that warnings exist in the first place
> - which I'm inclined to agree with. If it's something that has to be fixed, it
> should be an error, and if it doesn't have to be fix, don't warn about it,
> because any good programmer is going to have to fix all of the warnings anyway,
> ultimately making it not much different from an error anyway. Stuff like you're
> suggesting really should be left up to lint-like tools.

I personally think that there might be some benefit to an official discussion about lint-like tools. The schedule for the Conference has a lecture about AnalyzeD, which is the only official lint-like tool I've heard of so far. That is either meant to remain a third-party operation, or it is meant to at some point come closer to being an "official" lint-like tool.

I understand that D tries to clearly separate errors from legal code. But I'm sure lint-like tools have their place. It seems a little weird that there is nothing standard (that I've found, at least) about that topic. D has many standard things, unittest, ddoc, assert, etc., but no standard lint-like tools. My understanding of lint-like tools is that they address the areas a compiler shouldn't address, namely those which can generate false positives. But just because it could generate a false positive doesn't mean that it should be completely ignored.

Is there a way standardize a set of warnings such that some lint-like tool could be "compliant" with the standard warnings? A standard might help people focus on this issue better.

On 2013-04-10 04:34, Jonathan M Davis wrote:

> It's bad practice for a project to have any warnings at all.

It depends on what you want with warnings. If we decide that warnings are like a lint tool in D then it won't be bad practice.

-- 
/Jacob Carlborg

On Wednesday, 10 April 2013 at 03:43:47 UTC, Walter Bright wrote:
> On 4/9/2013 7:34 PM, Jonathan M Davis wrote:
>> This is one area where I'm actually in full agreement with Walter.
>
> I'm glad there's at least one!

Count me in, too. Compiler warnings are atrocity.
Having standard lint-like tool packaged with compiler is not though ;)

On 04/10/2013 05:57 AM, Walter Bright wrote:
> On 4/9/2013 1:17 AM, Russel Winder wrote:
>> I have yet to find anyone who can tell me why Go must have generics with
>> a cogent argument that makes sense to me.
>
> ....
> What this means is the compiler (and language) needs NO KNOWLEDGE of
> what the GC needs. The library implementer is free to innovate whatever
> kind of tables are necessary. It means that radically different GCs can
> be built and swapped in and out without change to the compiler or
> language. It means that anyone who wants to build a better GC can do so
> without forking the compiler.

What about precise tracking of stack references?

On 04/10/2013 05:55 PM, Timon Gehr wrote:
> On 04/10/2013 05:57 AM, Walter Bright wrote:
>> On 4/9/2013 1:17 AM, Russel Winder wrote:
>>> I have yet to find anyone who can tell me why Go must have generics with
>>> a cogent argument that makes sense to me.
>>
>> ....
>> What this means is the compiler (and language) needs NO KNOWLEDGE of
>> what the GC needs. The library implementer is free to innovate whatever
>> kind of tables are necessary. It means that radically different GCs can
>> be built and swapped in and out without change to the compiler or
>> language. It means that anyone who wants to build a better GC can do so
>> without forking the compiler.
>
> What about precise tracking of stack references?

/stack references/references on the stack/s