D Programming Language

jove

Member
Hello,

Is Apple or Metro planning on creating D compilers? I have read incomplete tidbits on D here and there. Some of the articles are so Visual C++ oriented that they made incorrect comparisons to C++. Anyways, these are some of my thoughts and questions.

There seems to be some great ideas.

1) No need for forward declarations.

2) Contracts - validation code segments that can be attached to methods and objects.

3) In, Out designation on parameters. This denotes intention much better than const, references and pointers.

4) Garbage collection, YES!

5) Structures with properties. myObject.size and myArray.upperBound

6) Elimination of -> operand. The compiler is smart enough to know if something is a pointer or not. There are no stack objects as well. If D provides enough facilities for interface propagation, then I won’t be upset that the overridable -> operator is gone.

Items that have me concerned

1) No header files. C++ didn't do it very well but there is a need to specify a public interface to a class in a separate file for distribution. C++ has the overhead of bridge classes.

2) No preprocessor. Macros as functions are bad. Macros as constants are bad. Macros as well documented text placements are handy to reduce maintenance. Macros to eliminate code from being complied and linked in are necessary (cross-platform code, demo mode...). Does D have a counterpart?

3) No multiple inheritance. There is a time for has-a relationships, a time for is-a relationships. The best design may have a single class adopting multiple interfaces. And an interface may have to have some logic (besides prototyping) attached to it. Is there multiple abstract inheritance? Is there interface delegation?

4) Does it have default parameters?

5) No stack based objects - everything heap. Stack based objects are handy to quickly save/alter/restore states. Heap objects seem like a lot of overhead for that purpose.

6) Does it have templates or overridable class methods?

7) The parameter list is not part of the function signature. You can no longer create two methods with the same name within a class. I understand the argument that this isn’t necessary (but creates more maintainable code). Unfortunately this eliminates the possibility for templated methods.

If anybody has any thoughts or clarification, that would be great.
 
Two things I hate about C and that I want TOTALY killed forever

POINTERS and BITWISE operations... die damn it die :p


sounds ok, preprocessing I dont care about. As for the #include...that can be a mixed blessing. I would prefer something central where you would have an API or header files, like java does :)


Admiral
 
Hello,

Admiral you would be pleased to hear the one of D's intentions is to eliminate the necessity of pointers for high level uses (i.e. object references and arrays) but pointer support is needed for good ol' low level programming that just needs to get done at times.

But bitwise operations are fun :)

The three problems I see with a single implemenation file is, no "table of contents" for interfaces, insanely large files, and the idea of distributing only the protypes of public methods requires a seperate header file.

At my so-called place of work one of the teams develops with, what is affectionatley called, "Macro C". That kind of abuse is the reason my their is an urge to eliminate the preprocessor.
 
Originally posted by AdmiralAK
Two things I hate about C and that I want TOTALY killed forever

POINTERS and BITWISE operations... die damn it die :p

Bitwise operations have nothing to do with C; they're in Java too. Ditto with pointers. ??
 
tie,

I think Admiral was just explaining his general fustration with those two easily abused programming constructs.

---*--p>>8;

is a valid line of C code.

And Java has garbage collection which means "pointers" can be more intellegent for high level objects.
 
I dont recal having to deal with bitwise ops in java, anyway---keep them but kill the pointers...die die die :p

THe above line is indeed confusing but I guess its called job security :p
 
Disclaimer: When it comes to programming languages, the arguments often are rather subjective. So let's not start a flame war here but always remember it's more _opinions_ than _facts_.



3) In, Out designation on parameters. This denotes intention much better than const, references and pointers.

Does 'out' imply 'in' or is there a special 'inout' keyword?



4) Garbage collection, YES!

That depends on the application you develop. When it comes to a GUI application it can be very handy. And since the user is not as fast as the CPU, there's plenty of time for the garbage collector to clean up. In case of batch-like applications it's not that handy though, since it's not guaranteed that the garbage collecter ever has time to do something, since the batch job is running and running... Also, for real-time applications garbage collectors are no fun... ok so you can usually turn them off for a while, but..


