Greetings,

I'm interested in the D language - here's my 2c-worth.

The website gives a list of features to drop, at
http://www.digitalmars.com/d/overview.html
and it is great that the D spec is so radical in dropping unnecessary legacy
features.  Here are my suggestions for a couple more.

1. The C syntax.
C syntax is freeform: it uses ";" to separate statements, and it uses braces
"{" and "}" to group statements together.  A good example of this is the
example D program on the web page mentioned above.

These features are unhelpful, and lead to lots of bugs.  Why?  Because, unlike compilers, programmers aren't good at keeping track of large numbers of "{" and "}" in deeply nested structures.  So we indent our code with whitespace, to make it more readable.  The problem is that bugs arise when whitespace and braces disagree, e.g. in

if (blah) {
    if (blah)
    {
        blah;
        blah;
/* This comment is not in a good place */
}
else
{
    blah;
}
blah;
blah;
/* OK, this code does
 * blah blah
 */
}

This one's easy to spot, but you might be reading code that uses an
unfamiliar convention for positioning braces.
I agree that you can run the code through an indenter, or lint, but one
stated aim of D is to remove the features of C/C++ that make it necessary to
pre-check code in this way.  Indentation will always be the most convenient
way to make structured code readable to humans: the example D program itself
demonstrates this. So why not adopt indentation as a language feature?
Perhaps the syntax should be more like Python than like C/C++.

Freeform (";").  It's bad coding practice to put more than one statement on a line; it makes code difficult to read.  Style guidelines tell us not to do it.  Why not design D so that style guidelines are unnecessary (this too is one of D's stated aims) - so that it is difficult, if not impossible, to write bad code?  Use "newline", and only "newline", as a statement terminator.

2. Equality.
Confusion of "=" and "==" is a common source of bugs.  Please use something,
*anything*, in place of "==", even FORTRAN's ".EQ." would be better.



Whether or not you agree with these suggestions, I suggest that the language syntax should not be exempt from examination and improvement; not least because, after D has been released, we will no longer have the opportunity to do this.

If you've read this far, thanks for reading.  I look forward to the day when D replaces C/C++!

Best wishes,

Keith.

"Keith Nash" <k.j.nash@usa.net> wrote in message news:a39e2f$2gk9$1@digitaldaemon.com...
> Greetings,
>
> I'm interested in the D language - here's my 2c-worth.
>
> The website gives a list of features to drop, at
> http://www.digitalmars.com/d/overview.html
> and it is great that the D spec is so radical in dropping unnecessary
legacy
> features.  Here are my suggestions for a couple more.
>
> 1. The C syntax.
> C syntax is freeform: it uses ";" to separate statements, and it uses
braces
> "{" and "}" to group statements together.  A good example of this is the example D program on the web page mentioned above.

There are a lot of Java, Perl, C, C++ programmers who are used to this.
I've not done any python, but I was under the impression it relied on the
indenting
a real pain if your editor changes tabs to spaces, and even if 1 tab == 4
spaces
not every one sets their tabstops the same.

