"Sebastian Moleski" <s.moleski@tcu.edu> wrote in message bb8cou$2ee8$1@digitaldaemon.com
> "DRS" <drs@removethis.ihug.com.au> wrote in message news:bb8bp7$2d0u$1@digitaldaemon.com...

[...]

>> You know what?  It's 5:35am and I'm going to bed. :-)
>
> 5:35 AM? Hmm, I wonder where you are located now. It's 2:49 PM here at GMT-6. So that would place you at GMT+9, e.g. Japan, the Koreas or parts of Australia. Right?

I'm on the east coast of Australia.  *And* *I* *am* *going* *to* *bed*.

-- 

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

"DRS" <drs@removethis.ihug.com.au> wrote in message news:bb8d25$2er2$1@digitaldaemon.com...
> "Sebastian Moleski" <s.moleski@tcu.edu> wrote in message bb8cou$2ee8$1@digitaldaemon.com
> > "DRS" <drs@removethis.ihug.com.au> wrote in message news:bb8bp7$2d0u$1@digitaldaemon.com...
>
> [...]
>
> >> You know what?  It's 5:35am and I'm going to bed. :-)
> >
> > 5:35 AM? Hmm, I wonder where you are located now. It's 2:49 PM here at GMT-6. So that would place you at GMT+9, e.g. Japan, the Koreas or parts of Australia. Right?
>
> I'm on the east coast of Australia.  *And* *I* *am* *going* *to* *bed*.

Sweet dreams.

Alisdair Meredith wrote:
> [...] It would
> be nice to track down a Python guy too, as that is next langauge on my
> list-to-learn <gg>

My pleasure.  This comparison isn't as useful as others, though, since Python doesn't do a very good job as a systems language. ;)

>Garbage Collection
Yup.

>> Function overloading
Nope.

>> Function delegates
Yes.

>> Out function parameters
No.

>> Nested functions
Yes.

>> Function literals
Yes. (lambda)

>> Dynamic closures
Yes.

>> Covariant return types
Python is dynamically typed, so I suppose so. :)

>> Lightweight arrays
No?

>> Resizeable arrays
Yes.

>> Arrays of bits
No.

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

>> Associative arrays
Yes.

>> Strong typedefs
No. (doesn't make sense)

>> String switches
No switch at all.

>> Aliases
I guess so.  Classes are objects, so you can just create another reference to the class.

ie.   MyAlias = TheClass

>> Object Oriented
Yes.

>> Multiple Inheritance
Yes.

>> Interfaces
Not explicitly so.  Python looks for methods by name.  If your "interface" has a method called doThis, then any object with a doThis will do.  So... yes?

>> Operator overloading
Yes.

>> Modules
Yes.

>> Dynamic class loading
Yes. (all class loading is dynamic, technically)

>> Inner classes
I don't think so.

>> Performance
>> Inline assembler
>> Direct access to hardware
No.

>> Lightweight objects
No.

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

>> Templates
Not applicable.  They're not there, but they have no use in a dynamically typed language, since any variable can reference anything anyway.

>> Design by Contract
Through assert statements, yes.

>> Unit testing
No.

>> Static construction order
Yes.  Things are constructed the first time the module is imported.

>> Guaranteed initialization
Yes.

>> RAII
Yes.  Python currently uses reference counting to garbage collect, so object destruction is deterministic.

>> Exception handling
>> try-catch-finally blocks
Yes.

>> Thread synchronization primitives
No.  The library has a lock object, though.

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

>> Complex and Imaginary
Yes.

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

>> Macro preprocessor
No.

>> Other
>> Conditional compilation
No. (not compiled)

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

Variants.
Lexical closures.
Argument defaults.
Keyword arguments.
Variable argument lists.
Metaclasses. (classes whose instances are actually classes themselves. Amounts to creating object types on the fly)
Multiple assignment. (you can swap two variables with "x,y = y,x")
List/dictionary (associative array) literals.
Portability.
Embeddability. (unfair, because D isn't meant to be used that way)

Comments follow.

Andy Friesen wrote:
> Alisdair Meredith wrote:
> 
>> [...] It would
>> be nice to track down a Python guy too, as that is next langauge on my
>> list-to-learn <gg>
> 
> 
> My pleasure.  This comparison isn't as useful as others, though, since Python doesn't do a very good job as a systems language. ;)
> 
>  >Garbage Collection
> Yup.

Automated memory managemenr through refence counting. :)

>  >> Lightweight arrays
> No?

Standard library defines c-arrays, but i believe that's not what is meant. Walter, did you mean statically sized arrays or something else?

