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.
I'd be interested to see a *true* benchmark
I've done that - kinda. Wrote several mickey-mouse comparisons (moving memory, calculating pi, etc), in C, C-machine-translated-to-Java and in regular Java.
The biggest problem was that, for the tasks we were interested in (memory-management, for example) C and Java do it so differently there is no easy way to compare. (Java's habit of creating multiple references to single objects instead of multiple copies of the same object really helps it here).
In general, Java was 3-4 times slower than C on string manipulation with built-in classes/library functions, but was damn-near identical on heavy maths (Java dropped ~1 second for every 30 secs of calculations.)
(Visual C++ 6 compiler against Sun's latest JRE for Windows NT. These timings were only ever meant to be rule-of-thumb.)
And calling it Fifth fits more so than Further- Forth comes from the word "Fourth," as in the cardinal number. The mythology goes, the filesystem where Forth was first implemented couldn't handle a filename as long as Fourth. ;) Hence, forth.
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
Have you ever tried Visual Basic? I know it gets a bad rap sometimes, because it is VERY forgiving. It is extremely easy to write very crappy code that still works.
.NET runtime is about: moving away from Win32. What is easier for using sockets to listed on Port 80? Fooling with the separate WinSock2 API, or doing "Dim mySocket as New System.Sockets.TcpListener(80)" ?
.NET is a very large umbrella. But what it is bringing to the programming side of things is very impressive indeed. An entirely new programming paradigm where everything you ever wanted to do is neatly arranged within the various Class libraries. I know that in and of itself isn't new, but having that kind of support on the OS level IS new.
However, for those who bother to do the job right, VB can be a very powerful tool, used to create shipping application. (As I personally have done.)
With VB, you don't care about all the "stuff" underneath (which can be a problem when you try to do something that isn't built-in, but there are creative solutions). You just drag controls onto your window, and write the code behind them. Very easy.
VisualStudio.NET is bringing this in two different directions: First, VB gets full access to everything, and is no longer the "bastard" child of the VS family. Secondly, the other VisualStudio languages get a new Forms system similar to VB's -- just drag controls onto the Window, set properties, then write the code to handle the events. Easy and clean.
That's really what the entire
This message sometimes gets lost because
Microsoft has already stated that when the Win9x code line is pretty much dead, and everyone is writing to the CLR instead of Win32, they are going to make a move to port the CLR to the WinNT Executive (that is NT's native kernel API). Win32 will finally be relegated to "legacy" tech just like DOS interrupts and Win16.
Natural != (nontoxic || beneficial)
While I think you have some valid points, you are far too eager to suckle at Microsoft's teat and call the watered down skim soya milk it gives 10% m.f. homogenized.
I too like VB (quit staring at me like that!), and I agree with you that poor programmers give VB a bad man, but I big to differ on the idea that VB somehow protected you from Microsoft's shifting API's. You've read the reviews for VB.Net? Everyone VB programmer out there is screaming blue murder because the object model in VB has so radically changed that it requires re-learning VB. Yes, I said re-learning VB. MFC has changed their official "ways to do things" with each major release that it's necessary to re-learn MFC every major release. Sure, MS can provide some insulation from their API's, but even their insulation can't protect you from the pointy spikes that poke through everytime MS changes its architecture.
One other thing:
As an embittered and disgruntled fan of NextStep, I vehemently disagree with your opinion. :-) You want a seriously kick-ass distributed networking object-based API? Try NextStep's Distributed Objects. Can you say, "Sweeeeeeet!"
Other than that, I think you made some good points for people to think about.
The bitter lessons of a veteran coder: http://bitterprogrammer.blogspot.com
It's unfair to compare a Java UI directly with a native UI.
Why? Users don't care about wether your application has a slow user interface, all they'll do is complain that "This program is slow"
Java has a place, and by extension Java UI's have their place. But saying "Oh well it's O.K for the user interface to be slow, because it will run equally slow across all platforms" is a load of rubbish. If Java code can run just as fast as native compiled C or C++, just why are the Java User Interfaces slow?
Any Java zealots want to clear up the aparent contradiction there?
Syllable : It's an Operating System
There used to be a guy called Stewart something on Fidonet programming board, who would argue that ASM was the most portable of any language, and he could cross-compile his project (with millions of lines of code) onto any new CPU. It was great fun
Many of the features look pretty sensisble. There is now pretty unanimous support for dropping Multiple inheritance. The problem with multiple inheritance being that it leads to programs only the original authors understand.
It is disapointing that the syntax was not changed more radically. I for one am pretty bored with typing semicolons at the end of lines. Using braces for block structure is equally tedious.
The garbage collector is of the 'stop everything and collect' type, this is not a good scheme as anyone who has seen a PET running Microsoft Basic GC will agree. The incremental GC in .NET is a better scheme, even if it is slower overall. But that is an implementation detail.
It would be good if people would start to look at adding support for parallel program execution. The threads programming model is very clunky and hard to use, in part because there is no means for the program to perform checks on access conflicts.
Also a persistence model should be part of any new language. The current division between programming language and database is a lot of wasted overhead.
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/
I'm afraid I have to disagree. I'm a pretty strong Java advocate, but I still don't feel that it's ready for desktop use because of Swing performance issues. I spoke with several of the engineers that worked on JBuilder while I was at JavaOne this year. They spent a *LOT* of time writing custom classloaders, etc. to make their GUI so snappy. JBuilder is a spectacular example of a well written Java GUI, but I don't know if it would be reasonable to say that just anybody could write something like it in 1/10 the time of some other language.
Now on the server...that's a totally different story. I write server apps all day in Java --- my development times are SLASHED from what they would be in C/C++, or even CGI's. Maintenance and documentation are a breeze, and performance is fabulous. Java really has done great things on the server.
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.
If you get different answers on different computers due to different roundoff errors, your software becomes unreliable. It's true!
People get confused by Intel's 80-bit FP arithmetic. Yes, the FPU expends some effort in rounding the 80-bit result back to 64 bits, but the result is not more accurate than a 64-bit FPU. In fact the answers will be exactly the same--this is mandated by the standard.
Anyone using floating-point arithmetic for anything serious needs to know exactly what the arithmetic model is. If Walter pursues this philosophy with his new language, he will make it unusable for numerical applications.
Walter needs to read:
David Goldberg, "What Every Computer Scientist Needs To Know About Floating Point Arithmetic," ACM Computing Surveys, vol. 23, pp. 5-48, 1991.
I could not find a copy online, but here is an interview with William Kahan, the Turing award winner who co-developed the IEEE 754 floating-point standard. Language designers should notice that Kahan implicates of Java and Fortran at the end of the article.
First their was BCPL, then B, then C. Logically the next language in this family would be P.
from the overview page...
features to keep:All except the last is contained in Java.
features to drop:This seems to be precisely the parts of C++ that Java also does away with. Furthermore, the C preprocessor is not strictly part of the C language and in fact many other programming projects use cpp for simple cut and paste includes of their favorite language. When I first read about trigraphs, I couldn't wait to try them out to make some extra obfuscated code, but alas the C compiler I was using didn't support them. In fact the lack of standards compliance is one of the main drawbacks to programming in C++ and C. If my Java code compiles on sun's compiler, then I can be assured that it will also compile on any other compiler claiming to compile Java code.
The author also mentions that D will not have any bytecodes. From a strict perspective, the Java programming language and the Java VM are two different standards and just because you typically compile Java code into (confusingly named) Java byte codes, doesn't mean you can't use one without the other. For example, anyone (who is insane) can pick up a copy of the Java Virtual Machine Specification and a hex editor and make some syntactiacally correct class files. More realistically though, java bytecodes are often targets for compiler construction classes. Also, if you use the GNU Java Compiler you can compile programs written in the Java programming language directly into machine code.
While 90% of the description of this language screams Java, there seem to be some of the more useful features of C++ thrown in (typedefs, scope operator, etc.). The only way for this to be successful, is to finish standardizing the language as soon as possible and get a reference compiler for it so it leaves the realm of theoretical vaporware. Perhaps Java might have looked more like this if the language design was revisited. However, Java has lots compilers which are much much more likely to conform to the standard than the C++ equivalents.
From the dictionary:
1. "#", ASCII code 35.
Common names: number sign; pound; pound sign; hash; sharp; crunch; hex; mesh; grid; crosshatch; octothorpe; flash; square; pig-pen; tictactoe; scratchmark; thud; thump; splat.
Personally, I like "C-octothorpe"
- JoeShmoe
-- I wonder which will go down in history as the bigger failure: the War on Drugs or the War on Filesharing
I've got an idea... let's hybridize a postfix language like Forth and natural language processing. We can call the new programming language "Yoda." Here's some sample code:
Variable x to 10 be setting.
1 to x you add.
This times 10 you be repeating.
"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.
"Declaration" is an overloaded term in this context.
.class files in the CLASSPATH and poking around in them, and presumably the byte compiled files. So you don't need access to source code to use a class. If you wanted to do something like this in C++, you couldn't, because the necessary information probably isn't in the object file format. You would need a new format that performs some of the functions of the ".class" files, or perhaps the compiler could generate the header files for the programmer as his classes are compiled.
If you look at the source files, you see that you still have to declare variables (e.g. "int i;").
What you don't have to do is to declare classes in a separate header file, when all the information about the class's public interface could have been gleaned from source file in which the class is actually defined.
The purpose of this, I guess, in C++ is to allow the compiler to layout an object in memory prior to the constructors being called, and generate assembly for class member access, without necessarily knowing where the class is defined or even having access to source at all. Secondarily the class's interface can be determined for compile time checking. I say secondarily, because clearly that isn't the main purpose of class definition headers since they also reveal information about private members and methods, which are of no interest to the client modules.
D is more like Java in that the compiler can do all this without any special help (in the form of header files) from the programmer.
Perhaps somebody who knows java better than I can comment, but I expect that the Java compiler does all its checking by looking for
In any case, I've never found the C++ way of doing things much of a problem, but if you think about it, it is rather unnecessarily complicated. Every little bit counts.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
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!
: Variable ; IMMEDIATE
: to SWAP ;
: be ; IMMEDIATE
: setting ! ;
"Variable" and "be" do nothing and compile to nothing; they are just syntactic sugar. "to" does a SWAP so you can say "x to 10 !" rather than "10 x !". "setting" just does a ! (store) operation.
Actually, you could make "to" and "setting" IMMEDIATE words; you would just need to make them compile in the words they implement. I'm very rusty on my FORTH, but I think you can do it this way:
: to COMPILE SWAP ; IMMEDIATE
Then "to" compiles a reference to SWAP, instead of creating a subroutine that calls SWAP and then returns. The IMMEDIATE version saves one subroutine call and one return.
This would make a nice short article to publish in Dr. Dobb's or some similar magazine, right around April Fool's Day.
I have fond memories of an April-Fools article on FORTH, describing how to add GOSUB to FORTH. He went through several versions, before finally arriving at this very efficient solution:
: GOSUB ; IMMEDIATE
In other words, GOSUB does nothing and compiles to nothing. FORTH is all subroutine calls anyway; it never really needed GOSUB in the first place.
steveha
lf(1): it's like ls(1) but sorts filenames by extension, tersely
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.
It's unfair to compare a Java UI directly with a native UI. How well does that native UI run on other platforms? Oh yeah, it can't. How well does it run from a web page? It doesn't.
Properly written Java code can approach the speed of pure C, be done in a tenth the time, and be significantly more maintainable and portable.
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
¦ ©® ±
It's a nice name. I like "D" as a name better than C#. But that's all. From the description of the language, it's just Java without bytecodes -- but with "the option" of bytecodes. The major things it does is throw away legacy C compatibility -- making for faster compilers that are easier to write, but not a whole lot of gain for the programmer. However, maybe it would be good to have C++ updated and throw away unnecessary features, and more structured ways of defining things (like the try-catch-finally structure instead of try-catch, which I like the idea of).
Read again. Nowhere do I compare the speed of a VM executed program to a native compiled one. Java is not the end all, be all of languages, but it is much more than the applet creation toolkit it was in 1995. Will fourier transforms ever run as fast in a VM as they do in optimized native code? Probably not. But, then again, how many of your programs are doing fourier transforms
It's simply a right tool for the right job issue. Plain and simple
It is a scripting language for a X Window based RAD tool called Telesys(? - maybe that was the name of the company that made the software).
I am very small, utmostly microscopic.
He's talking about making the compiler do all the work - for instance, there are no headers, as declarations are lifted from the source. For that matter, modules and libararies and source are treated the same. I think that he *might* be talking about features that would require a new object format, and thus a new linker.
I really don't like his ".html" file idea: code inside a html file is compiled by ignoring everything but tagged bits. The concept is to use html to document and compile the code right in the documentation. Personally, I prefer to generate documentation from the code. A language that implements context sensitive comments that can be compiled into various types of documentation would be, IMHO, a very good thing. As it is, systems like doxygen seem to work okay, but if it were built into the language, you could even dump documentation out of modules on the fly. Nifty in an IDE environment, or makefile driven dev when you want to check that version 2.2 of openfoo() does the same thing that 2.1 openfoo() did.
--
Evan
"$30 for the One True Ring. $10 each additional ring!" -- JRR "Bob" Tolkien
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.