Slashdot Mirror
The D Programming Language
dereferenced writes: "Walter Bright, author of the
original Zortech C++ Compiler and the free (as in beer) Digital Mars C/C++ Compiler, has posted a draft
specification for a new programming language that he describes as "a successor to C and C++". It seems to me that most of the "new" programming languages fall into one of two categories: Those from academia with radical new paradigms and those from large corporations with a focus on RAD and the web. Maybe its time for a new language born out of practical experience implementing compilers."
o Multiple inheritance is absolutely necessary. The main way it is useful is for Java-style interfaces.
o Getting rid of macros (preprocessor) is a very bad idea. What is needed is even more powerful macros (see Lisp).
o Generic programming with templates is the greatest thing about C++ -- the one feature that puts C++ above other programming languages. I'd rate generic programming capability as being a "must" of any modern programming language.
o Operator overloading is a Good Thing, in that it helps you set up a well-designed library as a "mini-language". Good programming practice involves reducing the number of keystrokes required to achieve a given result (ultimately). Generic programming, macros, and operator overloading all go in this direction. Eliminating them is a step backward.
o You say "smart pointers are irrelevant in a garbage collected language". Not true. There are many types of resources which a destructor might free besides memory. One weakness of Java vs C++ is that it is hard to control Java's "destructors".
The "best" programming language (for general-purpose "big" programming projects) I've encountered may be Ocaml. It can compile into native code as efficient as C++'s. It can also be interpreted. It is stronly typed. It supports a powerful "functional" programming idiom. It looks pretty good to me, although I haven't used it for anything "real" yet. But if you're looking for the "be-all, end-all" modern programming langauge, I think Ocaml's worth taking a look at.
Here's my 2 cents: D Sounds ok. I DO like the idea that a typedef actually creates a new type. But as a C++ programmer of 9+ years who is not "terrified" of managing his own memory, and who thinks that operator overloading and templates are cool, I have some issues with the draft standard as it stands:
1) Templates: I hope that Mr. Bright does find an answer. I agree that C++ template syntax is tough, but the power of generic programming is far too great a feature to drop for large applications!
2) Operator overloading: I like it, many people don't. Used properly you can make some very cool looking type safe code. I don't think a very powerful feature should be dropped from a language just because some people are idiots. C++ is not a toy; and neither should it's successor be.
3) Interfaces: Hello out there? The world has gone distributed. How about direct language support for CORBA interfaces? Now THAT would be a slick feature to add to an extended C++ language!
4) Standardize the name mangling! Name mangling issues are what make different C++ compilers incompatible; let's fix this oversight...
5) Garbage Collection: I'm ok with garbage collection but DO give me a way to override the collector! There will always be situations where I know I can get rid of something but the garbage collector wouldn't see it that way. DO give me a way to manually kick off a garbage collection cycle and DO give me a way to manually delete things.
6) I'm working on a million line+ surface ship combat system right now. One thing that the old Ada programmers keep screaming about is the inability to get very fine grained control over numbers; and for this application I can see why they are complaining. What's needed is a way to enforce the domain of a numeric type, ala low bound high bound with an exception thrown for invalid values. Very fine grained control over coordinate and range values is key to a large class of military applications.
I've been pondering my own new language too. Maybe I should go for it. My language would look alot like C++/D - with the items listed above - plus some other ideas that I've been pondering...
--Richard
Hmm...
Meaning that, since the garbage collector has to periodically walk all of the heap of a process, it would seem to me that it would thus periodically force any pages that are paged to disk to be brought back in by the VM even if they didn't need to be otherwise.
I used to do alot of Java programming, and I got the uncanny feeling that every time my program grew very large (which was very often - Java programs use *soooo* much memory, don't know if it's just a general tendency of GC or if it's Java's implementation) the system would thrash quite a bit more than if I wasn't running any Java programs ... and I came to believe that it might have something to do with the garbage collector forcing the OS to load every page of the process into memory as the GC swept through, so everything that modern OS's do in terms of trying to streamline VM kind of gets thrown out the window when garbage collectors are forcing every page of their process to be loaded in periodically.
Just wondering why no one has ever made the point (to my knowledge, anyway) that garbage collectors may be very bad for virtual memory performance. It seems quite likely to me, anyway.
Otherwise, I like just about every idea in the D language, especially his Name Space notion - although I didn't read too much detail of his spec, at least he's thinking about it. I hate the fact that modern languages are based on string identifiers during linking; there's no formal mechanism whatsoever of avoiding clashes in the namespace (Java's class package name idea is a small step in the right direction), and it really seems stupid to me that shared libraries should be carrying around all this string baggage, and doing all these string compares during linking ...
Anyway, that's how I see it.
Seems like every language is an excercise in How Things Should Be Done.
As a programmer that's worked with about 15 languages over 18 years what I really want is a language that:
1> Is as quick to program in as php/perl/python.
2> Is still managable for large projects.
3> Is as fast as C/C++.
4> Is easy to port across platforms(porting Quake V from Linux to Windows should just be a recompile).
5> Performs in a predictable manner(no wierd behavior out of the basic operations every language has in common).
6> Memory management should be handled automatically.
7> Integrates seemlessly over networks.
Is this too much to ask for?
"Maybe its time for a new language born out of practical experience implementing compilers."
Maybe it's time for a new language to be born out of practical experience writing software.
I don't know how it is in Linux, but I really hate having to write several hundred lines of code for a single window w/controls in Window API calls. Personally, I'd like to see MS get rid of those API calls (and don't replace it with ActiveX until ActiveX works). Between the ones that don't work as documented and the rest of them being overly cumbersome, it's just a hassle. Especially when you have to create your own encapsulation objects for those things. I like Delphi because of its encapsulation of the visual components, but their base library sucks in itself in that it doesn't expose all the functionality. And since they saw that it was so important to declare everything as PRIVATE methods, you can't get descendent object to do everything you want either because you don't have access to all the base functionality.
Simplicity shouldn't be taken to the extreme either, and gear a new language towards the non-programmer crowd like MS tries to do.
Of course MS is just making things worse right now by implementing these new Luna APIs for XP. I'm sorry, but I don't know of anybody thats been really dying for the ability to use API calls to put a gradient on a button. In my opinion, this is just MS's attempt at trying to get developers to waste time, so they don't work that hard on developing new products that may compete with MS.
From what the draft specs says, D doesn't look like a very good language. It ditches (arguably) useful features like multiple inheritance, templates, and operator overloading; and then it adds features like resizable, bounds checked arrays...in the language. In C++, there is a very nice resizable (optionally bounds checked using vector::at()) that is implemented in the Standard Library.
What D will implement in the core language is really meant for the standard library. Not everyone needs resizable and bounds checked arrays (the bounds checking is the one with the real overhead). If you are coding a kernel or something low level, the overhead isn't neccesary. If I don't need to resize my arrays, I just don't #include <vector>. Simple as that.
Also, there are no prototypes. Now, tell me, how does one get the source for a 3rd party proprietary library and read the source for the documentation? Often times, I document my code by putting a 3 or 4 line description of what the class [member|function|data type] does below its declaration in the header. If I forget what a function does, I just open the header in another frame in emacs and read its description (which has such useful information as what it uses its arguments for, what exceptions it may throw, what it returns, and whether or not it will modify an argument). It is also much easier to see what members are in a class when you can look at a simple declaration with the outline of class, instead of having to wade through 50 line members to see the next member. That just makes the class look messy, unless each function was only 1 line long.
The lack of operator overloading also makes it harder to implement something like, say, a complex number in a library. With C++, you have the standard complex type in the standard library. If there was no operator overloading, using complex would be more difficult (which is easier: complex foo, bar; foo.i = 1; bar.r = 2; foo.add(bar); OR complex foo, bar; foo.i = 1; bar.r = 2; foo += bar;).
I do see some good qualities. One is the ability to call a constuctor from a constructor. This results in less duplicated code, and makes it easier to keep two constructors of a class synced. Say you had a class with two constuctors: one that takes no arguments (default) and one that takes an int argument. The int argument one can't call the default constructor (this creates a temporary, contructs it, and then deletes the temporary). D allows you to do that. Maybe the next C++ specification will fix that.
D does seem to have a lot of flaws. It doesn't seem very useful. Maybe some people will find it useful. But it seems to me to be yet another language written for someone's personal usage. It makes sense to that person, but not to anyone else. C is a good language because its creators made it useful for other people as well as themselves, same for C++, lisp, Objective-C, and countless other languages.
HAL 7000, fewer features than the HAL 9000, but just as homicidal!
I long for a better C++ but I don't think this is it.
But maybe he will accept feedback and improve his proposal?
It's a very heartwarming idea - he's attempting to conjugate C's performance, speed, and low "levelness" with Java's "oh-my-god-did-I-just-finish-writing-that,-boy-it- only-took-me-3 minutes... but-it-runs-slow" beauty.
But if it can be done, why hasn't it been done already, hmm?
It seems this guy really dosen't like c++. Now, being that he is a compiler implementor, I can certainly understand that! *grin*
Templates and stack instantiation of of objects with semantics [i.e. constructors/destructors] is a royal pain in the a** for compiler writers. In fact, only somewhat more recently is g++ even able to handle templates in a decent way; it took a long time to get it right. C++ was a very ambitious language, hard as hell to implement, but that's what makes it so usefull. Give up templates and multiple inheirantance? He suggests this is a good thing?! D is clearly not a language innovation, he should have called it C--.
Besides, you don't actually have to use such features extensively [or at all, really] in a C++ program. You could always avoid iostream and just #include old stdio.h, for example, only choosing to use classes with constructors for some usefull/neccessariy/labor-saving part of the code, while all the rest of it is essentially no different then C [aside from stricter compile-time type checking, which ANSI C has been moving towards anyway, lately]
This is no innovation.
A few other random points:
Ohh! Garbage collection, you can link to a garbage collecting malloc in a C++ program anyway. [If you really care to look into it, C++ allows a whole range of complex underlying storage classes for custom memory management of different parts of a project.]
Arrays are not first class objects?!
Well, this is true, sort of. But you can choose to use vectors, [or other more efficient representations [such as maps, etc] depending on your data type, and with inlining, they will be as efficient as if they were 'native language syntax' features. You don't even have to use the STL, you can write a custom implementation of dynamicly resizable vectors of your own [with automatic bounds checking and resizing, for example] quite trivially. I did it once, and it took, what, 2 pages of source. That's the power of C++, it's so expressive for implementing custom manipulations of low level data, packaged nicely into classes.
No on stack variables? All data as dynamic references?
Yech. Generally too inefficient. I still suspect that he just dosen't want to tackle the hairness of writing such a complex compiler. Remember, you can use only dynamic memory in C++ easily enough, with garbage collection too.
Overall, I think D is too lenient. I give him an F.
Still, I strongly respect the desire to attempt to implement a novel language. Not that there aren't hundreds out there, but it's a noble effort. Still, publishing without even demo code? Yeesh.
---
the pen is mightier than the sword, the sword is mightier than the court, the court is mightier than the pen.
D == (C++)++
Because:
you take all the backward compatibility junk out.
but retain the old libs and development model.
D == (Java)--
Because:
Java also removed all the compatibility junk.
Java, like D, also added GC as a major development booster.
Java added advanced programming paradigms, extensive standard API and bytecode, and D didn't.
D == C#
Because:
D is Yet Another C++ Successor.
it was developed by another i-want-a-better-c++ that didn't like Java.
it didn't introduce any innovations over existing languages
Besides, the name "D" is completely unoriginal (just like language concept itself). Dozens of next-worldwide-languages-wannabes had that name.
-Omer
If, on the other hand, all he wants to do is sell compilers, and therefore he needs to convince the rest of the world of the language's benefit, then fooey.
And for the record, damn, I feel old -- I remember trying to make the Zortech compiler work for an old project of mine circa maybe 1989 or so(?) and having problems. I think at one point or another I might have actually gotten email from Walter. Wow, names from the past. In a conference call yesterday I needed to come up with a secure hashing algorithm and I said "ROT13. If we need extra security we can do it twice." and absolutely no one got it.
Anyway, back on topic: No templates? Oooooo, I have a C++ friend who is gonna be pissed....
duane
"In C++, you can look at your friend's privates."
www.HearMySoulSpeak.com
Well, I like Forth - I used it for years. It has _many_ good qualities; readability is unfortunately not one of them. You can write readable Forth, but you have to really work at it, and it's still a pain to understand something you wrote months previously. Understanding someone elses code is even worse (especially once people start doing nifty things to the return stack :-P)
/Janne
Trust the Computer. The Computer is your friend.
He's making a more important point, and it's not the wrong way around - he says the specs for C or C++, for example, are so big that the compilers that implement those specs will contain bugs. And the programmers will have problems writing code that's bug free and uses the best features of the language. If he can find the right set of features to include in "D" then it'll be easier to learn, easier to write code in, and very importantly, easier to produce compilers for.
"we demand rigidly defined areas of doubt and uncertainty!"
I love the way there's a reserved word "imaginary" heh...
He doesn't have any post-code gen optimization? I know you can perform elementary optimization onthe intermediate rep, (such as folding, etc), but he'll really need another phase if he wants to optimize for pipelines, which will vary from architecture to architecture? Tut tut. Maybe it's just an omission on his part.
Why aren't new languages based on Forth ? Forth is very fast, because you can work at very low level with it. Forth applications can be portable, while staying extremely optimized. Forth can be easily extended to fit any sort of application, and you can have the feeling of a very high level language, while keeping the control of things that needs special optimizations.
{{.sig}}