Critique of D, so far.

0.  Not different enough to be useful?   I really want some more radical changes.

1. Misuse of UNICODE, why limit to the old character set?  The goal wasn't
BIGGER SOURCE FILES!
    Programming cries out for a larger source character set, we need single
character codes for assignment (a left arrow will do nicely), logical
implication (a right arrow will do), begin and end blocks (no, I don't mean
curlies).  See the next item. The two-character <= (less-than or equal)
should be a single graphic.

1a.  Simple environment hacks can be arranged (by the text editor/ide) to use ctrl-1 and so on as the keying sequence.  Published code should look more polished.

1b.  It should be possible to write code in a Rich Text Format that maintains its form across operating systems.

1c.  Fixed width fonts are artifacts of ancient history.

2.  Old-fashioned if statement.  The if/else/elseif/endif format is nicer
and is widely understood.
    IF   a< b THEN         // THEN is a one-character code that includes
function of close paren and open curly.
           a <- b;               // Assign b to a, with a one-character
assignment left arrow.
   ELSIF g = h THEN    // one-character equality test.  One-character ELSIF
.
           x(foo);
   ENDIF                      // one-character ENDIF, not 5 characters, as
show.

3. I don't see support for SQL data types (possibility of a null field).
References could allow for a null reference.
    See http://www.joelonsoftware.com/items/2004/03/25.html,  for more ideas
see
    http://discuss.fogcreek.com/newyork/default.asp?cmd=show&ixPost=4628

3a.  The time and date file types are built around the primitive system types. SQL has time and date types of it own that should be supported.  I guess you can do this in std.sql or sql.datetime.   You'll need to be able to convert between types of date/time.

4.  Too limited to just the C/C++/C#/Java family of languages as a base. Okay, hashes from perl.  I can't believe there isn't more from ML, Haskell, and so on, to steal or absorb.

5.  May as well have two-valued division.  Get the quotient and remainder from a division in one step instead of repeating the division. Or document the way to tickle the optimizer to obtain that performance.

6.  I always tweak my build environments to have 3 basic build types, Debug, Release, and Fast-Build.  The Fast-Build has no debugging and no optimization.  Use it to systems-check small changes with a fast test before starting the big builds.  Highly recommended.  Include all the asserts, invariants, and contracts.  A Fast-build both builds much faster and runs much faster than a full debug build (at least in Microsoft environments).

7.  Support for URLs in program source text.  Referencing specification documents in comments is okay but we can do better.  Next step is Import from a url.

8.   Large systems benefit from automatic documentation tools. Java and C# have them. Does D?

9.   How do you guarantee there are no buffer overruns when calling sprintf and vprintf?

10. It is good that the world recognizes that C++ is primarily a research language.

11.  The ability to allocate class instances on the stack makes OO much more practical.

12. There is no "Bindings" or binary-object interface for things like corba or COM.   No assurance that two different Linux (or Windows) compilers output can be linked together and run, no publication of a name-mangling scheme.



The following statement put a grin on my face that lasted a half hour. I've
had relationships with shorter lifetimes:
  "There's no need for multiple warning levels in D, a "D Puzzle Book", a
lint program, a "Bug Of The Month", or a world's leading expert on
preprocessor token concatenation"

 The pleasure I received from reading that prompted me to write this
message, which I intend as encouragement.

On Tue, 20 Apr 2004 14:32:56 -0700, Warren wrote:

> Critique of D, so far.
> 
> 0.  Not different enough to be useful?   I really want some more radical changes.

Like what?

> 1. Misuse of UNICODE, why limit to the old character set?  The goal wasn't
> BIGGER SOURCE FILES!
>     Programming cries out for a larger source character set, we need single
> character codes for assignment (a left arrow will do nicely), logical
> implication (a right arrow will do), begin and end blocks (no, I don't mean
> curlies).  See the next item. The two-character <= (less-than or equal)
> should be a single graphic.

A language should be limited to the keys on my keyboard. And I shouldn't have to remap it.

> <snip>
> 1b.  It should be possible to write code in a Rich Text Format that
> maintains its form across operating systems.

I cannot recommend against non-plaintext files strongly enough. This will make it much more difficult to edit without necessitating editor changes.

> 1c.  Fixed width fonts are artifacts of ancient history.

This is not a language issue, this is an environment issue. I can program in wingdings if I want to. No semantec meaning is placed on tabs or whitespace, so fixed/variable width is completely irrelevant.

> 2.  Old-fashioned if statement.  The if/else/elseif/endif format is nicer
> and is widely understood.
>     IF   a< b THEN         // THEN is a one-character code that includes
> function of close paren and open curly.
>            a <- b;               // Assign b to a, with a one-character
> assignment left arrow.
>    ELSIF g = h THEN    // one-character equality test.  One-character ELSIF
> .
>            x(foo);
>    ENDIF                      // one-character ENDIF, not 5 characters, as
> show.

This is a 100% cosmetic change for almost zero gain, and high cost in usability (see previous responses). And what character is an 'else if'? I see no compelling reason to change from the existing paradigm.