>
> Freeform (";").  It's bad coding practice to put more than one statement
on
> a line; it makes code difficult to read.  Style guidelines tell us not to
do
> it.  Why not design D so that style guidelines are unnecessary (this too
is
> one of D's stated aims) - so that it is difficult, if not impossible, to write bad code?  Use "newline", and only "newline", as a statement terminator.

C programmers find ways round these problems, if you took away the ';' we'd use the ',' more :)

consider:
   i = 9; a = buf[i]; b = a*i;
is the almost that same as
  i = 9, a = buf[i], b= a*i;

except that the latter will have a value of a*i.

or are you intending the all statements must fit onto oneline.
>
> 2. Equality.
> Confusion of "=" and "==" is a common source of bugs.  Please use
something,
> *anything*, in place of "==", even FORTRAN's ".EQ." would be better.
>
personally I would prefer Pascal := as assign and == remains as equal to, if you where to change anything.

Mike.

Oooo, no. That's not very good. "==" and "=" bugs are very common in
C/C++ because int<->bool types are compatible in flow control statements, if they weren't there were only only one possibility:
if (bool_expr1 == bool_expr2)     OR      if (bool_expr1 = bool_expr2)
{                                         {
}                                         }

Sure, it could be nice that equal and assign operators were "strict" different (i.e. ":=" and "==", but of course not ":=" and "=", that would be the same problem for some people as "=" and "==").

Ruslanas

Mike Wynn wrote:

> "Keith Nash" <k.j.nash@usa.net> wrote in message
> news:a39e2f$2gk9$1@digitaldaemon.com...
> 
>>Greetings,
>>
>>I'm interested in the D language - here's my 2c-worth.
>>
>>The website gives a list of features to drop, at
>>http://www.digitalmars.com/d/overview.html
>>and it is great that the D spec is so radical in dropping unnecessary
>>
> legacy
> 
>>features.  Here are my suggestions for a couple more.
>>
>>1. The C syntax.
>>C syntax is freeform: it uses ";" to separate statements, and it uses
>>
> braces
> 
>>"{" and "}" to group statements together.  A good example of this is the
>>example D program on the web page mentioned above.
>>
> 
> There are a lot of Java, Perl, C, C++ programmers who are used to this.
> I've not done any python, but I was under the impression it relied on the
> indenting
> a real pain if your editor changes tabs to spaces, and even if 1 tab == 4
> spaces
> not every one sets their tabstops the same.
> 
> 
>>Freeform (";").  It's bad coding practice to put more than one statement
>>
> on
> 
>>a line; it makes code difficult to read.  Style guidelines tell us not to
>>
> do
> 
>>it.  Why not design D so that style guidelines are unnecessary (this too
>>
> is
> 
>>one of D's stated aims) - so that it is difficult, if not impossible, to
>>write bad code?  Use "newline", and only "newline", as a statement
>>terminator.
>>
> 
> C programmers find ways round these problems, if you took away the ';' we'd
> use the ',' more :)
> 
> consider:
>    i = 9; a = buf[i]; b = a*i;
> is the almost that same as
>   i = 9, a = buf[i], b= a*i;
> 
> except that the latter will have a value of a*i.
> 
> or are you intending the all statements must fit onto oneline.
> 
>>2. Equality.
>>Confusion of "=" and "==" is a common source of bugs.  Please use
>>
> something,
> 
>>*anything*, in place of "==", even FORTRAN's ".EQ." would be better.
>>
>>
> personally I would prefer Pascal := as assign and == remains as equal to, if
> you where to change anything.
> 
> Mike.
> 
> 
> 

Actually I'm kinda partial to the way a very very old language did assignment (the language that scripted the robots in Robot Wars on the Apple ][, by Silas Warner if I remember correctly.  precursor to the CRobots etc games).

It used

9 * x + 5 to a
a * speed * 3 to speed

that kind of thing.  Makes sense to read and also it's sorta easier to work out what the machine will actually do because it reads left to right consistently.  Parses easily for both machines and humans.  I also wouldn't be opposed to using ->, now that that is removed from D.  Or --> or whatever.

9 * x + 5 -> temp
temp * x - 3 -> speed

Either one definitely doesn't look like equality.  Then we could use regular = for equality, which is also very intuitive for math folks.

Math doesn't use = as assignment, neither should programming languages.  I'm not sure how *= , +=, etc would work in that case though...

One quirk with that language is that it didn't have unary minus (that's how simple it was).  You had to use 0 - x.

I definitely don't like relying on indentation and newlines to delimit a language...  but then again most of mine I just make the ; optional as most of the time you can unambiguously tell when one expression or statement ends and another begins (however not always, with C style grammars that allow arbitrary expressions by themselves).

Maybe

put 9 * x + 5 in temp
put * x - 3 in speed

would clear that up cuz a statement could only be an assignment, function call, loop, or logic, never any spurious crap like - x.  Nah, it'd never work, I'm sure people would bitch about the extra typing.  <heh>

Sean


