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