> 3. I don't see support for SQL data types (possibility of a null field).
> References could allow for a null reference.
>     See http://www.joelonsoftware.com/items/2004/03/25.html,  for more ideas
> see
>     http://discuss.fogcreek.com/newyork/default.asp?cmd=show&ixPost=4628

The runtime library isn't complete yet. Submissions to Phobos are, of course, welcome ;)

> 3a.  The time and date file types are built around the primitive system types. SQL has time and date types of it own that should be supported.  I guess you can do this in std.sql or sql.datetime.   You'll need to be able to convert between types of date/time.

See above.

> 4.  Too limited to just the C/C++/C#/Java family of languages as a base. Okay, hashes from perl.  I can't believe there isn't more from ML, Haskell, and so on, to steal or absorb.

What features do you want, and why? A lot of people know the other curly-brace languages, so similar syntax is a plus for learning. If there's no reason to deviate, why do so?

> 5.  May as well have two-valued division.  Get the quotient and remainder from a division in one step instead of repeating the division. Or document the way to tickle the optimizer to obtain that performance.

This could be kind of nifty, but I seriously doubt that there is an application that is bound by the cost of dividing an integer, since processors are so fast now. This is not always an excuse for poor coding, but this is such a tiny, special case optimization that a language change isn't called for.

> 6.  I always tweak my build environments to have 3 basic build types, Debug, Release, and Fast-Build.  The Fast-Build has no debugging and no optimization.  Use it to systems-check small changes with a fast test before starting the big builds.  Highly recommended.  Include all the asserts, invariants, and contracts.  A Fast-build both builds much faster and runs much faster than a full debug build (at least in Microsoft environments).

The DMD compiler has an optimization and debug flags, and so does the GCC compiler. Or are you asking for something different?

> 7.  Support for URLs in program source text.  Referencing specification documents in comments is okay but we can do better.  Next step is Import from a url.

It's not clear what you are calling for here.

> 8.   Large systems benefit from automatic documentation tools. Java and C# have them. Does D?

Doxygen supports D, as I recall.

> 9.   How do you guarantee there are no buffer overruns when calling sprintf and vprintf?

Don't call sprintf and vprintf.

> 11.  The ability to allocate class instances on the stack makes OO much more practical.

Why?

> 12. There is no "Bindings" or binary-object interface for things like corba or COM.   No assurance that two different Linux (or Windows) compilers output can be linked together and run, no publication of a name-mangling scheme.

I have not programmed for either of COM or CORBA, but recent discussions have been addressed maintaining compatibility with COM (these discussions included the author, Walter).

Mike Swieton
__
We must respect the other fellow's religion, but only in the sense and to the
extent that we respect his theory that his wife is beautiful and his children
smart.
	- H. L. Mencken

See inline comments

Mike Swieton wrote:

> On Tue, 20 Apr 2004 14:32:56 -0700, Warren wrote:
> 
> 
>>7.  Support for URLs in program source text.  Referencing specification
>>documents in comments is okay but we can do better.  Next step is Import
>>from a url.
> 
> 
> It's not clear what you are calling for here.
> 

Does he want to be able to call:
import http://path.to/my/import.d?


> 
>>8.   Large systems benefit from automatic documentation tools. Java and C#
>>have them. Does D?
> 
> 
> Doxygen supports D, as I recall.
> 
D can be documentation itself.
You can write your code as HTML document.
> 
>>11.  The ability to allocate class instances on the stack makes OO much more
>>practical.
> 
> 
> Why?

Maybe because you can use
MyClass myclass;
instead of
MyClass myclass = new MyClass;?
> 
> 
>>12. There is no "Bindings" or binary-object interface for things like corba
>>or COM.   No assurance that two different Linux (or Windows) compilers
>>output can be linked together and run, no publication of a name-mangling
>>scheme.
> 
> 
> I have not programmed for either of COM or CORBA, but recent discussions have
> been addressed maintaining compatibility with COM (these discussions included
> the author, Walter).
> 
I think he is talking about stub code generators. These are tools that generate for example .cpp files from .idl . That there is no ABI for D is an issue that will be adressed...

Warren schrieb:

> Critique of D, so far.
> 
> 0.  Not different enough to be useful?   I really want some more radical
> changes.

If it was as radically different as academic languages, hardly anyone would like to use it. ;>

But well, expect some real revolutionary innovations in D 2.0 - now we have to prepare a solid basis which would not make the ground thin for them, as C++ has.

> 1. Misuse of UNICODE, why limit to the old character set?  The goal wasn't
> BIGGER SOURCE FILES!
>     Programming cries out for a larger source character set, we need single
> character codes for assignment (a left arrow will do nicely), logical
> implication (a right arrow will do), begin and end blocks (no, I don't mean
> curlies).  See the next item. The two-character <= (less-than or equal)
> should be a single graphic.
> 
> 1a.  Simple environment hacks can be arranged (by the text editor/ide) to
> use ctrl-1 and so on as the keying sequence.  Published code should look
> more polished.
> 
> 1b.  It should be possible to write code in a Rich Text Format that
> maintains its form across operating systems.
> 
> 1c.  Fixed width fonts are artifacts of ancient history.