"Ruslanas Abdrachimovas" <anubis@03bar.ktu.lt> wrote in message news:3C5907D3.3080507@03bar.ktu.lt...
> Oooo, no. That's not very good. "==" and "=" bugs are very common in
> C/C++ because int<->bool types are compatible in flow control
> statements, if they weren't there were only only one possibility:
> if (bool_expr1 == bool_expr2)     OR      if (bool_expr1 = bool_expr2)
> {                                         {
> }                                         }
>
> Sure, it could be nice that equal and assign operators were "strict" different (i.e. ":=" and "==", but of course not ":=" and "=", that would be the same problem for some people as "=" and "==").
>
> Ruslanas
>
> Mike Wynn wrote:
>
> > "Keith Nash" <k.j.nash@usa.net> wrote in message news:a39e2f$2gk9$1@digitaldaemon.com...
> >
> >>Greetings,
> >>
> >>I'm interested in the D language - here's my 2c-worth.
> >>
> >>The website gives a list of features to drop, at
> >>http://www.digitalmars.com/d/overview.html
> >>and it is great that the D spec is so radical in dropping unnecessary
> >>
> > legacy
> >
> >>features.  Here are my suggestions for a couple more.
> >>
> >>1. The C syntax.
> >>C syntax is freeform: it uses ";" to separate statements, and it uses
> >>
> > braces
> >
> >>"{" and "}" to group statements together.  A good example of this is the example D program on the web page mentioned above.
> >>
> >
> > There are a lot of Java, Perl, C, C++ programmers who are used to this. I've not done any python, but I was under the impression it relied on
the
> > indenting
> > a real pain if your editor changes tabs to spaces, and even if 1 tab ==
4
> > spaces
> > not every one sets their tabstops the same.
> >
> >
> >>Freeform (";").  It's bad coding practice to put more than one statement
> >>
> > on
> >
> >>a line; it makes code difficult to read.  Style guidelines tell us not
to
> >>
> > do
> >
> >>it.  Why not design D so that style guidelines are unnecessary (this too
> >>
> > is
> >
> >>one of D's stated aims) - so that it is difficult, if not impossible, to write bad code?  Use "newline", and only "newline", as a statement terminator.
> >>
> >
> > C programmers find ways round these problems, if you took away the ';'
we'd
> > use the ',' more :)
> >
> > consider:
> >    i = 9; a = buf[i]; b = a*i;
> > is the almost that same as
> >   i = 9, a = buf[i], b= a*i;
> >
> > except that the latter will have a value of a*i.
> >
> > or are you intending the all statements must fit onto oneline.
> >
> >>2. Equality.
> >>Confusion of "=" and "==" is a common source of bugs.  Please use
> >>
> > something,
> >
> >>*anything*, in place of "==", even FORTRAN's ".EQ." would be better.
> >>
> >>
> > personally I would prefer Pascal := as assign and == remains as equal
to, if
> > you where to change anything.
> >
> > Mike.
> >
> >
> >
>
>

I don't like this. I think ":=" and "==" are good enough..., but something like this "+=" or "*=" we should leave as it is.

Ruslanas

Sean L. Palmer wrote:

