https://www.reddit.com/r/programming/comments/30ad8b/why_gos_design_is_a_disservice_to_intelligent/

Andrei

I just wish D examples didn't include string lambdas.

2015-03-25 22:00 GMT+01:00 Andrei Alexandrescu via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com>:

> https://www.reddit.com/r/programming/comments/30ad8b/why_gos_design_is_a_ disservice_to_intelligent/
>
> Andrei
>

On Wednesday, 25 March 2015 at 21:00:37 UTC, Andrei Alexandrescu wrote:
> https://www.reddit.com/r/programming/comments/30ad8b/why_gos_design_is_a_disservice_to_intelligent/
>
> Andrei

Downplaying other languages makes the D crowd look desperate...

Go has stability, is production ready and has an ecosystem with commercial value.

D lacks all of these atm...

Ola Fosheim Grøstad:

> Downplaying other languages makes the D crowd look desperate...

That kind of articles are bad for the image of the D community (and the D code shown in that article is not the best).

Bye,
bearophile

On Wednesday, 25 March 2015 at 23:00:32 UTC, bearophile wrote:
> Ola Fosheim Grøstad:
>
>> Downplaying other languages makes the D crowd look desperate...
>
> That kind of articles are bad for the image of the D community (and the D code shown in that article is not the best).
>
> Bye,
> bearophile

+1
but his points about go really are right.

On 3/25/15 2:55 PM, Mathias Lang via Digitalmars-d-announce wrote:
> I just wish D examples didn't include string lambdas.

There was an initiative to just change them everywhere, seems to have petered out. "Just do it." -- Andrei

On Wednesday, 25 March 2015 at 23:00:32 UTC, bearophile wrote:
> Ola Fosheim Grøstad:
>
>> Downplaying other languages makes the D crowd look desperate...
>
> That kind of articles are bad for the image of the D community (and the D code shown in that article is not the best).
>
> Bye,
> bearophile

I don't know about that... I too think that maybe it was a clumsy way of doing it but I'm not sure that we would have had such critics if Python (eg.) had been choosen to write the examples, even with not very pythonic code.

Maybe it should have been backed up with another language not to put the comparison on D alone.

Bad publicity is better than no publicity in many cases. There's no reason why this couldn't play out right in the end.

On Wednesday, 25 March 2015 at 22:30:15 UTC, Ola Fosheim Grøstad wrote:
> Go has stability, is production ready and has an ecosystem with commercial value.

You could say the same things about Cobol or PHP, but that doesn't mean the languages themselves should be free from criticism. My opinion of Go was very much consistent with the article. It doesn't mean much to me to have a stable language that I don't want to use. His points are valid.

On Wednesday, 25 March 2015 at 21:00:37 UTC, Andrei Alexandrescu wrote:
> https://www.reddit.com/r/programming/comments/30ad8b/why_gos_design_is_a_disservice_to_intelligent/
>
> Andrei

As I know Gary is sometimes (often?) on these forums I'll post some critique here. Misrepresenting Go in a comparison with D doesn't reflect well on the D community, so please have a look at the following issues:

In the first code example, the Go version returns 1 on failure and 0 on success, while the D version always returns 0. Also, the Go version correctly uses stderr for error messages while the D version uses stdout for everything.

In the second example maybe you should print four lists to be equivalent of the Go code. I think it's misrepresentative to shorten the D example by making it do less work.

> auto text   = source.byLine.join.to!(string);

This is not safe as byLine reuses the same buffer for every line. It may or may not work depending on join's implementation. Also, it's idiomatic to omit parantheses when a template argument list consists of a single token: source.byLine.join.to!string;

> With all that said, I honestly think Go’s design a disservice to intelligent programmers.

s/design a disservice/design is a disservice/

> From my experience of using Go it’s just too simple to create useful abstractions.

This sentence is ambiguous and could be taken to mean it's really simple to create useful abstractions in Go. The intended meaning is obvious with context, but it threw me off for a second...

> I guess by now Go programmers reading this will be frothing at the mouth shouting “Your doing it wrong!”.

s/your/you're/

That could be misconstrued as a jab at the intelligence of Go programmers, which I don't think serves your cause.

> Well, there is another way of implementing generic functions and data types, and that is to completely break the type system!

Didn't you just say there was simply no way around it?

> I know object-oriented programming is no silver bullet but it would of been nice to be able to abstract details away into types and provide better encapsulation.

s/would of/would have/

Also, this statement just begs for responses pointing to Go's OOP features. It has both user-defined types and encapsulation features.

On Thursday, 26 March 2015 at 00:19:44 UTC, Jakob Ovrum wrote:
> As I know Gary is sometimes (often?) on these forums I'll post some critique here. Misrepresenting Go in a comparison with D doesn't reflect well on the D community, so please have a look at the following issues:

You describe these as issues forming part of a critique and suggesting the substance of what he wrote is wrong, but are these substantive in the context of a quick blog post (where it is more important to say something generative than to be perfect in its expression).

I don't claim to know Go, but is his basic point off the mark?

> In the first code example, the Go version returns 1 on failure and 0 on success, while the D version always returns 0. Also, the Go version correctly uses stderr for error messages while the D version uses stdout for everything.

   stderr.writeln(text);
   return 1;
correctness is important, but does this change much?


> In the second example maybe you should print four lists to be equivalent of the Go code. I think it's misrepresentative to shorten the D example by making it do less work.

surely people can see beyond a difference of three lines ?  would this change his point?

>> auto text   = source.byLine.join.to!(string);
>
> This is not safe as byLine reuses the same buffer for every line. It may or may not work depending on join's implementation. Also, it's idiomatic to omit parantheses when a template argument list consists of a single token: source.byLine.join.to!string;

fair point if true (I will let others who know better say whether .array. or something is needed).
>
>> With all that said, I honestly think Go’s design a disservice to intelligent programmers.
>
> s/design a disservice/design is a disservice/

What he wrote is correct English, and he is an Englishman living in England.

>>I guess by now Go programmers reading this will be frothing at the mouth >>shouting “Your doing it wrong!”.
> That could be misconstrued as a jab at the intelligence of Go programmers, which I don't think serves your cause.

Again, nobody English would think this was more than mildly humorous (and by no means insulting).  To suggest somebody is rabid is not to insult their intelligence, but merely to tease them about their likely strong emotional reaction.

But what is one to do when making the trade-off between being blandly corporate and acceptable to everyone, versus writing with some character and spirit and offending the sensitive.  It's a personal choice, but not easy to criticize another for theirs.

I personally find the world too bland these days.  One cannot police the forms of expression of people who do not speak for a community or claim to be acting as such (apologies if I am mistaken and he does have an official position within D).  And perhaps one ought not to try.


Laeeth.