Then why don't you write a cool editor which would replace for you tokens by unicode visually, and still allow the VI users to use their favorite. "Official" misuse of Unicode has already been discussed to the extent that we reached a clear agreement: NO.

> 2.  Old-fashioned if statement.  The if/else/elseif/endif format is nicer
> and is widely understood.
>     IF   a< b THEN         // THEN is a one-character code that includes
> function of close paren and open curly.
>            a <- b;               // Assign b to a, with a one-character
> assignment left arrow.
>    ELSIF g = h THEN    // one-character equality test.  One-character ELSIF
> .
>            x(foo);
>    ENDIF                      // one-character ENDIF, not 5 characters, as
> show.

Yes, but it won't happen. Walter doesn't seem to like Pascal, although i argue that it saves on many parenthesis which are hard to type and to read.

> 3. I don't see support for SQL data types (possibility of a null field).
> References could allow for a null reference.
>     See http://www.joelonsoftware.com/items/2004/03/25.html,  for more ideas
> see
>     http://discuss.fogcreek.com/newyork/default.asp?cmd=show&ixPost=4628

Guess what is a class reference before you new it? Exactly that, null. You can assign null, test against non-null with if(obj) or if(obj !== null) or against null with if(!obj) or if(obj is null).

> 3a.  The time and date file types are built around the primitive system
> types. SQL has time and date types of it own that should be supported.  I
> guess you can do this in std.sql or sql.datetime.   You'll need to be able
> to convert between types of date/time.

Library feature. Write your SQL library and add that.

> 4.  Too limited to just the C/C++/C#/Java family of languages as a base.
> Okay, hashes from perl.  I can't believe there isn't more from ML, Haskell,
> and so on, to steal or absorb.

See No. 0. We have a surprise in the pocket - after /me and Bill Cox have advertised it for such a long time, there *might* be a language extension mechanism some day. Say, allowing to add pattenmatcher and stuff a-la functional languages per *library*. See OpenC++ to get some inspiration.

> 5.  May as well have two-valued division.  Get the quotient and remainder
> from a division in one step instead of repeating the division. Or document
> the way to tickle the optimizer to obtain that performance.

Not a language feature, but quality of implementation. There are many similar cases, like fsin and fcos, and so on. Idea: these could be included among intrinsics. But we need more anyway, like bit rotate and so on.

> 6.  I always tweak my build environments to have 3 basic build types, Debug,
> Release, and Fast-Build.  The Fast-Build has no debugging and no
> optimization.  Use it to systems-check small changes with a fast test before
> starting the big builds.  Highly recommended.  Include all the asserts,
> invariants, and contracts.  A Fast-build both builds much faster and runs
> much faster than a full debug build (at least in Microsoft environments).

We already have exactly that built into the current compiler. Look for command line options somewhere.

> 7.  Support for URLs in program source text.  Referencing specification
> documents in comments is okay but we can do better.  Next step is Import
> from a url.

Why? This is unreliable!

> 8.   Large systems benefit from automatic documentation tools. Java and C#
> have them. Does D?

Write one. So far there is one dirty, very dirty Doxygen hack. Not a language feature anyway. Yes, it does matter for popularity.

> 9.   How do you guarantee there are no buffer overruns when calling sprintf
> and vprintf?

We don't. printf siblings are nearly deprecated. No official guidelines yet, besides that libraries in general should allocate as much memory as requiered themselves by newing it.

> 10. It is good that the world recognizes that C++ is primarily a research
> language.

??????

> 11.  The ability to allocate class instances on the stack makes OO much more
> practical.

See class custom allocators. You can even allocate a class on a moon if you have moonalloc() implemented elsewhere.

> 12. There is no "Bindings" or binary-object interface for things like corba
> or COM.   No assurance that two different Linux (or Windows) compilers
> output can be linked together and run, no publication of a name-mangling
> scheme.

No, there won't be. Different compilers have to be able to employ radically different optimization schemes, unlike C++ which only employs conservative optimization. Agressive optimisation won't make friends with anything like link interfaces.

> The following statement put a grin on my face that lasted a half hour. I've
> had relationships with shorter lifetimes:
>   "There's no need for multiple warning levels in D, a "D Puzzle Book", a
> lint program, a "Bug Of The Month", or a world's leading expert on
> preprocessor token concatenation"
> 
>  The pleasure I received from reading that prompted me to write this
> message, which I intend as encouragement.

We're all glad you like it, dispite the beginning of the message.

-eye

Warren wrote:
<snip>

lol.

Neato.
Thanks for putting this together.  There is no way I'll be able to read all of the D slashdot thread.

-- 
-Anderson: http://badmama.com.au/~anderson/

You should send these answers to slashdot.  I think Warren understands that these questions are bogus.

-- 
-Anderson: http://badmama.com.au/~anderson/