>  >> Interfaces
> Not explicitly so.  Python looks for methods by name.  If your "interface" has a method called doThis, then any object with a doThis will do.  So... yes?

Multiple inheritance makes interfaces irrelevant, since they are a backdoor to make an object have multiple parents in a single-inheritance typesystem.

-i.

"Alisdair Meredith" <alisdair.meredith@uk.renaultf1.com> wrote in message news:3ED7B457.9AC9B9A9@uk.renaultf1.com...
> Georg Wrede wrote:
>
> > Its position on the web pages entertains the notion of advertising. Which is OK, those pages are _supposed_ to advertise. In that case maybe the point of view shoud be that of a prospective customer.
>
> > What counts for the customer is
> > - is this genuinely in it? (I get it automatically)
> > - does this come with it? (I have to write extra words to get it)
> > - is this a 3rd party thing? (see below)
>
> The other question I ask of every advert is 'Do I trust it?'
> In order to evaluate this table, I compare the column I know well with
> my own knowledge.  I look at the dynamic array row and say to myself
> 'heck, this is the C++ standard, a required part of any conforming C++
> distribution, but this table flat out says it is not supported'  I think
> about it, and see where Walter is coming from, but it means I am looking
> for a twist on every entry.

Just because there are classes that support certain semantics, residing in standard libraries, does not mean that the language supports the feature inately. Certainly C, C++, C# and Java do not support resizable arrays, albeit that most have common/standard library features that do so.

I think Walter is quite correct here.

>
> OTOH, to simply say 'Yes C++ has dynamic arrays' clearly does dis-service to the D array.  No point in having advertising if it doesn't push your product <g>
>
> I think a standard library type option would solve a lot of the 'niggly' issues, and make it easier to take the table at face value.
>
> > You can do module stuff in C++, like Walter said. But, hey, with
> > the same amount of work you can do OO in plain C. (Really?
> > Yes, I talked with this guy who's written programs for the Mars
> > Pathfinder rovers. They did it in OO plain C.)
>
> IIRC, it was a big thing at MS that COM programming should be possible in C, and many of the early COM texts came with decent examples of how you could create a vtable using structs of function pointers.  Done this way, OO in C can be as dynamic as Python, where you can override a method for a single instance of a class if you choose <g>

Some of use still do the occasional bit of COM in C, for the reasons you cite. :)

>
> I think the comparison to modules in C++ is good too, as it certainly requires the same level of discipline and convention to turn the available language features into something non-C++ fans might recongise as a module system.
>
> --
> AlisdairM

"Alisdair Meredith" <alisdair.meredith@uk.renaultf1.com> wrote in message news:3ED79A33.AAF47CD1@uk.renaultf1.com...
> 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.

Sure, this is a good point ...

>
> 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

"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.

You're right. But namespaces do provide the biggest feature of modules.


> 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!!

I'm not sure what you mean by 'units' in D.


> > 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...]

The C preprocessor is a difficult thing to understand when you get into the details of nested macros and their arguments. I suspect most people just flail away at it until it produces what they want, and never dare change it <g>.


> > 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>

I know next to nothing about Delphi, other than it being in the Pascal camp.

"DRS" <drs@removethis.ihug.com.au> wrote in message news:bb85ot$24dv$1@digitaldaemon.com...
> > Design by Contract
> Yes (assert).

assert is a basic building block for design by contract, but design by contract is so much more. It really starts coming into its own by the addition of class invariants and the inheritance of in and out contracts. Being able to turn the whole thing on or off with a compile switch makes it nearly painless to load up your code with DbC.

I'll wager that you'll start seeing all the major languages adding in DbC.

"DRS" <drs@removethis.ihug.com.au> wrote in message news:bb86gp$25d2$1@digitaldaemon.com...
> I think Ignacio might have been trying to distinguish between true
constants
> and OP's variable constants.  :-)

variable constants? Dare I ask? <g>

"DRS" <drs@removethis.ihug.com.au> wrote in message news:bb8ci1$2dtl$1@digitaldaemon.com...
> Yes, but some of the terminology is not the same and not all of us are intimately familiar with the other languages, so there are cases where we need to be careful that we know what we're talking about.  Also, there are
a
> lot of things which Delphi can kinda-sorta do (for example, it can kinda-sorta do multiple inheritance via interfaces but it's not the same
as
> C++'s genuine multiple inheritance) or there are things which are library dependant (since every Delphi unit by default uses the System unit does
that
> mean everything in Sytem constitutes part of the language?) and so on.

That's one reason I'd have a problem including Delphi in the chart - I simply don't know enough about Delphi to make such calls in a consistent manner with the other languages. Not to say the rest is perfect, either.