Slashdot Mirror
C, Objective-C, C++... D! Future Or failure?
TDRighteo writes "OSNews is carrying a quick introduction to a programming language under development - D. Features include garbage collection, overrideable operators, full C compatibility, native compilation, inline assembler, and in-built support for unit testing and "Design by Contract". With all the discussion about the future of GNOME with Java/Mono, does D offer hope of a middle-road? Check out the comparison sheet."
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.
The perfect sig is a lot like silence, only louder
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.
Karma: Bad (mostly due to all those "In Soviet Russia" jokes)
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...
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.
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.
"How to Do Nothing," kids activities, back in print!
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.
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.
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.
"Times have not become more violent. They have just become more televised."
-Marilyn Manson
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++?
#define struct union
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.
All about me
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.
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.
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)
What we need more of is science!
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++
I'm sure the gentleman will update his table once 1.5 comes out.
Templates.... great. It's like C++, but it's not.
Huh?
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.
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,
Project Manager of Crystal Space (http://www.crystalspace3d.org). Support CS at http://tinyurl.com/cb3x4
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..
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?
directly, them you're a good enough programmer to ensure that you've called for each new. And with std::auto_ptr, it's as easy as How much simpler does it need to be?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
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.
Opinions on the Twiddler2 hand-held keyboard?
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.
[ home ]
while (!asleep()) sheep++
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.
Vote in November. You won't regret it.
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.
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.
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?
Like woodworking? Build your own picture frames.
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.
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
diegoT
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.
Programmers don't need a new language as much as they need powerful, open, standardized, updated libraries.
"Provided by the management for your protection."
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...)
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.
Multiple inheritance is awesome and indispensible- when you find a language that implements it well. See Eiffel.
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:
(From which many sensible people conclude that it's bad practice to write in C.)
... the language spec didn't write the code. With power should come responsibility.
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
Code or be coded.