Slashdot Mirror
C, Objective-C, C++... D! Future Or failure?
TDRighteo writes "OSNews is carrying a quick introduction to a programming language under development - D. Features include garbage collection, overrideable operators, full C compatibility, native compilation, inline assembler, and in-built support for unit testing and "Design by Contract". With all the discussion about the future of GNOME with Java/Mono, does D offer hope of a middle-road? Check out the comparison sheet."
Looking at that comparison table, it's clear the author hasn't looked at Java since 1.4
Don't miss Google Directory if you're looking for more D info:
Computers > Programming > Languages > D
New programming languages are interesting, and sometimes I wonder what the next "big thing" will be. Will we have another big, revolutionizing, new concept like "object-oriented programming" that you simply must know in a near future?
Beware: In C++, your friends can see your privates!
D drops archaic C++ features like the preprocessor and forward declarations. It adds modern features like design by contract, unit testing, true modules, automatic memory management, first class arrays, closures, and a reengineered template syntax. D retains C++'s ability to do low level coding, and adds to it with support for an integrated inline assembler. C++ multiple inheritance is replaced by single inheritance with interfaces. D's declaration, statement and expression syntax closely matches C++.
Opera Watch - An Opera browser blog.
Actually, the post was a bit misleading -- D only provides *link* compatibility with C. You can link to C libraries without any trouble, but you can't compile C source code in the D compiler.
Checking return values is a horrible use for exceptions. Exceptions are for critical but recoverable errors. "Normal" error conditions shouldn't throw exceptions, not least of which because it makes the code so much nastier and twisting to deal with it. Exceptions are great and allow you to do a type of error handling that would be impossible without them, but I think that some C++ (and especially Java) people get far to enamored of them.
It's seems that a lot of people are complaining about something that was seriously mis-reported. D CAN'T COMPILE C CODE!! (Sorry for shouting.. but I'm hoping to get peoples' attention). D can link to C binary code.. wow.. what a concept.. almost every programming language can do this. It's almost a requirement for any new language. Without it you would start with 0 code base, and no one will use it. The below text is taken directly from the article. Notice 'Binary Compatibility' and 'Link Compatible.'
Binary C Compatibility:
D programs can import and link against C code and libraries, providing D with free access to a huge amount of pre-written code. Note, however, that D is not link-compatible with C++, so pure C wrappers are required to access C++ code in D.
Personally, I've been praying for years for a language like this to get adopted. Why is it that I can only use full object oriented programming for web/network applications?! Sure.. I know you can do more than this with Java or C#, but is it really practical?? Usually it's just a massive drain on resources. If you need high performance, then you can't do better than C++. Unfortunately, C++ is a transitional language (just look at it's name..). A pure object oriented, fully compilable language that has no VM is desperately needed. I can't believe it's 2004, and such a thing still hasn't been adopted. I hope D (or something like it catches on.. As much as I loved it when it first came out, I'm sick of wrestling with C++ code.
The backend (code generator) for the reference compiler is closed source. However, the frontend is dual-licensed under the GPL or Artistic licenses, and is free in every sense of the word.
David Friedman has already had success connecting this frontend to the GCC code generator, in fact: http://home.earthlink.net/~dvdfrdmn/d
"Break out the gin, and the small violin, I'm a raging success as a failure." --Firewater
BOOM! And you reveal that you don't know what you're talking about. Circular references are irrelevant to any GC scheme more sophisticated than reference counting.
My point was that to avoid the problem of circular references, the garbage collector does have to be more sophisticated, and sophistication takes time and (memory) space -- time and space that a program may or may not be able to spare.
"for very many applications modern garbage collectors provide pause times that are completely compatible with human interaction. Pause times below 1/10th of a second are often the case,"
Pause times below 1/10th of a second? Hmm, how much below? TV-quality video is 24 frames per second, so a one-tenth second pause means dropping two or three frames. Acceptable? Perhaps, but not desirable.
"Does garbage collection cause my program's execution to pause? Not necessarily."
Yes, if you read my post carefully -- perhaps you missed a word or two when the garbage collector in your head did some clean-up -- I didn't say that pauses were inevitable. My complaint -- and not just mine, it's no revelation that garbage collection has may detractors -- is that the pauses are not predictable by writer of the program.
With non-garbage collected language, I know that memory allocation will either succeed ort fail, and I know (or a library writer knew) when allocation happens, because I'm explicitly coding it. So I know, at this particular point in my program, either allocation succeeded or failed.
But garbage collection can happen at any time, and cause a pause at any point in my program -- even when I'm needing to re-fill under-run buffers or read volatile memory or make time-critical choices. With garbage collection, I no longer have an algorithmic program, in which I can say what it's doing at any particular point in the code.
Then come back and make some informed comments, instead of spouting nonsense. Thank you.
That overly hostile arrogance suggests you're either a zealot or a fourteen year-old. That sort of blustering generally indicates someone who isn't that confident in himself or his argument, and so wishes to preempt questioning by being a posturing like a "tough guy"; it's particularly prevalent on the net -- though I'll grant that you didn't hide behind an Anonymous Coward post. Adults can disagree and discuss things without resorting to insults and attitude -- and I think you'll be able to do that too, with a little more experience.
Opinions on the Twiddler2 hand-held keyboard?
Kind of sad really. If the inventors of this language had any sense of history they'd have called it "P" (Remember: there was no language called A, Ken Thompson's naming convention wasn't alphabetic, it was after BCPL, the language he was trying to improve upon.)
You are not alone. This is not normal. None of this is normal.
My point was that to avoid the problem of circular references, the garbage collector does have to be more sophisticated
No it doesn't. Handling of circuler references falls naturally out of most GC algorithms. One of the simplest possible memory algorithms is the mark & compact GC, which handles circuler references naturally.
Pause times below 1/10th of a second? Hmm, how much below? TV-quality video is 24 frames per second, so a one-tenth second pause means dropping two or three frames.
You disable the GC in those cases. A good GC will give you the option to manually manage memory in certain cases (say, through a pool allocator), so in any time-sensitive paths, you can disable the GC and rely on those other options. There are also real-time GC's that have absolutely bounded pause times.
But garbage collection can happen at any time, and cause a pause at any point in my program -- even when I'm needing to re-fill under-run buffers or read volatile memory or make time-critical choices.
You do realize that you have this issue with any modern OS? A malloc() can take tens of thousands of clock-cycles if it decides to mmap() to get more backing memory, and the kernel decides to block the app.
A deep unwavering belief is a sure sign you're missing something...
D's only link-compatible with vanilla C, so you'd need to create a GTKD wrapper, or just use regular old gtk.
Stroustrup is on record many times over as saying that link compatibility with some existing language was a design criterion for him. If not C, then something else.
It is an axiom in the C++ community that compatibility with C is both C++'s greatest strength and its greatest weakness.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
C++ itself is undergoing a revision. But the plans for it aren't that good.
The big problem with the C++ committee is that most of the members don't want to admit the language has major problems. Neither does Strostrup, who has written that only minor corrections are needed. If that was really true, we wouldn't need all those variants on C++ (Java, D, C#, Objective-C, Managed C++, etc.)
The committee is dominated by people who like doing cool things with templates. Most of the attention is focused on new features for extending the language via templates. It's possible to coerce the C++ template system into running programs at compile time (see Blitz). Painfully. LISP went down this dead end, where the language was taken over by people who wanted to extend the language with cool macros. (See the MIT Loop Macro.) We all know what happened to LISP.
What isn't happening is any serious attempt to make C++ a safer language. C++ is the the only major language that provides abstraction without memory safety. That's why it causes so much trouble. C++ objects must be handled very carefully, or they break the memory model. This usually results in bad pointers or buffer overflows. Java, etc. are protected against that. This is the basic reason that writing C++ is hard.
It's not fundamentally necessary to give up performance for memory safety. I've written a note on "strict mode" for C++, an attempt to deal with the problem. I'm proposing reference counts with compile-time optimization, rather than garbage collection. The model is close to that of Perl's runtime, which handles this well.
Garbage collection doesn't really fit well to a language with destructors, because the destructors are called at more or less random times. Microsoft's Managed C++ does that, and the semantics of destructors are painful. With reference counts, destructor behavior is repeatable and predictable, so you can allocate resources (open files, windows) in constructors and have things work. The main problem with reference counts is overhead, but with compiler optimization support and a way to take a safe non-reference-counted pointer from a reference counted object, you can get the overhead way down and reference count updates out of almost all inner loops.
C++ itself isn't that bad. The language could be fixed. But I don't see it happening. Microsoft has gone off in a different direction with C#. SGI, HP, DEC, Bell Labs, SCO, and Sun are defunct or in no position to drive standards any more.
What C++ needs is some hardass in a position to slam a fist on the table and say "Fix it so our software doesn't crash all the time". It doesn't have one.