On 4/9/13 4:17 AM, Russel Winder wrote:
> On Mon, 2013-04-08 at 23:51 +0200, Paulo Pinto wrote:
> […]
>> Lets not forget the lack of generics, the religious view against dynamic
>> linking and errors for unused variables and imports.
>
> OK so every language has it's religious side: Go's obsession for static
> linking is indeed a problem and cgo is not really the solution.

I think this thread has collected a good amount of arguments (of the devil's advocate style) you might also encounter from informed attendees during and after your talk.

I expect arguments against D to be mainly based on completeness of definition, quality of implementation, and of course current adoption.

> I have yet to find anyone who can tell me why Go must have generics with
> a cogent argument that makes sense to me. OK so C++ has generics;
> templates, how wonderful. Java has generics, and type erasure, great.
> Scala, Ceylon and Kotlin have huge infrastructure to reify generics on a
> platform with unreified generics. At least C# got that right. Why is the
> Go idea of total separation of state and behaviour not a good
> experiment, after all JavaScript, Python, etc. have shown this works
> even without static type checking.

I think one of the less savory things the Go culture has done is to compromise the notion that generics are desirable in that language, to the extent that n00b posts asking about it are met with derision.

Lack of generics makes it very tenuous to do meaningful work on algorithms and their associated data structures. To compound the matter, Go itself doesn't follow its own preaching (thou shall shun generics and use interfaces throughout) for its own essential data structures (arrays, associative arrays, and channels) - all of which are generic in ways unattainable to client code. You can only go this far by claiming two data structures are enough and algorithms based on map/reduce are unneeded because there are loops.

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

> I think this thread has collected a good amount of arguments

  GO SUCKS

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?


> To compound the matter, Go itself doesn't follow its own preaching (thou shall shun generics and use interfaces throughout) for its own essential data structures (arrays, associative arrays, and channels) - all of which are generic in ways unattainable to client code.

Every language has primitives that have special privileges. I don't think this can be used as an argument against Go.


> You can only go this far by claiming two data structures are enough and algorithms based on map/reduce are unneeded because there are loops.

Two *primitive* data structures. There's nothing stopping you from creating your own data structures - they just won't be generic like the built in ones.

On 4/9/13 12:54 PM, 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?

Is this an actual question?

>> To compound the matter, Go itself doesn't follow its own preaching
>> (thou shall shun generics and use interfaces throughout) for its own
>> essential data structures (arrays, associative arrays, and channels) -
>> all of which are generic in ways unattainable to client code.
>
> Every language has primitives that have special privileges. I don't
> think this can be used as an argument against Go.

Of course not. The point here is that it's disingenuous to claim generics are useless because they're successfully replaced by interfaces, yet in the same breath use generics for a few select cases.

>> You can only go this far by claiming two data structures are enough
>> and algorithms based on map/reduce are unneeded because there are loops.
>
> Two *primitive* data structures. There's nothing stopping you from
> creating your own data structures - they just won't be generic like the
> built in ones.

This is repeating what I said.


Andrei

On Tuesday, April 09, 2013 00:18:32 Timothee Cour wrote:
> > I know it is hard to balance these type of errors, but unused imports and variables seems a bit extreme.
> 
> seems like go won't support temporarily suppressing such errors (see
> http://weekly.golang.org/doc/faq#unused_variables_and_imports) (nor in
> fact having compile flags affecting semantics, so no
> version(identifier) constructs).
> 
> However D should have opt-in flags for those:
> --warn_unused_import
> --warn_unused_lib (for pragma lib statements)
> likewise, with error instead of warn
> 
> 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.

> --warn_unused_variable

Warning about unused variables could be a big problem, because they're heavily used in traits and RAII, and having -w makes _any_ kind of warnings worse, because they'll then affect what code does and doesn't compile.

> --warn_unused_version (for unused version identifiers, indicating a potentially mis-spelt version identifier given at compile time)

Impossible to warn about, because by definition, not all version identifiers are used at once, and users can define their own.

> --warn_unreachable_code

This is already a warning.

- Jonathan M Davis

On Tuesday, 9 April 2013 at 18:22:33 UTC, Jonathan M Davis wrote:
> Stuff like you're
> suggesting really should be left up to lint-like tools.
>
And profiling should be left to a profiling tool and documentation generation should be left to doxygen-like tool. Wait ...

On Tuesday, 9 April 2013 at 18:39:59 UTC, Tobias Pankrath wrote:
> On Tuesday, 9 April 2013 at 18:22:33 UTC, Jonathan M Davis wrote:
>> Stuff like you're
>> suggesting really should be left up to lint-like tools.
>>
> And profiling should be left to a profiling tool and documentation generation should be left to doxygen-like tool. Wait ...

Yes. Having profiler and ddoc as standard, but separate tools would have been better. But no need to make situation even worse.

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.

Can Go do this:

--------------
import std.stdio;
import std.array;
import std.algorithm;

void main() {
    stdin.byLine(KeepTerminator.yes).
    map!(a => a.idup).
    array.
    sort.
    copy(
       stdout.lockingTextWriter());
}
------------
(Read lines from stdin, sort the lines, write the sorted result to stdout.)

This makes heavy use of generics in order to implement pipeline programming.

On 4/9/2013 11:22 AM, Jonathan M Davis wrote:
> 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.

Yes, that's an accurate assessment of my opinion on the matter. Warnings are a sign that one has made a mistake in the language design. That's perfectly acceptable in, say, C, where there are many known mistakes but the C Standards committee finds it impractical to fix. Hence, warnings become the most reasonable avenue to improve the language.

In D we have the opportunity to fix. Warnings in D are often proposed when reasonable people do not agree on what the correct behavior of the language should be, but I regard such compromises as a copout.

Another bad problem with warnings (and we also have this issue with deprecation errors) is an increasing amount of D code relies on asking the question "does this expression compile without errors". A lot of sand gets thrown in those gears with compiler switches that turn language features on and off.

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.)