> Actually I'm kinda partial to the way a very very old language did
> assignment (the language that scripted the robots in Robot Wars on the
> Apple ][, by Silas Warner if I remember correctly.  precursor to the CRobots
> etc games).
> 
> It used
> 
> 9 * x + 5 to a
> a * speed * 3 to speed
> 
> that kind of thing.  Makes sense to read and also it's sorta easier to work
> out what the machine will actually do because it reads left to right
> consistently.  Parses easily for both machines and humans.  I also wouldn't
> be opposed to using ->, now that that is removed from D.  Or --> or
> whatever.
> 
> 9 * x + 5 -> temp
> temp * x - 3 -> speed
> 
> Either one definitely doesn't look like equality.  Then we could use regular
> = for equality, which is also very intuitive for math folks.
> 
> Math doesn't use = as assignment, neither should programming languages.  I'm
> not sure how *= , +=, etc would work in that case though...
> 
> One quirk with that language is that it didn't have unary minus (that's how
> simple it was).  You had to use 0 - x.
> 
> I definitely don't like relying on indentation and newlines to delimit a
> language...  but then again most of mine I just make the ; optional as most
> of the time you can unambiguously tell when one expression or statement ends
> and another begins (however not always, with C style grammars that allow
> arbitrary expressions by themselves).
> 
> Maybe
> 
> put 9 * x + 5 in temp
> put * x - 3 in speed
> 
> would clear that up cuz a statement could only be an assignment, function
> call, loop, or logic, never any spurious crap like - x.  Nah, it'd never
> work, I'm sure people would bitch about the extra typing.  <heh>
> 
> Sean
> 
> 
> "Ruslanas Abdrachimovas" <anubis@03bar.ktu.lt> wrote in message
> news:3C5907D3.3080507@03bar.ktu.lt...
> 
>>Oooo, no. That's not very good. "==" and "=" bugs are very common in
>>C/C++ because int<->bool types are compatible in flow control
>>statements, if they weren't there were only only one possibility:
>>if (bool_expr1 == bool_expr2)     OR      if (bool_expr1 = bool_expr2)
>>{                                         {
>>}                                         }
>>
>>Sure, it could be nice that equal and assign operators were "strict"
>>different (i.e. ":=" and "==", but of course not ":=" and "=", that
>>would be the same problem for some people as "=" and "==").
>>
>>Ruslanas
>>
>>Mike Wynn wrote:
>>
>>
>>>"Keith Nash" <k.j.nash@usa.net> wrote in message
>>>news:a39e2f$2gk9$1@digitaldaemon.com...
>>>
>>>
>>>>Greetings,
>>>>
>>>>I'm interested in the D language - here's my 2c-worth.
>>>>
>>>>The website gives a list of features to drop, at
>>>>http://www.digitalmars.com/d/overview.html
>>>>and it is great that the D spec is so radical in dropping unnecessary
>>>>
>>>>
>>>legacy
>>>
>>>
>>>>features.  Here are my suggestions for a couple more.
>>>>
>>>>1. The C syntax.
>>>>C syntax is freeform: it uses ";" to separate statements, and it uses
>>>>
>>>>
>>>braces
>>>
>>>
>>>>"{" and "}" to group statements together.  A good example of this is the
>>>>example D program on the web page mentioned above.
>>>>
>>>>
>>>There are a lot of Java, Perl, C, C++ programmers who are used to this.
>>>I've not done any python, but I was under the impression it relied on
>>>
> the
> 
>>>indenting
>>>a real pain if your editor changes tabs to spaces, and even if 1 tab ==
>>>
> 4
> 
>>>spaces
>>>not every one sets their tabstops the same.
>>>
>>>
>>>
>>>>Freeform (";").  It's bad coding practice to put more than one statement
>>>>
>>>>
>>>on
>>>
>>>
>>>>a line; it makes code difficult to read.  Style guidelines tell us not
>>>>
> to
> 
>>>do
>>>
>>>
>>>>it.  Why not design D so that style guidelines are unnecessary (this too
>>>>
>>>>
>>>is
>>>
>>>
>>>>one of D's stated aims) - so that it is difficult, if not impossible, to
>>>>write bad code?  Use "newline", and only "newline", as a statement
>>>>terminator.
>>>>
>>>>
>>>C programmers find ways round these problems, if you took away the ';'
>>>
> we'd
> 
>>>use the ',' more :)
>>>
>>>consider:
>>>   i = 9; a = buf[i]; b = a*i;
>>>is the almost that same as
>>>  i = 9, a = buf[i], b= a*i;
>>>
>>>except that the latter will have a value of a*i.
>>>
>>>or are you intending the all statements must fit onto oneline.
>>>
>>>
>>>>2. Equality.
>>>>Confusion of "=" and "==" is a common source of bugs.  Please use
>>>>
>>>>
>>>something,
>>>
>>>
>>>>*anything*, in place of "==", even FORTRAN's ".EQ." would be better.
>>>>
>>>>
>>>>
>>>personally I would prefer Pascal := as assign and == remains as equal
>>>
> to, if
> 
>>>you where to change anything.
>>>
>>>Mike.
>>>
>>>
>>>
>>>
>>
> 
> 

