Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

The D Programming Language

michael posted more than 13 years ago | from the whiter-whites-and-brighter-colors dept.

Programming 530

dereferenced writes: "Walter Bright, author of the original Zortech C++ Compiler and the free (as in beer) Digital Mars C/C++ Compiler, has posted a draft specification for a new programming language that he describes as "a successor to C and C++". It seems to me that most of the "new" programming languages fall into one of two categories: Those from academia with radical new paradigms and those from large corporations with a focus on RAD and the web. Maybe its time for a new language born out of practical experience implementing compilers."

cancel ×

530 comments

Sorry! There are no comments related to the filter you selected.

A critique (and take a look at Ocaml) (3, Interesting)

Chuck Messenger (320443) | more than 13 years ago | (#2110708)

Briefly examining the specs for D, here are some thoughts which occur to me, based on my experiences with C++, Java, and a few other languages:

o Multiple inheritance is absolutely necessary. The main way it is useful is for Java-style interfaces.

o Getting rid of macros (preprocessor) is a very bad idea. What is needed is even more powerful macros (see Lisp).

o Generic programming with templates is the greatest thing about C++ -- the one feature that puts C++ above other programming languages. I'd rate generic programming capability as being a "must" of any modern programming language.

o Operator overloading is a Good Thing, in that it helps you set up a well-designed library as a "mini-language". Good programming practice involves reducing the number of keystrokes required to achieve a given result (ultimately). Generic programming, macros, and operator overloading all go in this direction. Eliminating them is a step backward.

o You say "smart pointers are irrelevant in a garbage collected language". Not true. There are many types of resources which a destructor might free besides memory. One weakness of Java vs C++ is that it is hard to control Java's "destructors".

The "best" programming language (for general-purpose "big" programming projects) I've encountered may be Ocaml. It can compile into native code as efficient as C++'s. It can also be interpreted. It is stronly typed. It supports a powerful "functional" programming idiom. It looks pretty good to me, although I haven't used it for anything "real" yet. But if you're looking for the "be-all, end-all" modern programming langauge, I think Ocaml's worth taking a look at.

'D'? Shouldn't it be called 'P'? (1)

Profound (50789) | more than 13 years ago | (#2110827)

BCPL begat B which begat C.

So it follows the next character should be P.

Not nice thing to say (2)

krokodil (110356) | more than 13 years ago | (#2111469)

It is not very nice thing to say, but the guy stuck
in the time few years ago:

1. Java is already invented.
2. Nobody cares about 16 bit code anymore.

If you like Java, use it. If you dislike java,
stick to good old C++. No need to invent a new language.

I hope he gets it finished (2)

MSBob (307239) | more than 13 years ago | (#2111470)

It would be really nice to have an open alternative to Java that is also compiled. Glancing through the spec there is lots to like there. For instance the idea of building unit tests into the language spec seems like a pretty good one to me and would help popularise unit testing among developers. Native support for unicode is nothing new but it's nice that unlike Java he still retians the ascii type for those who don't need i18n. I hope the guy pulls it off. I'd like to play with a new C++ like language. If he only reconsidered his views on templates though...

Good points and bad points (1)

King Of Chat (469438) | more than 13 years ago | (#2117215)

A lot of people I meet can't really cope with C++ so some simplification would not be a bad thing. Losing the C baxkwards compatibility should've happened in C years ago. I like the "no headers as well and macros are a tool of the devil.

However, there are times when I do want to manage my own memory - generally for performance. If I know I'm going to be allocating a ton of SmallObjs then I write my own new & delete and manage in blocks. Obvious.

Similarly as someone said earlier, I like operator overloading. If you're doing matrices etc. then it's cool. I also like templates - ugly, but type-safe.

The good points could've been done by a compiler switch
Maybe -noshit
Turns off macros, global functions (apart from main), global variables, C style casts, use of void * and all the other crap which we inherited from Brian and Dennis. Oh, and get a proper auto_ptr class and then we're done. Oh yeah, and get some decent programmers. You can write shit code in any language (try not writing shit code in VB).

Not a troll (-1, Offtopic)

Anonymous Coward | more than 13 years ago | (#2122817)

Although you people will most likely mark me as one. I'm posting as a dirty loathful AC because I know none of you will agree with me. Oh well.

Fuck D and fuck C++. Go back to cold raw C people! We're supposed to like programming! It's supposed to be in our blood!

This isn't about making money. It's about creating something beautiful. Something so complex and amazing that only few can understand it's purity. So shut the fuck up and stop bitching about how hard your lives as programmers are.

fp (-1, Offtopic)

Anonymous Coward | more than 13 years ago | (#2126521)

fp

I would just feel better if... (-1, Offtopic)

Anonymous Coward | more than 13 years ago | (#2135563)

...these names quit sounding like grades.

(Yeah, yeah, yeah. I know all about Bell labs. It's a joke, OK?)

here comes another war.... (1)

4n0nym0u$ C0w4rd (471100) | more than 13 years ago | (#2137020)

Langauge X is better, it runs on average about 3 times faster than slow-ass langauge Y.

Langauge X sucks, it's not incredibly portable or as easy to use as Langauge Y, and speed is becoming less important as time marches on.

But what about LNOU (Langauge No One Uses) it's got both the speed of Langauge X and the ease and portability of Langauge Y.

bicker

whine

Seriously, I'm mostly playing arround with C++ right now (and I love it) but Java, Python, Perl, and most of the other langauges out there ALL have their uses. Yes, all of them. D will be no different, it will have a few great features that supporters will throw in the oppositions face and a few downsides that the opposition will exaggerate. I gave the specification a look over and it seems to me that D is basically what C++ would be if the designers hadn't given a damn about backwards compatability with C, except they are removing a few usefull (in my opinion) features of C++ and either replacing them or dropping them completely. The specification is still rough, but overall D looks like a decent langauge, one made to work well rather than confor to some ideal (kinda like C++, again IMO). The guy is very straight forward about what D should not be used for and gives examples of some things it would be good at.

I guess what the whole thing comes down to is "How Good Will It Be". If the answer doesn't end up being "Wow, I Can't Live Without It" then D will fail even if it's much better than other, older solutions, simply because no one wants to port old code or learn a newer langauge when the old one still works fine. That's the reason why many of the newer langauges don't have the following their creators think they should (and they may be right), they're simply not worth the time or effort it would take to learn them and port them. Unless D is absolutely incredible I know I'll be sticking with C++. Why? Because C++ simply WORKS for what I'm doing right now, and there is no reason to all of my code or learn yet another langauge when the one I'm using is fast and easy enough to get the job done, and C++ is already a proven langauge (as is C), as widely used as it is....it's not going anywhere.

Why would we need another language? (1, Funny)

shine (1502) | more than 13 years ago | (#2137808)

When we have COBOL, the only language you would ever need to know.

Identifcation Division.
Environment Division.
Data Division.
Working-Storage Section.
01 TheOnlyLanguageYoullEverNeed pic x(30) value spaces.
01 ArgumentSettled pic x(01).
Procedure Division.
Move 'COBOL' to TheOnlyLanguageYoullEverNeed
Move 'Y' to ArgumentSettled.
Stop Run.

Sounds like the same reasoning that lead to Java (1)

IPFreely (47576) | more than 13 years ago | (#2138424)

The overview talks about how C/C++ has become overloaded and needs to be simplified. Isn't that the same reasoning that lead to Java. how different will this be from just using Java? (syntax aside, just object orientation and capable architecture).

Re:Sounds like the same reasoning that lead to Jav (0)

Anonymous Coward | more than 13 years ago | (#2147206)

This doesn't use a vm like java does. Read the spec.

After C comes P! (4, Informative)

vu13 (462742) | more than 13 years ago | (#2138425)

First their was BCPL, then B, then C. Logically the next language in this family would be P.

Re:After C comes P! (0, Flamebait)

heffrey (229704) | more than 13 years ago | (#2147087)

First their was BCPL

Then there was spelling....

Re:After C comes P! (1)

Keith_Beef (166050) | more than 13 years ago | (#2154105)

Not the way this boy sees things. He clearly doesn't remember BCPL.

But then, I'm still waiting for somebody to write a successor to Forth. Would it be called Further?

can you say "Java?" (5, Insightful)

dobratzp (155212) | more than 13 years ago | (#2138570)

from the overview page [digitalmars.com] ...

features to keep:
  • compile/link/debug development model
  • Exception handling
  • Runtime Type Identification
  • link compatibility with the C calling conventions

All except the last is contained in Java.

features to drop:
  • C source code compatibility
  • Link compatibility with C++
  • Multiple inheritance
  • Templates
  • Namespaces
  • Include files
  • Creating object instances on the stack. In D, all objects are by reference.
  • Trigraphs and digraphs
  • Preprocessor
  • Operator overloading
  • Object oriented gradualism
  • Bit fields of arbitrary size
  • Support for 16 bit computers

This seems to be precisely the parts of C++ that Java also does away with. Furthermore, the C preprocessor is not strictly part of the C language and in fact many other programming projects use cpp for simple cut and paste includes of their favorite language. When I first read about trigraphs, I couldn't wait to try them out to make some extra obfuscated [ioccc.org] code, but alas the C compiler I was using didn't support them. In fact the lack of standards compliance is one of the main drawbacks to programming in C++ and C. If my Java code compiles on sun's compiler, then I can be assured that it will also compile on any other compiler claiming to compile Java code.

The author also mentions that D will not have any bytecodes. From a strict perspective, the Java programming language and the Java VM are two different standards and just because you typically compile Java code into (confusingly named) Java byte codes, doesn't mean you can't use one without the other. For example, anyone (who is insane) can pick up a copy of the Java Virtual Machine Specification [sun.com] and a hex editor and make some syntactiacally correct class files. More realistically though, java bytecodes are often targets for compiler construction classes. Also, if you use the GNU Java Compiler [gnu.org] you can compile programs written in the Java programming language directly into machine code.

While 90% of the description of this language screams Java, there seem to be some of the more useful features of C++ thrown in (typedefs, scope operator, etc.). The only way for this to be successful, is to finish standardizing the language as soon as possible and get a reference compiler for it so it leaves the realm of theoretical vaporware. Perhaps Java might have looked more like this if the language design was revisited. However, Java has lots compilers [geocities.com] which are much much more likely to conform to the standard [sun.com] than the C++ equivalents [cplusplus.com] .

2p (-1, Troll)

Anonymous Coward | more than 13 years ago | (#2139532)

w00t!

Slow down cowboy!

Slashdot requires you to wait 2 minutes between each submission of comments.pl in order to allow everyone to have a fair chance to post.

It's been 1 minute since your last submission!

i can't wait (-1, Troll)

Anonymous Coward | more than 13 years ago | (#2140138)

to fuck taco's mom again. she is a wildcat in the sack. and she sucks big cock like nobody's business. which is why i'm telling all you pathetic fuckers.

SECURITY BY DEFAULT (2, Insightful)

zenray (9262) | more than 13 years ago | (#2142847)

One thing in this new programming language that needs to be designed in from the ground floor is SECURITY BY DEFAULT. Make buffer overruns impossiable for starters. I'm very weak as a C programmer and just a student of computer security but it woluld go a long way to solve most of the security problems in appliacations if the programming language enforced proper security codeing practices. Maybe everything would be as secure as OpenBSD. Theo should help design D language to be SECURE BY DEFAULT rather than doing a security review after the software is written. Just my opion, I might be wrong.

Why another language?? (0)

Anonymous Coward | more than 13 years ago | (#2144075)

Common lisp has already all the features of D. and a lot of more! Where are the macros?? Why re-inventing the wheel again and again? Then we will learn "D in 21 days". How about learning our existing languages in 10 years?

Re:Why another language?? (-1, Offtopic)

Anonymous Coward | more than 13 years ago | (#2114003)

lisp sucks.

Re:Why another language?? (0)

Anonymous Coward | more than 13 years ago | (#2133295)

A lot of programmers never experienced lisp. That's why!

Maybe? (3, Interesting)

scott1853 (194884) | more than 13 years ago | (#2154059)

"Maybe its time for a new language born out of practical experience implementing compilers."

Maybe it's time for a new language to be born out of practical experience writing software.

I don't know how it is in Linux, but I really hate having to write several hundred lines of code for a single window w/controls in Window API calls. Personally, I'd like to see MS get rid of those API calls (and don't replace it with ActiveX until ActiveX works). Between the ones that don't work as documented and the rest of them being overly cumbersome, it's just a hassle. Especially when you have to create your own encapsulation objects for those things. I like Delphi because of its encapsulation of the visual components, but their base library sucks in itself in that it doesn't expose all the functionality. And since they saw that it was so important to declare everything as PRIVATE methods, you can't get descendent object to do everything you want either because you don't have access to all the base functionality.

Simplicity shouldn't be taken to the extreme either, and gear a new language towards the non-programmer crowd like MS tries to do.

Of course MS is just making things worse right now by implementing these new Luna APIs for XP. I'm sorry, but I don't know of anybody thats been really dying for the ability to use API calls to put a gradient on a button. In my opinion, this is just MS's attempt at trying to get developers to waste time, so they don't work that hard on developing new products that may compete with MS.

Why not completely from scratch? (2)

Badgerman (19207) | more than 13 years ago | (#2154080)

Improving languages? More power to the people doing it. C++ is daunting as hell even to experienced programmers coming from other languages, and has some pretty odd legacies.

However, to play Devil's Advocate, why base a language on anything pre-existing? Is anyone creating languages completely (or mostly) from scratch?

Admittedly a from-scratch language would be up against a higher learning curve, but I wonder if the benefits would outweigh this.

Just a thought from a person who's had to learn a lot of languages.

Absolutly not! (0)

Anonymous Coward | more than 13 years ago | (#2154139)

Practical experience designing compilers? No way! The programming language is the human interface. The compiler's job is to translate that into what a computer can recognize. If 10 people spend 1 year crafting a compiler for a language that is especially difficult to translate to assembly so that a million people can save a day coding a project. Tailor the language to the humans, make the compiler as large and nasty as is necessary. I'm one of those people that would rather spend 1 hour compiling a small program if it would run 10% faster than if I spent 10 mins compiling it.

Buggy compiler? (1)

thejake316 (308289) | more than 13 years ago | (#2154153)

I should think as compilers go a C compiler would be fairly easy to implement, aren't there just like 14 reserved words, and aren't several of them obsolete/never used? And weren't c++ "compilers" really cross-compilers that converted c++ to plain old c? Giving us that delightful "name mangling"?
I wish people would stop dreaming up new languages and concentrate on enhancing existing languages, Java in particular. As a programmer, I'm not going to keep more than 2 or 3 languages handy on the top of my head and I doubt many other programmers are so inclined either. Java at the moment does the most for me, even if it does compute a FFT slower than asm, perl is nice when you don't have a plan and don't want to think too much, and C is the common tounge of *nix. What's in it for me to learn C#, D, Python, etc. that isn't already covered by perl, C or Java? (That's rhetorical, the answer is nothing.)

Convince me (2, Interesting)

Anonymous Coward | more than 13 years ago | (#2155131)

It's a very heartwarming idea - he's attempting to conjugate C's performance, speed, and low "levelness" with Java's "oh-my-god-did-I-just-finish-writing-that,-boy-it- only-took-me-3 minutes... but-it-runs-slow" beauty.

But if it can be done, why hasn't it been done already, hmm?

Re:Convince me (2, Insightful)

JohnA (131062) | more than 13 years ago | (#2158367)

Why, oh, why must people propogate the myth that Java is slow? While that may have been true in 1995, it is hardly the case today.

If you're going to make comparisons, at least get your facts straight

Re:Convince me (2, Informative)

JanneM (7445) | more than 13 years ago | (#2158048)

I run one Java program today (PCGen). It is really a menu interface to an internal database. My machine is no slouch (600Mzh, 128Mb memory). Lists are _slooow_ to scroll, everything 'hesitates' a moment whenever you do something, and I can sometimes actually see the redrawing. It's like being back on using a graphical shell on my C64... And no, it's not an old Java interpreter either, it's the latest Sun offering for Linux.

I use that program simply because ther is (to my knowledge) no other option under Linux, but it is a pain to use, when such a (computationally) light program simply shouldn't be.

Other Java programs I've tried has suffered from the same agonizing effects. I'd need a whole lot of convincing to ever use a Java application if there was _any_ other option.

Disclaimer: Just my personal experience (but that's the one that counts for me...)

/Janne

Re:Convince me (3, Insightful)

rossjudson (97786) | more than 13 years ago | (#2157865)

What you've learned is that shitty programming can run slow anywhere. A well-written Java UI can fly. Do yourself a favor and download JBuilder from Borland. That's a nicely written Java UI, and it's pretty much the same speed as a native UI.

It's unfair to compare a Java UI directly with a native UI. How well does that native UI run on other platforms? Oh yeah, it can't. How well does it run from a web page? It doesn't.

Properly written Java code can approach the speed of pure C, be done in a tenth the time, and be significantly more maintainable and portable.

Re:Convince me (3, Insightful)

Vanders (110092) | more than 13 years ago | (#2132590)

It's unfair to compare a Java UI directly with a native UI.

Why? Users don't care about wether your application has a slow user interface, all they'll do is complain that "This program is slow"

Java has a place, and by extension Java UI's have their place. But saying "Oh well it's O.K for the user interface to be slow, because it will run equally slow across all platforms" is a load of rubbish. If Java code can run just as fast as native compiled C or C++, just why are the Java User Interfaces slow?

Any Java zealots want to clear up the aparent contradiction there?

Re:Convince me (5, Insightful)

IsleOfView (23825) | more than 13 years ago | (#2135022)

I'm afraid I have to disagree. I'm a pretty strong Java advocate, but I still don't feel that it's ready for desktop use because of Swing performance issues. I spoke with several of the engineers that worked on JBuilder while I was at JavaOne this year. They spent a *LOT* of time writing custom classloaders, etc. to make their GUI so snappy. JBuilder is a spectacular example of a well written Java GUI, but I don't know if it would be reasonable to say that just anybody could write something like it in 1/10 the time of some other language.

Now on the server...that's a totally different story. I write server apps all day in Java --- my development times are SLASHED from what they would be in C/C++, or even CGI's. Maintenance and documentation are a breeze, and performance is fabulous. Java really has done great things on the server.

Re:Convince me (0, Troll)

andrewscraig (319163) | more than 13 years ago | (#2158246)

Because it is slow...take a simple Hello World app - java takes 2 seconds just to start up, whereas C starts immediately - winner == C.
Ok - so the VM overhead accounts for that. So how about GUI apps - hmmm - which would win there? I've yet to see a Java GUI run as fast as C -- therefore the winnder is C again. (Anyone like to come up with a like-for-like example of where a C GUI is slower than the equivelant Java one)?
Next let's compare File I/O - load a 10 MB file in both....last time I did this the Java app took several seconds, whereas the C version performed

Re:Convince me (0)

Anonymous Coward | more than 13 years ago | (#2158283)

Yes, Java rusn faster now. But so does C. Computers have gotten faster. Native compiled machine code will run faster than interpereted. Stop using advances in hardware to hide the weakness in software.

Re:Convince me (1)

kurokaze (221063) | more than 13 years ago | (#2158351)

So your contention is that a program
can run just as fast on a virtual machine
as one that is compiled natively?

I'd like to see that please.

Re:Convince me (1)

IsleOfView (23825) | more than 13 years ago | (#2133294)

Are you forgetting that Java code *is* compiled natively? (in memory when the app* is executed) This is why Java can be performant on the server-side -- there are start-up costs associated with this, but a good JIT compiler (Sun's Server HotSpot compiler is good) can identify optimizations *at run time* and compile even faster code on the fly....

Re:Convince me (1)

Doctor Memory (6336) | more than 13 years ago | (#2138421)

The point is, it's not perceptible for most applications. We just switched from using J++ (native C/C++) to NetBeans (100% Java), and on a decent machine (I've just got an 850MHz P///) there's really no difference. On some of the slower machines here (400MHz PIIs), there's a sub-second delay on some operations, but it's not enough to be distracting. I wouldn't use it for real-time stuff, but then I wouldn't use C++ for real time either (unless I didn't use any templates or any of the other nice OOP features, and then it's basically just C anyway).

Re:Convince me (1, Insightful)

Anonymous Coward | more than 13 years ago | (#2158247)

With a smart JIT compiler it's actually possible for it to be _faster_ under some cirumstances as it has runtime information :-) It might seem impossible, but computer performance is so complex to determine that it's possible.

Re:Convince me (4, Informative)

JohnA (131062) | more than 13 years ago | (#2158249)

Read again. Nowhere do I compare the speed of a VM executed program to a native compiled one. Java is not the end all, be all of languages, but it is much more than the applet creation toolkit it was in 1995. Will fourier transforms ever run as fast in a VM as they do in optimized native code? Probably not. But, then again, how many of your programs are doing fourier transforms

It's simply a right tool for the right job issue. Plain and simple

templates and operator overloading are good things (5, Interesting)

sanermind (512885) | more than 13 years ago | (#2157829)

It seems this guy really dosen't like c++. Now, being that he is a compiler implementor, I can certainly understand that! *grin*

Templates and stack instantiation of of objects with semantics [i.e. constructors/destructors] is a royal pain in the a** for compiler writers. In fact, only somewhat more recently is g++ even able to handle templates in a decent way; it took a long time to get it right. C++ was a very ambitious language, hard as hell to implement, but that's what makes it so usefull. Give up templates and multiple inheirantance? He suggests this is a good thing?! D is clearly not a language innovation, he should have called it C--.

Besides, you don't actually have to use such features extensively [or at all, really] in a C++ program. You could always avoid iostream and just #include old stdio.h, for example, only choosing to use classes with constructors for some usefull/neccessariy/labor-saving part of the code, while all the rest of it is essentially no different then C [aside from stricter compile-time type checking, which ANSI C has been moving towards anyway, lately]

This is no innovation.

A few other random points:
Ohh! Garbage collection, you can link to a garbage collecting malloc in a C++ program anyway. [If you really care to look into it, C++ allows a whole range of complex underlying storage classes for custom memory management of different parts of a project.]

Arrays are not first class objects?!
Well, this is true, sort of. But you can choose to use vectors, [or other more efficient representations [such as maps, etc] depending on your data type, and with inlining, they will be as efficient as if they were 'native language syntax' features. You don't even have to use the STL, you can write a custom implementation of dynamicly resizable vectors of your own [with automatic bounds checking and resizing, for example] quite trivially. I did it once, and it took, what, 2 pages of source. That's the power of C++, it's so expressive for implementing custom manipulations of low level data, packaged nicely into classes.
No on stack variables? All data as dynamic references?
Yech. Generally too inefficient. I still suspect that he just dosen't want to tackle the hairness of writing such a complex compiler. Remember, you can use only dynamic memory in C++ easily enough, with garbage collection too.

Overall, I think D is too lenient. I give him an F.

Still, I strongly respect the desire to attempt to implement a novel language. Not that there aren't hundreds out there, but it's a noble effort. Still, publishing without even demo code? Yeesh.

Maybe not... but... (1)

squaretorus (459130) | more than 13 years ago | (#2157835)

I can't help thinking that too many languages spoils the broth. Focus should be on ease and speed of development, error handling, development tools that enable the 'simple' problems to be auto detected as far as possible, that assist in testing loops, that FORCE you to document, and produce readable documentation on the fly. Get all that working WELL and I'll write in bloody VB if I have to.
Fundamentalism is for church or TV shows - lets just all agree to compromise - stick to C++ and develop better TOOLS for C++. Yeah it sucks in areas, yeah we all have things we hate about it - but NO we aren't going to be rid of it any time soon - so lets make life with C++ easier.

Programmers man your stations! (2, Funny)

slasho81 (455509) | more than 13 years ago | (#2157843)

The montly programming language holy war is about to begin!

Interesting idea, but... (1)

Richard Bannister (464181) | more than 13 years ago | (#2157863)

I've read the D spec and I like a lot of it. It certainly would not be difficult for a C programmer to start developing in D as specified.

However, I have to wonder about the string concatenation code. Specifically, I've noticed that it does the same thing as java - namely a + b = c for strings. In Java, this is mindblowingly inefficient - a StringBuffer does the job with far less memory wasteage and so on - BUT, as the + operator is easier to use, it tends to be the chosen solution. I wonder if these string concatenations are efficient...

Here's what D can't do... (1, Redundant)

d3l3t3_m3 (322756) | more than 13 years ago | (#2157894)

from the original text

There is no:
  • C source code compatibility. Extensions to C that maintain source compatiblity have already been done (C++ and ObjectiveC). Further work in this area is hampered by so much legacy code it is unlikely that significant improvements can be made.
  • Link compatibility with C++. The C++ object model is just too complicated - properly supporting it would essentially imply making D a full C++ compiler too.
  • Multiple inheritance. It's a complex feature of dubious value. It's very difficult to implement in an efficient manner, and compilers are prone to many bugs in implementing it.
  • Templates. Templates are a way to implement generic programming. Other ways are using macros, or having a variant data type. Using macros is out. Variants are straightforward, but the loss of type checking is a problem. The difficulties with C++ templates are their complexity, they don't fit well into the syntax of the language, all the various rules for conversions and overloading fitted on top of it, etc. What's needed is a smoother way to integrate them into the language, so they have a much more natural and obvious feel to them. I am searching for this solution.
  • Namespaces. An attempt to deal with the problems resulting from linking together independently developed pieces of code that have conflicting names. The idea of modules is simpler and works much better.
  • Include files. A major cause of slow compiles as each compilation unit must reparse enormous quantities of header files. Include files should be done as importing a symbol table. Creating object instances on the stack. In D, all objects are by reference. This eliminates the need for copy constructors, assignment operators, complex destructor semantics, and interactions with exception handling stack unwinding. Trigraphs and digraphs. Unicode is the modern solution to international character sets. Preprocessor. Modern languages should not be text processing, they should be symbolic processing.
  • Operator overloading. The main applications for operator overloading seem to be implementing a complex floating point type, a string class, and smart pointers. D provides the first two natively, smart pointers are irrelevant in a garbage collected language. When using operator overloading for non-trivial purposes with multiple non-trivial classes, the interaction complexity of the overloading coupled with user-defined conversions, overloading in general, leads the person maintaining the code wondering whether it was all worth it.
  • Object oriented gradualism. Class instances in D are object oriented, the other data types are not.
  • Bit fields of arbitrary size. Bit fields are a complex, inefficient feature rarely used. Support for 16 bit computers. No consideration is given in D for mixed near/far pointers and all the machinations necessary to generate good 16 bit code. The D language design assumes at least a 32 bit flat memory space. D will fit smoothly into 64 bit architectures.
After using C++ how can someone want to use this???

Languages comparison (2, Interesting)

slasho81 (455509) | more than 13 years ago | (#2157980)

D == (C++)++

Because:

you take all the backward compatibility junk out.

but retain the old libs and development model.

D == (Java)--

Because:

Java also removed all the compatibility junk.

Java, like D, also added GC as a major development booster.

Java added advanced programming paradigms, extensive standard API and bytecode, and D didn't.

D == C#

Because:

D is Yet Another C++ Successor.

it was developed by another i-want-a-better-c++ that didn't like Java.

it didn't introduce any innovations over existing languages

Besides, the name "D" is completely unoriginal (just like language concept itself). Dozens of next-worldwide-languages-wannabes had that name.

-Omer

Re:Languages comparison (1)

rossjudson (97786) | more than 13 years ago | (#2138422)

D = Java + structures - (class library+remote code)

Single inheritance (1)

Canyon Rat (103953) | more than 13 years ago | (#2158075)

I'm not interested in a statically bound language without multiple inheritance. Experience shows that it just leads to abortions like MFC. Every language needs either MI like C++ or forwarding like ObjC.

Re:Single inheritance (1)

rossjudson (97786) | more than 13 years ago | (#2139803)

So you feel that design by interface isn't practical? Millions of Java programmers would like to disagree with you. You almost never need MI if you have interfaces.

There's behavioral inheritance and structural inheritance. Structural inheritance just isn't very necessary, and needing it generally indicates that you did something wrong.

This was discussed in my class today. (-1)

Anonymous Coward | more than 13 years ago | (#2158076)

We just went over this in my Advanced Programming class today. The Prof posts his outline on the web [stileproject.com] for us to go over before class. There was some heated debate as t whether you could do cross-link algos or not with any effective speed. We will actually compile something simple within two weeks.

There already is a D language (1, Informative)

Anonymous Coward | more than 13 years ago | (#2158080)

Everyone : When I was doing desktop database programming back in the mid 80's, there was already a language named "D". It was sort of DBase clone that ran on the PC, VAX, UNIX, etc. Hope Mr. Bright doesn't have any copyright problems with his choice of name.

Re:There alreaby is a [CENSORED] language (1)

seizer (16950) | more than 13 years ago | (#2157867)

Boes someboby alreaby have copyright on the letter [CENSORED]? Bamn. Coulb make it bifficult....

;-) use yer brains, matey

Sounds like... (5, Interesting)

dmorin (25609) | more than 13 years ago | (#2158083)

...just a case of a guy who knows what he doesn't like about C/C++, and has the capability to do something about it, doing it. More power to him. Hey, if it generates traditional binary executable code so the end result is independent of the D language, and it really does have the advantages he says, then what does he have to prove to anybody? Create his own little company doing D development, crank out better product faster than anybody else, and take over the world. It could happen. If he's managed to create the language that he would prefer to work in, go for it. His only problem would be getting programmers. But it's not like D would be the first proprietary language out there.

If, on the other hand, all he wants to do is sell compilers, and therefore he needs to convince the rest of the world of the language's benefit, then fooey.

And for the record, damn, I feel old -- I remember trying to make the Zortech compiler work for an old project of mine circa maybe 1989 or so(?) and having problems. I think at one point or another I might have actually gotten email from Walter. Wow, names from the past. In a conference call yesterday I needed to come up with a secure hashing algorithm and I said "ROT13. If we need extra security we can do it twice." and absolutely no one got it.

Anyway, back on topic: No templates? Oooooo, I have a C++ friend who is gonna be pissed....

duane

"In C++, you can look at your friend's privates."

Re:Sounds like... (2)

tb3 (313150) | more than 13 years ago | (#2110825)

I remember trying to make the Zortech compiler work for an old project of mine circa maybe 1989.

Didn't Borland end up buying the Zortech compiler and turning it into Turbo C? There were a lot of C compilers back then.
Which reminds me, back in 1987 I was working with the Computer Innovations CI86 compiler. The documentation was a few hundred pages of photocopies in a 3-ring binder, no tools, just the debugger and linker, but it came with the source. Find a commericial compiler these days that includes the source.

Nothing special... (3, Informative)

frleong (241095) | more than 13 years ago | (#2158095)

  • Dynamic arrays - Some juicy stuff that frees the programmer from using malloc, realloc. Copied from Java or Ada or _________________ ( fill in the blank, strip out unused characters)
  • Fixing some inconsistency issues of C's syntax - some purification to make it prettier - like switch/case accepting strings, using something.size, instead of sizeof(). Nothing by itself is absolutely necessary. Syntactic sugar.
  • Unicode character support - Interesting, but usually people just got used not to embed Unicode strings in the source code. Besides, they simply renamed wchar_t to unicode just to make sure that D supports Unicode.

Great feature, but. . . (2, Insightful)

alnapp (321260) | more than 13 years ago | (#2158102)

I like the fact that you can embedd code in html and still compile it [digitalmars.com]

Apparently this means "The code and the documentation for it can be maintained simultaneously, with no duplication of effort"

Unfortunately until its "the documentation is automatically created and maintened with no effort" it still won't prevent the junk I'm often buried in

I would rather eat my E pills. (1)

GunnarR (161157) | more than 13 years ago | (#2158103)


The E programming language :

http://citeseer.nj.nec.com/richardson89design.ht ml

And another for the Amiga :
http://wouter.fov120.com/e/index.html

Think I'll rather stick to Java as that provides me with a robust framework for creating scalable
server side applications.

Floating Point (1)

Root Down (208740) | more than 13 years ago | (#2158106)

He discusses at length the 80 digit precision of Intel x86 architecture and how he intends to speed this up. Last I checked, the S-Float floating point representation used by most PCs is still only valid (accurate) to the 6th decimal place, and other floating types are not much better, if at all. Perhaps I am confused, and if so, please illuminate.

Re:Floating Point (2, Informative)

AndrewHowe (60826) | more than 13 years ago | (#2110826)

80 bits, not 80 digits. The x87 supports three formats: 32 bits, 64 bits, and 80 bits. All internal processing is done with 80 bits, but it's rounded when it's stored out as a float or double.
Some operations always give an 80 bit result (eg. adds & muls) but some (eg. divides) can be limited by the current precision setting.
floats have 23 bits of mantissa, 7 digits precision.
doubles have 52 bits of mantissa, 15 digits precision.
80 bit "long doubles" have 64 bits of mantissa, 19 digits precision.

No templates? (2, Informative)

Anonymous Coward | more than 13 years ago | (#2158168)

I opened up the link, read as far as the section on "things to leave out", saw "templates", and closed the link. Now, this might seem a bit hasty, but hear me out. Templates are the single greatest feature of C++, and the reason that I like the language at all. Yes, they are complicated to implement, and compilers initially failed on them, but they've gotten a lot better now. Yes, they can be tricky to use, and you can get trapped with them. But for writing libraries, there's just nothing like templates. As a matter of fact, lack of templates is probably the one thing that annoys me most about Java (excessive verbosity being the other). There are people trying to fix this, with Generic Java [bell-labs.com] . (Didn't want to unfairly malign an area of Java that is obviously being worked on.) Anyway, this comment has gotten rather far afield of D, so I'll just say what you all know to be true: there are hundreds of C or C++ like languages out there. Few of them attain widespread use for a simple reason: lack of backing from large entities, be they commercial or open-source supporting (or both!). D will likely be the same.

Interesting ... (1)

benspionage (265723) | more than 13 years ago | (#2158222)

I must admit, the specifications sounded impressive, interestingly the D language uses garbage collection and has exception handling. From the article:

D memory allocation is fully garbage collected. Empirical experience suggests that a lot of the complicated features of C++ are necessary in order to manage memory deallocation. With garbage collection, the language gets much simpler.

and ...

The superior try-catch-finally model is used rather than just try-catch. There's no need to create dummy objects just to have the destructor implement the finally semantics.

No VM though, so languages Java, Smalltalk et al would still have portability advantages I'd imagine.

Re:Interesting ... (-1, Flamebait)

Anonymous Coward | more than 13 years ago | (#2121636)

from the above link

Garbage Collection, Sloppy Programming and Idiots

Interesting that software using garbage collection tends to use more memory than software that doesn't use garbage collection. It seems that the new languages around that use garbage collection as a feature tend to just give idiots a licence to do stupid things and work with concepts they don't understand. A typical Java OO program might contain hundreds of objects all with references to each other. This sort of complex structure might take a few cycles to get deallocated by the garbage collector. Using a similar structure in a language without garbage collection would be well nigh impossable to free, unless you are a damn good programmer. That is, the programmer is forced to deal with the complexity they create. For this reason, most programs without GC don't use such arcane structures, since they don't really make much sense anyway.

These object networks that are used in OO languages are really a bit like the data structures people used before we had proper abstract data types. It's really like going back to the bad old days when a program was a bunch of ifs, gotos and pointers strung together into somthing that sort of worked. I think that by forcing programmers to deal with the complexity of the dynamic memory allocations they're working with, it also forces them to find simple, comprehensible solutions the problems they have to deal with instead of just making a whole lot of objects and pointing them at each other.

To my mind, it seems that garbage collection is like putting a bunch of idiots in a clean room and saying "Okay guys, you can shit all over the floor, and we'll clean it up for you later!". This would be a bad thing to do in real life, and I think it's a pretty poor thing to do in programming too.

Re:Interesting ... (-1, Flamebait)

Anonymous Coward | more than 13 years ago | (#2135562)

Please, GC is a joke, a tool for bad programmers to make sloppy code even sloppier because now they don't even have to try and think clearly.

read http://www.cit.uws.edu.au/~blilburn

The only thing new is the name (4, Insightful)

seldolivaw (179178) | more than 13 years ago | (#2158236)

It's a nice name. I like "D" as a name better than C#. But that's all. From the description of the language, it's just Java without bytecodes -- but with "the option" of bytecodes. The major things it does is throw away legacy C compatibility -- making for faster compilers that are easier to write, but not a whole lot of gain for the programmer. However, maybe it would be good to have C++ updated and throw away unnecessary features, and more structured ways of defining things (like the try-catch-finally structure instead of try-catch, which I like the idea of).

D already exists.. (4, Informative)

gatkinso (15975) | more than 13 years ago | (#2158250)

It is a scripting language for a X Window based RAD tool called Telesys(? - maybe that was the name of the company that made the software).

Re:D already exists.. (1)

Gill Bates (88647) | more than 13 years ago | (#2157898)

I've had the (mis-)fortune of working with 'D' scripts on a project some years ago. The product is (was?) TeleUSE. I don't recall the company name.

What are his motives? (2, Insightful)

deppe (27130) | more than 13 years ago | (#2158252)

Go ahead and flame me, but I really think this is silly.

I think this is the work from someone who has worked so long with C and C++ that he thinks Java is useless, and now he's going about trying to write a language that looks so much like Java that it's just ridiculous.

Plus, Java can be compiled without a VM with GJC.

Besides, it's going to be a really hard time implementing a full suite of standard libraries for this kind of language when the C APIs are available because legacy D code will probably have just the same problems as older C++ code has (i.e. not using the std::string etc.).

But hey, if he can pull it off and it works out then why not. But I can't see large organizations adopting this anytime soon.

Overloading? (1)

luckykaa (134517) | more than 13 years ago | (#2158282)

According to the overview, there are "only three significant uses for operator overloading", and since these are all supported internally, there is no need to support it.

Is this wise? I can think of many uses - Vector arithmetic, area intersections and combinations, list concatenation. All of these can be achieved without operators, but matematical syntax is considerably faster.

Re:Overloading? (2, Informative)

Vic Metcalfe (355) | more than 13 years ago | (#2158043)

Not to mention the whole c++ i/o system with cout and cin, etc.

I couldn't help but chuckle when I saw the example code using printf.

Also I don't think c++ should be put down for lack of a high level string type or safe associative arrays. One needs only look so far as the Standard Template Library for these things.

This seems to almost parallel UNIX/Windows. UNIX consists of lots of little tools, and each does its job well. Users can choose the best tool for the job. Windows includes all-in-one, where every application has every feature the way the developer wanted, and the user doesn't have to worry about knowing how to make the pieces work together. C++ lets the user (of the language) decide which string class to use, and whether or not to include garbage collection. D appears to provide these as decided by the developer (of the language), removing the burden from the user, and aiding in consistancy across different projects.

I'm not saying one way is better than the other, but I like UNIX and c++ myself. Most people like Windows, maybe they'll like D too.

oh Lord, please help (0)

Anonymous Coward | more than 13 years ago | (#2158334)

those compulsively thinking and programming Gurus from themselves and us from their creations.

weirdness (3, Interesting)

seizer (16950) | more than 13 years ago | (#2158370)

I love the way there's a reserved word "imaginary" heh...

He doesn't have any post-code gen optimization? I know you can perform elementary optimization onthe intermediate rep, (such as folding, etc), but he'll really need another phase if he wants to optimize for pipelines, which will vary from architecture to architecture? Tut tut. Maybe it's just an omission on his part.

Forth !!!! (2, Interesting)

chrysalis (50680) | more than 13 years ago | (#2158420)

Why aren't new languages based on Forth ? Forth is very fast, because you can work at very low level with it. Forth applications can be portable, while staying extremely optimized. Forth can be easily extended to fit any sort of application, and you can have the feeling of a very high level language, while keeping the control of things that needs special optimizations.

Re:Forth !!!! (0)

Anonymous Coward | more than 13 years ago | (#2154088)

There has been a FORTH developed that places the code between code /code tags in HTML pages see: coldforth.teegra.net/ The web pages are the source. You code can include nice HTML comments, images etc. The FORTH in question has also done a decent job of implementing local variables so there is no need to do return stack manipulation.

Re:Forth !!!! (2, Interesting)

JanneM (7445) | more than 13 years ago | (#2158100)

Well, I like Forth - I used it for years. It has _many_ good qualities; readability is unfortunately not one of them. You can write readable Forth, but you have to really work at it, and it's still a pain to understand something you wrote months previously. Understanding someone elses code is even worse (especially once people start doing nifty things to the return stack :-P)

/Janne

Re:Forth !!!! (2)

chrysalis (50680) | more than 13 years ago | (#2154104)

C and Perl are often hard to read, too. And OO languages are an horror when you have to walk through dozens of classes to find a function.

practical experience implementing compilers?? (2)

kisrael (134664) | more than 13 years ago | (#2158421)

Born out of practical experience implementing compilers?

Seems to be the wrong way 'round...keep up this thinking and we'll all be coding in assembler language! At this stage, languages are meant to make thing easier for the programmer.

Of course, being a programmer I might be somewhat biased...

ASM ROCKS !!! :) (1)

syntax3rror (514740) | more than 13 years ago | (#2157921)

goddam ! what's your problem with assembler ?
it simply rocks !
Maybe Joe Coder prefers using his good old VB6 but i can do much more than what he does (and pretty fast) using TASM or MASM and a resource editor (to create user interface..)
And it can be PRETTY fast too !!!

Linux asm can be really interesting too !
Regards.

Re:ASM ROCKS !!! :) (1)

IpalindromeI (515070) | more than 13 years ago | (#2154087)

Don't get me wrong, I love coding in assembly too. The control you get is like a powertrip. The problem with assembly, obviously, is that it's architecture specific. While that isn't necessarily a bad thing, it is nice to have the broadest possible user-base, which means cross-platform. That's why everyone's been infected with this Java disease. Of course, if you're not worried about that, more power to ya. I personally think programmers should be required to know some kind of assembly, so they have a concept of what their code actually gets turned into. "Look, this vector search only takes one line of code! That's way faster than trying to use this array that would take at least 5 lines." I'm not exaggerating here.

Re:practical experience implementing compilers?? (2, Interesting)

grey1 (103890) | more than 13 years ago | (#2158132)

He's making a more important point, and it's not the wrong way around - he says the specs for C or C++, for example, are so big that the compilers that implement those specs will contain bugs. And the programmers will have problems writing code that's bug free and uses the best features of the language. If he can find the right set of features to include in "D" then it'll be easier to learn, easier to write code in, and very importantly, easier to produce compilers for.

Re:practical experience implementing compilers?? (1)

AlanStokes (42890) | more than 13 years ago | (#2117218)

he says the specs for C or C++, for example, are so big that the compilers that implement those specs will contain bugs

And he should know - I was unlucky enough to have to use his Zortech C++ compiler, and it was absolutely terrible. Loads of code generation errors, a debugger that couldn't cope with large programs, and generally a royal pain.

Re:practical experience implementing compilers?? (1)

Doctor Memory (6336) | more than 13 years ago | (#2121633)

Maybe we should just go back to BCPL...

Re:practical experience implementing compilers?? (1)

the_ph0x` (170740) | more than 13 years ago | (#2158156)

At this stage, languages are meant to make thing easier for the programmer.

Keep up _this_ thinking and we'll all be de-spaghettifying _your_ code.

Languages are already way too easy and bloated - I think it's time for more hardcore languages to come out. All these /easy/ languages are letting in too many Joe Schmoes, ya know the type. Mr. Hey-I-took-a-class-once comes in and look hes got your job now. I for one am tired of people that just haven't the ability to write or think outside of the box and I'm also tired of floating on a fluffy cloud of tangled pasta code. I want streamlined, fast-as-hell code and people that can write it.

.ph0x

Re:practical experience implementing compilers?? (5, Insightful)

JabberWokky (19442) | more than 13 years ago | (#2158311)

At this stage, languages are meant to make thing easier for the programmer.

He's talking about making the compiler do all the work - for instance, there are no headers, as declarations are lifted from the source. For that matter, modules and libararies and source are treated the same. I think that he *might* be talking about features that would require a new object format, and thus a new linker.

I really don't like his ".html" file idea: code inside a html file is compiled by ignoring everything but tagged bits. The concept is to use html to document and compile the code right in the documentation. Personally, I prefer to generate documentation from the code. A language that implements context sensitive comments that can be compiled into various types of documentation would be, IMHO, a very good thing. As it is, systems like doxygen seem to work okay, but if it were built into the language, you could even dump documentation out of modules on the fly. Nifty in an IDE environment, or makefile driven dev when you want to check that version 2.2 of openfoo() does the same thing that 2.1 openfoo() did.

--
Evan

Re:practical experience implementing compilers?? (2)

Syberghost (10557) | more than 13 years ago | (#2154106)

for instance, there are no headers, as declarations are lifted from the source.

That sounds like a step backwards; declarations were put there on purpose. It helps other people figure out what the code does, including you six months later when you forget.

First Parrot (2, Funny)

HerrGlock (141750) | more than 13 years ago | (#2158422)

Then C#, now "D"?

Could we get languages that actually have some semblance to a name, please?

I must say, though, that D is actually pronouncable instead of "Cee Pound" which sounds like you are putting sand up where the SUN don't shine (errr, maybe that's the reason it's called that?)

Or maybe it's "Look at me I'm language Dee" from Grease...

Okay, coffee time.
DanH

Re:First Parrot (4, Funny)

JoeShmoe (90109) | more than 13 years ago | (#2138581)

From the dictionary:

1. "#", ASCII code 35.

Common names: number sign; pound; pound sign; hash; sharp; crunch; hex; mesh; grid; crosshatch; octothorpe; flash; square; pig-pen; tictactoe; scratchmark; thud; thump; splat.

Personally, I like "C-octothorpe"

- JoeShmoe

Re:First Parrot (0)

Anonymous Coward | more than 13 years ago | (#2110711)

Why not C-splat?

Octothorpe (0, Flamebait)

streetmentioner (28936) | more than 13 years ago | (#2154065)

Apparently it was named octothorpe because it looked like the street pattern of an English village. Can't remember where I read that.

idjit (0)

Anonymous Coward | more than 13 years ago | (#2157864)

it is pronounced 'see-sharp'

Not exactly on topic... (1)

JEmLAC (158505) | more than 13 years ago | (#2157922)

but if you like Foxtrot, take a look at this [ucomics.com]

Salut!

Re:First Parrot (1)

jumpinin (79218) | more than 13 years ago | (#2158281)

How is C# pronounced? As a musician I've always thought it was "See Sharp"

Re:First Parrot (0)

Anonymous Coward | more than 13 years ago | (#2157952)

See sharp. See sharp code. See sharp compile. See sharp run. Oh! Access Violation.

Re:First Parrot (0)

Anonymous Coward | more than 13 years ago | (#2158354)

Don't confuse me now - isn't C# read cee sharp. Not my area, but that's what I thought leastwise...

Mike

Re:First Parrot (0)

Anonymous Coward | more than 13 years ago | (#2158355)

I'm pretty sure its pronounced "C Sharp" not "Cee Pound"

Re:First Parrot [OT] (1)

seizer (16950) | more than 13 years ago | (#2158356)

In the UK, we call # "hash".

And bizarrely, the phone company (BT) calls it "square"

Sea Square or Sea Hash. The UK's gonna LOVE MS.

Re:First Parrot [OT] (2, Funny)

andrewscraig (319163) | more than 13 years ago | (#2158153)

and given that hash is another name for cannabis - it can be interpreted as C on drugs :-)

Re:First Parrot (1)

doob (103898) | more than 13 years ago | (#2158369)

Actually, I think you'll find it's "Cee sharp" (as in opposite of flat)

Re:First Parrot (2, Funny)

Dashslot (23909) | more than 13 years ago | (#2158353)

You're both wrong. Cee Hash, pronounced Cash.

Re:First Parrot (1)

doob (103898) | more than 13 years ago | (#2158226)

ahem... here [microsoft.com] , here [oreilly.com] , and here [hitmill.com] say different.
Or just look here [google.com] .

Re:First Parrot (1)

IpalindromeI (515070) | more than 13 years ago | (#2157866)

I think you missed the subtley that your parent post was going for. Try reading it again, keeping in mind who produced it.

Re:First Parrot (-1, Offtopic)

Anonymous Coward | more than 13 years ago | (#2157948)

It all sounds like "Cash" to me.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>