The D Programming Language

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."

Re:Floating Point

[AndrewHowe]

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.

Re:Convince me

[32855136]

I'd be interested to see a *true* benchmark

I've done that - kinda. Wrote several mickey-mouse comparisons (moving memory, calculating pi, etc), in C, C-machine-translated-to-Java and in regular Java.

The biggest problem was that, for the tasks we were interested in (memory-management, for example) C and Java do it so differently there is no easy way to compare. (Java's habit of creating multiple references to single objects instead of multiple copies of the same object really helps it here).

In general, Java was 3-4 times slower than C on string manipulation with built-in classes/library functions, but was damn-near identical on heavy maths (Java dropped ~1 second for every 30 secs of calculations.)

(Visual C++ 6 compiler against Sun's latest JRE for Windows NT. These timings were only ever meant to be rule-of-thumb.)

Re:After C comes P!

[RevAaron]

Actually, there was a successor to Forth called Fifth. Forth with OO extensions, IIRC. I've not been able to find a reference on the web, but I played around with it in the early nineties, when I was downloading every language I could find off of local BBSes.

And calling it Fifth fits more so than Further- Forth comes from the word "Fourth," as in the cardinal number. The mythology goes, the filesystem where Forth was first implemented couldn't handle a filename as long as Fourth. ;) Hence, forth.

Re:Maybe?

[MagikSlinger]

While I think you have some valid points, you are far too eager to suckle at Microsoft's teat and call the watered down skim soya milk it gives 10% m.f. homogenized.

I too like VB (quit staring at me like that!), and I agree with you that poor programmers give VB a bad man, but I big to differ on the idea that VB somehow protected you from Microsoft's shifting API's. You've read the reviews for VB.Net? Everyone VB programmer out there is screaming blue murder because the object model in VB has so radically changed that it requires re-learning VB. Yes, I said re-learning VB. MFC has changed their official "ways to do things" with each major release that it's necessary to re-learn MFC every major release. Sure, MS can provide some insulation from their API's, but even their insulation can't protect you from the pointy spikes that poke through everytime MS changes its architecture.

One other thing:

An entirely new programming paradigm where everything you ever wanted to do is neatly arranged within the various Class libraries. I know that in and of itself isn't new, but having that kind of support on the OS level IS new.

As an embittered and disgruntled fan of NextStep, I vehemently disagree with your opinion. :-) You want a seriously kick-ass distributed networking object-based API? Try NextStep's Distributed Objects. Can you say, "Sweeeeeeet!"

Other than that, I think you made some good points for people to think about.

D versus C#

[Zeinfeld]

It would be interesting to know if the guy has contacted Microsoft. Many of the features of D are in C# and vice versa. It would be a good thing if the future of programming languages was not considered the domain of Microsoft alone (bad) or Suns lawyers alone (worse).

Many of the features look pretty sensisble. There is now pretty unanimous support for dropping Multiple inheritance. The problem with multiple inheritance being that it leads to programs only the original authors understand.

It is disapointing that the syntax was not changed more radically. I for one am pretty bored with typing semicolons at the end of lines. Using braces for block structure is equally tedious.

The garbage collector is of the 'stop everything and collect' type, this is not a good scheme as anyone who has seen a PET running Microsoft Basic GC will agree. The incremental GC in .NET is a better scheme, even if it is slower overall. But that is an implementation detail.

It would be good if people would start to look at adding support for parallel program execution. The threads programming model is very clunky and hard to use, in part because there is no means for the program to perform checks on access conflicts.

Also a persistence model should be part of any new language. The current division between programming language and database is a lot of wasted overhead.

Re:The only thing new is the name

[Eric Giguere]

The Java try-catch-finally construct is not the same as nesting a try-catch within another try-catch because the finally block is always executed. In your scenario the finally is only executed if an exception is thrown. Adding a throw at the end of the inner try will make it behave like try-catch-finally, but then you have to have code in the outer catch to distinguish between the various cases. try-catch-finally is a simpler way to do it.

D's floating-point model is dangerous

[fullcity]

D's philosophy about floating-point arithmetic is dangerous:

On many computers, greater precision operations do not take any longer than lesser precision operations, so it makes numerical sense to use the greatest precision available for internal temporaries. The philosophy is not to dumb down the language to the lowest common hardware denominator, but to enable the exploitation of the best capabilities of target hardware.

For floating point operations and expression intermediate values, a greater precision can be used than the type of the expression. Only the minimum precision is set by the types of the operands, not the maximum.

This reflects a terrible misunderstanding of floating-point arithmetic. Decades ago, scientific programmers realized that getting a computer to "just give me the best FP answer you can come up with, I'm sure it's good enough" caused headaches. That's why we have IEEE FP standards that define EXACTLY what the results should be, to the bit.

If you get different answers on different computers due to different roundoff errors, your software becomes unreliable. It's true!

People get confused by Intel's 80-bit FP arithmetic. Yes, the FPU expends some effort in rounding the 80-bit result back to 64 bits, but the result is not more accurate than a 64-bit FPU. In fact the answers will be exactly the same--this is mandated by the standard.

Anyone using floating-point arithmetic for anything serious needs to know exactly what the arithmetic model is. If Walter pursues this philosophy with his new language, he will make it unusable for numerical applications.

Walter needs to read:

David Goldberg, "What Every Computer Scientist Needs To Know About Floating Point Arithmetic," ACM Computing Surveys, vol. 23, pp. 5-48, 1991.

I could not find a copy online, but here is an interview with William Kahan [berkeley.edu], the Turing award winner who co-developed the IEEE 754 floating-point standard. Language designers should notice that Kahan implicates of Java and Fortran at the end of the article.

After C comes P!

[vu13]

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

Re:Convince me

[Anonymous Coward]

ahem.. yes, java can be faster doing an fft. http://www.aceshardware.com/Spades/read.php?articl e_id=153 also another article comparing speeds: http://www.javaworld.com/javaworld/jw-02-1998/jw-0 2-jperf.html too many people have preconceptions back from the days when the only runtime was a byte code interpretor. Try the latest JIT and you may be surprised..

Re:The only thing new is the name

[mooneyguy]

Anyone who really knows the origins of the language "C" knows that its successor should be called "P" and not "D".

Re:Forth !!!!

[steveha]

You could extend FORTH easily to do what you describe. FORTH is very extensible. Here is FORTH code to make the first line work:

: Variable ; IMMEDIATE
: to SWAP ;
: be ; IMMEDIATE
: setting ! ;

"Variable" and "be" do nothing and compile to nothing; they are just syntactic sugar. "to" does a SWAP so you can say "x to 10 !" rather than "10 x !". "setting" just does a ! (store) operation.

Actually, you could make "to" and "setting" IMMEDIATE words; you would just need to make them compile in the words they implement. I'm very rusty on my FORTH, but I think you can do it this way:

: to COMPILE SWAP ; IMMEDIATE

Then "to" compiles a reference to SWAP, instead of creating a subroutine that calls SWAP and then returns. The IMMEDIATE version saves one subroutine call and one return.

This would make a nice short article to publish in Dr. Dobb's or some similar magazine, right around April Fool's Day.

I have fond memories of an April-Fools article on FORTH, describing how to add GOSUB to FORTH. He went through several versions, before finally arriving at this very efficient solution:

: GOSUB ; IMMEDIATE

In other words, GOSUB does nothing and compiles to nothing. FORTH is all subroutine calls anyway; it never really needed GOSUB in the first place.

steveha

Re:Overloading?

[Vic Metcalfe]

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.

Re:Convince me

[JanneM]

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

There already is a D language

[Anonymous Coward]

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:Garbage Collection vs. Virtual Memory

[rossjudson]

Nope. Modern garbage collectors certainly don't walk around memory collecting things (and neither do modern heap allocators). All the tabular stuff that indexes memory and structures is usually contained in a small set of pages. Those refer to blocks elsewhere. No page swapping is required.

Java's class packaging is considerably more than a small step in the right direction. It supports a universal naming convention, based on the internet's naming systems, that can underlie local and remote code. D's modules are a primitive mechanism at best, similar to Delphi's. They're OK for a single organization, but problematic for integrating code on a wider basis.

Nothing special...

[frleong]

• 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.

No templates?

[Anonymous Coward]

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.

Re:Convince me

[JohnA]

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

D already exists..

[gatkinso]

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:Convince me

[horse]

Java GUI apps _are_ slower, because Swing is basically all written in Java and it can't really take advantage of platform-specific tricks to run faster. The trade-off here is that Swing is very, very portable. For many applications this is a good trade-off, but it's not a 100% solution. I don't think Quake is going to be written in Java real soon. On a 800 mHz machine, you will seldom notice the Swing slowdown in Windows. On Linux it's a little more noticeable. The next JDK has some performance enhancements for running on X, I think.