> [...] D did only a little better.
>
> I call them "cargo-cult languages". Their designers
> copied features from other fashionable languages, but
> without understanding. They are the language equivalent of
> those shareware CDs that used to be described as
> shovelware. They are full of features, tossed into a bag
> with little thought given to how the features will
> interact.

I'd be interested if you'd like to present a more concrete critique of D. There's not much I can respond to here.

> A true successor to C++ is dearly needed. We need a
> language that leaves behind C's promiscuous conversions,
> its chaotic declaration syntax, its gratuitous undefined
> behaviors, its ill-thought-out library. We need a
> language that leaves behind C++'s name-lookup complexity,
> its awkward compile-time pattern-matching and expression
> syntax, its unfortunate library history. These other
> languages are only distractions.

Would your language look like C++, or be something completely different?

I really appreciate this article and look forward to reading the sequels.

I never paid much attention to B or BCPL because I assumed they were just variants of C, so I was unaware that their typing system was so different.

However, you introduce the term "typeless" without defining the term. I've learned through long study that a language that allows you to give function arguments without specifying the type can have very different meanings and behaviors. I can only guess that since this is a C-like language, everything is determined at compile time, like C++ templates. But does "typeless" mean that all variables are of a single unified type, or does some kind of type inference take place to figure out if something is an int, long, float, double, etc.? Or is it something else? I'd really like a more specific definition of "typeless."

By "typeless" I just meant the ability to code without explicitly declaring types. I B this was possible because there was really one underlying type, the machine word. In C++ this might be possible by reusing the type inference machinery.

> By "typeless" I just meant the ability to code without
> explicitly declaring types. I B this was possible because
> there was really one underlying type, the machine word.
> In C++ this might be possible by reusing the type
> e inference machinery.

In most cases it is a decision of when the language will bind the value to a type. I designed a language in the early 1990s that used the value of the expression to assign type. The type was then carried with the value and used in future expressions to manage the semantics of its use.

So you might write:

integer i = 3;

and that would allow i to only reference integer valued values, and the value 3 would be assigned to it. But, you could also just write

i = 3;

if you didn't need to type restrict i. At runtime, all the type checking made sure that the correct thing was done. This complicates the runtime environment from the perspecive that it has more overhead for expression evaluation. But, it frees the programmer and the code to be more expressive. Thus, a functional expression engine might have methods such as the following.

func add(a,b) 
   return a + b;
end;
 
func mult(a,b)
   return a * b;
end;

As expressions are recognized and need to be evaluated, I don't have to have an add(integer a, integer b) and other such type specific versions. I just need the one version. The type checking is still done, its just that the types are not bound until entry to the method and thus the type check is not performed until the '+' is evaluated.

This is placing a lot of trust in the programmer. What happens with this type of programming over a long time, is that inadequate test cases can cause changes that break the application to not be found at first. Then, someone else introduces the execution path that demonstrates the bug, but is sure they did not change anything related.

So, a lot more runtime testing has to be in place. Coverage analysis was an integral part of my language so that we could see what code had and had not been executed after our lab/test sessions.

>
> I'd be interested if you'd like to present a more concrete
> critique of D. There's not much I can respond to here.

I looked into D at one point, after reading about it in Dr. Dobbs Journal. While reading the newsgroup about it, I got the impression that the designer just wanted a native code version of Java. He had included templates only because there was imense popular support for them, and would not budge on his refusal to provide scope bound objects. He claimed to like using 'finally' clauses instead of destructors, and he felt that only memory management and thread syncronization were important enough resources to justify language level support for managing. That convinced me that I didn't want anything to do with the language.

> I looked into D at one point, after reading about it in
> Dr. Dobbs Journal. While reading the newsgroup about it,
> I got the impression that the designer just wanted a
> native code version of Java. He had included templates
> only because there was imense popular support for them,
> and would not budge on his refusal to provide scope bound
> objects. He claimed to like using 'finally' clauses
> instead of destructors, and he felt that only memory
> management and thread syncronization were important enough
> resources to justify language level support for managing.
> That convinced me that I didn't want anything to do with
> h the language.

Since D has long had templates in many ways more powerful than C++, and has scoped destruction of variables (the 'auto' storage class), the issues you raised are history. (D has very little in common with Java beyond a shared heritage of C++.)

>
> Since D has long had templates in many ways more powerful
> than C++, and has scoped destruction of variables (the
> 'auto' storage class), the issues you raised are history.
> (D has very little in common with Java beyond a shared
> heritage of C++.)

I'll have to look into it again. When I was reading the news groups, I was hearing "never" for the auto storage class. I wonder if Nathan Myers was reacting to an old version too.

Nathan Holt

D is a young language, and is rapidly evolving much like C++ did in its early days. It moves in the direction that the D community wants it to go. There isn't any holy writ that comes with it <g>.