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

wow

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

Oh, wait...

Re:wow

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

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.

Here's one

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.

Re:wow

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

Yeah - turn up that thumping music man!!!

Re:wow

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

Wikipedia: B Programming Language [wikipedia.org]

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

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

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

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

Visual D

Cue loads of VD jokes :-D

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

I was thinking Double-D.

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

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

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

full C compatability?

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?

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?

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?

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?

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?

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?

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

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

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.

Re:full C compatability?

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?

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?

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?

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?

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?

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.

Old news

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

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 [memtest86.com] 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 [joelonsoftware.com].
• 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.

Obligatory java response...

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

Re:Obligatory java response...

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.

That's because 1.4 is the CURRENT version

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

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

Re:That's because 1.4 is the CURRENT version

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:Obligatory java response...

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

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

Sounds like a good idea

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.