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."

Comments

wow

[spangineer]

Who said computer geeks don't have any creativity in naming their programming languages?

Oh, wait...

Re:wow

[slickepott]

I think they still had some good choices with the C.. I have loads of cool signs on my number keys to play around with. *C, //C, &C, "C", /*C*/, C--, C+=1 Why the rush for D already?

Re:wow

[91degrees]

I'd like them to come up with a better name. D makes it very hard to find information about it on the web. A name like "zlxrt" would be better since it would get zero hits that weren't about the language.

For the pedantic - I consider this post to be about the zlxrt language.

Re:wow

[rishistar]

You guys are all behind the times. I'm already on E!

Yeah - turn up that thumping music man!!!

Re:wow

[twocents]

Yes yes yes.

Look for .Net in Google - the first result is php.net. That should offer a lesson for anyone.

Re:wow

[xSquaredAdmin]

Well, the value of 'C'++ is 'D'. Looks like they're gonna need a new name (maybe... 'E'?)

Re:wow

[ByteSlicer]

Don't worry. In a while they will add some new extensions and call it D++.

Re:wow

[squiggleslash]

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.)

Re:wow

[schapman]

no... DEF-G and DEF+G will have to be two separate specs that arent compatible with each other at all. Then we can have big corps battle it out until the poor compilier makers have to write DEF+-G compilers for us.

Re:wow

[llimllib]

D's only link-compatible with vanilla C, so you'd need to create a GTKD wrapper, or just use regular old gtk.

Re:wow

[gunpowder]

No, I think he meant this.

Re:wow

[gwjgwj]

The value of C++ is actually C. It is guaranteed to be C+1 after a sequence point.

Re:wow

[Salsaman]

I'm already on E!

Shush ! They can arrest you for that, you know.

Re:wow

[mrjb]

Look for 'estupido' on google and the first hit is that of the Portuguese government.

Re:wow

[Tired and Emotional]

This is indeed the historical record - there was a language called just "B" which was based on BCPL and then C. So the next language after C++ should be --P. I believe BCPL stands for Basic CPL. CPL was Combined (sometimes Christopher's in honour of Christopher Strachey) Programming Language. In which case a subset implementation of the next language after C++ could be B--P.

Re:wow

[Jorkapp]

Wikipedia: B Programming Language

It was essentially BCPL stripped of anything Thompson felt he could do without, in order to fit it on very small computers, and with some changes to suit Thomson's tastes (mostly along the lines of reducing the number of non-whitespace characters in a typical program).
...
According to Ken, B was greatly influenced by BCPL, but the name B had nothing to do with BCPL. B was in fact a revision of an earlier language, bon, named after Ken Thompson's wife, Bonnie.

Microsoft will come out with it's own version

[eclectus]

Microsoft will come out with it own version, and call it D-.

Re:Microsoft will come out with it's own version

[b4rtm4n]

Visual D

Cue loads of VD jokes :-D

Re:Microsoft will come out with it's own version

[stevesliva]

I was thinking Double-D.

Re:Microsoft will come out with it's own version

[Lord_Slepnir]

Heck, I got enough of a kick out of Visual C (VC). Made me want to listen to acid rock and hunt Charlie.

Re:Microsoft will come out with it's own version

[Anonymous Coward]

You know why you can't get information on Visual C on the web? 'Cos Charlie don't surf.

Re:Microsoft will come out with it's own version

[T-Kir]

Or instead of sharp, use the hash orientation and you could have D-bong... mind you'd have to be on drugs to be able to use it though ;-)

Re:Microsoft will come out with it's own version

[lacrymology.com]

You know; whenever I startup Microsoft's IDE I get flashbacks, curl into a ball, and shiver. Now I see why.
-m

Re:Microsoft will come out with it's own version

[red floyd]

I suppose you will need virus protection when using VD?

full C compatability?

[beegle]

I think the "full C compatability" is a problem. It's -not- a feature.

In "small program" languages like perl, giving people lots of ways to do things is a feature. In a "large program" language, providing both C compatability and garbage collection is a maintainability nightmare. You'll have people who use both, or worse yet, who only understand one, so to understand the mixed code that results from a hybrid langage like this, you'll have to be utterly proficient with -both- languages.

Re:full C compatability?

[Anonymous Coward]

I don't know, I think objective-c handled it pretty well and clearly. It's a superset of c, and it's optional garbage collection is as simple as setting or not setting the auto-release flag when you construct your object.

I wish the article actually compared to objective-c, as the story's poster seemed to imply...

Re:full C compatability?

[Elbows]

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.

Re:full C compatability?

[PhrostyMcByte]

Agreed. Though it's generally bad practice for libraries to allocate their own memory for returned data, it happens.

Because it's not handled by D's garbage collection, it still needs to be freed. I'm sure this will make those developers who love to leak memory even worse.

Re:full C compatability?

[noselasd]

No. Its a very nice feature.
Just about anything you need, there's a C library for it.
Think nice things like opengl,pam,openssl,GUI librairies, database
libraries, and heaps more.
Having access to those is very nice, and you don't have to wait anyone
to port those to a new language(which probably won't happen anyway.)
I'd imagine how far C++ had gotten if it couldn't use C libraries..

Re:full C compatability?

[orthogonal]

In a "large program" language, providing both C compatibility and garbage collection is a maintainability nightmare.

For those of us who don't like unpredictable...

pauses...

in our programs while the garbage collector does its work, will we be able to turn off garbage collection entirely or run the garbage collector only at specified times?

I'll answer my own question: even if this is possible, if D ever becomes a serious language, we will be using libraries written by other people, libraries that do rely on garbage collection.

So, no, we won't (realistically) be able to turn off the garbage collector, which means that we won't be able to write real-time programs, and it'll even be touchy writing programs, such as, oh, audio or video players, that require near real-time performance. (Not to mention the disappointment we all felt with the various java window-widget APIs (AWT, Swing) that looked great but couldn't run fast enough to respond to the mouse.)

Look folks, taking care of your own garbage wasn't possible in C for a library writer (even ones returning opaque pointers to structs that allocated their own memory) because you had to rely on the library user to call your cleanup function(s).

But the library user could clean-up. The problem was essentially that some programs didn't care enough to be careful -- pointers actually had to be tracked.

Now, it's fine if a library user wants to add on a garbage collector by re-writing malloc to track allocations. But libraries, which are intended to be used by lots of programmers, to write code, and by lots and lots of end users who run code should not use garbage collectors themselves -- because that forces the library user to use garbage collection too.

But in C++, library writers can write libraries that take care of their own garbage even when used by careless users, because the compiler will automatically call class destructors which can do clean-up. (Yes, except in the case of derived classes -- the writer of the derived class has to explicitly write a dtor to ensure the parent class dtor is called.)

And in C++, with the Standard Template Library, there's little need for non-library writers to do explicit allocation at all -- std::vector and std::string and std::auto_ptr, just by themselves, take care of most of the problems of memory leaks and buffer overruns.

If you're using C++ and you feel that you're a good enough programmer that there's real need for you to be calling

new

directly, them you're a good enough programmer to ensure that you've called

delete

for each new. And with std::auto_ptr, it's as easy as

std::auto_ptr<foo> pfoo( new foo ) ;
pfoo->do_Stuff() ;
return ;
// auto_ptr calls delete on pfoo, right here,
// without you doing anything,
// and without garbage collection overhead

How much simpler does it need to be?

So why complicate things with garbage collector and tracking down circular references and unpredictable pauses? Garbage collection is a bad answer for non-trivial programs, and pretty much necessary for trivial programs.

Re:full C compatability?

[Mr. Piddle]

Though it's generally bad practice for libraries to allocate their own memory for returned data, it happens.

It happens a lot. I've seen a few expensive C-based libraries that clearly show their designers struggled with the classic caller-callee allocation dillema and lost. Debugging memory leaks in programs that use these libraries is typically hopeless and requires high effort-versus-progress computationally-expensive run-time checks to find them. I like C quite a bit, but it is disheartening to see such a simple malloc() function cause so much pain.

Re:full C compatability?

[Haeleth]

we won't (realistically) be able to turn off the garbage collector, which means that we won't be able to write real-time programs, and it'll even be touchy writing programs, such as, oh, audio or video players, that require near real-time performance. (Not to mention the disappointment we all felt with the various java window-widget APIs (AWT, Swing) that looked great but couldn't run fast enough to respond to the mouse.)

Yeah, nice FUD. Java is slow because it's bytecode, not because it's garbage collected. (Incidentally, all the Swing applications I've used recently have been every bit as responsive as I could desire, so it isn't even necessarily slow.)

So why complicate things with garbage collector and tracking down circular references...

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. They simply have nothing to do with it.

I suggest you read this. Pay particular attention to the bits that explain things like "Modern garbage collectors appear to run as quickly as manual storage allocators (malloc/free or new/delete)," and "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," and "Does garbage collection cause my program's execution to pause? Not necessarily.".

Then come back and make some informed comments, instead of spouting nonsense. Thank you.

Re:full C compatability?

[PhrostyMcByte]

std::auto_ptr is good but rather limited if you want to use the pointer in various locations at the same time. boost's shared_ptr is very nice for this.

Re:full C compatability?

[ballista]

So why not say it like it is: *Fortran* compatability, since that is what C was origionally designed to be compatible with. That way you could link with those pesky fortran math libraries.

Re:full C compatability?

[WWE-TicK]

> Yes, except in the case of derived classes -- the
> writer of the derived class has to explicitly
> write a dtor to ensure the parent class dtor is
> called.

This is wrong. If your compiler requires this, then your compiler is broken.

The destructor in a base class has to be made virtual though to ensure that correct destructors will be called if you do something like this:

Base* o = new Derived();
delete o;

where Base is some class and Derived is derived from Base. If Base::~Base() is not virtual, then Derived::~Derived() would never get called.

Re:full C compatability?

[Darren Winsper]

