The D Programming Language 530
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."
A critique (and take a look at Ocaml) (Score:3, Interesting)
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.
Sounds Ok but needs Interfaces... (Score:2, Interesting)
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
Re:A critique (and take a look at Ocaml) (Score:2, Interesting)
Sure, and such surveys as have been done have repeatedly shown that your typical programmer will average roughly the same number of lines of code in a given period of time (about 20 per day, usually). Thus, the more power there is in each of those lines, the better.
It should be. If it's not pretty much immediately obvious what a + operator means in a given context, then it's clearly a bad use of operator overloading. (Granted, it does get widely abused. So does inheritance. That's not to say these things can't be very useful when used properly.)
What many people ignore is that operator overloading, like the option to use value or reference semantics, is important to allowing user-defined types to function just like built-in ones. C++ is one of the few languages that (almost) achieves this. As a result, you can do things like writing nice generic algorithms using templates, which is still a much under-rated but incredibly powerful feature.
For example, in C++, I can write a "sum" algorithm that iterates over an array of values, and +s them all. On ints, you get the sum of the values. On complex numbers, with a suitably overloaded operator+, you also get the sum of the values. On strings, if I've defined + to mean "concatenate" (which even those langauges claiming operator overloading is bad actually do) then I get the concatenation of several strings. All of this makes sense and is nicely consistent. It's just that in C++, it's fully controllable, whereas in Java, you're stuck with + meaning concatenate with a String, whether you like it or not.
Syntax Erros in Example? (Score:1, Interesting)
Hmm...
Garbage Collection vs. Virtual Memory (Score:3, Interesting)
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.
Languages should be written for programmers (Score:2, Interesting)
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? (Score:3, Interesting)
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.
Useful? Not Really. (Score:3, Interesting)
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.
Needs work (Score:2, Interesting)
I long for a better C++ but I don't think this is it.
But maybe he will accept feedback and improve his proposal?
Convince me (Score:2, Interesting)
But if it can be done, why hasn't it been done already, hmm?
Re:Convince me (Score:2, Interesting)
I don't see a pure Java machine as practical since on the web Java is typically used in conjunction with other languages (HTML, XML etc). This would leave such a machine to go the way of the pure LISP machine. It would be a novel concept, especially in academia, but not necessarily practical in the real (read: business) world.
However, having an embedded JVM that worked at the hardware level and could easily be worked in with current hardware (think math coprocessor on old [3|4]86DX machines) might be something a little more practical. However, since I am a programmer, I could very well be talking out of my ass, so take this post worth a grain of salt.
cheers
templates and operator overloading are good things (Score:5, Interesting)
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.
Languages comparison (Score:2, Interesting)
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
Sounds like... (Score:5, Interesting)
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."
Re:Forth !!!! (Score:2, Interesting)
/Janne
Re:practical experience implementing compilers?? (Score:2, Interesting)
weirdness (Score:3, Interesting)
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.
Forth !!!! (Score:2, Interesting)