I originally sent this to Walter privately, but he suggested I post here so we can get more involved in any discussion <g>

Following up some recent debate in the Borland Delphi newsgroups about this page [http://www.digitalmars.com/d/index.html] I would like to query a couple of items in the list.  (I expect you will get a message or two with Delphi's capabilities shortly <g>)

i/ Huge play is made on the versatility of array type, which seems somewhat unfair to languages that explictly support the listed behaviour in their STANDARD libraries that are expected as part of a conforming implementation.

Specifically, C++ does not have 'resizable arrays' as a langauge feature because they are in the standard library, std::vector.  There is no likelihood any proposal to add such a feature to the language would ever pass committee because it is already required to be present (in the library) in any conforming C++ implementation.

While I can understand your desire to show your own product in the best possible light, I would like to at least see a 3rd option between 'yes' and 'no' for features implemented in the standard library of other languages (rather than 3rd party libraries, no matter how common)

Suggest a 'LIB' cell coloured yellow.

[otherwise such clear bias on something I do know well will give me doubts about other items I am less clear on, see below]


Under OOP you say C++ has module support.  News to me, this is one of the most requested extensions to the library and I still don't know anyone with a clear idea how to approach it!  I suggest you change this to 'No'

Also, Covariant return types is duplicated in OOP and functions sections, is that intentional?


Under reliablility I am very surprised that only 'D' rates as unit testable.  I would at least like a link to some material explaining why only 'D' qualifies here.  A good opportunity for a sales pitch if ever I saw one, this is the detail that caught my attention most!!  [Although I don't use Java, I was surprised that its extensive reflection API and unit-testing community did not qualify]


Again, a footnote explaining why C++ does not support all 'C' types would be useful.  Do you mean C99 here, or are there even more obvious cases I am missing?


I would be happy to see 'struct member alignment control' dropped from C++ (and presumably C) as this relies on common compiler extensions, rather than true features of the language itself.  If we are going to permit extensions, there are several popular C++ variants supporting delegates, but I would not suggest you add that to the list either <g> Rather, be stricter and say 'no' to struct layout control.


Last but not least, it would be really nice to turn the logic on the Macro Preprocessor.  The presence of this mis-feature is the cause of endless annoyance to C++, and its lack is certainly another score for 'D'.


Oh, and as a cheeky new feature you might want to add 'reference implementation available' given that I am not yet aware of a conforming C++ implementation [although EDG-based solutions are getting very close now]


Interesting chart though.  If you can find the people to contribute I would be interested in seeing how Eiffel, Python, Smalltalk and Haskell score as well.

-- 
AlisdairM

"Alisdair Meredith" <alisdair.meredith@uk.renaultf1.com> wrote in message news:3ED71CC3.F205F89F@uk.renaultf1.com...
> i/ Huge play is made on the versatility of array type, which seems
> somewhat unfair to languages that explictly support the listed behaviour
> in their STANDARD libraries that are expected as part of a conforming
> implementation.
> Specifically, C++ does not have 'resizable arrays' as a langauge
> feature because they are in the standard library, std::vector.  There is
> no likelihood any proposal to add such a feature to the language would
> ever pass committee because it is already required to be present (in the
> library) in any conforming C++ implementation.

The idea is that one can do anything with an add-on library with enough effort, so to compare the languages, library add-ons were excluded. Java strings are explicitly handled by the compiler, as operations involving string literals are translated by the compiler into calls to Java.lang.string.


> While I can understand your desire to show your own product in the best
> possible light, I would like to at least see a 3rd option between 'yes'
> and 'no' for features implemented in the standard library of other
> languages (rather than 3rd party libraries, no matter how common)
> Suggest a 'LIB' cell coloured yellow.
> [otherwise such clear bias on something I do know well will give me
> doubts about other items I am less clear on, see below]

That's a good thought.

> Under OOP you say C++ has module support.  News to me, this is one of the most requested extensions to the library and I still don't know anyone with a clear idea how to approach it!  I suggest you change this to 'No'

The namespace feature of C++ coupled with separate compilation duplicates enough of the features of modules I decided to give it the nod.

> Also, Covariant return types is duplicated in OOP and functions sections, is that intentional?

No, it's a bug.

> Under reliablility I am very surprised that only 'D' rates as unit testable.  I would at least like a link to some material explaining why only 'D' qualifies here.  A good opportunity for a sales pitch if ever I saw one, this is the detail that caught my attention most!!  [Although I don't use Java, I was surprised that its extensive reflection API and unit-testing community did not qualify]

It's done in Java with add-on libraries. It is not part of the language.

> Again, a footnote explaining why C++ does not support all 'C' types would be useful.  Do you mean C99 here, or are there even more obvious cases I am missing?

I mean C99 types.


> I would be happy to see 'struct member alignment control' dropped from C++ (and presumably C) as this relies on common compiler extensions, rather than true features of the language itself.  If we are going to permit extensions, there are several popular C++ variants supporting delegates, but I would not suggest you add that to the list either <g> Rather, be stricter and say 'no' to struct layout control.

You're right.

> Last but not least, it would be really nice to turn the logic on the Macro Preprocessor.  The presence of this mis-feature is the cause of endless annoyance to C++, and its lack is certainly another score for 'D'.

It is a feature - there will always be some clever thing you can do with a preprocessor that you can't do otherwise.

> Oh, and as a cheeky new feature you might want to add 'reference implementation available' given that I am not yet aware of a conforming C++ implementation [although EDG-based solutions are getting very close now]

DMD is not a perfect implementation of D, either <g>.


> Interesting chart though.  If you can find the people to contribute I would be interested in seeing how Eiffel, Python, Smalltalk and Haskell score as well.

My problem is I don't know those languages well enough to write a fair comparison. Also, the chart is designed to compare D with the languages it replaces as well as the pretenders to the throne as replacements <g>.

> > feature because they are in the standard library, std::vector.  There is no likelihood any proposal to add such a feature to the language would ever pass committee because it is already required to be present (in the library) in any conforming C++ implementation.
>
> The idea is that one can do anything with an add-on library with enough effort, so to compare the languages, library add-ons were excluded. Java

I may be wrong, but I'd say, libraries and standard libraries
are fundamentally different things in this context. (And nowadays,
with extensible languages coming along, the language vs. stdlib
thing is going to be even less clear-cut.)

Cheers,
Sz.

Luna Kid wrote:

> I may be wrong, but I'd say, libraries and standard libraries
> are fundamentally different things in this context. (And nowadays,
> with extensible languages coming along, the language vs. stdlib
> thing is going to be even less clear-cut.)

Especially when design goals of some languages (notably C++) are NOT to provide features in the syntax if they can be provided by a library, but to instead make sure said library is part of the standard.  C++ does have associative containers and dynamic arrays 'out-the-box', but they will never be native syntax.  I think it would do no harm for the chart to reflect this.

The langauge/library barrier is even more blurred as you get to some low-level library classes.  Most exception-supporting languages require certain library execptions to be thrown when language-construct fail (in C++, bad_alloc, bad_typeid, bad_dog...)  Java would be lost without the Object class, etc.  This blurring is a deliberate policy of the language designers.

As to which libraries to include?  In C/C++ it appears simple as there is a clear ISO standard.  Where do you draw the line with Java packages though, and the .NET framework for C#?  I still think libraries should be considered, but we need to be clear which libraries are indeed 'standard' for each language.

-- 
AlisdairM

"Luna Kid" <lunakid@neuropolis.org> wrote in message news:bb83p8$21ch$1@digitaldaemon.com...
> > > feature because they are in the standard library, std::vector.  There
is
> > > no likelihood any proposal to add such a feature to the language would ever pass committee because it is already required to be present (in
the
> > > library) in any conforming C++ implementation.
> > The idea is that one can do anything with an add-on library with enough effort, so to compare the languages, library add-ons were excluded. Java
> I may be wrong, but I'd say, libraries and standard libraries
> are fundamentally different things in this context. (And nowadays,
> with extensible languages coming along, the language vs. stdlib
> thing is going to be even less clear-cut.)

Sure. There are a lot of different ways to look at the issue. I personally look at something in the compiler vs something in the library as fundamentally different. Perhaps because I'm a compiler writer <g>.

Even with language features, there is plenty of room for argument. For example, I've gotten a lot of email arguing that C++ does not have modules. I view C++ namespaces combined with separate compilation as addressing that issue (however badly), hence I gave it a 'yes' for modules.

"Alisdair Meredith" <alisdair.meredith@uk.renaultf1.com> wrote in message 3ED71CC3.F205F89F@uk.renaultf1.com

[...]

> Following up some recent debate in the Borland Delphi newsgroups about this page [http://www.digitalmars.com/d/index.html] I would like to query a couple of items in the list.  (I expect you will get a message or two with Delphi's capabilities shortly <g>)

Note: Delphi in Borland's parlance means both the language and the package which includes the compiler, RAD IDE, standard libraries (VCL for Win32, CLX for cross-platform), and sundry other bits.  For that reason I shall refer to the language by the older name of Object Pascal.

As best I can make out, this is the current consensus over at borland.public.delphi.non-technical:

> Garbage Collection

No (and we like it that way!).

> Function delegates
> Function overloading
> Out function parameters
> Nested functions

Yes

> Function literals

No.

> Dynamic closures

No?

> Covariant return types

No.

> Lightweight arrays
> Resizeable arrays

Yes.

> Arrays of bits

No.

> Built-in strings
> Array slicing
> Array bounds checking

Yes.

> Associative arrays

No.

> Strong typedefs

Yes.

> String switches

No.

> Aliases
> Object Oriented

Yes.

> Multiple Inheritance

No.

> Interfaces

Yes.

> Operator overloading

Yes (custom variants).

> Modules

Yes.

> Dynamic class loading

Yes (via RegisterClass).

> Inner classes

No.

> Performance
> Inline assembler
> Direct access to hardware

Yes.

> Lightweight objects

Yes (deprecated).

> Explicit memory allocation control
> Independent of VM
> Direct native code gen

Yes.

> Templates

No.

> Design by Contract

Yes (assert).

> Unit testing

No.

> Static construction order

Yes (modules only).

> Guaranteed initialization

Yes (consts only).

> RAII

No.

> Exception handling
> try-catch-finally blocks

Yes.

> Thread synchronization primitives

No?

> Algol-style syntax
> Enumerated types
> Support all C types
> Long double floating point

Yes.

> Complex and Imaginary

No.

> Direct access to C
> Use existing debuggers
> Struct member alignment control
> Generates standard object files

Yes.

> Macro preprocessor

No.

> Other
> Conditional compilation

Yes.

> And what are other stuff that you can add to this list that is found in OP
and
> not in D?

Set types
Variant records
True constants
Default parameters
Open array parameters
Reintroduce
Dynamic
Return value as variable vs. return
Run-Time Type Information (RTTI) operators
Ur-types
Packages

This stuff you probably wouldn't accept without referring to libraries, but Delphi was practically designed around them:

Native UI librar(y/ies)
Interactive UI design
Native DB librar(y/ies)

We're still arguing about some of the definitions. :-)

-- 

 A: Top-posters.
 Q: What is the most annoying thing on Usenet?

"Alisdair Meredith" <alisdair.meredith@uk.renaultf1.com> wrote in message 3ED79A33.AAF47CD1@uk.renaultf1.com

[...]

> Especially when design goals of some languages (notably C++) are NOT to provide features in the syntax if they can be provided by a library, but to instead make sure said library is part of the standard.  C++ does have associative containers and dynamic arrays 'out-the-box', but they will never be native syntax.  I think it would do no harm for the chart to reflect this.

By that criteria Object Pascal would probably get a few extra ticks.

-- 

 A: Top-posters.
 Q: What is the most annoying thing on Usenet?

Walter wrote:

> The namespace feature of C++ coupled with separate compilation duplicates enough of the features of modules I decided to give it the nod.

But namespaces can be reopened at any time, and pre-compiled libraries are very fragile in the face of the preprocessor.  Header files are continually reparsed.  I am a bona-fide member of the C++ fan club, but feel more than uncomfortable saying C++ has 'units'.

I guess that if 'D' relies on the same justification, I want to drop units for 'D' as well.  I'm hoping you can find a neater solution though, that would really give D a push!!

> It is a feature - there will always be some clever thing you can do with a preprocessor that you can't do otherwise.

Yes, but I'm still prejudiced <g>
[Boost actually have quite a powerful pre-processor library that can do
some amazing things, including confusing the heck out of me!  PP
programming is a black art, and even with Boost it remains a murky
grey...]


> My problem is I don't know those languages well enough to write a fair comparison. Also, the chart is designed to compare D with the languages it replaces as well as the pretenders to the throne as replacements <g>.

Fair enough, but would be quite nice to have a parallel table covering the less C-like languages if we can find contributors.  I expect you will be hearing from some vocal Delphi supporters shortly <g>  It would be nice to track down a Python guy too, as that is next langauge on my list-to-learn <gg>

-- 
AlisdairM

"DRS" <drs@removethis.ihug.com.au> wrote in message news:bb85ot$24dv$1@digitaldaemon.com...
> Variant records
That's a union in C.

> True constants
I didn't understand then nor do I understand what you are referring to here.

sm

"Alisdair Meredith" <alisdair.meredith@uk.renaultf1.com> wrote in message news:3ED79C54.380633B@uk.renaultf1.com...
> Walter wrote:
>
> > The namespace feature of C++ coupled with separate compilation
duplicates
> > enough of the features of modules I decided to give it the nod.
>
> But namespaces can be reopened at any time, and pre-compiled libraries are very fragile in the face of the preprocessor.  Header files are continually reparsed.  I am a bona-fide member of the C++ fan club, but feel more than uncomfortable saying C++ has 'units'.
>
> I guess that if 'D' relies on the same justification, I want to drop units for 'D' as well.  I'm hoping you can find a neater solution though, that would really give D a push!!
It doesn't. D has real modules not unsimilar to Java packages or C# assemblies.

sm