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 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.
--
1. D is not new. If this D is new, then we've got about 50 of them floating around by now.
.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.
2. Java and
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).
Javascript + Nintendo DSi = DSiCade
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.
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.
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.
Gotta get me one of these!
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?
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.
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.
Thirdly, pointers and "suggested" types. I say suggested because the type system isn't enforced, why bother with types at all if they don't mean anything. 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. Memory protection is also a software problem. The modern computer throws away about 30% of its performance on various protection schemes. More than enough to make up for using a language like Java or C#.
So, in conclusion, C compatibility is a bug, not a feature.
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".
Opera Watch - An Opera browser blog.
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.
Famous Last Words: "hmm...wikipedia says it's edible"
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.
I found this immensely amusing...and yes, I know that's sad.
"There are a dozen opinions on a matter until you know the truth. Then there is only one." - CS Lewis (paraprhase)
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.
[RIAA] says its concern is artists. That's true, in just the sense that a cattle rancher is concerned about its cattle.
Speaking of perl... /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!
I really wish lanugages would start implementing the ~ operator from perl (as with $myvar =~
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.
Tired of FB/Google censorship? Visit UNCENSORED!
And this differs from assertions how, exactly? (Honest question - looks very much the same to me...)
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
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.
"Give orange me give eat orange me eat orange give me eat orange give me you." -Nim Chimpsky
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++.
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.
"Live Free or Die." Don't like it? Then keep out of the USA
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.
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.
The clear successor for C is Limbo.
a .com/idown4e.pl
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.vitanuov
Inferno/Limbo are the only hope for some sanity in the software industry!
Best wishes
uriel
"When in doubt, use brute force." Ken Thompson
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.
Six score characters.
Brevity being wit's soul
I have enough space.
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)
Yeah, "real" programmers keep on coding in C++...they press on despite:
or they just switch to a more productive language...like the majority of the software industry is doing.
D looks interesting, and may well be a good alternative to Java and C# if good compilers become available. The DBC support looks promising. In the meantime, gcj is doing pretty well with ahead-of-time Java compilation.
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....
... 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.
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.
Like woodworking? Build your own picture frames.
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.)
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.
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.
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.
Squirrel!
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).
- Mr.Oreo
You have to remember that this table was done without STL in mind as STL is not built-in and can easily be replaced with something else. So while you may critise the author for not including the STL and boost libraries, it is not wrong.
I'll just go through a couple of these things:
Bound checking
How many extra lines of code would you need to add this? D does not check array bounds on release builds.
Preproccessor
If you really must, you can still use c's preproccessor, it's very easy to use individually.
So you say enabling bound-checking is easy, but enabling the C-prepoccessor is hard (one line)?
D solves most of the hacks and work-arounds you need to use macros for in C++. Why not post a case to the D newsgroup that you think can't be solved without macros?
The problem with C++ strings is that there are so many different types.
Complex and Imaginary
Your probably right here, but how primative do you go? Floating point doesn't nessarily need to be built into a language either (don't argue performace because Complex and Imaginary types can get a large performce boost by being optimised by the compiler).
Conditional compilation now whos trying to bloat the language?
I guess we all have different ideas on what makes a perfect language. You can never write a language that everyone is 100% happy with.