Err...he said real-time applications. Because the behaviour of a garbage collector is often approaching non-deterministic (You don't know when it will run or how long for), it's not acceptable for real-time systems. Real-Time Java gets around this by having other memory models which don't involve using the heap, along with providing types of threads that can run in parallel with the garbage collector.

Re:full C compatability?

[orthogonal]

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.

Re:full C compatability?

[elhaf]

Um, auto_ptr/reference counting is a form of garbage collection, just not a very good one. The trivial example given is certainly fine, but why not just put pfoo on the stack if it's that trivial. Reference counting has problems with circular references; most other garbage collection schemes do not. Note: any doubly-linked list or both-way parent-child relationship is circular.

There is overhead to auto_ptr; In the statement pfoo->do_Stuff(), the -> is an overloaded operator, requiring a function call. The implied destructor is also a function call. In the gc world, there are far better schemes than mark/sweep, which is the other one that most people think of when talking about gc. Incremental and concurrent gc is feasible.
Also, new and delete aren't free, by the way; they do things that aren't strictly necessary in a gc environment. Reference counting (smart pointers)has overhead at every assignment/function call, whereas most gc has far better overhead performance, especially for long-lived data. The argument that gc is too expensive holds little water.

Re:full C compatability?

[MartinG]

Pause times below 1/10th of a second are often the case,

That's not even remotely low enough for realtime audio applications. "Human interaction" includes realtime mixing of audio streams etc, not just displaying windows and moving a mouse pointer.

Yeah, nice FUD. Java is slow because it's bytecode

Bytecode is not slow if its jit compiled. Java can be as fast as compiled c in some cases where the jit engine has done a good job. That doesn't reduce GC latency though.

Re:full C compatability?

[rblum]

Yes, he said real time. Big deal. If he actually was informed about the topic, he'd know there are several GCs that are useable for *hard* realtime. They have *guaranteed* response times.

Sorry - the whole "GC is slow" is a myth, unless you implement a naive GC. But guess what - naive memory allocation by hand can kill performance, too. (It's not like malloc is a speed demon, after all...)

Re:full C compatability?

[swillden]

It's not like malloc is a speed demon, after all...

Malloc's usually pretty good, it's the performance of free that typically sucks. It all depends on the implementation, of course.

Re:full C compatability?

[at2000]

No! It is call-compatible only.

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.

Re:full C compatability?

[be-fan]

Malloc is still ridiculously expensive compared compared to what a generational GC can do. A malloc is dozens to hundreds of instructions, while in many cases (eg: when you're following the typical functional-language allocation patterns), a generational GC can alloc in just a few instructions. And while the GC phase itself is hardly speedy, the amortized cost of the GC is much lower than the non-amortized cost of doing all those free()'s individually.

Re:full C compatability?

[be-fan]

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.

Re:full C compatability?

[iabervon]

An afternoon with Valgrind should track down most of these without too much effort. It's really gotten to be a nice "please tell me what's wrong with my program" tool, capable of letting you send in bug reports like "function X leaks a 20-byte chunk of memory and a 4-byte chunk every time I call it with these arguments." For now you can't determine things like "bytes 16-19 of the leaked chunk are a pointer to a filename", but I suspect that will be in a later version (determined by what system calls are called with it).

One thing I'd really like to see in Java is Object.free(), which would tell the garbage collector that the object is garbage and can be freed, and cause any further use of the object to throw a FreedMemoryException. This would be useful both as a hint to the system (letting it get rid of things the object references early) and as a debugging aid (so you can find cases where stuff remains in use after you don't think it will). Of course, it violates Java's sandbox design to have a C-style free() which recycles the address space.

Re:full C compatability?

[metamatic]

So, no, we won't (realistically) be able to turn off the garbage collector, which means that we won't be able to write real-time programs, and it'll even be touchy writing programs, such as, oh, audio or video players, that require near real-time performance

Ah, the eternal anti-GC FUD of the ignorant.

Yes, clearly it would be complete lunacy to write video games in garbage-collected LISP, like Jak and Daxter, Ratchet and Clank and so on.

Obviously AT&T were insane to write their telephone exchange control software in garbage collected LISP.

And those massive overheads ensure that we'll never see NASA using LISP to control space probes.

Re:full C compatability?

[emarkp]

I think the "full C compatability" is a problem. It's -not- a feature.

Actually it's both. C compatibility leads to early and widespread adoption, but it also carries tons of baggage--at least that's been the case in C++.

One of the biggest problems in C++ is backwards-compatibility with integer promotion rules. It appears to cause more confusion than templates and name lookup combined.

Re:full C compatability?

[Chester K]

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.

There are an awful lot of dashes at random places in this paragraph. Were you by chance running garbage collection?

Re:full C compatability?

[Anonymous Coward]

try this...
object = NULL;
System.gc();

although you shouldn't really call System.gc yourself. Also, object = NULL would do the same thing as object.free() since you don't actually want to free the memory right now, but instead tell the JVM that it should be free'd in the future. Inline memory free'ing is only necessary in embedded apps that are written in C anyway. BTW, valgrind rocks. I used it to trim a version of Doom from 16MB to under 4 with all textures. This allowed me to get it running on very small hand held devicies.

Re:full C compatability?

[void*]

(From which many sensible people conclude that it's bad practice to write in C.)

Your 'many sensible people' would be ignoring that 'libraries allocate their own memory' and 'libraries that have fixed size return data' are not the only options.

Sure, you can do bad things in C. You can do "bad things" in pretty much any language - I just ran into an issue where a third party java library closed a stream I passed to it. It didn't create the stream, why should it assume I want it closed? It's a bogus design decision that limits the libraries usefulness - if I want a chunk of data processed by that library wrapped by other data that I write before and after the processing, I can't just write the data that goes first, pass my output stream to this lib, and then pass the data that I want after, I have to write the middle data out to a file somewhere and then reread and rewrite it. Should I now conclude that it's 'bad practice to write in java' because a third party came up with a poopy implementation of a util library?

I recognize that C allows worse things (buffer overflows, etc) to happen when such design errors are made. However, I think that anyone writing code in C should be aware of that - the code doesn't write itself, and the root of the problem is a given programmer following bad practices. You may blame the language for allowing it, but you can't blame the language for the presence of the given overflow ... the language spec didn't write the code. With power should come responsibility.

Re:full C compatability?

[mystran]

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.

Then again, malloc needs sophistication as well, and can be every bit as slow as a good garbage collector. Indeed, even garbage collectors for C (try google with "garbage collector") can outperform the regular glibc malloc sometimes, even when there is NO reference counting involved. Which btw is another issue, reference counting + malloc pretty much combining the bad (and slow) things from both worlds.

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.

Such pausetime on a machine capable of playing TV-quality video in the first place indicate an awful garbage-collector. Even a stop-and-copy shouldn't take that much time, and these days we have generational collectors which only bother with the "youngest" stuff, that is, stuff most likely garbage. And you can make that incremental, it's not even very hard, and you can then slice the "pause" into almost as small parts as you want. There are collectors which provide real-time guarantees. Mallocs usually don't.

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.

Except this isn't necessarily true either. One example is Linux, which doesn't guarantee that there is memory left, because memory isn't allocated when you map pages, but when you touch them first time. If you allocate memory, and there's not enough free virtual memory to fill in the pages when you actually need them first time, then OOMkiller is called. Speaking of which, unless you lock (all) pages into memory, you won't know whether there'll be pauses anyway, since that memory of yours might just as well be a block of hard-drive space. Welcome to the world of virtual memory. Guess already which pause takes longer, a call to an incremental collector or the swap-in? Oh, and do you have a deterministic thread scheduler in your OS?

Finally, if you have an incremental collector (designed for this) you could run it with priority lower than your "real-time" tasks, and you could then collect only when the processor would be idle otherwise. Dijkstra's classical tri-coloring was actually developed for a scenario where there is one processor for running the task (mutator) and another for collecting the heap (collector). That you didn't think of this pretty much proves you've got no idea about garbage collectors.

Just because there are bad collectors doesn't mean they all are bad. And even stock solutions, over are the days when Lisp machines hanged for hours to collect their memory. Unless you are running the CPU at 100% all the time, you'll have plenty of time to collect.

Re:full C compatability?

[Minna Kirai]

Yes, clearly it would be complete lunacy to write video games in garbage-collected LISP, like Jak and Daxter, Ratchet and Clank and so on.

It is a misrepresentation to claim that those games were "written in LISP".

One can say that the "behavioral and game logic" processing was written in LISP, but that's a minor part of the overall software work- especially if you count it in terms of percentage of CPU usage. (Which, since you're talking about performance, is what actually matters)

Games have used LISP to control higher-level flow since the 80s, but to claim that they're written in LISP is no more accurate than saying Mozilla was written in XUL.

And those massive overheads ensure that we'll never see NASA using LISP to control space probes.

Another misrepresentation. Actually reading that article plainly says that the performance-critical elements of the space-probe were written in C.

Furthermore, you cannot use LISP as an example to defend all GC. LISP programs naturally give the compiler more information, allowing it to make better optimizations. Frequently it can eliminate the need to actually execute much of the GC at runtime (converting it into logically static or stack allocations). But with an imperative language like Java, the overall code is less analyzable, so the GC can't reach the same heights of performance.

Re:full C compatability?

[tyrecius]

You make a number of good points. I agree that the instances where garbage collection is infinitely better than any other tool. However, there are also places where ownership is the better tool. I am not going to make the specious 'it is faster' argument here, because usually it doesn't matter.

An ideal language for me would be one where there is a GC (possibly as a default), but that also allowed ownership semantics where that is applicable. Now I am going to talk about situations that I have run across where GC wasn't that useful. Note that I am not making an argument that GC is bad (it is usually very good), but that there is a case to be made for a language where GC isn't required in all cases.

There are many cases where order of destruction is very important. There are cases where this is implicit. For instance, it is best that a 'successful completion' message is written to the log file before the log file is closes.

But there are cases where an elegant solution can depend on it. A good example of this would be streams. Streams, for the sake of argument, are objects that take in a variety of data, turn that data into bytes, and send those bytes someplace else.

Often, a stream will have attributes defining how it processes the incoming data. If the incoming is a bool and true, does it turn it into the character '1', the sequence of characters "true", or the byte 0x01? Floats (how many sig figs?), signed integers (put a sign at the front if its positive?), etc. also have choices to be made.

But if a caller sends a stream to a method for output and the method changes the state for some reason, later output might be unexpected. This is where a stack-based allocation could come in handy. A new kind of object can be created which saves the stream in its constructor and restores the stream in its destructor. If these happen at known points in the program, then all is well. If the destructor (or finalizer) is called at an undefined point, badness results.

Such a stream-state-saver object can be used by the caller to make sure that the method doesn't screw with the state. Or it could be used by the method to make sure that it doesn't step on the callers toes.

The other case where a GC might not be a help is if one were trying to develop a new kind of GC. There is no way in Java, for instance, for me to develop my new "tyrecius' patented GC" as a Java library in any kind of transparent way. I'd have to go in and modify the guts of the compiler/VM.

Finally, memory is just one kind of resource. GC's generally don't make dealing with other resources very easy. The best that one can do is to put the release of the resource in a finalizer of some kind and hope that the resource will be released in a timely manner. File Descriptors, network Sockets, database connections, etc. are all harder to deal with in an efficient and brainless way in a GC-only language.

Let me reiterate that GC is great to have in a language. But I tend to be nervous about a language if there is not a way to bypass it in the few instances when it becomes a problem.

Re:full C compatability?

[WalterBright]

D offers several ways to do allocation, gc is only one of them:

• garbage collection
• using C's malloc/free
• stack allocation via alloca()
• automatic stack allocation and cleanup (RAII technique)
• static data
• overloading new/delete on a per-class basis
• writing one's own functions to allocate/release memory

Old news

[AKAImBatman]

1. D is not new. If this D is new, then we've got about 50 of them floating around by now.

2. Java and .Net are successful because they protect the program from complete failure. (i.e. error recovery ability) Making a C compatible language isn't going to help anything.

3. If a new popular language does come on the scene, you won't notice it until it has nearly taken over the world. Oh, and developers will love it so much they'll drop everything else (like what happened with Java).

Re:Old news

[mark_lybarger]

the java jvm can lock up hard. makes recovery quite interesting.

also java and .net are "successfull" b/c of general investment from big companes. there's lots of marketing dollars selling products and articles about these platforms. the PHB's read the PHB magazines, and those mags have articles re java and .net. Do those mags have articles on D? then it's not a competition.

Re:Old news

[fforw]

the java jvm can lock up hard. makes recovery quite interesting.

Off course it can lock up (nothing is perfect) , but it never occured to me. I experienced a few thread deadlocks, which are also not nice to debug, but only had one complete java VM crash - and that was due to faulty memory as memtest86 revealed.

also java and .net are "successfull" b/c of general investment from big companes. there's lots of marketing dollars selling products and articles about these platforms. the PHB's read the PHB magazines, and those mags have articles re java and .net. Do those mags have articles on D? then it's not a competition.

Sure there's a lot of hype around java related issues, but that isn't the reason for it's success. ( Every commercial software is hyped, dummies fall for hype - news at 11)

Java is successfull because:

• it offers a nice abstraction for system specific issues which is only seldomly leaky.
• you can dive into an unknown project, select a random source file and understand it. You may have problems getting the big picture, but the code itself is there - there are no suprises like operator overloading, defines etc. All you need to know about the class is in it (and it's superclass and interfaces)
• its complex enough to do some magic in it, but the idiot next cubicle can't run totally amok and wreck the whole system.

IMHO all these reasons are more important than for Java's success than hype.

Re:Old news

[b17bmbr]

also, perl code could be written to be readable

no. it can't.

Obligatory java response...

[mogrinz]

Looking at that comparison table, it's clear the author hasn't looked at Java since 1.4

Re:Obligatory java response...

[Nasarius]

I'm as excited about the new syntactic sugar in 1.5 as the next guy, but it *is* still in beta, and therefore not quite part of the "official" language. I for one can't and won't use the new features until there's a stable 1.5 JDK.

Re:Obligatory java response...

[wideBlueSkies]

I'm sure the gentleman will update his table once 1.5 comes out.

Templates.... great. It's like C++, but it's not.

What does D stand for?

[Spiked_Three]

Doom of course.

Re:What does D stand for?

[TheJavaGuy]

What does D stand for?

Here is a qoute from their website:

"The original name was the Mars Programming Language. But my friends kept calling it D, and I found myself starting to call it D. The idea of D being a successor to C goes back at least as far as 1988, as in this thread".

Sounds like a good idea

[CharAznable]

I like this. It was about time someone saw the need of a cleaner, more modern version of C/C++ that takes the best features of the modern languages that are supplanting it in higher-level application development, like Java and Perl.
However, I it is doubful it will gain a foothold in the current ocean of multiple, semi-specialized languages.

Re:Sounds like a good idea

[Kruemelmo]

What I found interesting was that they claim applications with garbage collection to be faster. I would never have expected this.

The D approach is pretty much taking the best from C++, Java and C#, and you can find a lot the stuff you were asking yourself "why is this not possible in [insert current language]" in it. For example what they call function deletates is really missing in C++.

However, some time will pass until a usable compiler will be available for *any* plattform.

D @ Google

[Jugalator]

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?

try, catch, finally

[91degrees]

Wjhy do programming languages keep implementing this nasty tired interface? It's too bulky and long winded. Whereas I might just call a cleanup method if the function returns NULL, I'm actually obliged to deal with a thrown exception.

In theory this would be an ideal solution. It forces programmers to think about what they're doing. In practice, it doesn't. Coders are too busy thinking about the actual problem. Error checking gets in the way. They end up implementing the quickest way of ignoring the problem. The result is that we're no better off than if we just checked return values. The application should be doing what the user wants. Not the other way round.

Re:try, catch, finally

[PotPieMan]

As you say, programmers don't want to spend time worrying about error checking. The problem with return values is that some functions return -1, some return NULL, and others return some magic number depending on the problem. You can come up with rules and standards, but these are often broken or forgotten while programming.

Exceptions provide an obvious answer to the problem of how to handle different types of problems. If a file doesn't exist and someone tries to open it, a FileNotFoundException is thrown. If a file exists but the permissions don't allow access, an IOException is thrown.

Exceptions also provide a MUCH cleaner way of propagating errors. If one method calls another method to open a file, and the file can't be opened, how do you tell the original caller that there was a problem? With exceptions, you simply declare that your method throws IOException, and then (typically) skip the try-catch-finally block.

Re:try, catch, finally

[david.given]

Exceptions are wonderful --- in garbage collected languages. In languages with manual memory allocation, they're a pain.

The problem is that exceptions short-circuit the return path in non-obvious ways. Say we have a chain of functions a calling b calling c. c throws an exception. a catches it. Does b need to care?

Well, yeah, if b allocates some memory that needs to be freed on an error condition. It needs to catch the exception, clean up, and rethrow --- work that needs to be done whether you're using exceptions or not. And using exceptions usually results in more and more complex code than just returning an error code.

C++ attempts to get around this by calling the destructors of any auto variables on the stack as it works its way up the return path. This works great, except when dealing with pointers, which still need to be done manually. It may be possible to do something scary with smart pointers and templates, but that is, as I said, scary.

(Part of the problem with C++ is that it's such a huge language that it's only possible to thoroughly know and use a subset of it. I don't doubt that there are ways of using exceptions with dynamically allocated memory safely... but I don't know them, and every time I've tried to find out, I've come back with a headache and a renewed determination not to use exceptions. The only time I've ever actually used the things was in a daemon that deliberately did not dynamically allocate anything, and they were brilliant. YMMV.)

But in a garbage collected language, you don't have to worry about this sort of cleanup except in very rare cases, and it all works very nicely. Anything b allocates will be orphaned and just vanish, magically.

Re:try, catch, finally

[KagakuNinja]

To program effectively in both C and C++, you have to develop consistent rules, to keep you r code manageable. One such rule is, always pass smart pointers by reference; this avoids the unnecessary construction and destruction of a temporary. Of course, I almost never write functions that accept auto_ptrs as parameters. Conceptually, you don't to pass an auto_ptr to a function like you are doing.

The purpose of the auto_ptr is to provide temporary ownership of an allocated object. I would have coded your example like this:

int a(Thing *) {
...
}

int b(Thing *) {
...
}

int main(...) {
auto_ptr<Thing> ptr(new Thing);

a(ptr.get());
b(ptr.get());
}

Summary

[TheJavaGuy]

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++.

Re:Summary

[andy55]

D drops archaic C++ features like the preprocessor

I'm a veteran C/C++ dev, and when I saw this I went cock-eyed. Macros are essential if you have a performance-critical section that has very redundant portions (that can otherwise be maintained with just a single macro called many times). If D has it's way, I suppose it'd want a dev to write a proc to replace his macro in this a situation--are they kidding? It'd be a turkey shoot for the compiler to it screw up the inlining (without you knowing about it), so you're getting non-optimal execution.

I've wondered why so many Java finatics, Sun, and now D finatics are so anti-macros. It's a real mystery to me--and it's not like they're significant for the compilers to implement and maintain--macro implementation for a preprocessor is nothing next to their C/C++ compiler. If you have piss-poor dev abuse macros, shame on the dev, not on the language.

Looking forward to job ads

[swapsn]

Looking forward to job ads saying :

• 10+ years of C#,Java programming experience
• 10+ years Windows 2000 experience
• 10+ years programming experience in D

Duh !!

Re:Looking forward to job ads

[doublem]

You laugh, but I was turned down for a job in 1998, because I didn't have the "5+" years in Windows 95 that they wanted.

D already exists?

[Anonymous Coward]

I remember reading something in a C book years ago about the existence of the language D, which was supposed to be an evolution of the C language, the book even specified some of the added benefits of D, this was before DigitalMars even started on D. I also know of a language called "E" on the Amiga, which was a C++ derivate and was explicitely not called D because D already existed, and I'm _not_ talking of DigitalMars' flavor. In fact I once mailed this to DigitalMars but never got a reply.
Can anybody confirm this in any way?

p.s. If I'm not mistaken there's also an "F", based on Fortran if I'm not mistaken.

Unneeded history

[xoran99]

From the article:

D is designed to address the shortcomings of C++. While a powerful language, years of history and unneeded complexity has bogged down that language. They want to overcome C++'s "history" while still maintaining C compatibility. Suddenly, I'm confused.

A, B, C, D, ... R!

[KjetilK]

Bah, We've allready made it all the way to R!

What a good choice of name! (sarcasm intended)

[OwlWhacker]

Sheesh. You'd have thought they'd come up with a name that's a little more interesting than "D".

No, I'm not going to suggest that it should have been called "Rupert".

Hmm

[Lank]

Well, while the addition of a garbage collection mechanism sounds appealing, it also sounds a little bit scarey when dealing with low-level code. Additionally, D has no macro preprocessing. I know some people out there consider this a feature, others will consider it a failing. However, I do think it's awesome in that it has STL-like data structures somewhat built in - STL saves a ton of time and code, regardless of whether or not you like it.

Re:Hmm

[ViolentGreen]

Additionally, D has no macro preprocessing. I know some people out there consider this a feature, others will consider it a failing.

You have to remember that this language is still in development. A preprocessor can be added as a step after a standard is developed. Many older languages had preprocessors added as an optional compiler pass. I believe g77 even has one for FORTRAN though it's been a while since I used it.

What about C++0x?

[Jezral]

What happened to C++0x?

Last I heard about that was in this Slashdot story from 2001...exactly 3 years ago, nearly to date.

But that was supposed to be the next official holy grail, no?

C!

[zegebbers]

We want C!
with apologies to eminem...
to the tune of 'without me'

Two GUI classes go on the inside; on the inside, on the inside
Two GUI classes go on the inside; on the inside, on the inside
Guess who's back Back again C is back Tell a friend
Guess who's back, guess who's back, guess who's back, guess who's back
guess who's back, guess who's back, guess who's back..

Sun's created a monster, cause nobody wants to code Java no more
or basic, but something quicker
Well if you want speed, this is what I'll give ya
A language called C that won't let you do "is a"
Some "has a" that makes me feel sicker
than the bugs when I build patch that's critical
using make to compile and be building
with a language that allows object orientating

Your var name's too long, now stop line breaking
Cause I'm back, I'm a new var and instantiating
I know that you got a job Bill and Steve
but your company's trust problem's complicating

So GCC won't follow ANSI or copy memory, so let me see
They try to recompile with visual C But it feels so bloated, without C
So, connect with SLIP, or create a RIP Fuck that, write a function, and shift some bits
And get ready, and use a pattern like proxy MS just settled their lawsuits, expect a levy!

Now this looks like a job for C So everybody, just code in C
Cause we need a little, bit more speed Cause it runs so slowly, without C
Now this looks like a job for C So everybody, just code in C
Cause we need a little, bit more speed Cause it runs so slowly, without C

Little Hallions, MS feelin litigious Embarrassed that users still listen to RMS
They start feelin like ellen feiss 'til someone comes on the television and yells SWITCH!!!

A visionary, beard's lookin' scary Could start a revolution, lives in a bear cave
A rebel, although emacs ain't real fast and there's the fact that I only got one class
And it's a disaster, such a castastrophe for you can see so damn much of my class; meant to use C.

Well I'm back, i-j-k-x-y-z-out-ta-var-names Fix your damn indentifier tune your code and I'm gonna
open it, under vim, maybe pico and variables, no such thing as a member
I'm interesting, the best thing since assembly but not Polluting the namespace with inherits
We're Testing, your functions please Feel the tension, soon as someone commits some C
Here's my webpage, my code is free who'll pay the rent? What, You code with vi?

Now this looks like a job for C So everybody, just code in C
Cause we need a little, bit more speed Cause it runs so slowly, without C
Now this looks like a job for C So everybody, just code in C
Cause we need a little, bit more speed Cause it runs so slowly, without C

An object in .NET, I go tit for tat with anybody who's setting this bit, that bit
AT&T, you can get your ass kicked worse than those little C++ bastards

And Ruby? just like a static property not even used with KDE and QT
You're not like C, you're too slow, let go It's over, nobody'll code in OO!
Now let's go, -9's the signal I'll be there with a whole list of XM and L
I use SOAP, XPATH with XSL And you know perl's just like coding in symbols
everybody only just codes C so this must mean, some com-pile-ing
but it's just me i'm obfuscating And though I'm not the first king of controversy
And i'm not the worst thing since assembly but I am the worst thing since 86 XFree
do use BASIC and JSP and used it to get myself wealthy
Here's a concept that works twenty million new coders emerge
but no matter how many fish in the sea half of them can't even code C

Now this looks like a job for C So everybody, just code in C
Cause we need a little, bit more speed Cause it runs so slowly, without C
Now this looks like a job for C So everybody, just code in C
Cause we need a little, bit more speed Cause it runs so slowly, without C

Re:C!

[Jugalator]

by EnglishTim (9662)

You fucking geek.

You must be new h... No, wait...

Re:C!

[Anonymous Coward]

I just HAVE to add this one:

(sorry for the OoO, but else it wouldn't post cause I had to few chars per line)

OoOoOoOoO WRITE IN C
OoOoOoOoO
OoOoOoOoO (sung to The Beatles "Let it Be")
OoOoOoOoO
OoOoOoOoO When I find my code in tons of trouble,
OoOoOoOoO Friends and colleagues come to me,
OoOoOoOoO Speaking words of wisdom:
OoOoOoOoO "Write in C."
OoOoOoOoO
OoOoOoOoO As the deadline fast approaches,
OoOoOoOoO And bugs are all that I can see,
OoOoOoOoO Somewhere, someone whispers"
OoOoOoOoO "Write in C."
OoOoOoOoO
OoOoOoOoO Write in C, write in C,
OoOoOoOoO Write in C, write in C.
OoOoOoOoO LISP is dead and buried,
OoOoOoOoO Write in C.
OoOoOoOoO
OoOoOoOoO I used to write a lot of FORTRAN,
OoOoOoOoO for science it worked flawlessly.
OoOoOoOoO Try using it for graphics!
OoOoOoOoO Write in C.
OoOoOoOoO
OoOoOoOoO If you've just spent nearly 30 hours
OoOoOoOoO Debugging some assembly,
OoOoOoOoO Soon you will be glad to
OoOoOoOoO Write in C.
OoOoOoOoO
OoOoOoOoO Write in C, write in C,
OoOoOoOoO Write In C, yeah, write in C.
OoOoOoOoO Only wimps use BASIC.
OoOoOoOoO Write in C.
OoOoOoOoO
OoOoOoOoO Write in C, write in C,
OoOoOoOoO Write in C, oh, write in C.
OoOoOoOoO Pascal won't quite cut it.
OoOoOoOoO Write in C.
OoOoOoOoO
OoOoOoOoO Guitar Solo
OoOoOoOoO
OoOoOoOoO Write in C, write in C,
OoOoOoOoO Write in C, yeah, write in C.
OoOoOoOoO Don't even mention COBOL.
OoOoOoOoO Write in C.
OoOoOoOoO
OoOoOoOoO And when the screen is fuzzy,
OoOoOoOoO And the editor is bugging me.
OoOoOoOoO I'm sick of ones and zeroes.
OoOoOoOoO Write in C.
OoOoOoOoO
OoOoOoOoO A thousand people people swear that T.P.
OoOoOoOoO Seven is the one for me.
OoOoOoOoO I hate the word PROCEDURE,
OoOoOoOoO Write in C.
OoOoOoOoO
OoOoOoOoO Write in C, write in C,
OoOoOoOoO Write in C, yeah, write in C.
OoOoOoOoO PL1 is 80's,
OoOoOoOoO Write in C.
OoOoOoOoO
OoOoOoOoO Write in C, write in C,
OoOoOoOoO Write in C, yeah, write in C.
OoOoOoOoO The government loves ADA,
OoOoOoOoO Write in C.

That's because 1.4 is the CURRENT version

[the-matt-mobile]

it's clear the author hasn't looked at Java since 1.4

Well, since 1.5 is still in beta , I don't see how this is an invalid comparison.

Re:That's because 1.4 is the CURRENT version

[fforw]

it's clear the author hasn't looked at Java since 1.4

Well, since 1.5 is still in beta , I don't see how this is an invalid comparison.

.. because

The specification and reference compiler are currently at version 0.82, and are expected to reach 1.0 within the year.

So D will reach 1.0 around the release of Java 1.6 Beta.

Re: Fads

[dpbsmith]

Of course.

There are fads in programming just as there are in clothing and management methodologies. And there are always people telling you to adopt the flavor of the month, I mean wave of the future if you don't want to become obsolete.

And you can usually ignore them.

I sat out PL/1, which, well, gee, it had BIG BLUE behind it (in a day when IBM's domination was far more complete than Microsoft's is now). And it doesn't seem to have done me much harm.

True, you can score big by being the person who actually has the "two years experience in" (language-that's-only-existed-for-two-years) that the recruitment ads want, but if you go this route remember that it's easy to be knowledgeable in the latest language if you've just spent some unpaid years in college learning it. If you want to make a career out of always having the skill that's in demand, keep in mind that the only reason the skill is in demand is because it is rare--and you'll need to be quite clever at guessing the next fad, and dedicated about finding out how to educate yourself in it while keeping your day job.

Libraries

[jetkust]

In the end, it may come down to having extensive library support weather this language gets any attention or not. Without having easy to use, easily availiable libraries for sound,graphics,networking etc..., along with support examples and help with the libraries, it may not be worth using the language at all. Sure you can import C/C++ based libraries, but this will all be unmanaged C/C++ code and not protected D code with all the bennifits of D.

Re:Libraries

[Tony Hoyle]

I'm not at all sure how the library compatibility will work in practice... all libraries come with header files, in C, which require a C compiler. Converting them will be nontrivial - especially since they change between versions. You'll end up making D wrapper functions which are no different to Java wrappers or Perl wrappers really.

Nice to see a system language

[wtrmute]

I've seen this language before, and I happen to think it's pretty cool. It's been almost ten years since we've seen a language that isn't compiled to bytecode and interpreted on a VM come out. If I need to write something that compiles to straight Linux ELF/Win32, I'm stuck with C (which I dearly love, but is 34 years old an not even OO) or C++ (g++ gives me terrible headaches, what with refusing to compile code with throw statements), and D is a pretty interesting bare-bones compiling language with very nice features.

Really, kudos to Walter Bright for this little piece. It needn't become popular, if it stays good it's plenty more than enough.

Re:Nice to see a system language

[juhaz]

g++ gives me terrible headaches, what with refusing to compile code with throw statements

What do you mean by that? G++ absolutely does support throw statements. How about an example of code snippet that doesn't work because of throw?

Oh, and you're using 3.3, right? C++ has been moving so fast only recent compilers are any good...

Re:Nice to see a system language

[jareds]

Both Objective Caml and SML (using, say MLton) can be compiled to ELF executables for the x86.

Anyway, native-code compilation versus bytecode compilation isn't a property of a language, it's a property of an implementation. The GNU Compiler for Java exists.

These were pretty arbitrary examples: there are plenty of options for native code executables besides C/C++.

I don't mean to slight D, though!

High Hopes

[Randolpho]

Looks like the D website has gotten a facelift since the last time I checked in on the language. I've had high hopes for the concept. I've often felt that C++ needed syntactic a facelift away from C; I especially hate the preprocessor, and am glad D looks to get rid of it.

The only thing about D that bothers me is the inclusion of the Garbage Collector and several other runtime components that occur in the background of your program. I'm not sure I really like that; it sounds a little *too* close to Java, if you get my drift. What I'd really love to see, and what I hope D inspires if not actually implements, is a language with the power of C/C++, but the easier syntax of Java.

D *seems* to be the first step in that direction. I hope it goes further.

Hmmm....

[shrykk]

C has a masssive codebase, and some real code wizards - we're talking people with 30 years experience. There are mature, free compilers avaiable.

Walter Bright's D is free as in beer but not speech, and there's only the one compiler. Do we really need another language that's a bit like C++?

Re:Hmmm....

[Anonymous Coward]

There is a (surprisingly complete) port by David Friedman to GCC-3.4. It is being used on Mac and Linux with impressive results.

For more information see the D.gnu newsgroup on news.digitalmars.com

Re:Hmmm....

[noselasd]

>another language that's a bit like C++?
Yes. How many do we have that's like C++ ?
None. We have Java,C#,Python and similar things.
BUT, they're interpreted or JIT'ed languages.
But really none(save perhaps objective-c) in the
same league as C and C++.

Success is Elusive

[ChaoticCoyote]

D is certainly a very interesting language;

However, there are many interesting languages. Over the years, I've explored Prolog, Modula-2/3, Oberon, Haskell, Ocaml, and others. All of those embody some very interesting concepts; in some cases. they may be "better" than mainstream languages.

But the fact remains that no one has ever paid me (or anyone else I know) to write code in Ocaml, Haskel, Oberon, Prolog, or D. For the most part, it is C, C++, and Java that feed my family; upon occasion, clients need Python and Fortran 95. I'd love to be paid for a project in D or Ocaml; I'm not going to bet the farm on that happening.

I wish the world of languages (both human and computer) was more diverse -- but reality suggests a hard road to popularity for original concepts like D. I respect and appreciate Walter Bright's abilities; his Zortech compiler paved the way for C++, and provided excellent optimization. I wish him luck in promoting his vision.

D'oh!

[SkimTony]

I believe you're mistaken. D stands for "Duke Nukem Forever."

The delays in release of the game are simply a result of having to wait for a new programming language in which to write the software.

Wishing for this yesterday

[miyako]

Just yesterday I was thinking about how usefull a language like this would be. Java doesn't run too slowly anymore for most applications, but at times it is just impossible to justify it's slowness compared to a natively compiled language. GCJ seems like a good idea in theory, but doesn't seem to really be going anywhere.
Being able to use pointers if need be is also something really nice about this language that I have found that i really long for in Java at times (not so often to actually use, but oh how much easier it would be to explain the way some things work if pointer wasn't a dirty word in java).
I have not really looked at C# much, but it seems to be freed of many of the complaints about Java (lack of pointers for example), but still has the problem of being a bytecode compiled language running in a VM, and adds the problem of being owned by the company that everyone loves to hate (or at least not trust). AFAIK C# also is not C compatible.
I think these facts leave at least a niche for D, and if it's well done it could soon become one of the DeFacto languages of the future. It seems like development has been going on for quite a while on this, I'm honestly suprised that i've never run across it before, since I have been, mostly out of curiosity, looking for just this. I'm not sure how it will pan out, but I am definitly going to give this new language a shot.

actually, the more important reason for exceptions

[jbellis]

is that when you get an error that is properly handled 3 or 5 or 10 levels out from where the error happens, you DON'T want to have to check for that error in all the intervening calls. Your code would be messy as hell, and what happens more often, as you can see in a LOT of C code out there, is the coder pretends the error just won't happen.

Exceptions let you throw the error where it happens and catch it where it makes the most sense, however far down the stack that may be.

D as Delphi?

[Tuqui]

It will be interesting to see how it compares to Delphi too.

Re:D as Delphi?

[certsoft]

It will be interesting to see how it compares to Delphi too.

Although this was moderated as "Funny", I think it's a serious question. It's common, when making what are essentially marketing comparisons, to leave out competitors that would make your target "less amazing".

All the C++ programmers are laughing at you...

[Chemisor]

Every once in a while people try to improve on C++. Usually it is those wet-behind-the-ears kids straight out of college who think that because C++ is too hard for them, it is a bad language. But real programmers just shrug and keep on coding in C++. Let the kids have their fun; they'll come around eventually when they want to write some real code. Maybe someday they'll discover that garbage collection is not necessary when you know who owns your memory and encapsulate allocation in logical places, like STL containers. They'll discover that C++ already has overridable operators, full (well, all that matters, anyhow) C compatibility, native compilation (VMs are for script kiddies), inline assembler, and in-built support for unit testing (called a debugger). And as for "Design by Contract", good luck getting any contracts in your new D.

Re:All the C++ programmers are laughing at you...

[rblum]

Yep - totally agree. But the guy behind D is not a wet-behind-the-ears college kid. He wrote one of the first C++ compilers for Zortech.

So if somebody with those credentials thinks there are things we could do better, maybe we should at least take the time to listen to him....

Obsession with C-like syntax

[Bander]

I don't understand why these people keep designing C-like languages that are nothing like C. By the time they are done, the resulting language has so many more features than C, the surface similarity is more of a boondogle than a benefit. While not perfect, C syntax is great for what C is, "human-readable assembly language". When you try to extend it to object oriented systems, the end result is a confusing mess.

There are far better syntax models for an object-oriented programming language than C. I wish people who feel a need to create new languages were willing to base their efforts on a framework more suited to their goals.

Bander (in curmudgeon mode)

Re:Obsession with C-like syntax

[skeptikos]

I think it's kind of a marketing issue. When a new language is proposed and does not look like C but more like Ada/Pascal/Modula etc many programmers will just say "It is so verbose, there is no ++ operator, and it shoud use braces, they save LOTS of typing!". Who cares if the programs are more readable. I happen to be interested in programming language design, and I have asked some programmers "What would an ideal language be like". They all answer "Oh, it should be like X, but with feature Y", where X is their favorite language and Y is their favorite (usually superficial) missing feature of X. Stangely, nobody answers "It should use garbage collection, it should have easy to remember operator precedeces, it should disallow jumping into data, it should have optional array bound checking" and so on. People just look at superficial properties of the language, mostly the lexical part. They don't even get to the context free part, and forget about semantics. If it looks like C/C+/Java (which they know) it must be like C/C++/Java (and they feel confortable)

this is strikingly similiar to Pike

[Anonymous Coward]

from Pike website:

Pike is a dynamic programming language with a syntax similar to Java and C. It is simple to learn, does not require long compilation passes and has powerful built-in data types allowing simple and really fast data manipulation.

Syntatically, D is almost identitical to Pike, like the foreach and the range operator "..". Pike is also loosely object oriented, and has a rich set of libraries just like Python, Perl or even Java.

I'm not sure if the Author has borrowed ideas from Pike, but it is is really a great language that has been around for 10+ years, tested in real world applications.

Re:Toss out C.

[endx7]

Guys, it's time to face the facts. C is a relic from a time when compilers were stupid. Declare all your variables before executing code, declare all your functions before using them, include headers that almost invariably break one another, hurrah.

I'm so glad that every time I write C I get to write each function signature several times, that's lovely. In addition, C takes much more time to compoile than Java/C# because all the stupid headers take forever to parse.

What will you use for your low level device drivers? Or how about that code that needs run fast? I don't know about compile (C does compile faster than C++ though), but C runs faster than java and C# (only -sure- about the first one). In fact, the java virtual machine and compiler are both written in C. Face it, C isn't dead yet, even though people have been trying to say so for years.

So, in conclusion, C compatibility is a bug, not a feature.

Other posts have mentioned this is -link- compatibility. Remember, D is meant to live in the real world as a binary outside of a vm. Link compatibility becomes a pretty damn useful thing when you need to work with other people's libraries.

Re:the most interesting part of that table

[ThosLives]

Actually, the most interesting thing I saw is that D defines a type 'ireal' which is an imaginary number. They also have 'creal' which is a complex number. What's funny to me is that, by definition, imaginary and complex numbers are not real at all.

I found this immensely amusing...and yes, I know that's sad.

How about Eiffel

[charnov]

I'll admit I suck as a programmer, but Eiffel was the first language that actually made sense to me and from what I have been told (I have to trust others on this one), it generates extremely clean and safe programs.

A feature every language should have

[bangular]

Speaking of perl...
I really wish lanugages would start implementing the ~ operator from perl (as with $myvar =~ /expression/). From what I understand Ruby also has it. I'm tired of having to deal with pcre's little caveats (as implemented in php, python, java, c, c++ etc.). Such as having to compile the expressions beforehand. Or having to play the backslash game \\\\n to get a newline. There's nothing nicer than being able to have a regular expression that does exactly what I want on one line with minimal code. When programming in perl I tend to use the =~ operater almost as much as the == operator!

D does not have dynamic classloader

[Guardian of Terra]

This is a very very big problem. Plugin problems, binary compatibility problems, DSO problems, vtable format problems, and all other things we hate in C++ and that absent in java/c++

P, not D.

[IGnatius T Foobar]

Wow. The "D" developers don't know their C history if they chose that name. There was a language called BCPL, which begat a subset called B (the first letter of the name), and then its successor, C. Therefore the next successor would be called P, not D.

Buncha wetbacks. :)

Re:P, not D.

[tpv]

Supposedly B was not actually named after BCPL

See the Wikipedia

Re:Toss out C.

[Anonymous Coward]

First off, it's link compatability with C. Secondly, no matter how archaic/simple/boneheaded you find C it's still the lingua franca of systems. More so, any system without any link level compatability with C is not really that useful.

Re:Toss out C.

[Jorrit]

I believe it all depends on what you want to do. For most system software (where security is very important) I would agree with you. Also for big application software (like word processing and stuff like that) I would also tend to agree.

However, I'm not sure I agree for software where security is little or no concern but speed is the main issue. One example of that kind of software is games. I'm author of a 3D engine in C++ and I also program in Java for a living. I think that for things like these low-level languages like C and C++ are still the way to go. You can argue that computers are getting faster and faster. But user expectations about what those games can do are also constantly rising.

Greetings,

Ooops

[EnglishTim]

Meant to post that anonymously...

I refuse to support D

[maunleon]

Cuz it makes it hard to google for "D".

Re:I refuse to support D

[XBL]

Actually this is a good point. If I want Java help, I can search for "Java SOMETHING" and the search results will likely be good. "D SOMETHING" will not work.

Re:Toss out C.

[St. Alfonso]

OK, let's take your advice. No more C. Goodbye Unix - OS kernel written in C. Goodbye interpreted languages like Perl, that have their interpreter written in C. Goodbye device drivers. Most of these are written in C. Have fun re-writing all these things in D/Java/whatever.

Full C compatibility sucks

[squarooticus]

Being a long-time C++ software engineer (10+ years), the biggest thing that irritates me about C++ is backwards compatibility with C. I would love to have to explicitly cast everything, including between signed and unsigned scalars: in such a case, it is perfectly clear to the programmer when he is performing a type-mismatched comparison or assignment, something that has bitten me often in the past.

In sum: C++'s biggest problem is its C legacy. Tear it away, add real type-safety, and you have a language much more powerful and safer than Java.

Re:actually, the more important reason for excepti

[arkanes]

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.

Re:the most interesting part of that table

[Trejkaz]

Troll away, maybe people will start paying attention when the dozens of useful Java libraries are available from C#. *shrug*

What I really need right now though is a nice, clean looking language with access to well-thought-out libraries for image loading/saving and virtual filesystem access. I can't find any of this stuff in a portable form other than on Java, unfortunately. :-(

Re:The preprocessor is archaic?

[bradkittenbrink]

I didn't find how it deals with endianness specifically, but the idea is that D replaces a text-only preprocessor with actual sybolic features of the language. They definitely have support for conditional compilation and inline assembly code so I'm sure you could do whatever you need to handle endianness without a text-based preprocessor. The preprocessor itself isn't necessarily archaic, it's just unneccesary if your language isn't archaic.

D WON'T compile C code

[21chrisp]

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.

D converts code to C

[noselasd]

Just fyi, D is really a frontend. It generates C code, which is then
compiled with your ordininary gcc. Nice imho so you get great speed,
and don't have to write a compiler again ;)

Re:D converts code to C

[digitaldaemon]

No, it compiles natively.
Walter Bright, who also wrote the first native C++ designed the language and wrote to compiler for it. The compiler shares the same backend as his C and C++ compiler.

ManiaC++

I was hoping for more C

[mnmn]

Garbage collection? Java-like? I thought the world was finally beginning to hate Java.

I'm not sick of C at all. I was hoping for more like ANSI C 04 or something (like ansi c99), more low-level, more control, less objects, less behind-the-scenes crap like garbage collection. The quality of code is always higher with C than C++, unless VERY well programmed with C++, and for that reason alone, C code is reused more despite being less reusable. C++ allows for more cheap right-out-of-college employees, while C gives us quality code that lingers for decades. Think UNIX for a second, and give me an example of something in C++ that has lived so long and so well.

I hate fatter higher-level languages, and we all seem to hate backwards compatibility. If a language has 100 keywords, and you make the next version backwards compatible with 100 more keywords, any sample code can have 200 different keywords in it. Thats making it all tough. C is like RISC, fewer instructions that can be used more creatively, so a smaller amount of code can give you more functionality.

Its all a conspiracy by computer manufacturers. Say you come up with a language that produces binaries slower than Java, all of a sudden a Pentium 3.0GHz with HT is too slow for it, the market keeps pushing for faster and capitalism works. doesnt matter at all that you can run a file/print/mail/application/web server on a 386sx or an ARM MCU 2mm^2 in size running some operating system made in C.

Shenanigans

[Anonymous Coward]

features include...garbage collection...full C compatibility

I'll have to call shenanigans on this, as these two features are mutually contradictory (or at least "real" GC is contradictory with full C compatibility).

Now before anyone goes on and on about the existence of GC for C/C++, my definition of "real" GC is that it has to be a NON-conservative, compacting, ephemeral collector. Collectors outside this definition have their place: they help you clean up leaks. But they cannot guarantee two features which are crucial to collectors in any modern language: safety and speed.

Safety. You just can't tell the difference between a pointer and an int in C. Thus there are all sorts of ways of hiding pointers as ints in the language, causing memory leaks. Conversely, if you've encoded a pointer in some way, or have allocated hanging off the edge of a struct (a *very* common occurrance -- Objective-C uses this as its basic objejct storage procedure underneath, or used to) the collector may reap your memory before you're done using it. Ungood.

Speed. One of the things that makes HotSpot kewl is that it moves around memory as it does collection; as a result long-lived objects get compacted together, taking advantage of cache loads. This can't be easily done in GC if it's not allowed to fool with your pointers safely.

The point of garbage collection is to be ubiquitous and invisible. This isn't possible in C/C++.

Re:Toss out C.

[m.koch]

Now on to preprocessor macros. They are useful in statically compiled languages, but in dynamic (VM based) languages they are less than useless. The VM will take any code that it can and inline it, propagate constants, etc.... Macros are not needed.

I think this is more or less a wishlist, at least concerning Java. E.g. using a method in a loop condition has dramatic impact on performance. The Java VM does not determine if a method has no side effects.
Also there is more to a preprocessor than macros.

C++'s successor is already here....

[callipygian-showsyst]

...and it's called C#!

Now before you think I'm nuts, I was skeptical, too. But after programming in C# for the past year, I absolutely love it. The language is perfect. Why design another one? Just make sure good Open implementations get done for it, and leverage all the good design work Microsoft has done!

Re:Toss out C.

[happyfrogcow]

Declare all your variables before executing code

Leads to cleaner code, in my opinion. C++ doesn't require you to do it, but I still do.

declare all your functions before using them

What's the big deal about this? If your tired of typing, you either need to learn to copy/paste, use an IDE that will generate code for you, or find a new industry.

C takes much more time to compoile than Java/C# because all the stupid headers take forever to parse.

Ever hear of "Make" and "Makefiles"? You don't need to keep recompiling things than havn't changed.

Pointers are a problem because they allow unsafe code that forces the hardware to make up for lack of security in the software. Repeat after me, security is a software problem.

Pointers, in some capacity, are needed for low level programming. If you don't need access to hardware, then you might have a reason to consider something besides C.

Dropping multiple inheritance ?

[DerFeuervogel]

While I agree with many of the changes, I think the dropping of multiple inheritance is probably a mistake. This comes in very handy when defining interfaces for object compartmentalization - as in Microsoft's COM.

Re:Dropping multiple inheritance ?

[bradkittenbrink]

Which is why they do include support for interfaces. I don't think you understand the disadvantages of multiple inheritance. I've never found a situation where I actually required the additional functionality that multiple inheritance allows and coudn't be done better with just interfaces. Plus, if you were gonna copy multiple inheritance from c++ you'd need to copy all those nasty casting operators.

Re:Dropping multiple inheritance ?

[the_Speed_Bump]

This would be a bigger deal if D templates weren't as robust as they are.

It's quite a simple matter to write template classes that extend their template argument. In this way, you can arbitrarily compose things any which way you like in a way that very closely resembles multiple inheritance.

Of course, it requires a bit of work, but it's my understanding that implementing MI involves making the compiler very arcane and complicated. One of the goals of D is to be easy for compiler vendors to implement correctly. (no waiting 10 years for a correct compiler!)

Re:Dropping multiple inheritance ?

[Anonymous Coward]

With multiple inheritance in C++, there was not a standard way to layout the object in memory. If C inherited A & B, sometimes the objects inherited from A would be allocated first, but sometimes those from B (in the same program). While I can't remember a specific issue that came up from this, it causes non-deterministic behavior, debug vs. release issues, etc. Debugging is hell because of it.

Re:Dropping multiple inheritance ?

[shiftless]

Multiple inheritance is awesome and indispensible- when you find a language that implements it well. See Eiffel.

Re:Dropping multiple inheritance ?

[slamb]

I've never found a situation where I actually required the additional functionality that multiple inheritance allows and coudn't be done better with just interfaces.

How about StreamSocket. Okay, multiple inheritance isn't required in the strictest sense, but object-oriented programming isn't, either. MI makes this class make much more sense - it is both a stream and a socket.

In a language providing only support for multiple interfaces, you'd have to reimplement at least one of those in the derived class. You'd probably end up just dispatching all of the calls in the derived class to a shared implementation elsewhere. Not nearly as clean.

Or you could pull a Java and have a getStream() method on the StreamSocket. (Make the caller do the dispatching to the shared implementation.) I don't like it either.

Plus, if you were gonna copy multiple inheritance from c++ you'd need to copy all those nasty casting operators.

I don't see how eliminating MI makes any of them unnecessary:

• static_cast<> - still useful. I like saying "make it an error at compile-time if this can be false". Catching errors earlier = more goodness. C didn't have this, but C didn't ever have a way of knowing one structure could be cast to another safely, since it lacked OOness (inheritance, specifically). Also better performance than a dynamic cast.
• dynamic_cast<> - yup, still useful. A little simplified (it would always return the same actual address or NULL). This is basically what Java's cast is.
• const_cast<> - nothing to do with MI. (Nonexistant in Java because Java doesn't have constness at all.)
• reinterpret_cast<> - nothing to do with MI. Necessary for backwards-compatibility with C stuff.

Google incompatible

[uncadonna]

In addition to D, there's another interesting language called J, not related to Java at all but a descendant of APL. And in today's news there's also a story about X.

Exactly how are we expected to Google for such things?

Please give your projects distinctive names with more than one character, thanks.

Re:Google incompatible

[zhenlin]

I call my new operating system \u7985. It is precisely one character, but it says a lot!

(Also, hats off to anyone who can convice slashdot.org to enable HTML entities in such a way that page-widening posts still don't work)

It's not entirely closed source

[the_Speed_Bump]

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

ABA Games uses D

[billcopc]

ABA Games, that wacky psychedelic asian dude writes shoot-em-ups in D. I think the D is for Drugs.

http://www.asahi-net.or.jp/~cs8k-cyu/index_e.htm l

OBJECTIVE-C: APPLE VERSION?

[tyrione]

Nice to see once more another myriad of articles that espouse all sorts of wonderful capabilities while either due to ignorance or purposeful deception leaves Apple's Objective-C compiler out of the comparison list.

No matter. All in due course.

Re:OBJECTIVE-C: APPLE VERSION?

[JPyObjC Dude]

I could not agree more. The OpenStep and OSX developers will have their day in the limelight. Objective-C still has a future and I know when I start doing more app development that I will be using Objective-C in combination with Python and Java.

Apple has the correct paradigm and it's just a matter of time until other developers realize this. We do not need another language!!

I would not be suprised if M$ is somehow behind this to further confuse entry level developers....

Java is fast.

[Kombat]

You have no idea what you're talking about. I have mod points, and already modded in this discussion, but you are spouting such clearly incorrect nonsense that I feel compelled to respond anyway, lest any newbies actually think you know what you're talking about, and repeat your nonsense.

What will you use for your low level device drivers?

C. There you go, congrats, you found one use for C. Now, I ask you: How many low-level device drivers have you written lately? I've never written any, and probably never will. I would wager that over 99% of Slashdot readers are in the same boat as me.

Or how about that code that needs run fast?

Sigh. Go read some benchmarks. JIT-compiled Java is just as fast as C/C++ for virtually everything. You are apparently unaware that compilers have been steadily advancing for several decades now, and are actually extremely sophisticated and smart. They are very good at what they do. When you execute a Java program, nothing is interpreted. It is compiled to optimized native code and executed full-speed.

Actually, in some cases, Java code is faster than C code. When you compile a C program for an x86 platform, you compile to the lowest common denominator. Your compiler cannot assume the presence of advanced instruction sets, like MMX or SSE2. It must restrict itself to outputting code that will run on a 386. A Java interpreter, on the other hand, already knows what platform it is running on, because the native compilation happens at run time, instead of compile time. Thus, it already knows what CPU it is running on, and can take advantage of the precise instruction set availble on the host CPU.

In fact, the java virtual machine and compiler are both written in C.

This was the comment that really had me screaming "You IDIOT!" at my monitor. The Java compiler is written in Java, not C. It lives in com.sun.javac.Main. Go look at the "javac.exe" executable. It's tiny. Know why? Because it's nothing more than a native bootstrapper that executes java com.sun.javac.Main <args>. The interpreter is, in fact, written in C. But the compiler is 100% Pure Java (TM).

Don't believe me? Look disassemble it and look at the code. That should be easy for you, what with your professed experience writing low-level device drivers, eh?

Re:Java is fast.

[Kombat]

Are you planning on compiling custom binaries for every platform? Heck, most users have enough trouble deciding whether they're supposed to download the "Windows or Mac" installers. Are you suggesting it is practical to compile your app for every conceivable platform and CPU combination, and allowing your users to select the one appropriate for their configuration?

With Java, you'd just download the one JAR file. The user already has the correct, optimizing runtime for their platform, and that will take care of optimizing your bytecodes to the proper target platform instructions.

Limbo is the only legitimate successor of C

[CondeZer0]

The clear successor for C is Limbo.

Limbo was developed in Bell Labs by the the same people that created Unix, C, and Plan 9, and someone once described it as "the language the creators of C would have come up with if they had been give and enormous amount of time to fix and improve C", that is exactly what Limbo is.

Dennis M. Ritchie: The Limbo Programming Language
Brian W. Kernighan: A Descent into Limbo

Together with Inferno, Limbo forms the best platform for distributed applications.

Inferno and Limbo were recently released under an open source license and you can download them here:

http://cgi.www.vitanuova.com/cgi-bin/www.vitanuova .com/idown4e.pl

Inferno/Limbo are the only hope for some sanity in the software industry!

Best wishes

uriel

Re:Limbo is the only legitimate successor of C

[Dawn Keyhotie]

To quote from the lead-in to your referenced documentation by Kernighan:

"Limbo is strongly typed, provides automatic garbage collection, supports only very restricted pointers, and compiles into machine-independent byte code for execution on a virtual machine."

This pretty much disqualifies Limbo as a successor language to C. C is a systems programming language, not a byte-code interpreted play-toy.

Cheers!

enumerated types

[elbarrio]

The comparison list shows that Java doesn't have enumerated types. Thought it was worth mentioning that java will soon have enumerations in release 1.5:

java 1.5 spec

Inaccurate comparison sheet

[AArnott]

Whoever put the comparison sheet of D, Java, C#, C++, and C together needs to be more careful. It claims that C# has no inner classes. Which it currently has. Also the comparison sheet claims many things are unique to D, which in fact are supported by the C# 2.0 specification. "C# 2.0 isn't here yet" you say? Neither is D. In fact, the D spec is only at rev. 0.8x.

Re: Fads

[Decameron81]

I agree with your post on most of your points.

However I just look as this forum and I can't fail to notice that most of the mainstream languages are so because of what they can offer to a certain target of people. For instance you can see how C / C++ remain unbeaten in the low-level programming field. A friend of mine told me perl is used a lot in science (and web programming as well). Something like Java is quite useful for multi-platform development. Visual Basic makes fast development for Windows true. And of course other languages have their purposes too.

So to put it simple, I get the feeling that the future will divide programmers into different fields of programming. Much more than we are split now, that is. So I am not sure that the "wave of the future" will be just one winner, like it's been in the past. I already can see that there are several winners for several different reasons.

My 2 cents,
Diego Rey

Screw More Languages

[4of12]

After Java and C#, why do we need yet another rendition of "what C should have been"?

As far as I'm concerned the standards for C (89,99) are a reasonable place for this language given all its history.

More than anything else we need more standardization of libraries, in the same vein as libc or the STL, but updated to include almost 20 years worth of experience with all kinds of drivers.

• Java provides these and cross-platform which is really nice, but Sun effectively owns final say on the standard.
• Microsoft provides libraries, but MS owns the standard and changes it around for various marketing purposes.
• Apple provides nice libraries, but they own the standard and they don't seem to want to open it up.

Programmers don't need a new language as much as they need powerful, open, standardized, updated libraries.

D? D?? Read your history!

[elhaf]

D? Don't you geeks have any sense of history? The next language in line is P. The first language derived from BCPL was B, then C. Next is P, then L.

Re:actually, the more important reason for excepti

[DrXym]

Exceptions in C++ are just horrid. You might catch an exception and but not have the faintest idea who threw it. And C++ doesn't even enforce exception handling - you have no idea if a function throws an exception unless someone declares it explicitly. And the compiler won't care if you don't you put try / catch blocks in for it either. Even worse for Win32 programming are that #imported COM interfaces throw _com_error exceptions rather than return an HRESULT, making it a massive pain in the arse to program ADO or anything like it - a single uncaught exception can kill your app or make it fall out of functionality in a very bad way.

I have no problem when exceptions are done properly as in Java, but using them in C++ is an exercise in frustration.

Re:What about Objective C?

[Zobeid]

As best I recall, both Objective C and C++ were introduced about the same time and for the same purpose: to add OOP support to C. For some reason the marketplace chose C++ and made it successful and widespread while Objective C languished. Why? I have no idea. . . From my admittedly limited experience with both languages, Objective C appears to be a lot easier to work with.

I agree that the world doesn't need yet another extended C. If you're going to build a modern buzzword-compliant language, build it from scratch!

Considering the era C came from, it's a fundamentally good procedural language. Not perfect. Probably not even great. Just good.

In particular, its terse syntax and heavy reliance on operators instead of keywords makes C code dense and hard to read. You can write readable C code, but it takes a conscious effort, some documenting, and some discipline *not* to use every clever coding trick that pops into your mind. (I've read one opinion that C really stands for Clever, because it encourages you to do all sorts of excessively clever things that you'll later regret.)

The reason why the whole software industry seems hell-bent on created mutated versions of C, several decades later, is beyond my understanding.

They should have a form for ppl with a C successor

[iamacat]

... like they have for a spam fighters and for physics. Also, wait until the language is tremendously popular before claiming K&R fame and calling it "D". Even Microsoft is more humble.

Probably the language's greatest goal is the elimination of archaic and/or needlessly complicated features. For instance, D does away completely with the C preprocessor, relying instead on built-in versioning capabilities. Forward declarations are out the window on the same token. Also, it replaces the often-complicated multiple inheritance of C++ with Java's single inheritance and interfaces.

Thank you very much, but we can already write a program without using the features we don't like. If that's a primary goal of your language (as opposed to side effect of offering some advanced features like GC), I think I'll pass.

Besides, multiple inheritence is useful and meaningful when your object really both an InputStream and an OutputStream. Duplicating default code or having a A where every method calls B->method is just silly.

As for C preprocessor, it can be used to do enormous work in a page of code. Like auto-generating stubs for hundred functions that get a mutex, call the original function which is not thread safe, release the mutex and return the original function's results. There are solutions for each specific use, for example Aspect-based programming. But there is still a need for a tool that can more safely extend language's grammer without writting a complete parser first. Until then, let's just use the only one available, but only when templates, aspects and such don't solve the problem. In fact, I want JPP, especially for #ifdef.

Nope, ain't gonna do it.

[Zobeid]

10 years of pain and suffering. I feel sorry for those who must code C++, like it or not, to put bread on their table. No, I'm not going to use C++. I'd rather use Objective C. I'd rather use ANSI C. Heck, I'd rather use Java.

I'd even rather try to bend my mind around Smalltalk. . . the original object-oriented language, in case anybody forgot. Squeak Smalltalk is open source, cross-platform, and seems to be pretty powerful. It's just so damned *alien* though. It's like something that dropped through a wormhole from some alternate reality. (I suspect Squeak would be much easier to learn if I'd never been exposed to any normal programming languages.)

Re:actually, the more important reason for excepti

[cheide]

Oh! sure, nice, but then the problem is with resources allocated on those 3, 5 or 10 'skipped' levels during exception handling.

Most resources *should* automatically free if they were allocated on the stack, wrapped in an std::auto_ptr, or a guard class whose destructor will do whatever's necessary.

If one of those layers has a resource it knows has the potential to leak anyway, it can add its own exception handler, catch the exception on its way back, release the resource, and then rethrow the exception.

Of course this is still the fundamental problem with languages like C++ -- it works great, *if* you have the discipline to do it properly in the first place...

Nice Comparison

[Elladan]

Heh.

Nice feature comparison, except for the fact that it's wrong. Perhaps the authors of D would do better if they actually learned C++ first? Designing a new language when you're clueless is the first sign of disaster. Look at Java.

Resizeable arrays: D Yes, C++ No

BZZT.

Arrays of bits: D Yes, C++ No

BZZT.

Built-in strings: D Yes, C++ No

BZZT.

Array slicing: D Yes, C++ No

BZZT.

Array bounds checking: D Yes, C++ No

BZZT.

Associative arrays: D Yes, C++ No

It's called a map.

Inner classes: D Yes, C++ No

BZZT (perhaps they meant specifically the automatic parent resolution?)

typeof: D Yes, C++ No

BZZT.

foreach: D Yes, C++ No

BZZT.

Complex and Imaginary: D Yes, C++ No

BZZT.

Struct member alignment control: D Yes, C++ No

Give me a break, every C++ compiler supports this. It's just implementation defined.

Now go look at D's page on Design By Contract in C++: here

Notice that any C++ programmer can come up with a far better implementation than theirs using child class destructors and inlining. In fact, Stroustrup even put one in his book in case you're having trouble getting the brain in gear.

The comparison list combines cluelessness and sophistry ("C++ doesn't have this feature! It's in the STL, not the language" - oh please) to try to promote their own half-baked language.

Conclusion:

Yet another half-baked useless language.

Don't need to imagine -- it was the whole point

[devphil]

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.

I'm glad they kept operator overloading

[AArmadillo]

Operator overloading is a huge syntactic blessing, and its abscence in Java is one of the reasons I hate using it. It takes a highly abnormal amount of kludge in a language without operator overloading to compare two objects. For example, in Java to compare of one array element is less than another:

if(((Comparable) a.get(0)).compareTo((Comparable) a.get(1)) == -1)

This is horribly ugly, especially when all I want to do is compare two integers for size. Casting, parenthesis everywhere, comparison with some arbitrarily chosen integer, etc. With operator overloading and templates, the same thing is possible in a much cleaner and more intuitive fashion:

if(a[0] < a[1])

It doesn't take any 'work' to understand what this code does. A ten year old kid could probably tell you that it involves 'less than'. This is also type-safe (I don't have to worry about if my objects actually inherit from Comparable).

I like D. In my ideal world it would replace all uses of Java everywhere and anywhere, but unfortunately I doubt that will be the case.

The problem with C++

[Animats]

D is Walter Bright's improvement on C++. Bright wrote the original Zortech C++ compiler, which was one of the first real C++ compilers, as opposed to a front-end for a C compiler. D is really too similar to the other C++ variants to get much traction.

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.

Re:The problem with C++

[Zobeid]

You had a minor inaccuracy there. . . Objective C should not be listed as a "variant" on C++ or any kind of spinoff from it. It's a competitor. I'm not sure which one was invented first, but I remember clearly that both C++ and Objective C were introduced around the same time and both competed to be the widespread successor to C. C++ won that competition, though the reasons why are obscure to me. I rather like Objective C, and it's still the preferred language for application development on Mac OS X (that's a legacy from NeXT).

Amiga E

[LentoMan]

There is already a programming language called E for Amiga:
http://wouter.fov120.com/e/

Re:Table errors regarding c#

[ad0gg]

They are ojbect collections. Not a collection of your specified type, until .net 2.0 comes out with generics. It won't have resizable arrays.

Going down the chart point by point...

[Chuck Messenger]

OK, I delved into D a bit more. It does look like a very interesting language, now that it has templates. Some comments, going down the cart (considering D in relation to C++):

Function literals This is excellent. Function literals would make C++ a much better language. The STL cries out for them. While Java doesn't have function literals, it has something pretty close -- anonymous nested classes. But C++ has nothing very close. The best you can do is something like the Boost lamba library, which while impressive, it quite horrible. This feature makes D pretty interesting to me.

I'd be interested to know what D has in terms of standard libraries -- something akin to the STL..?

Dynamic closures Not sure exactly what this is, but I imagine it makes D into a fully-functional language. Sounds great! It makes me even more interested.

Resizeable arrays Well, I don't think this claim stands up -- that C++ doesn't have resizeable arrays. After all, since D is a garbage-collected language, I'm guessing its arrays are on the heap, not the stack. C++ has resizeable heap arrays -- vector, etc.

Arrays of bits Again, I take issue with C++ not having these. Check out Boost::dynamic_bitset.

Built-in strings Once again -- no way. C++ certainly has built-in strings, in any meaningful sense of the word -- std::string.

Array slicing I'd be intersted to see an example of how D's array slicing compares to C++'s interator-based programming. I'm not sure what's being talked about here, exactly.

Array bounds checking There's really no meaningful way you can say C++ doesn't have array bounds checking. Come on! What C++ has, which might be much better than D, is switchable array bounds checking. You don't _have_ to check array bounds (e.g. for release builds), but it's trivial to add if you want it.

Associative arrays Wrong! C++ certainly has associative arrays. They're quite excellent. See std::map and std::multimap. And of course, you can build any special sort of associative array you want -- say, a hash.

This chart is completely biased against C++ -- quite unrealistic. Why not just stick to the _real_ benefits D has over C++, and not kick up alot of FUD? It only serves to make people like me (rightfully) skeptical.

Strong typedefs OK, fine -- typedefs aren't strong in C++. But if you want something to be strong, make it a class/struct/enum. Why do typedef's need to be strong? What's really being said here is that D lacks a "type alias", which is what a C++ typedef is -- just a shorthand for another type. Does D have that?

String switches Just syntactic sugar, although I admit it might be nice syntactic sugar.

Multiple Inheritance An unfortunate deficiency of D. I find multiple inheritance to be quite useful. But D can't have everything -- that's OK. If this were D's only deficiency, it wouldn't be fatal to me, especially because...

Interfaces ... interfaces get you _most_ of what's good about multiple inheritance. But not all.

Dynamic class loading This is a nice thing about Java. Too bad D doesn't have it (but hardly a fatal problem, for me).

Inner classes Seems like D's functional programming capabilities trump the lack of inner classes...

Covariant return types Ummm -- what are these? C++ has them, so I must know what they are....

Properties Syntactic sugar...?

Inline assembler
Direct access to hardware
Direct native code gen Excellent. However, one reason I really like C++ is that there are toolchains for a huge variety of hardware. If there were a gcc front-end for D, that would go a long way to addressing this issue...

Lightweight objects Meaning, stack-allocated objects?

Explicit memory allocation control Does this mean D has _real_ destructors (unlike Java's pseudo-d

Against the grain...

[mattgreen]

In the midst of the, "it's not C it sucks," and "it has a GC only real programmers manage memory," and other bullshit arguments you're just ignoring what is generally a much needed cleanup of C++ that isn't terribly more complicated than the original C. I'm not saying you have to like it, but everyone seems to have read the tag line and not actually gone to the site. Walter is very thorough about why he made the choices he did. The only real point I've seen in all the posts was that it needs dynamic class loading, and I've wanted introspection to at least be an option. Also, I disagree with the syntax he used for templates, but that is a minor issue.

With C#'s generics being somewhat gimped and users working on a functional library for D that is similar to STL but easier to use, D is really shaping up nicely as a future development platform and a bleeding-edge language, kind of like what C++ is today with template metaprogramming. I tend to gravitate towards the looser, more esoteric languages like Perl and C++ because of the steep learning curve -- who doesn't enjoy a challenge?

So don't bitch about how it sucks because it isn't C. It's amazing C is still kicking.

" ... the most important thing

[baudolino]

in the programming language is the name. A language will not succeed without a good name. I have recently invented a very good name and now I am looking for a suitable language." -- D. E. Knuth, 1967

Here's one

[sacrilicious]

I'd like them to come up with a better name [than "D"]

How about "Double-D"? *That* will bring out the programmers in hordes.

Save the Game Industry?

[Mr.Oreo]

I'm a long time C/C++ coder, mostly working on games or other real-time apps. Right now, I code in Java (J2ME for cell phones), and after some hiccups, I have to say, I really really like coding in Java. Syntactically, it's beautiful. Code is easy to read, it's super easy to dive into a project and just start working. Eclipse is great to work in, and the MIDP and CLDC libraries are very well designed.

Popping into a big C++ project (a moder day AAA game for instance) means spending about a week or so of JUST surfing the source tree to find out where everything is and how everything pieces together. In Java, I spend next to no time at all surfing source trees. I can just dive in, and work. A lot of teams get bogged down making engine code work with game code, which means a lot of refactoring.

Example? When Maxis was working on Sims Online, they spent a large portion of their time (and budget) refactoring nearly 1 million lines of code from the previous team (who had left because of the EA buyout IIRC). At it's peak, they had around 50 engineers refactoring it.

The only reason game developers aren't using Java, is because it's slow, and not suited for games at all. The speed improvements in 1.5 still mean absolutely nothing to anyone who is looking to push hardware as far as possible.

For many years I've been praying for a natively compiled Java that has a built in assembler (a lot of intense code still uses assembly for access to processor extensions), some of syntactic rules as Java (all classes in their own file, no multiple inheritance, which I'm still not 100% sure was the right idea).

I'm stuck using Java for my current project, but in the future, I hope to God that D takes off and becomes the generally accepted successor to C++.

Perhaps the developers should really look to the games industry and listen to what they have to say, since their one of the only software industries that are pretty much exclusively compiled only (C/C++ onle).

Re:C++ rights&wrongs and predictions for succe

[Animats]

I tend to agree with much of the above. But I think that Java and C# are the "next big languages" for the present.

Strostrup does say that he's reasonably happy with the basic language. I don't agree. If the basic language was OK, there wouldn't be a need for C#, etc.

C++ has some major outstanding problems, dating from early bad design decisions. Not just C legacy problems, either. Here's a few of them:

• The original C++ language had no templates, no exceptions, no run time type info, and no references. This led to a horrible programming style in the early years, with big ugly macros, no standard way of handling errors, wide use of unchecked downcasts, and "this" as an assignable pointer. Much of that legacy lives on in running code.
• You can't implement safe smart pointers in C++. No matter how hard you try, you can't make auto_ptr work right. It's been formally revised three times, without success. The problem is that you have to let a raw C pointer out of the encapsulation to do anything with the object, and that pointer isn't "special" to the language. There needs to be a const-like attribute that says "this pointer can't be deleted or copied to an outer scope". Then you can build safe encapsulations.
• Iterators and references were both afterthoughts. They should have been a fundamental part of the language. C's ambiguous syntax for pointers, which makes a pointer to an object and a pointer within an array indistinguishable, shouldn't have been perpetuated in C++.
• A major effort should have been made to make built-in arrays obsolete. Even today, you still see extensive use of C arrays in C++ code. They should be unnecessary. To this day, you can't say "no C arrays or pointers allowed in C++ code" on a project. If you could, there'd be far fewer buffer overflows.

None of this is being fixed in C++. That's the problem