C, Objective-C, C++... D! Future Or failure? 791
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."
Obligatory java response... (Score:5, Informative)
D @ Google (Score:5, Informative)
Computers > Programming > Languages > D [google.com]
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?
Summary (Score:5, Informative)
Re:full C compatability? (Score:5, Informative)
Re:Obligatory java response... (Score:5, Informative)
Comment removed (Score:4, Informative)
Re:try, catch, finally (Score:1, Informative)
In
Furthermore, at least in
Re:Toss out C. (Score:3, Informative)
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:Toss out C. (Score:2, Informative)
Re:Old news (Score:1, Informative)
Re:actually, the more important reason for excepti (Score:5, Informative)
Re:the most interesting part of that table (Score:4, Informative)
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:full C compatability? (Score:3, Informative)
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 [iecc.com]. 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? (Score:3, Informative)
Re:The preprocessor is archaic? (Score:3, Informative)
D WON'T compile C code (Score:5, Informative)
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.
Re:full C compatability? (Score:3, Informative)
> 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:Hmmm.... (Score:2, Informative)
For more information see the D.gnu newsgroup on news.digitalmars.com
C* (Score:1, Informative)
C* actually is a language. It is the C-like parallel language used mainly on Connection Machines.
Re:Dropping multiple inheritance ? (Score:2, Informative)
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:Libraries (Score:4, Informative)
It's not entirely closed source (Score:4, Informative)
David Friedman has already had success connecting this frontend to the GCC code generator, in fact: http://home.earthlink.net/~dvdfrdmn/d
Re:D converts code to C (Score:3, Informative)
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++
ABA Games uses D (Score:2, Informative)
http://www.asahi-net.or.jp/~cs8k-cyu/index_e.ht
Re:Nice to see a system language (Score:3, Informative)
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:full C compatability? (Score:5, Informative)
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.
enumerated types (Score:2, Informative)
java 1.5 spec [sun.com]
Inaccurate comparison sheet (Score:3, Informative)
Re:full C compatability? (Score:3, Informative)
Comment removed (Score:5, Informative)
Re:full C compatability? (Score:5, Informative)
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:actually, the more important reason for excepti (Score:3, Informative)
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...Re:wow (Score:4, Informative)
Re:wow (Score:3, Informative)
Don't need to imagine -- it was the whole point (Score:5, Informative)
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.
The problem with C++ (Score:5, Informative)
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 [oonumerics.org]). 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. [cmu.edu]) 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++ [animats.com], 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.
Amiga E (Score:2, Informative)
http://wouter.fov120.com/e/
Re:full C compatability? (Score:2, Informative)
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.
Going down the chart point by point... (Score:3, Informative)
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
Re:Limbo is the only legitimate successor of C (Score:2, Informative)
Cheers!
Re:full C compatability? (Score:4, Informative)
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:try, catch, finally (Score:2, Informative)
The purpose of the auto_ptr is to provide temporary ownership of an allocated object. I would have coded your example like this:
Re:full C compatability? (Score:2, Informative)
Re:Nice to see a system language (Score:3, Informative)
Both Objective Caml [ocaml.org] and SML (using, say MLton [mlton.org]) 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 [gnu.org] 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!
Re:wow (Score:4, Informative)
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.
Re:The problem with C++ (Score:2, Informative)
Join the D newsgroup (Score:1, Informative)
Negative additudes are wellcome, D needs feedback from all sectors. By negative additudes, I don't mean we want people to spoil the friendly nature of these group. So if you hate D, come to the group and explain exactly what you hate about it.
Parhaps there's a solution to be found.