1) No header files. C++ didn't do it very well but there is a need to specify a public interface to a class in a separate file for distribution. C++ has the overhead of bridge classes.

Java also doesn't have header files. The way to do it there is to run the source thru 'javah' (I think) which creates an up-to-date documentation whenever you want.


3) No multiple inheritance. There is a time for has-a relationships, a time for is-a relationships. The best design may have a single class adopting multiple interfaces. And an interface may have to have some logic (besides prototyping) attached to it. Is there multiple abstract inheritance? Is there interface delegation?

I wish D would use the concept of interfaces (Java) or protocols (ObjC). Technically they're also multiple inheritance but it's a clean way to do it.


4) Does it have default parameters?

Always hated default values in C++. If the last 2 parameters have a default value but you only want to make use of the 2nd last one, you still have to specify both of them. A way to handle this would be to allow to skip an argument (ie myFunction("Huhu", , 42) but it's not that readable IMO. A nicer way it to be able to reference arguments by their name. (ie myFunction(Name => "Huhu", Age => 42)) I've noticed that people use default parameters way too often. In many cases it's not clear at all what the default value is. (ie assuming age is 42 if it's not specified is just dumb)


6) Does it have templates or overridable class methods?

I wish it had an object-class instead of templates. ;)


7) The parameter list is not part of the function signature. You can no longer create two methods with the same name within a class. I understand the argument that this isn’t necessary (but creates more maintainable code). Unfortunately this eliminates the possibility for templated methods.

I like the fact that it's not possible to create two methods with the same name but with different arguments. (like also in ObjC or in SmallTalk) You don't have to guess whether the method with 'char' or the one with 'long' is called when you give it an 'int'.

Sargon
 
Originally posted by AdmiralAK
I dont recal having to deal with bitwise ops in java, anyway---keep them but kill the pointers...die die die :p

THe above line is indeed confusing but I guess its called job security :p

LOL, pointers are great.
 
Originally posted by Sargon

4) Garbage collection, YES!

That depends on the application you develop. When it comes to a GUI application it can be very handy. And since the user is not as fast as the CPU, there's plenty of time for the garbage collector to clean up. In case of batch-like applications it's not that handy though, since it's not guaranteed that the garbage collecter ever has time to do something, since the batch job is running and running... Also, for real-time applications garbage collectors are no fun... ok so you can usually turn them off for a while, but..

Have you ever used VisualStudio.NET?
It's garbage collection is horrible. Applications will stop in the middle of execution and do garbage collection.
<i>BeginEdit</i>
Of course it might just be because it's a Microshaft product, but who knows...
<i>EndEdit</i>

If D will do it better than Java or C# then I'm all for it, but if it's going to be as slow as Java or C#, then keep it out!
 
Hello,

I am much informed now, I read the specs at Digital Mars. The language looks amazing. Nearly every hack or work around I have had to do, there is an elegant language construct. If you are a serious C++ programmer you really have to check it out.

To answer my questions and those proposed by Sargon

There is an inout specification. Just like the const &'s it is illegal to modify an input parameter.

devonferns specified a behavior thats in D as well, the creater of D admits to it. There are facilities to control the garbage collector, so a programmer should be able to optimize the cleanup.

D does have interfaces like Java. I am not convinced that interfaces are always an appropriate replacement for multiple inheritence. But I digress.

D will have templates, not implemented yet. In order to have templated functions D will have to support some fashion of functions with the same name. Just like multiple-inheritance vs interfaces, there is a time and a place for templates and class-objects.

If this language ever takes off, it can truly be an evolutionary step above what is developed today.
 
Sweet. As long as you can control when the garbage collection happens and can make sure it doesn't make the program unresponsive for a second or two, then it sounds good.
 
Back
Top