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

Comments

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, 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: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: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).