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."
Who said computer geeks don't have any creativity in naming their programming languages?
Oh, wait...
Microsoft will come out with it own version, and call it D-.
This signature is a waste of 42 characters
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
Looking at that comparison table, it's clear the author hasn't looked at Java since 1.4
Doom of course.
slashdot troll = you make a compelling argument I do not like the implications of.
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
I don't see D having the kind of successful adoption that Perl had/has or Python (to name two) yet neither of these were overnight successes. Only time and programmer support will tell if it has D chance!
Where the answers are...
Don't miss Google Directory if you're looking for more D info:
Computers > Programming > Languages > D
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?
Beware: In C++, your friends can see your privates!
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.
D drops archaic C++ features like the preprocessor and forward declarations. It adds modern features like design by contract, unit testing, true modules, automatic memory management, first class arrays, closures, and a reengineered template syntax. D retains C++'s ability to do low level coding, and adds to it with support for an integrated inline assembler. C++ multiple inheritance is replaced by single inheritance with interfaces. D's declaration, statement and expression syntax closely matches C++.
Opera Watch - An Opera browser blog.
Looking forward to job ads saying :
Duh !!
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.
I can understand many of the goals D is trying to achieve and like many of the features they have listed. However, I am surprised that D wants to be C compatible. IMHO, that has been the biggest problem with C++, it totally violates the thinking of the object oriented coder.
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)
Bah, We've allready made it all the way to R!
Employee of Inrupt, Project Release Manager and Community Manager for Solid
Sheesh. You'd have thought they'd come up with a name that's a little more interesting than "D".
No, I'm not going to suggest that it should have been called "Rupert".
Linux/Open Source/Anti Microsoft News
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.
We want C!
.NET, I go tit for tat with anybody who's setting this bit, that bit
with apologies to eminem...
to the tune of 'without me'
Two GUI classes go on the inside; on the inside, on the inside
Two GUI classes go on the inside; on the inside, on the inside
Guess who's back Back again C is back Tell a friend
Guess who's back, guess who's back, guess who's back, guess who's back
guess who's back, guess who's back, guess who's back..
Sun's created a monster, cause nobody wants to code Java no more
or basic, but something quicker
Well if you want speed, this is what I'll give ya
A language called C that won't let you do "is a"
Some "has a" that makes me feel sicker
than the bugs when I build patch that's critical
using make to compile and be building
with a language that allows object orientating
Your var name's too long, now stop line breaking
Cause I'm back, I'm a new var and instantiating
I know that you got a job Bill and Steve
but your company's trust problem's complicating
So GCC won't follow ANSI or copy memory, so let me see
They try to recompile with visual C But it feels so bloated, without C
So, connect with SLIP, or create a RIP Fuck that, write a function, and shift some bits
And get ready, and use a pattern like proxy MS just settled their lawsuits, expect a levy!
Now this looks like a job for C So everybody, just code in C
Cause we need a little, bit more speed Cause it runs so slowly, without C
Now this looks like a job for C So everybody, just code in C
Cause we need a little, bit more speed Cause it runs so slowly, without C
Little Hallions, MS feelin litigious Embarrassed that users still listen to RMS
They start feelin like ellen feiss 'til someone comes on the television and yells SWITCH!!!
A visionary, beard's lookin' scary Could start a revolution, lives in a bear cave
A rebel, although emacs ain't real fast and there's the fact that I only got one class
And it's a disaster, such a castastrophe for you can see so damn much of my class; meant to use C.
Well I'm back, i-j-k-x-y-z-out-ta-var-names Fix your damn indentifier tune your code and I'm gonna
open it, under vim, maybe pico and variables, no such thing as a member
I'm interesting, the best thing since assembly but not Polluting the namespace with inherits
We're Testing, your functions please Feel the tension, soon as someone commits some C
Here's my webpage, my code is free who'll pay the rent? What, You code with vi?
Now this looks like a job for C So everybody, just code in C
Cause we need a little, bit more speed Cause it runs so slowly, without C
Now this looks like a job for C So everybody, just code in C
Cause we need a little, bit more speed Cause it runs so slowly, without C
An object in
AT&T, you can get your ass kicked worse than those little C++ bastards
And Ruby? just like a static property not even used with KDE and QT
You're not like C, you're too slow, let go It's over, nobody'll code in OO!
Now let's go, -9's the signal I'll be there with a whole list of XM and L
I use SOAP, XPATH with XSL And you know perl's just like coding in symbols
everybody only just codes C so this must mean, some com-pile-ing
but it's just me i'm obfuscating And though I'm not the first king of controversy
And i'm not the worst thing since assembly but I am the worst thing since 86 XFree
do use BASIC and JSP and used it to get myself wealthy
Here's a concept that works twenty million new coders emerge
but no matter how many fish in the sea half of them can't even code C
Now this looks like a job for C So everybody, just code in C
Cause we need a little, bit more speed Cause it runs so slowly, without C
Now this looks like a job for C So everybody, just code in C
Cause we need a little, bit more speed Cause it runs so slowly, without C
Unpretentious Sydney reviews by unqualified Sydney reviewers
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.
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!
Whatever, first off they compared Java 1.4, not 1.5 so a lot of your C# Yes's are should be in the Java column. Also, some of the categories are just plain vague and the judgment call doesn't seem right. For example, "Independent or VM" and "Direct native code gen" are essentially the same and Java is listed as a No with no consideration ever given to GCJ which provides both of those for Java. Anyhow, use whatever damned language you want, I'm sticking to C, C++, and Java like the rest of the majority.
Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws-Plato
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
that's a pretty rediculous juxtaposition. perl is good language for one-offs and "duct tape;" Java is a systems language like. They really don't share the same problem domain; the one place they do intersect (web applications) is a place nobody uses C++, so they can't very well be supplanting it there. :)
props to the homey... (whatever that means).
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
Well, I guess with all the "I can't build GAIM from scratch because of lib.foo.so!" rants from Eugenia, then maybe they've become 31337 h4X0r5, but when was the last time that OSNews had anything decent or insightful? I'm surprised that there's been no bitching about 'theming' this new language.
I want to delete my account but Slashdot doesn't allow it.
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
Then what about Java on BSD?
The Tao of math: The numbers you can count are not the real numbers.
I believe you're mistaken. D stands for "Duke Nukem Forever."
The delays in release of the game are simply a result of having to wait for a new programming language in which to write the software.
I was oddly confused when I read that un-sourced term in the quickie part of the story...so, from this page:
Contracts are a breakthrough technique to reduce the programming effort for large projects. Contracts are the concept of preconditions, postconditions, errors, and invariants. Digital Mars introduces the first C and C++ compiler to support contracts. Building contract support into the language makes for:
1. A consistent look and feel for the contracts
2. Tool support
3. It's possible the compiler can generate better code using information gathered from the contracts
4. Easier management and enforcement of contracts
5. Handling of contract inheritance
The idea of a contract is simple - it's just an expression that must evaluate to true. If it does not, the contract is broken, and by definition, the program has a bug in it. Contracts form part of the specification for a program, moving it from the documentation to the code itself. And as every programmer knows, documentation tends to be incomplete, out of date, wrong, or non-existent. Moving the contracts into the code makes them verifiable against the program.
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.
funny words like ABACADABRA only using names of programming languages.
In fact, if you follow the "What is R?" link from the R-projects main page, you'll see that:
...
It is a GNU project which is similar to the S language and environment
And I wouldn't bet against there being a link to a "T" language on the S project's homepage or something.
What next? AB language? Eventually we'll get to COBOL all over again! Oh No!
It will be interesting to see how it compares to Delphi too.
Every once in a while people try to improve on C++. Usually it is those wet-behind-the-ears kids straight out of college who think that because C++ is too hard for them, it is a bad language. But real programmers just shrug and keep on coding in C++. Let the kids have their fun; they'll come around eventually when they want to write some real code. Maybe someday they'll discover that garbage collection is not necessary when you know who owns your memory and encapsulate allocation in logical places, like STL containers. They'll discover that C++ already has overridable operators, full (well, all that matters, anyhow) C compatibility, native compilation (VMs are for script kiddies), inline assembler, and in-built support for unit testing (called a debugger). And as for "Design by Contract", good luck getting any contracts in your new D.
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!
http://pluk.sf.net/ is also a programming language that has similair syntax, open source, BSD licensed, and still in development, so you can still insert your killer feature.
Syntatically, D is almost identitical to Pike, like the foreach and the range operator "..". Pike is also loosely object oriented, and has a rich set of libraries just like Python, Perl or even Java.
I'm not sure if the Author has borrowed ideas from Pike, but it is is really a great language that has been around for 10+ years, tested in real world applications.
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 =~
The article speaks of managed code as if it is a Bad Thing. Sure, systems level code is sometimes necessary, but for normal application code and especially trusted computing initiatives, a VM is a must.
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++
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!
Meant to post that anonymously...
Cuz it makes it hard to google for "D".
.. when it was called C#!
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 ]
Well if it is then someone has obviously designed a fully functional compiled language that operates EXACTLY the same way on ALL
architectures even though it goes down to bit level operations. Wow , I'm impressed given that no one else has managed to do that yet. Tell me , how for example does it deal
with big/little endian issues at compilation?
As a fellow said :EOP, That's what we do, Error Oriented Programming, all day long!.
You know, to decide to program is always the first error.. and so on.. (Murphy).
What's in a sig?
What's in a sig?
Checking return values is a horrible use for exceptions. Exceptions are for critical but recoverable errors. "Normal" error conditions shouldn't throw exceptions, not least of which because it makes the code so much nastier and twisting to deal with it. Exceptions are great and allow you to do a type of error handling that would be impossible without them, but I think that some C++ (and especially Java) people get far to enamored of them.
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. :-(
Karma: It's all a bunch of tree-huggin' hippy crap!
Oh! sure, nice, but then the problem is with resources allocated on those 3, 5 or 10 'skipped' levels during exception handling.
No easy way out.
What's in a sig?
What's in a sig?
I thought from the headline that the new title was D!; D bang. Ahhahaahhahahaaa.. what a cool name!
For as long as there's a need to be able write anything in assembler or a decent system programming language, there will be a need for some modicum of protection in hardware.
Though I do gotta say, if you ever write a device driver in Java I'd love to see it.
In C++, the destructors for those objects run to reclaim those resources.
In garbage-collected languages, the garbage collector reclaims memory automatically. If you've allocated other kinds of resources, such as file handles, you need a finally block to clean these up. C# makes this easier: the compiler automatically generates the appropriate cleanup code if you allocate resources in a "using" block.
On balance, the languages that have exception handling mechanisms, such as C++, Java and C#, make life easier for programmers to prevent leaks in the face of errors, not harder.
It's seems that a lot of people are complaining about something that was seriously mis-reported. D CAN'T COMPILE C CODE!! (Sorry for shouting.. but I'm hoping to get peoples' attention). D can link to C binary code.. wow.. what a concept.. almost every programming language can do this. It's almost a requirement for any new language. Without it you would start with 0 code base, and no one will use it. The below text is taken directly from the article. Notice 'Binary Compatibility' and 'Link Compatible.'
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.
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++.
Now before you think I'm nuts, I was skeptical, too. But after programming in C# for the past year, I absolutely love it. The language is perfect. Why design another one? Just make sure good Open implementations get done for it, and leverage all the good design work Microsoft has done!
Best Buy can have you arrested
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.
Exactly how are we expected to Google for such things?
Please give your projects distinctive names with more than one character, thanks.
mt
"This is your life, and it's ending one second at a time."
Not only that:
...
public void myStuff(){
if(this.DEBUG_ON){
System.out.println("Conditional compile for java == true");
}
}
Or just run it through an obsfuscator and have everything you don't need removed. Automatically. Why cram everything into the compile tool?
C* actually is a language. It is the C-like parallel language used mainly on Connection Machines.
(S(SKK)(SKK))(S(SKK)(SKK))
Not so clear, different problems needs different solutions. In my experience (C/asm & Java/C++) the cost of proper error handling is pretty much the same, and is directly proportional to the desired code quality level,not to language facilities.
What's in a sig?
What's in a sig?
The backend (code generator) for the reference compiler is closed source. However, the frontend is dual-licensed under the GPL or Artistic licenses, and is free in every sense of the word.
David Friedman has already had success connecting this frontend to the GCC code generator, in fact: http://home.earthlink.net/~dvdfrdmn/d
"Break out the gin, and the small violin, I'm a raging success as a failure." --Firewater
You won't rewrite all your code just because you switch to another language. Reusing existing code is good.
The most intersting part of the table is that Limbo was left out. Limbo is the successor to C, not C++, not C#, and certainly not D. For more info, see the following: God Dennis M. Ritchie: The Limbo Programming Language. http://www.vitanuova.com/inferno/papers/limbo.html
God Brian W. Kernighan: A Decent into Limbo. http://www.vitanuova.com/inferno/papers/descent.ht ml
-- vt3
I would argue the existence of a preprocessor is not archaic (although I would grant you that C/C++'s preprocessor is archaic).
Preprocessors allow you to deal with a great range of unanticipated situations -- allowing you to come up with creative solutions to sticky problems. Granted, they can be abused. So what? Don't abuse them.
The biggest thing I don't like about Java, now that it has templates, is that it's missing a (standard) preprocessor.
D has 2 strikes against it: first, no templates. Without templates, it's horribly inconvenient to write safe (i.e. strongly-typed) code. Second, it has no (standard) preprocessor.
S: Bell labs statistical language;
W: Stanford distributed windows;
X: Graphics protocol for W (now XWindows).
ABA Games, that wacky psychedelic asian dude writes shoot-em-ups in D. I think the D is for Drugs.
m l
http://www.asahi-net.or.jp/~cs8k-cyu/index_e.ht
-Billco, Fnarg.com
Not true.
'dmd' is the Digital Mars D compiler.
It generates native code for windows and linux.
The frontend for GCC it's a recente and independent project.
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.
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.
And the comparison is imo clearly wrong in several points, for example regarding c# and arrays. Arraylists and hashtables are part of the .NET base class library, and as such I consider them part of C# also. So how can he say that C# does not support resizable arrays and associative arrays?
Seems pretty horrid to me, but all the default examples are of classical C printf() style code, though the operator overloading for > is by seperate functions so there is some possibility for a conversion of whatever string code they use and IO classes to be created using the C++ method, just wish it had been in there by default.
Though I acknowledge they probably wanted to move away from the hell of one operator having many jobs, but I think a decent IO system for objects is woth it.
I think I'll wait for D++.
Cress, cress, lovely lovely cress
I can build gdc with gdc
(gdc??? huh? why, the GNU D compiler of course)
I don't get it, what is wrong with D's templates. Admittedly, I haven't used D, but it sounds like it has templates to me...
Why a one letter name? Searching for "D" for help, reference, etc.. will be a major pain.
... The whole linux kernel with D and then i'll check it out!
I fuse with Mercer every single day...
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
People keep telling me that Aspect Oriented Programming is the next major step forward. I keep meaning to get around to learning more about it, but somehow I never do. Well, nothing deeper than a one paragraph overview.
My personal belief is that the next major steps forward are not in languages per-se, but in language and development tools. I suspect that new languages that are fundamentally similar, but without some of the hacks we've all learned to live with will be needed to get the most from these tools.
plus-good, double-plus-good
Perhaps we can all be proud when we get a D++ on our next quantum physics mid-term.
The poster ends his message with a comment about GNOME development. Now, I love C, but GUI programming is not what it was designed for. How about writing GTK in C++ before we worry to much about needing a whole new language to program in for GNOME. Give C++ a chance.
java 1.5 spec
The question is how much significant reuse is actually occuring in C programs? If by reuse you mean rewriting existing apps in a new language, that often doesn't pay off.
I have worked with an old D language from Teleuse it is much like VB is to windows... http://mbi.dkfz-heidelberg.de/helios/doc/manuals/m ips/chapter4.html
Whoever put the comparison sheet of D, Java, C#, C++, and C together needs to be more careful. It claims that C# has no inner classes. Which it currently has. Also the comparison sheet claims many things are unique to D, which in fact are supported by the C# 2.0 specification. "C# 2.0 isn't here yet" you say? Neither is D. In fact, the D spec is only at rev. 0.8x.
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
"Pause times below 1/10th of a second are often the case"
What if I need to respond to an event within 1/120 second? This happens very often in the video game field, which qualifies as a soft real-time[1] field, and it happens even more often in hard real-time fields such as anything related to robotics. Do there exist useful real-time garbage collecting algorithms? If so, are they at least 20 years old so as not to be encumbered by a subsisting patent?
[1] Another Slashdot user once criticized my use of "soft real-time." I define it as a guarantee of no deadline misses exceeding x milliseconds and fewer than y deadline misses per hour, for values of x and y depending on the application, as opposed to hard real-time where x = y = 0.
Many years ago, Amiga E was the first OO language that I learned -- after trying and failing to understand C++. E not only made OO concepts easy, but it also had great, readable syntax. Some people say syntax doesn't matter, but I was able to read E code easier and faster than C code, even though at the time I had far more experience with C. I still have a fond memory of Amiga E, and I wish there was something else like it in widespread use.
So what happened to E? It never got ported from Amiga to other systems. Much of the compiler was coded in 68000 assembler, and much of the documentation was concerned with accessing Amiga APIs.
Another factor was ambivalence on the part of its creator, Wouter van Oortmerssen. His hobby was designing and implementing new programming languages, he cranked out one after another. It seems he never became too attached to any one of them. After he got Amiga E working the way he wanted, he lost interest and started working on the next language. I guess he didn't consider advocacy to be a productive use of his time.
It's a pity, because as someone else here pointed out. . . A language that isn't widely available or widely used doesn't do much good, no matter how well designed it may be.
I'm on a Mac now, so I'll probably use Objective C and call it good enough.
You're not making sense. Remember, if you don't have exceptions, EVERYthing has to go into the return value, and that's what I'm talking about. It's not a pretty situation.
Uh... no. In modern languages, that's a non-issue.
Is it an integer? Could it be a string? A character? A float perhaps?
Perl mocks you...torments you, the cast dependent coder. Lick it up.
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."
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.
The ROOT CAUSE here is in-band error values.
/* handle error */ }
In the file descriptor world, -1 is invalid, and therefore a good error value.
NULL is often (void *)0, which is *technically* valid on some architectures (OS notwithstanding). It's just so unlikely a result that it's safe to use.
A better approach is this:
int result=some_argument_to_function;
if(function(&result)==0) {
Unfortunately, there are too many places where the argument you want to pass would not directly accessible or assignment to it is inconvenient.
Alternatively you could always set and check errno, which should be 0 on no error. This requires and addition line of code to check errors (and programmers, including me, are lazy).
Moving to out-of-band errors without the above requires cartesian products as return values, which are fine in set theory but would probably choke the average programmer.
You, and everybody else reading this article, should have a look at Eiffel.
I started reading about the language just a few days ago, and I'm very much impressed! I've been a hardcore C++ user for some years now, and after just a few hours of reading I felt ready to abandon C++.
Although D seems quite nice and has alot in common with Eiffel, it still lacks multiple inheritance. Like every other language I know of except Eiffel. =)
C# and java is just sponsored crap in my opinion.
There must only be a few dozen prototypes for programming languages called 'D'. I think every student with a compiler project has considered calling his/her language either D or C--. (there are two "official" C--'s that I know of, use google to find more).
“Common sense is not so common.” — Voltaire
..because big is best!!
I am a c/c++ programmer with 15 years experience.
I programmed professionally for two years in Java.
I DIDN'T drop c/c++, because I found Java to be a toy language and really bad at interfacing with the real world. Hardware, real-time algos, etc...
On the other hand, I STRONGLY recommend teaching Java to computer-science majors, as its restrictiveness (vis-a-vis c/c++) keeps them focused on proper application design and universal computing paradigms.
So Java is NOT worthless, but it nowhere near being a fitting successor to c/c++.
I don't know the meaning of the word 'don't' - J
Not being a programmer, I always thought Objective C to be the nicer OO C alternative, having been eclipsed by C++ and its derivatives for marketing reasons.
So the question is, how would D compare to Objective C?
Obviously a deeper question would be why insist on C derivatives instead of going functional and relational... once one's already smoking stuff...
Leandro Guimarães Faria Corcete DUTRA
DA, DBA, SysAdmin, Data Modeller
GNU Project, Debian GNU/Lin
And it doesn't seem to have done me much harm.
We will be the judge of that!
No, what I mean is that it is nice to be able to use the code you have already written in C. It is not uncommon that current versions of applications are based on C-code that was written 10+ years ago. If that code works you wouldn't rewrite it using D. It could easily pay off to to switch to a programming language which both lets you reuse that old code with a minimum of work and lets you produce new code faster on top of it.
If D wasn't compatible with your old C-code at all, switching to it wouldn't be an option.
Two CS freshmen up hacking all night, hacking all night, hacking all night
/Too complex, you might as well use C / printf() just has cout plain beat
Two CS freshmen up hacking all night, hacking all night, hacking all night
Gonna hack... Keep hacking...
Gonna hack... Drink caffiene
Gonna hack Gonna hack Gonna hack Gonna hack Gonna hack Gonna hack Gonna hack na na na
Enh enh enh enh enh enh, na na na, Enh enh enh enh...
You think you're a programmer? Well you've never used a debugger before / You're a newbie! Here's news, kid: / If you wanna hack code you need to debug it / 'cause your code will have bugs and you'll need to fix it
So your process is stopped on an infinite loop / On some operation where an iterator's not incrementing / And when you fix that bug you get segmentation faults / 'cause your strings are not NUL-terminated
Hey! It's no time to get frustrated / 'cause your CS 10 course left you uneducated / I know your boss wants it done tomorrow / So here are some programming tips you can borrow
When you're doing something this easy / The bug won't be in gcc / So try to track it down with gdb / And I hope you compiled with -g
So, come on kid, print out your listings / Sit down, load the core file and fiddle the bits / Set breakpoints, and check all your branchings / And check all of the values in memory
Now if you want to hack in C / Then you'd better learn gdb / 'cause you'll dump core eventually / And I hope you compiled with -g
I said, if you want to hack in C / Then you'd better learn gdb / 'cause you'll dump core eventually / And I hope you compiled with -g
Little hackers, beginner programmers / Embarassed your teachers are still using Windows? / You don't need Linux to find out why you're crashin' / Use CygWin or MingWin and pretend it's a penguin
Dev-CPP's a nice IDE / It's not Anjuta, but it works for what you need / No floppies, keep your software on the 'net / And get it with Putty 'cause you don't know CVS
A bash script can't necessarily / be used on tcsh or ported from Be / And Perl? It's like blowing in your modem / *pfft* -- look, it's a regex! You can't debug that
And nobody can write standalone apps in PHP / Does anyone even use Python or Ruby? / There's no reason to code in assembly / These days when you can do it in C
*pfft* Attention PHBs / C++ is something you don't need
Now if you want to hack in C / Then you'd better learn gdb / 'cause you'll dump core eventually / And I hope you compiled with -g
I said, if you want to hack in C / Then you'd better learn gdb / 'cause you'll dump core eventually / And I hope you compiled with -g
Now Visual Basic's a piece of shit / Even the data validation functions crash / in it, a piece of trash language / ASP's begging to have your website hacked
And Java? It runs as slow as lava / The VM takes an hour to load / And configuration, you get write once, run nowhere / The FHS ain't that hard to follow
And C# is an obvious ripoff / Its Java without the interoperability / So big deal, it does XML like everything else / MS sycophants pretending it's something respectful
There are some times it seems to me / That everybody ought to hack in C / This must mean that C is neat / And C is not yet obsolete
Hey, I'm not saying that C is supreme / It lacks garbage collection and some other things / Just know what language features you'll need / And use whatever will provide these
So hey, here's a concept that works: / Twenty million computer languages emerge / But no matter how well they fit your needs / There will always be a place for C
And if you want to hack in C / Then you'd better learn gdb / 'cause you'll dump core eventually / And I hope you compiled with -g
I said, if you want to hack in C / Then you'd better learn gdb / 'cause you'll dump core eventually / And I hope you compiled with -g
Na na na na na... Na na na na na... Na na na na na... Na na na na
Na na na na na... Na na na na na... Na na na na na... Na na na na
Dammit, just use C++ and stop bitching willya??
Sheesh, it's been 10 years already.
That is the coolest thing I've read in a while.
Did you write it? Kudos.
It's truly swell.
sig - I've upped my karma, so now up yours.
I don't know the meaning of the word 'don't' - J
From the page, here is some sample code of an "out" type parameter. (Think of it as a one way reference)
// bar is now 0
out parameters are set to the default initializer for the type of it. For example:
void foo(out int bar)
{
}
int bar = 3;
foo(bar);
The immediate problem I can see with this, is the same as using references in C++. There is no indication in the calling procedure that the variable passed in can be changed by the called procedure. In C, you can only do this by passing pointers, and as such you know that foo(&bar); can change the bar. (or that the variable you are passing in is a pointer, and thus can change what it's pointed too).
This sort of thing is only important after code has been written, and is now being maintained by other folk. The other folk not being familiar with foo, will have no idea that bar can be changed.
I have no problem when exceptions are done properly as in Java, but using them in C++ is an exercise in frustration.
There's nothing wrong with them, except that I didn't know about them... :-)
/. D didn't have them. In quickly reading the article, I missed any mention of templates, although going back, I see they were mentioned in passing.
Templates are something new for D -- last time it came up on
Thanks for pointing that out.
is not everthing is extensible. Not orthangonal. Basically the technique to deal with this is to put a wrapper (bridge and/or factory patterns) on stuff, sometimes lots of stuff. Locks (monitors) is Java is a classic example. You can't override that behavior. So you have to write your own lock class from scratch and then write wrappers for everthing that uses hard coded real monitor locks.
Why not include mysql/postgres/etc functions on default includes functions? This would be a major boost for C language IMHO.
For example:
Dynamic array length
Yeah, this sounds like a cool feature, but (quote):This is SO dangerous - it doesn't seem like the way forward for a modern programming language. It puts the impetus on the coder to undestand a rather strange side-effect of an efficiency in the language to know that they might accidentally be modifying a different array without realising.
Another example:
Out / inout function parameters
These sound like a nice short-cut to allow pass-by-reference or multiple return values, but also seem dangerous:I have only briefly skimmed the surface of the language, but it seems to me like an attempt to cater for everyone. I fear that, like C++ can be, it will result in too many unknowns and areas of murky understanding. This will in-turn lead to hard to maintain code and the nasty bugs!
padzo
If M$ is the solution, can we have the problem back?
... 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.
Before job ads start asking for 5 years of D experience.
"We can't solve problems by using the same kind of thinking we used when we created them." -- Albert Einstein
Does one pay for "modern languages" in performance? What "modern languages" with free compilers produce binaries that run fast enough on handheld systems with a 16 MHz ARM CPU and less than half a megabyte of RAM? Keep in mind that PC-class systems aren't the smallest useful computer systems.
It should be called 'E' to appeal to the drug-taking raver youth of today. It would fit the profile of being a more cerebral experience writing the code.
It might shake up a few offices.
It should have a set of libraries called Whizz.
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.)
What that means is that recruiters were looking for somebody who had worked for Microsoft, but regulations prohibited mentioning the name of a specific competitor in the ad.
I would like to see the Object Pascal of Delphi in the comparision sheet. It would have a "YES" on most topics too and that with a blazing fast (you have too see it to believe) and stable compiler.
Inline assembler
That's an implementation-dependent feature, not a language feature of C/C++.
Direct access to hardware
C# has unsafe pointers (in unsafe modules), so it has this feature to the same degree that C and C++ do.
Explicit memory allocation control
C# very much has explicity memory allocation control. In fact, C# has similar low-level programming features to C/C++, but it packages them MUCH better.
Independent of VM, Direct native code gen
Both Java and C# have implementations that do "direct native code gen", in the sense that you can take source code and have a compiler generate shared libraries. Both languages can be implemented without a VM, although many libraries (and many application programmers!) want the functionality that the VM provides. Where is D's VM?
Templates
If he really means "templates", I'm glad that none of the other languages have them. Templates are a specific feature of C++--enormously useful, but very poorly designed. C# has parameterized types, which are less powerful but a better design.
Support all C types
I'm not sure what that is supposed to mean. C doesn't have a well-defined set of specific types, it has type names for implementation defined types satisfying minimum requirements. C# certainly has a complete set of types corresponding to that.
Struct member alignment control
Not only does C# have struct member alignment control, it has it in a way that is more explicit and better designed than what C and C++ have.
Are you planning on compiling custom binaries for every platform?
No, I'm planning on shipping generic i586 binaries and giving the user the option to compile the source code during the Setup Wizard. Even in the world of proprietary software, many digital signal processing apps and plug-ins for Windows have separate DLLs containing cores for different processors.
Besides, I often work with small hardware. Does a JIT JVM plus a program both 1. fit into 256 KB of RAM and 2. allow for garbage collection without noticeably interrupting the flow of events that occur at 60 Hz?
I used to write in FORTRAN and assembler. And then I tried C and realized I don't have to switch languages so much to do system-level programming and besides preprocessor and generic for loops are neat.
Then for the longest time I refused to touch C++, because I could do everything with structs, function pointers and longjmp. Now I look at my old code and think "what the hell...?".
A lot of fads do make you more productive if you really get into the mindset and learn the available tools. So far, I am holding out against Perl, anything that starts with X and ends with L, complicated forms of source control, formal design procedures and modeling tools. I also tried Java and wish it didn't miss so many essential C++ features (like reference function parameters and automatic destructors for local variables) to make using it such a trade off. I tried C# and many features are still missing and others feel like they were slapped on rather than a natural part of the language.
There you go, congrats, you found one use for C. Now, I ask you: How many low-level device drivers have you written lately?
Programs for some handheld systems contain customized video drivers and sound drivers. I had to write my own display and sound drivers for these demos. Do you know of a better language than C for implementing soft-real-time graphical video games on a device with a 16 MHz CPU and 256 KB of RAM?.
...as does Python ;-)
(is it an integer, a string, a list, an enormous enterprise scale application encapsulated in one object?)
For those of us who don't like unpredictable... pauses... in our programs
You're mistaken if you think that by using "manual" storage management, you get intrinsically lower latencies or better memory management performance.
The only reason C/C++ allocators seem to perform better is because they are mature and widely used, and have been extensively tuned. But early BSD malloc implementations would sometimes go away for minutes at a time. Using "manual" storage management gives you no real time guarantees. And, if anything, it has an intrinsically higher overhead than equivalent garbage collected code.
So why complicate things with garbage collector and tracking down circular references and unpredictable pauses?
Garbage collectors have no problem with circular references (but many of those C++ memory management hacks you advocate very much do).
And if you don't like unpredictable pauses, then you need a real-time memory allocator. Those exist in both manual and garbage collected varieties. If all you want is soft real-time performance (interactive), then most good manual allocators and most good garbage collectors will do the trick.
Gosh, this is 2004 and arguments like yours were bogus even back in the 1980's. Get with the program.
I agree with most of your points, but there's a reason Microsoft implemented precompiled headers in its compiler:
Ever hear of "Make" and "Makefiles"? You don't need to keep recompiling things than havn't changed.
Even with GNU Make, sometimes even a single module takes too long to compile on some older but paid-for workstations, especially if it has to include the platform's all-inclusive API header file. Or has Microsoft broken up <windows.h> into separate headers yet?
That's true. Isn't that the secret of success? You must learn to take opportunities before they become general knowledge. To a degree that means being able to predict the future.
When you choose what you want to learn, what investments you want to make, what company to work for, it is always with an eye to the future. Investing a lot of money, time, or mind into something that has no future is not a recipe for success.
Actually, I was thinking about exactly that problem..... though I am perhaps a bit of a crackpot.
Here's what I figure. A device driver is really two parts. one part actually reads from and writes to the device, the other part is the actual code. The reading and writing part could be handled by allowing some sort of low level VM call (assuming the VM is somehow embedded in the OS, so you can have this sort of access, it would also have to run in system mode). Basically some sort of native code takes care of the bindings and then loads up your driver with some sort of context object that contains (perhaps) a bunch of byte[] objects that represent the memory the device driver will use to communicate with you. These arrays are pinned in ram, so they always exist at the right location.
Then you write your driver, use the byte[]s to communicate, are guaranteed that your memory addresses are always correct (if they started out correct) and all your code is safe. In addition, it would be nice if when you driver threw an exception (should never happen, but who knows) the System should just re-initialize the driver and reset the hardware (works better on video cards than harddrives, but I'm not a hardware hacker, so cut me some slack) and continue.
Basically, what I'm saying is that an OS should include a VM in system mode, and then throw everything possible into the VM to get security and protection. Even most of the device drivers could go into the VM (using a technique somewhat like that above) and leave only the basics of scheduling/memory management in the kernel. Less kernel code means fewer crashes (less code in system mode that can take down the system, especially the drivers), and Java programs could run in system mode (substantial performance increase) while native apps could run normally.
i believe that the original posted intended to say that Java is as dead as BSD is. BSD is not dead. Nor is Java.
"D programming language" and "J programming language" and X window system
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...The most interesting is why the Founder of D feels it is necessary to compare his language to other languages.
Quote from Bjarne Stroustrup's FAQ: "When looking at a language comparison consider who wrote it, consider carefully if the descriptions are factual and fair,
and also if the comparison criteria are themselves fair for all languages considered. This is not easy."
I tend to agree. A comparison table biasing the featured product makes me feel somewhat suspicious.
Moreover, some of the features where C++ is listed as 'No' are available although GC'ing isn't something I miss much about C/C++
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.
I can't help you with COM, but Google easily finds Microsoft .NET and .NET framework.
Python has a few ways to write strings which make working with regular expressions much easier...
You can use """triple-quoted strings""", which can contain newlines and so forth.
You can also use raw strings, with an 'r' prefix, as in r"a\backlash"...which turns off all \-style preprocessing. So that eliminates most cases where you have multiple-backslash explosion.
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.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
This is horribly ugly, especially when all I want to do is compare two integers for size. Casting, parenthesis everywhere, comparison with some arbitrarily chosen integer, etc. With operator overloading and templates, the same thing is possible in a much cleaner and more intuitive fashion:
It doesn't take any 'work' to understand what this code does. A ten year old kid could probably tell you that it involves 'less than'. This is also type-safe (I don't have to worry about if my objects actually inherit from Comparable).
I like D. In my ideal world it would replace all uses of Java everywhere and anywhere, but unfortunately I doubt that will be the case.
It's pretty mature by now and can have all of D's features by tomorrow. Just ask for it! freshmeat.net:projects/lwc
...if it's true that D has removed "archaic" (*snort*) things like forward declarations.
What, exactly, did they think a header file consists of?
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
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). 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.) 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++, 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.
Should've said ifloat/idouble, I guess? Would've made more sense...
I looked at the article and the chart, I don't see the comparison to Objective-C as promised. All I found is that Docoa is in the works.
Honestly I like the idea, but wake me when it's ready for the enterprise.
Exceptions can be just as problematic as return type issues (what if your catch block doesn't catch the right thing?). The advantage you may have with throw/catch is that your brain has been trained to think about error handling in these terms (bear with me -- I'm not trying to troll...).
. htm for a quick read on setjmp/longjmp if you're interested.
Some view try/catch/throw and exceptions as nothing but syntactic sugar for setjmp/longjmp and a thread-local pointer. Delocalizing error handling requires almost the same amount of code with these calls, and after a bit of practice you'll find it no less intuitive to use a function call than to write try/catch/throw.
With C you don't have to think about delocalized error handling if you don't want to; in a language that supports exceptions, you were likely taught the 'design pattern' as a language feature.
I also find exceptions convenient, but I still dream of the day when everyone agrees how they should be thrown across library boundaries.
Visit http://www.min.net/~gdinwiddie/programming/setjmp
I program turing engines directly, with wet clay and a sharp stick. And I like it that way.
I don't think that word means what you think it means...
wetback
If so, then it's completely lost on me.
.sigs are for post^Hers.
AFAIK Java has JUnit for unit testing and an "instanceof" operator instead of "typeof". "Arrays of bits" can used without performance-loss with java's booleans because they are primitive types. Some other things look to me like obstacles, not features and the whole array stuff doesn't recognize that Java hast many types of Lists and Vectors which provide much more useful methods than arrays (and also son't really need a "foreach" operator).
Those things are all marked red in the comparasion chart, so it looks like D is a clear winner. But please, let's look at how real code behaves in a real environment (security/performance/ease of use aspects).
Is that it was cobbled together over years, and has thus become this giant, nasty monster.
Having to carry two Meyers books
- Effective C++
- More Effective C++
to avoid shooting yourself in the foot with C++ is a strong indication that something is wrong.
Remember when automobiles had manual chokes?
.sigs are for post^Hers.
1) If you say D is most programmers they will know what that means (100%?). If you said L, how many do you think will not know this. The fact that you had to explain this illustrates my point.
2) D is not called D because its the next letter in the alphabet to C. D is D because its DigitalsMar's language.
It's really funny this thread. Half you people haven't even tried D, so you don't know what your taking about.
Anything you don't like about C++? Suggested it in the D forum and there just may be something done about it.
C++ was not always the dominant language it is today. Why argue about popularity. Why not some critical thinking and ideas on the direction of languages for the 21st century.
Boost and STL will also come out for D, but I'll bet they'll be half the size and much much neater and 99% of the time you won't have to use them.
-My granddad refuses to get a microwave because he believes food cooked by it does not taste as good.
Interesting comparison chart - it may be worth noting that the C# Version 2.0 standard introduces both Function Literals and Templates as well as some other language goodies.
I doubt it will ever allow inline assembler, though.
I'm a 2000 man.
BS..
exceptions are for all exceptional circumstances.. Errors are always exceptional, not part of the normal process flow.
You're confusing this with using exceptions for decision making. If a action has two posible (non-error) outcomes should this be handled w/ an exception?? No.
Java handles exceptions just fine thank you.. not forcing you to check return values. Java just copies Smalltalk on this.
Java's idea of Try/Catch is to separate error handling from normal process flow..
It is clear you don't know what you're talking about.
For C compatability with safety and speed, why not try Cyclone
:)
It's typesafe! No problems with null pointers, or out of bounds memory errors! Just say no to buffer over/underflows!
Tired of garbage collection slowing you down? Use its regional memory management - no dangling pointers guaranteed! Safe library wrappings, for her pleasure.
Need a little help with your "flow control"? You might check out its ML-baseed pattern matching. Shorter code, in less than 30 days, guaranteed!
And forget enums, what you really want is tagged unions - typesafe, and makes some algorithms oh so short and sweet to write. Makes recursive data types a snap - great for ASTs!
And of course there's parametric polymorphism, abstract structure types, and even subclassing of pointers! With all that done for you, you could even set up your own object system - just how you like it!
Last but not least, there's some decent type inference - stop writing down the damn type of every last thing you give to the compiler, this compiler knows better
Check out Cyclone today, it's sure to blow you away!
Cheers,
Justin
Heh, forgot to include a link to Cyclone.
All kidding aside, I really don't see why more people aren't using a fast, safe, low-level real-time capable language like Cyclone instead of C for many things.
Don't get me wrong, C is great for a certain set of specific things, but more often than not the power gets used in a suboptimal way (which wouldn't occur in a less expressive language).
Cheers,
Justin
There is already a programming language called E for Amiga:
http://wouter.fov120.com/e/
Automatically makes this a "NOT-A-REPLACEMENT-FOR-C/C++". I dont care how good your garbage collection is, I'm not letting it near my driver or game or high speed application of any type. Garbage Collection is a crutch for people who dont know how to code. "It can link with C" - yea, well so can C. Why program in 2 languages and worry about the inter-language problems? If your going to use this, might as well use java or C# or any number of a million other similar technologies. Nothing new here, move along.
So, your point about the undesireale effects of delays caused by Garbage Collection is even more relevent with regards to broadcast video.
An example might be a celular handset with a software-defined radio receiver for pulling in local TV broadcasts. Without some sort of realtime extensions which allow you to defer garbage collection, Java's GC would cause frame dropouts. Not that you'd notice on a 2 inch screen...
All of the publicly available GC's SUCK, for the most part. Especially the java plugin for running applets. I get 1 second pauses ALL the time with that steaming pile.
Writing GCs is hard, and by the time you're through, it's no wonder that most GC writers want some sort of compensation for their efforts. Which means it's going to be a looooong while before we see a good public open source GC.
Meanwhile, developers get to base their opinions on the GCs that are currently out there, and by the time a good one rolls around, nobody will care.
Personally, I think you should have the option whether or not to use a GC with a language - it should have the hooks for GC, but if you know what you're doing, you should be able to raise the training wheels, and go.
it looks like they've merely added features to the core language that have already been developed as libraries in java, C++, C#, etc..
'D' just looks bloated now.
...when you are working with the small machines.
C works quite well for the majority of processors out there - no, not 80x86, but 8051/8052 and 68xx's. You know, the REAL embedded systems.
These processors couldn't work with D or C++ (although I am game to try). C# [laughs] - yeah, pull the other one.
These guys are thinking sooooo IN the box....
Feloneous
IANAL, but I've seen actors play them on TV
D to me just seems like a language that rehashes a language that doesn't really need to be rehashed. Not that that's a bad thing necessarily, I'm always in favor of innovation. However, I don't see it making much of a difference unless it can make a particularly BIG splash in the sea of languages that already exist. There's also a factor of familiarity of languages and/or their use in certain situations.
I for one generally program in one of three different situations. On the one hand, I deal with programming low level drivers and/or real-time systems and programming high performance engines (whether networking, graphics, or sound oriented)and so I use C for the obvious reasons of speed and low level control. On the other hand, I also involve myself in programming GUI based business apps and web services and so I also use C# for its relatively rapid devel time. On yet another hand (didn't know I had 3......), I use Perl when i'm feeling like doing some system administration scripting or web interface scripting.
Even if D (or some other further iteration) becomes the absolute best language to do everything in (which I doubt) I still have my three languages that do everything I really need to do (with the occasional offshoot into LISP for personal AI projects).
That is why Java has a "finally" catch block. Code in it is run when the try block is exited for any reason -- including an exception being thrown that is caught higher up in the stack.
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
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.
The lack of MI is a big negative for me. I'm actually surprised Java doesn't have it. Oh wait, that's one reason why Java SUCKS! :-)
-- DuckWing
#define WIN32_LEAN_AND_MEAN
#include <windows.h>
You'll dump a lot of the GDI and OLE stuff.
in the programming language is the name. A language will not succeed without a good name. I have recently invented a very good name and now I am looking for a suitable language." -- D. E. Knuth, 1967
I was hoping for someone to get a clue and actually name it P instead of some C whatever or even worse, D...
The table has C, C plus plus, C sharp and Java. Unless Objective C is now C#, which used to be C sharp. I don't see it.
If I'm a troll, why do you feed me? :)
Seriously: Somethimes the "unnecessary" layers are what makes productive software development possible. It's called abstraction.
D has this. One can specifically delete a GC-allocated object, and the GC will delete it immediately without running a collection pass.
see templates
There initial list of features are nice, but dynamic loading, and shaky introspection are the two big things that really frustrate me about the C++ base. I would assume this was for reasons of efficiency, but I see no mention of this on their link.
Ada (95, not the original) also has first class polymorphism, which C++ does not (unless you fake it with smalloc, and a smart pointer)
Squirrel!
David Friedman has integrated the D frontend with GCC.
"I sat out PL/1"...
and missed a language that was a thousand times better than its competition at the time (lousy Fortran and lousy Cobol).
I don't use PL/I (the correct way to print it, BTW, even though it was pronounced "one") anymore, but I got valuable background training on pointers, decent loop-control structures, linked lists, etc., that came in handy when C came along years later.
Its all a conspiracy by computer manufacturers. If that's true, they haven't let me in on the conspiracy, and none of them have offered me any money to make D slow :-)
How did this get modded "interesting"? It sounds like a rant from a nine-year-old who doesn't know how to act like an adult and treat people with respect. And anyway, it misses the whole point of the language.
True, the C++ STL has several of the features which are labeled "No" in the comparison. But it appears that one of the design objectives of D is to put features like arrays into the core of the language, rather that relying on some library. Perhaps the comparison should have said "first class associative arrays" or "core language support for..." or such. It *did* actually say "built-in strings," which hints at the intent of the comparison.
Elladan: Grow up and learn some manners.
Moderators: Read some more details about the posts or skip them.
> a high incidence of memory management related
;) Seriously, a good C++ programmer can create interfaces that would make you drool. And as for newbies, well, they can write ugly code in any language.
:) As for idioms, all the other languages have them too.
> problems, which are often very hard to find
If you use STL or some other MM encapsulation classes, you will have NO memory management related problems. Ever. This is quite unlike C code, where you really do have to remember to free the mallocs. In C++ you never allocate any memory at all. Only newbies do it before they either learn STL or write their own.
> common security issues, often involving buffer overflows
Buffer overflows are not solved by making another programming language. They are solved by fixing your algorithms. They are solved by ditching hand coded text parsers or, better yet, ditching text files of all kinds altogether. Use a packaged XML library to parse your input (you do have all your config files in XML, don't you?) and use libreadline or something for the shell. If you keep reinventing the wheel, don't whine about it breaking.
> compiler incompatibilities, including frequent
> lack of proper template support, exception
> handling, namespaces
That's why you use gcc for everything. gcc supports all those things you mention and is available on every platform worth mentioning. Don't blame the language when your vendor insists on locking you into their lousy compiler.
> obscure and often terribly non-intuitive syntax
Bullshit. C++ makes for a beautiful syntax. You just have no taste!
> overly complex and redundant idioms necessary to
> work around language shortcomings
C++ has no shortcomings. What are you talking about?
> they just switch to a more productive
> language...like the majority of the software
> industry is doing.
No they are not. The majority of the software industry are concerned with developing web applications. You can't do that in C++ because you do not want the stupid user to install anything but a browser. C++ is for real applications that run on your machine, like an application is supposed to.
How about "Double-D"? *That* will bring out the programmers in hordes.
- First they ignore you, then they laugh at you, then ???, then profit.
hummm so did anyone started to write the Gnu D Compiler?
> You might catch an exception and but not have the faintest idea who threw it.
That's correct. It does not matter one bit who threw the exception; the only things that matter are one: there was an exception, and two: the problem that caused it. The exception should name the problem, not the thrower. You do not have to handle every exception, and neither should you try to. All you should do is clean up and report the error (which you can easily do if you design your exceptions with an appropriate interface). If you don't need to cleanup, which would be true for almost all functions, you don't need try/catch blocks either. And don't blame exceptions for the bad design of COM interfaces either.
> I don't think you understand the disadvantages of multiple inheritance.
You are entirely correct. I do not. Perhaps you would like to enlighten me? I have many classes using MI and I find the result very clean and simple.
Don't you mean Db? They already came out with that.
Well, the revealing thing about is, that it does include *some* STL features in the comparison chart, such as strings and vectors, but fails to recognize for example map. This reveals fundamental lack of knowledge about C++ and STL by the writer of the comparison, and justifies quite a bit of BZZZTing...
After all there's not much difference between putting stuff at the core and putting it into a standard library, really. Mostly putting stuff to core may allow cleaner syntax, while putting it to the library may allow more flexibility.
NULL is often (void *)0, which is *technically* valid on some architectures (OS notwithstanding). It's just so unlikely a result that it's safe to use.
NO!!!! (void *)0 is not the address of anything (that the C program can use). See the comp.lang.c FAQ on null pointers.
Most people who put D info on a web site also mention "Digital Mars" both to give context and to make sure people know what D is being talked about. So googling for "Digital Mars D ..." will usually be much more effective than just seaching for "D ..."
Have you checked out wxWidgets? It is a cross-platform C++ application framework that has a nice virtual filesystem and image handling capability. I know it isn't a language in and of itself, but it is still pretty good.
I just looked at two unit test suites I could find, namely jUnit and cxxunit, and I have to say that I was wrong to say that the debugger is the unit testing support for C++. In reality, assert() is the unit testing support for C++ (and C, of course). The unit testing frameworks appear to be nothing but collections of assert functions combined with a graphical tool to catch them. Of course, every self-respecting programmer has asserts in his code. Advanced programmers often have more asserts than real code, and write error diagnostic routines which "explain" more generic exceptions or dump out relevant data structures. Really advanced programmers write their comments in asserts (Incidentally, do you know this trick: assert(!p && "You must allocate a buffer before passing in the fragment");?) As for the GUI, we have the shell, which prints out the assertion messages quite nicely. C++ assertions are also always fatal, which is a very good thing because it forces you to fix things, unlike the unit test framework's GUI, where failures are ignorable.
Don't you people get it
C++ = D
No wonder it compatible with C libraries it's the sam thing!
A good way of thinking about exceptions is that whenever possible, you shoudl provide a way for the programmer to avoid encountering the exception programatically.
For example:
- You can avoid NoSuchElementExceptions by checking the index against the size()
- You can avoid FileNotFoundExceptions by using File.exists()
Note that the standard Java API failed this in some cases. For example, how do you determine if a String is parsable as an Integer without potentially getting an Exception? You can't. Of course, all of the work you would need to check such a String for integerness would be nearly as much work as parsing it into an integer anyways, so perhaps there was a method to their madness.
Anyways, the point is, you are right that exceptions should not be used for normal conditions. Map.remove() returns null instead of throwing NoSuchElemntExceptions, and you can use List.size() to avoid accessing an item that is beyodn the size of the List.
not a translator. It doesn't emit C code. It emits compiled object files.
In fairness, I think his view (at least as I've seen it expressed) is that only minor changes are needed to the language, as distinct from making changes to the library (where things like proper concurrency support etc. very much are on the cards).
I agree and disagree, respectively.
C++ is actually pretty good at what it's meant for. The problem is usually that it's being used by the wrong people for the wrong job. The fact that half the C++ world is stuck in a time warp and insists on ignoring the past ten years of its development really doesn't help matters.
On the other hand, clearly it's vastly underpowered compared to some other popular languages today:
But can this sort of problem be fixed yet still leave a language that is C++? I don't think so. You can't just bolt these things onto an existing framework. They have to be an integral part of the language design, its supporting libraries, and its programmers' mentality.
I don't believe anyone could do that effectively, starting from where we are. As you say, everyone's busy playing with templates, which are all very nice for the elite and may result in a few nice(r) libraries, but which are sod all use to the vast majority of programmers actually using C++ for their day-to-day development. That area is still suffering from readability problems, and silly limitations on basic tools (enumerations, for example).
I think what's really needed, in the medium term, is a replacement that goes up a level, learning from what has and hasn't worked well in C++. I don't think the next big language will be another variation on the C theme with extra bits added on: that was a smart move in C++'s infancy, but as Python shows so well, a language with a reasonably clean syntax can become useful and popular quite quickly, even if it's quite different from what went before, and commits a few "cardinal sins" (someone's sig around here used to read "Friends don't let friends use whitespace as punctuation" IIRC).
None of the direct competitors in recent years has really moved that far ahead of C++. I consider adding a GC to be an evolutionary or sideways move, not revolutionary. Several of the other much heralded changes in the Java and C# languages have been steps backwards, which they're now desperately trying to fix, or will given time.
No, the next big language for mainstream, mid- to large-scale development will look quite different to C++, Java and C#. It will have a clean, programmer-friendly syntax, but one supported by sound underlying models. In particular, it will learn from C++ and provide for "multi-paradigm design" or whatever it's called tomorrow, but with much better support for modular programming and arbitrary calling conventions (including distributed programming). It will have a small but high quality standard library, which will provide the essentials and then establish a framework for more powerful stuff to plug into. It will also
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
OK. That's completely the opposite design philosophy to C++, but that's their choice. It's unhelpful to imply that C++ doesn't have those features, however. Any programmer writing in either C++ or D could use them routinely, so both columns should be ticked if it's going to be a useful comparison.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Exactly why do we need this? In the marketplace, more and more, applications cast in C++ are moving towards a web-centric or Service oriented Architecture (SOA). This looks like the next coming wave of technological development. So... Why do we need a new language that supports backwards "C" compatibility? Is there that much legacy code out there worth preserving? Perhaps we need better business logic mining tools. Ciao
> it is all too easy to use MI incorrectly and screw things up with improper casting.
If you use casting, the problem is not with MI, but with your understanding of inheritance. In a good design you never have to cast anything. The only difficulty in understanding MI casting is that you have to realize that you can't cast to another branch. This is because the branches are not derived from each other and just because you have one class that merges both branches, does not mean that there no other such merges. Until you understand this, you should not be using MI. Just as you should not be driving until you know which side of the road to use.
> it is a particularly difficult feature for compiler writers to implement.
Not really. It will be difficult for you if only if you wrote your compiler with single inheritance only and hardcoded all your poor assumptions. There will be some tedious code for checking virtual bases and merging of vtables, but it should all be fairly straightforward. The output is simply a vtable pointer for each branch and you need to make sure you know which function call uses which vtable.
> when there are other language constructs that can do just as good
Like what? I can't think of any simpler way to implement this functionality. I mean, what can be simpler than two vtables? It's what you would do if you aggregated the interfaces through member variables too.
Just like C is.
"Break out the gin, and the small violin, I'm a raging success as a failure." --Firewater
Even "the idiot in the next cubicle" can write code that is fast in C++, without optimization, without tweaking, debugging on, etc. There are a million ways to make a program fast and a few ways to make it slow.
In Java you at least HAVE to think about making things fast in order for it to happen. No such requirement for C or C++. There are a million ways to make a program slow and some manual optimization effort is required to make it fast.
Even if it were politically possible to choose one language, it probably would not be a good thing.
Instead, we should focus on making it easier for people to use different languages.
For example, where "C" is currently recommended, allow any GCC language. This can already be done to a certain, very limited, extent (ie. most languages can consume C), but it could be much bettter, eg. if all these languages produced object files that could be linked together. I'm suggesting a compiler option that would produce object files according to this cross-platform GCC/Gnome standard.
It seems that Troll Tech is dealing with the deficiencies of C++ by creating their own proprietary version of the language. This is a bad approach. The GTK approach of allowing the library consumers to move to newer, better, languages is much preferable. Let's keep doing that.
(It would be nice to be equally open to Python, Java, and Mono, but I don't think I would want to have all three of these running on my machine at once.)
what's the difference?
I recently converted a C implementation of Quadpak to C# (not hard really) and the C version uses function pointers while I had to change it over to function delegates for C#.
For my purposes I didn't notice any glaring difference. It's functionally the same.
Is there some feature of delegates that isn't available using a straight pointer?
Ben
Work Safe Porn
Good god, people, the creator of the language deserves better than a score of 1---especially when he's counter-attacking a piece of FUD that got way over-modded.
:-)
Further discussion on memory management as it relates to D can be found here.
A slick, responsive 3D fighter game written in D (and somehow unencumbered by the burden placed on it by the garbage collector) can be found here. Source included, so you can see how slick it is on the inside.
And Walter: Thank you. I've spent a lot of time reading and interpreting the ISO C++ standard, and it usually leaves my brain feeling itchy, flaky, and swollen. With that in mind, I'd just like to say that, after reading all the specs I could find, D (so far) seems to me like the Gold Bond Medicated Powder of programming languages.
At least that would be easier to search for.
Got time? Spend some of it coding or testing
The thing that most of the GC naysayers in this thread are ignoring is that you only need to garbage collect when you allocate too much. It's trivial to write your own object pooling doohicky - pre-allocate all the objects that you think you will need, and stick them in a vector (optionally declare it static so if the GC ever runs it won't even look at them). Pop off an object when you need it, return it when you're done (or better yet, mark the entire resource unused at one point in your program), and in case you need more than you thought, just allocate another object as you normally would - the difference is that this object will be there the next time around. This is much more efficient that new/delete in C++ - you don't wait for memory to be fetched from the OS, you don't wait for that memory to be laid out, if you don't need it (and you really don't need it most of the time) you don't wait for object initialization, and you don't wait for deallocation (especially not if you return the whole thing at once!). Object allocation costs at best one function call and integer increment, and at worst that plus the cost of allocating the object; object de-allocation costs at worst one integer decrement (I suppose if you're worried about safety you'd do a range check too). Fancy, dynamically-sized data structures (arrays mostly) need a little search and pointer comparisons, but with hashing it's also pretty cheap. If you need to actually get rid of the thing, you just lose the reference, call the GC, and the whole thing gets reclaimed at once. Oh, and in case you didn't notice, this method has nothing to do with GC besides being safe and fast. I use it all the time with C++ and it works faster (and IMO the style helps prevent and debug memory leaks and other errors better) than manual memory allocation.
In the great CONS chain of life, you can either be the CAR or be in the CDR.
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
Hay anyone wanting to put forward some contructive critism join the D newsgroup(at news.digitalmars.com). Who knows you just may help *put the language back on track*.
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.
Strostrup does say that he's reasonably happy with the basic language. I don't agree. If the basic language was OK, there wouldn't be a need for C#, etc.
C++ has some major outstanding problems, dating from early bad design decisions. Not just C legacy problems, either. Here's a few of them:
-
The original C++ language had no templates, no exceptions, no run time type info, and no references. This led to a horrible programming style in the early years, with big ugly macros, no standard way of handling errors, wide use of unchecked downcasts, and "this" as an assignable pointer. Much of that legacy lives on in running code.
-
You can't implement safe smart pointers in C++.
No matter how hard you try, you can't make auto_ptr work right. It's been formally revised three times, without success. The problem is that you have to let a raw C pointer out of the encapsulation to do anything with the object, and that pointer isn't "special" to the language. There needs to be a const-like attribute that says "this pointer can't be deleted or copied to an outer scope". Then you can build safe encapsulations.
-
Iterators and references were both afterthoughts. They should have been a fundamental part of the language. C's ambiguous syntax for pointers, which makes a pointer to an object and a pointer within an array
indistinguishable, shouldn't have been perpetuated in C++.
-
A major effort should have been made to make built-in arrays obsolete. Even today, you still see extensive use of C arrays in C++ code. They should be unnecessary. To this day, you can't say "no C arrays or pointers allowed in C++ code" on a project. If you could, there'd be far fewer buffer overflows.
None of this is being fixed in C++. That's the problemI bet you that you can abstract even further in c/c++ than you can in Java, because you have access to literally everything directly; memory, hardware.
u tu re-4.html
:-)
And with pointers, references and all the other syntax c/c++ have that Java doesn't, how could it be less?
c/c++ is RICHER than Java.
Don't get me wrong; I LOVE Java, I really do!
With Java, it WAS simple to create theads of execution that would load classes from disk or create them at runtime, classes that serialized themselves and shot around a network and re-instantiated themselves somewhere else and talked with other systems... I mean come on, it's the COMPUTER WITHIN A COMPUTER, that's what Java is! Pretty cool.
But equally, you could obtain all the necessary libs to do the same thing in c/c++.
And in c/c++, you could abstract the mechanism any way you see fit, every module can have a different memory addresing/allocation schemes if you want, and you have all the granularity of control you want.
What we'd need is a transputer, so that programming languages really WON'T matter anymore.
c/c++/Java would all be pretty much equivalent in terms of execution speed.
http://arstechnica.com/cpu/2q00/x86future/isa-f
Scroll down (3rd or 4th paragraph) the page until you get to the paragraph about the HP Dynamo chip.
It begins "Dynamo is an odd beast."
It wouldn't matter which language you chose.
It would really be a question of which tool you felt went with the job at hand and how comfortable you are with that language.
I'm waitin' fer mah transputer...
PS - The whole article is great!
I don't know the meaning of the word 'don't' - J
I think that's being a little optimistic. While not technically untrue, I feel that a large C++ library wrapped around a large C library probably requires more than "minor modification".
C for great efficiency.
C++ for speed-critical object-oriented code.
Obj-C for very very flexible objects (kicks ass for interface code).
Obj-C++ for those brief ventures outside of Steve Job's little dream world.
Java for portable & easily networkable code.
Asm for the poor poor bastards stuck doing code that must be Godlike (M-M-M-Monster kernal panic!).
What's "D" supposed to do?
Notice it was an assignment, not a comparison. Besides the points is C still gets incremented. It's not like incrementing 'C' would make it 'D' anyway... unless C was ASCII 67.
Cheers Jonny
How far do you want to take this? I consider such things as a file open failure due to non-existant file, insufficient privleges, unmounted filesystem, etc., as a 'Normal' condition. If you take it to extremes, your code would look the same as a language without any exception handling capabilites.
Yes, there is a language called Z. I believe it is a functional specification language, or something like that. Maybe some other poster will know more about this.
I've been working for a while on some ideas for the Cube language---instead of object-oriented, it cubicle-oriented. For modeling of IT projects...cube has ideas of 'resources' that actionize on 'tasks' in 'cubes'.
It's not that funny. Amiga E is a pretty good language for starters, think of C and Pascal mix with some support for objects; unfortunately the compiler is written in M68K assembler making it hardly portable. Then there's Power D, which AFAIK is based on Amiga E (unsure about it).
I'm sure there are many so-called C successors. You can't put everyone in a table. Best use languages people actually use as a benchmark.
So D Would be Delphi ? :-)
Boz
www.boznz.com Simple solutions to complex problems.
>>NULL is often (void *)0, which is *technically* valid on some architectures (OS notwithstanding). It's just so unlikely a result that it's safe to use.
>NO!!!! (void *)0 is not the address of anything (that the C program can use).
To explain to those who can't follow the point:
I wasn't talking about C. Nor Unix. Physical memory addressing starts at zero. Therefore a pointer whose value is zero is a valid pointer (its address exists).
On many (but not all) CPU architectures, address zero is not writeable, but the implementation of memory handling under unix does not require an "invalid" pointer to be zero - simply outside the addressable memory space for the process. Zero is merely convenient (and likely to be protected on the CPU anyway, in the average case).
My *point* was about in-band error values. Given that different values can be valid or invalid for different operations, functions cannot use consistent in-band errors as the poster to whom I replied noted.
To emphasise:
I was observing that value zero is a valid file descriptor, but not (in C) a valid pointer.
Incidentally, with regard to the C faq, I am aware that the compiler spots the string "(void *)0" and uses the "internal representation for the architecture for an invalid pointer".
There are ways, however, to force the issue:
intptr_t ret_arg(intptr_t arg)
{
return arg;
}
void *ptr=(void *)ret_arg(0);
a) You still have to test on all platforms (a new version of the JVM counts as a platform, btw) because you can almost never rely on proper and performant support for all features
b) so yeah, I'd choose my deployment targets and compile the binaries I think are going to end up mattering the most.
Problem: Too many incompatible languages.
Solution: Another incompatible language!
Hmmm... I wonder what's wrong with this picture...
Ceterum censeo subscriptionem esse delendam.
That site has many broken and non-existent links.
(Broken = 404; non-existent = looks like it should be a link, but there is no a tag)
I'm getting just a little tired of people arguing that language X has garbage collection while C does not. Garbage Collection is not built into the C language. Then again, dynamic memory allocation is not built into C! How do programmers get by without built in memory allocation? They rely on external libraries.
Likewise, Garbage Collection can be compiled into C and it is usually done by linking a garbage collection library that will replace the usual mallocs with garbage collection code and replace frees with a noop. That's it. No changing the source code, just your makefile and you too can have garbage collection in C. As an aside, if dynamic memory allocation were built into the language, this method would not be possible.
Of course, there are always the border cases. If I want to open a file for input and process its contents, a missing file would (in my mind) be an exception. But what if the file is present but empty? That's not an exception to me. But, really, either way there is no data to process, so why do I think of one as an exception and not the other? I can't really think of a logical reason; it's just a "gut reaction".
Recruiter advertises for an ISP network engineer - Not for my company, since we didn't use Sun - and turned me down because I don't have a CCNA. If the recruiter had a clue he would've at least let the client reject my CV (which detailed my knowledge of all sorts of ISP-type stuff) rather than rejecting it himself. He might even have managed to close the job a month sooner (that was how long it took before the ad stopped appearing in the paper.
Sadly, tech recruiters are often nothing more than recruiters who know the difference between RAM and HDD. No technical experience required.
"God, root, what is difference?" - Pitr, userfriendly
I wish I had known that.
I paid mucho bucks for the SAS C++ compiler for the Amiga.
Those who sacrifice security to condemn liberty deserve to repeat history or something. - Benjamin Santayana
Most of these anti-D messages are very very wrong.
They come from people who have not tried D before.
Best bet is to send your questions to news.digitalmars.com (D news room). Half this bunch are ignorant.
Particularly the GC issue. See:
http://www.digitalmars.com/d/memory.html
If you want a GC, it's there. If you don't want it, you can turn it off (completely). That should please both java and C++ fans, but noooo.
Check out projectudi.org. I think its a little VM just for platform independent device drivers, that should also improve system stability when running a less than perfectly written driver. Goes some of the way you're heading. I at least wish the linux/bsd kernels were written in C++ (a sane subset thereof), or nowadays D.
Of course, microsoft wants to kill UDI since it implies leveling the playing field windoze is on - imagine universal compatibility with commodity devices...
'Right to innovate' my arse!
Anyone who avocated the use of just one language is an idoit. D is good for some things and not for others. That doesn't mean it's not a good language.
The major problem with D will be getting the message across to organisations that D will save them time and money. It's one of those retorical questions. So many languages have died because they have not beem popular enough.
/. email mention actual acidemnic problems with the language.
Also because a language isn't popular, people assume it's a bad language. Many miths and half/truths result.
Therefore I think for D to be acceptable to the masses it must first be used by the many indviduals.
Who knows, with a name like D it may by lucky and take off.
Appart from that, I can't see any problems with the language itself. I haven't seen one
MI - Is not a problem with the language, not when you can use interfaces (and mixins are planned). There is no problem that can't be simply solved without MI.
The comparison list - The argument presented here was not that D was bad, but that it was avaliable in C++ already. Doh!
Opperators - You simply don't understand how messed up C++ opperators are.
Webbased - Someone want to make a Djava? This is not a problem, it's simply a wish.
Come on use your heads an put together some serious (well thought out and researched) arguments.
Half you you think that there is nothing wrong with C++. I say you've had your heads stuck in the mud to long. This is what people said about C++ when it came out.
Obviously you haven't tried D. There are better ways to do things then by preproccessor. If you must, you can still use the C pre-proccessor.