> I'm not sure how much of a problem it is, especially given that Go has a
> strict style guide, but the objection has come up that these two are
> very different:
>
>   if i < f() {
>       g()
>   }
>
> and
>
>   if i < f()
>   {
>       g()
>   }
>
> In the second case, a semicolon is inserted on the same line as the if.
>
> However, like I said, in idiomatic Go, this is simply not a done thing.

Why would:

    if i < f()

gain a semi-colon? I thought the Go rules require that a line would compile to add the semi-colon. In D at least wouldn't the line have to be:

    if i < f() {}

before the compiler would add a semi-colon to it?

On 7/12/13 1:46 PM, ixid wrote:
>> They are not issues in Go, but Walter is strongly against optional semicolons, as bearophile said.
>> Me and others (like you) like optional semicolons, but since Walter doesn't and it's his language,
>> that will not change.
>>
>> I personally understand much better the code without semicolons, like in Ruby and Python. And
>> making a parser that way isn't that much difficult, and error recovery is as powerful.
>
> Yes, I don't expect anyone to change their opinion though frankly the anti-groups opinions feel more
> like attachment to the status quo than something that's evidently and demonstrably superior.
>
> It seems a pity that D is achieving such power and elegance in some areas while failing to take on
> some of the syntactic beauty that is within reach. The ultimate language would look something like D
> crossed with Go in my eyes. It would be interesting if someone were able to make a D subset that
> showed what it could look like. There is significant value to being easy to read and write, making
> the language naturally more appealing for users just as speed makes applications much more
> attractive to users.

One person's beauty is another person's ugly.  This is an area that reasonable people are going to disagree on.  You're feeling on their reasons is rather dismissive.

On Fri, Jul 12, 2013 at 05:51:21PM -0700, Brad Roberts wrote:
> On 7/12/13 1:46 PM, ixid wrote:
[...]
> >It seems a pity that D is achieving such power and elegance in some areas while failing to take on some of the syntactic beauty that is within reach. The ultimate language would look something like D crossed with Go in my eyes. It would be interesting if someone were able to make a D subset that showed what it could look like. There is significant value to being easy to read and write, making the language naturally more appealing for users just as speed makes applications much more attractive to users.
> 
> One person's beauty is another person's ugly.  This is an area that reasonable people are going to disagree on.  You're feeling on their reasons is rather dismissive.

I find this fixation on syntax rather strange. As long as the syntax is not *too* ugly (*cough*C++ templates*cough*) isn't the *semantics* more important? A pretty language that has limited expressiveness is useless; a powerful language that's a bit ugly in syntax isn't any less powerful because of it.


T

-- 
There are two ways to write error-free programs; only the third one works.

> As long as the syntax is
> not *too* ugly (*cough*C++ templates*cough*) isn't the *semantics* more
> important? A pretty language that has limited expressiveness is useless;
> a powerful language that's a bit ugly in syntax isn't any less powerful
> because of it.
>
>
> T

What is the cost of expressiveness in these cases? I don't think expressiveness should be limited and often prettiness lends itself to expressiveness. People find D templates much easier to use than C++ ones and in part that's because they're much easier for humans to parse.

On Sat, Jul 13, 2013 at 03:19:04AM +0200, ixid wrote:
> >As long as the syntax is not *too* ugly (*cough*C++ templates*cough*) isn't the *semantics* more important? A pretty language that has limited expressiveness is useless; a powerful language that's a bit ugly in syntax isn't any less powerful because of it.
[...]
> What is the cost of expressiveness in these cases?

But that's the issue, this is just a cosmetic change that doesn't really add expressiveness to the language.


> I don't think expressiveness should be limited and often prettiness lends itself to expressiveness. People find D templates much easier to use than C++ ones and in part that's because they're much easier for humans to parse.

But I find C's for-loop syntax easier to parse, because what's in the preamble is clearly distinguished from what's in the loop body. Omitting the parens would make it visually more similar to the loop body, and thus more liable to be confused with it.

I think comparing this to D vs. C++ template syntax is a bit unfair. C++
templates made a bad choice of using angle brackets, which are already
being used for comparison operators, thus things like func<a<b>(x)>y are
ambiguous: is it func<(a<b)>(x) > y, or is it func<(a<b>(x))> y? Not to
mention func<a<b>> is actually syntactically invalid until C++11 (how
many years did it take for them to fix that one!). D templates are so
much better, in part because they use normal parentheses, which *don't*
suffer from ambiguity with existing operators.

In the case of optional parens in for-loops, there are no such ambiguity issues involved. It's more a matter of personal preference than anything else, IMO.


T

-- 
To err is human; to forgive is not our policy. -- Samuel Adler

On Friday, 12 July 2013 at 20:46:21 UTC, ixid wrote:
> Yes, I don't expect anyone to change their opinion though frankly the anti-groups opinions feel more like attachment to the status quo than something that's evidently and demonstrably superior.
I think that Python has syntax evidently and demonstrably superior to D. Why not Python?
>
> It seems a pity that D is achieving such power and elegance in some areas while failing to take on some of the syntactic beauty that is within reach. The ultimate language would look something like D crossed with Go in my eyes. It would be interesting if someone were able to make a D subset that showed what it could look like. There is significant value to being easy to read and write, making the language naturally more appealing for users just as speed makes applications much more attractive to users.

There won't be an ultimate language - ever. People haven't settled up even on tabs vs spaces or braces issues yet.