I never sugested '=' (single equals as equality)

I guess I should have said ;
have a real boolean like Java so none of the
int a ; if ( a ) {...} and more of : int a; if ( a == 0 ) { ... }
that's equal equal like C/D/Java/etc etc
that's about 80% of the '=' "==" bugs
them replace assign ('=') with ":=" Like Pascal etc
this is inline with all the += <<= -= operators;
straight assign not operator assign
and '=' is never to be seen.
 you can't have
int a; if ( a := b ) {.. }
instead
int a; if ( (a := b) == 0 ) {.. }
I've not heard a java programmer complain about having to add 3/4 extra
symbols
as the time spent is well worth it.
and the compiled code is the same (try it with your C compiler)

Mike.

"Ruslanas Abdrachimovas" <anubis@03bar.ktu.lt> wrote in message news:3C5907D3.3080507@03bar.ktu.lt...
> Oooo, no. That's not very good. "==" and "=" bugs are very common in
> C/C++ because int<->bool types are compatible in flow control
> statements, if they weren't there were only only one possibility:
> if (bool_expr1 == bool_expr2)     OR      if (bool_expr1 = bool_expr2)
> {                                         {
> }                                         }
>
> Sure, it could be nice that equal and assign operators were "strict" different (i.e. ":=" and "==", but of course not ":=" and "=", that would be the same problem for some people as "=" and "==").
>
> Ruslanas
>
> Mike Wynn wrote:
> > >>
> > personally I would prefer Pascal := as assign and == remains as equal
to, if
> > you where to change anything.
> >
> > Mike.
> >

"Keith Nash" <k.j.nash@usa.net> wrote in message news:a39e2f$2gk9$1@digitaldaemon.com...

> 1. The C syntax.
> C syntax is freeform: it uses ";" to separate statements, and it uses
braces
> "{" and "}" to group statements together.  A good example of this is the example D program on the web page mentioned above.
>
> These features are unhelpful, and lead to lots of bugs.  Why?  Because, unlike compilers, programmers aren't good at keeping track of large
numbers
> of "{" and "}" in deeply nested structures.  So we indent our code with whitespace, to make it more readable.  The problem is that bugs arise when whitespace and braces disagree, e.g. in
...
> Perhaps the syntax should be more like Python than like C/C++.

We C guys have all got so used to it, I don't think it's a good idea to drop this syntax...

> Freeform (";").  It's bad coding practice to put more than one statement
on
> a line; it makes code difficult to read.  Style guidelines tell us not to
do
> it.  Why not design D so that style guidelines are unnecessary (this too
is
> one of D's stated aims) - so that it is difficult, if not impossible, to write bad code?  Use "newline", and only "newline", as a statement terminator.

BASIC once was like that. Now we can use colon to put several statements on one line. Sometimes, it just looks better - and clearer.

> 2. Equality.
> Confusion of "=" and "==" is a common source of bugs.  Please use
something,
> *anything*, in place of "==", even FORTRAN's ".EQ." would be better.

Then better use Pascal syntax, := for assigning and == for comparison. Or even better, leave it as is =) I like it this way

"Sean L. Palmer" <spalmer@iname.com> wrote in message news:a3b30k$2npi$1@digitaldaemon.com...

> consistently.  Parses easily for both machines and humans.  I also
wouldn't
> be opposed to using ->, now that that is removed from D.  Or --> or whatever.
>
> 9 * x + 5 -> temp
> temp * x - 3 -> speed

Knuth fan, eh? =)

> Math doesn't use = as assignment, neither should programming languages.
I'm
> not sure how *= , +=, etc would work in that case though...

Math uses :=

D has "real" bools (bits are), it's just syntax-relaxed.

> D has "real" bools (bits are), it's just syntax-relaxed.

BTW, Walter, could you please define binary operators on
bit so it doesn't get converted to byte - so that ~true
is false, not 0xfe =)