Please keep in mind that every change made to the langage has costs that have to be paid for the benefits. Sometimes costs are not worth paying for the potential benefits. Status quo has this wonderful feature - it has 0 cost, so the benefit/cost ratio approaches infinity :).

Also, i don't know what's wrong with parens - 2 additional keystrokes? I didn't see a for loop i a long time - ranges + foreach are everywhere. And foreach is 4 chars more to type than for :P.

On Saturday, July 13, 2013 06:42:57 QAston wrote:
> On Friday, 12 July 2013 at 20:46:21 UTC, ixid wrote:
> > Yes, I don't expect anyone to change their opinion though frankly the anti-groups opinions feel more like attachment to the status quo than something that's evidently and demonstrably superior.
> 
> I think that Python has syntax evidently and demonstrably superior to D. Why not Python?

I think that that's very disputable. In general, which syntax is better than another syntax is very subjective. Personally, I hate Python's syntax and find it far harder to deal with than that of languages like C/C++ or D. The lack of braces alone is a huge annoyance for editing code (being able to hop between braces in an editor is invaluable for getting to the beginning and end of functions, scopes, classes, etc.), and it's easy enough to find rants where people have had bugs in their python code due to spacing issues and how it cost them hours to find them.

Yes. Some people prefer python's syntax, but I don't see how anyone could possibly claim that it was demonstratably superior. It's primarily a subjective issue, and from what I've seen, the objective portions of the argument are very much against python as having braces and semicolons and the like makes the code more explicit and therefore less prone to scoping issues. So while that tradeoff may very well be worth it for some people, it's certainly not an objective advantage for python's syntax.

- Jonathan M Davis

On Saturday, 13 July 2013 at 04:56:19 UTC, Jonathan M Davis wrote:
> On Saturday, July 13, 2013 06:42:57 QAston wrote:
>> On Friday, 12 July 2013 at 20:46:21 UTC, ixid wrote:
>> > Yes, I don't expect anyone to change their opinion though
>> > frankly the anti-groups opinions feel more like attachment to
>> > the status quo than something that's evidently and demonstrably
>> > superior.
>> 
>> I think that Python has syntax evidently and demonstrably
>> superior to D. Why not Python?
>
> I think that that's very disputable. In general, which syntax is better than
> another syntax is very subjective. Personally, I hate Python's syntax and find
> it far harder to deal with than that of languages like C/C++ or D. The lack of
> braces alone is a huge annoyance for editing code (being able to hop between
> braces in an editor is invaluable for getting to the beginning and end of
> functions, scopes, classes, etc.), and it's easy enough to find rants where
> people have had bugs in their python code due to spacing issues and how it
> cost them hours to find them.
>
> Yes. Some people prefer python's syntax, but I don't see how anyone could
> possibly claim that it was demonstratably superior. It's primarily a
> subjective issue, and from what I've seen, the objective portions of the
> argument are very much against python as having braces and semicolons and the
> like makes the code more explicit and therefore less prone to scoping issues.
> So while that tradeoff may very well be worth it for some people, it's
> certainly not an objective advantage for python's syntax.
>
> - Jonathan M Davis

I agree, I was just playing games with ixid.

On Saturday, 13 July 2013 at 04:42:58 UTC, QAston wrote:
> Also, i don't know what's wrong with parens - 2 additional keystrokes? I didn't see a for loop i a long time - ranges + foreach are everywhere. And foreach is 4 chars more to type than for :P.

Replying to myself, but well, this is flawed, foreach is ususally shorter than for.

On Saturday, July 13, 2013 07:03:28 QAston wrote:
> On Saturday, 13 July 2013 at 04:56:19 UTC, Jonathan M Davis wrote:
> > On Saturday, July 13, 2013 06:42:57 QAston wrote:
> >> On Friday, 12 July 2013 at 20:46:21 UTC, ixid wrote:
> >> > Yes, I don't expect anyone to change their opinion though
> >> > frankly the anti-groups opinions feel more like attachment to
> >> > the status quo than something that's evidently and
> >> > demonstrably
> >> > superior.
> >> 
> >> I think that Python has syntax evidently and demonstrably superior to D. Why not Python?
> > 
> > I think that that's very disputable. In general, which syntax
> > is better than
> > another syntax is very subjective. Personally, I hate Python's
> > syntax and find
> > it far harder to deal with than that of languages like C/C++ or
> > D. The lack of
> > braces alone is a huge annoyance for editing code (being able
> > to hop between
> > braces in an editor is invaluable for getting to the beginning
> > and end of
> > functions, scopes, classes, etc.), and it's easy enough to find
> > rants where
> > people have had bugs in their python code due to spacing issues
> > and how it
> > cost them hours to find them.
> > 
> > Yes. Some people prefer python's syntax, but I don't see how
> > anyone could
> > possibly claim that it was demonstratably superior. It's
> > primarily a
> > subjective issue, and from what I've seen, the objective
> > portions of the
> > argument are very much against python as having braces and
> > semicolons and the
> > like makes the code more explicit and therefore less prone to
> > scoping issues.
> > So while that tradeoff may very well be worth it for some
> > people, it's
> > certainly not an objective advantage for python's syntax.
> > 
> > - Jonathan M Davis
> 
> I agree, I was just playing games with ixid.

Ah. Clearly I read through the posts too quickly.

I should probably add though that the problems that the lack of braces cause in python with regards to moving around in the code in an editor also apply to parens, which would be an objective reason why getting rid of parens on for loops would cause problems. Obviously, it could be argued that how the code looks without parens would be better than with parens and worth the problems it would cause with text editors, but that would be a completely subjective argument.

- Jonathan M Davis