[Warning: very lengthy post follows. Apologies in advance - it's a
complex topic]

Has anyone ever wondered just what language X would be like, if such a
headline were to make the news?

There have been many languages that have tried to become that language
X, but very few of them seem to have had modest success in taking over
C/C++'s turf (Note: I use the term "C/C++" to refer to C and C++ as
whole, due to their symbiotic relationship and their combined
wide-spread dominance):

*Eiffel

Its been around for about 18 or so years, undoubtedly serves its niche
well, and seems strongly driven by its adherents' claims of
superiority over C++ (Joyner's C++ critique is often cited by Eiffel
advocates).

*Ada and Wirth's languages

Ada and Wirth's languages (Modula, Oberon, Pascal etc) have also been
around ages and have that systems-programming feel to them. Ada still
tickles the DoD's fancy and probably powers that subway train you take
to work everyday. Pascal lives on as Delphi and competes with VB in
the jolly world of RAD and software components.

*Java

Aaah, all the hype and the buzz as Sun dug deep into its pockets and
unleashed some serious marketing dollars. The promise of WORA, the
applets, the removal of "confusing" C/C++ features and the joyful
100+MB memory consumption in any non-trivial desktop apps - Java sure
did make a noise. It made some improvements to C/C++ (e.g automatic
memory management) and runs on the server-side of many enterprises,
but probably went too far and is now being dragged back to some C/C++
roots (e.g enums and generics).

*C#

Like Java, this one came with all the muscle of Microsoft's marketting
machine. Promising to bring the power of C/C++ and the simplicity/RAD
of VB, C# keeps much of its C/C++ heritage (e.g pointers in "unsafe"
code, structs, enums) while learning from some of Java's shortcomings
(e.g by adding autoboxing and eventually generics).


I don't know of other languages that try to go head-to-head against
C/C++, but if I had to pick a langauge from the above that could even
remotely push C/C++ into decline it would have to be C# on Windows and
C# + Java if we consider Windows and other platforms (e.g. Linux)
together. (Note: that's just my take on the issue, I don't want to
start a holy war. Further, I've chosen C#/Java due to their closeness
to C/C++ and, more importantly, the very deep pockets of the companies
that can keep supporting them).

I say "even remotely push C/C++ into decline" because I personally
think, for both political and technical reasons, it will take more
than what the above languages offer or have offered, to supplant
C/C++. The battle to take over C/C++ seems to have been going on for
ages (time estimates are: ~17yrs for Eiffel, ~20yrs for Ada, ~17yrs
for Modula, ~9yrs for Delphi, ~9yrs for Java, and ~4yrs for C#) but
somehow they just wont be taken over -- surely there must be good
(technical) reasons for this. Read on!

In trying to do better than C/C++, it seems many languages
forget/ignore/timidly avoid the very things that make C/C++ so
formidable. So if the subject of this post was to make the news, what
would language X be like? What does its designer need to know? Here is
my take and I would be interested in seeing what others can add to
this list. May I state that, among the language mentioned above, I am
more familiar with C# and Java, so this list is essentially what a
successor of C#/Java will need to look and feel like, in order to
attrach the hard-core C/C++ advocate. (Note: these are things that *I*
think a language will need to supplant C/C++. They are not necessarily
"better" or "X" where "X" is an adjective that would make you take out
your holy war combat gear and defend whatever it is you currently
use). Without further ado:

**Drop the Virtual Machine thing

Given the limitations of VM technology today, VMs carry a negative
image: increased start-up times, appalling memory consumption, and the
impression of being bloated amongst other things. Yes we can throw
more hardware it, pre-compile this and do that, but for how long? The
technology is what, 30 years old? You can quote all the benchmarks you
like but it seems VMs will not get a second chance to make a proper
first impression. Perhaps it's time to admit that the concept can only
go so far, and start pouring all those dollars into other language
research areas.

**Type independent memory semantics

This is all about putting the programmer in control - let them choose
whether they want value semantics or reference semantics independently
of the type. Defaults may be provided for convenience (e.g primitives
and structs work by value, while objects work by reference). C/C++ do
this via the pointer syntax, but a higher-level syntax can be provided
to indicate the desired semantics.

**Comprehensive (compound) types

To be truly general-purpose and give programmers great flexibility in
defining powerful and compact data structures, support for structures,
unions, enumerations, bit-fields and classes is essential. Throw in
the ability to define these recursively (where applicable) and allow
their memory semantics to be chosen indepedently, you end up with some
stunning power. And please do more than just blindly copy from C/C++,
there is so much more that can be done to make these types even more
useful (and no - simply removing them from the language wont cut it).

**Everything is *not* an object

This one speaks for itself. Trying to write software with this overly
narrow view is like trying to operate on a patient saying "what's the
problem? the human body is just a bunch of atoms". There is no one
paradigm to rule them all and in the darkness, (neither statically nor
dynamically) bind them. C++ supports more than one paradigm and avoids
forcing the developer into one style - learn from that (the
requirement for such nicieties as static/shared/class members in some
"pure" OO languages should tell you something). Oh and there's quite a
range to choose from when you make language X: functional, logical,
procedural, OO, declarative, relational, ... , My take? OO and
procedural, with some good bits thrown in from the functional,
declarative and relational paradigms.

**Purity, mathematics and obscurity

In relation to the previous point, don't get carried away in a quest
for purity whether it be in paradigms, rules of control-flow, language
constructs or whatever. Those who strive for purity seem to also have
a strong mathematical background, but while purity is more easily
achievable in mathematics, the same can't be said for something as
arcanely complex as language design. The human mind is naturally
capable of handling things that are not reduced to their most basic
form. To force it to work at that level is like making someone read a
book *letter by letter* - it obscures the book's content and causes
much aggravation.

**Run-time efficiency *is* important

This is just a natural part of the C/C++ spirit. Moore's law is not an
excuse for casual sloppyness and this argument to "throw more CPU
power at it" is getting really old really fast. More CPU power should
mean that render farms for animations like "Monsters Inc" operate in
hours instead of days, not that some bloated application is now
capable of being barely usable. If premature optimisation is the root
of all evil then not doing any optimisation must be the root of all
arrogance. Why arrogance? because not only does one *charge* the
end-user for the software, they also expect them to go out and buy
better hardware to support it!!

**Deterministic automatic memory management

Many non-trivial or even useful applications will always access
resources (e.g file, socket, database and graphics handles). To claim
that the language provides automatic memory management, while
requiring/recommeding that one manually use the dispose/release
pattern to free resources, is a blatant lie. Designing an automatic,
deterministic, non-leaking and efficient memory model is still, AFAIK,
an open problem - if you crack it, you should win the Nobel prize and
free money to pay your local psychiatrist, who's business you'll have
made most profitable.

**Pointers and the clinically insane

Aaah pointers, pointers, pointers - you either love 'em or you don't.
If you are one of the lucky people who can code and work from home,
whenever the kids keep asking what you are doing, just give them a
glimpse of something like this:

char **foo(char (*)(int), int *(*(*(*b)())[10])());

Its guaranteed to scar them for life (terms and conditions apply.
Offer subject to status and availability <g>). If you spare the
pointer, you'll spoil the child and to supplant C/C++ you just can't
get rid of the pointer - you have to abstract it. Provide good array
support, by-reference argument passing, a notation for choosing
between stack/heap allocation, a cleaner notation for defining
function pointers and finally, a notation to define recursive data
types (pointers do *tons* of things!). Those are the simpler issues,
the harder one is efficiently abstracting the memory mapping idiom
used to facilitate access to things like I/O ports (this is crucial
for things like writing device drivers). "So", I hear you ask, "what
was the 'clinically insane' bit of the subheading referring to?". Oh,
that? That was for those who would also go far enough and look into
things like const-correctness, ways to prevent the dreaded
NullPointerException and the possibility of language support for
implementing the Null Object pattern - amongst other things.

**Syntax is a religion and BNF is its Bible

The world of programming seems to be currently divided into two camps:
those who like case-sensitivity, curly braces and the semicolon, and
those who don't. The biggest noise from one camp screams "brevity"
while the biggest noise from the other camp screams "readability". So
the challenge is coming up with a syntax that is both brief and
readable. At the lexical level, this can be done by abbreviations that
are easy to expand unambiguously (e.g "enum" and "struct"), while at
the syntax level this can be done by providing more expressive
constructs (e.g a "for each" loop on collections). Its hard to satisfy
both worlds but at the very least, you must drop the
backward-compatability argument for a second, and clean out *all* the
known syntax pitfalls. They'll probably kick, scream and spit if you
do it, but if you don't they'll do it eventually anyway, because
sooner or later the breaking point will be reached.

**Repent heathen, and thine seg faults shalt be forgiven!

After creating X, you'll need to promote it to the masses. Your
toughest and most skeptical audience will probably be in the C/C++
camp (afterall its their language you want to supplant), so the *last*
thing you need to do is speak to them in a tone similar to the one in
this paragraph's sub-heading. You must realise that if they are smart
enough to implement the OS your language will support, the compilers
for the intermediate language you use <cough>, the native APIs your
libraries need, and the webservers, browsers and internet protocol
stacks that allow you to see this post, then they must be smart enough
to know that C/C++ is imperfect. Talking down to them will only make
them defensive. Focus on why your language is a solution - not on why
their's is the problem. This way, even if you fail to convince them,
you'll atleast get them to listen.

**Politics and the Ministry of Marketting

Language adoption is driven more by politics than by technicalities.
If after the 3 or 4 years of your research (and if you think you can
do it in less time, well...remember the psychiatrist I mentioned
earlier? Yeah, book an appointment for tomorrow) you manage to come up
with something, you'll need to hook up with big companies with lots of
cash and convince them to market your solution - don't worry, I am
told this final process is the simplest in the journey <g>.


If you have read this far(!), then thanks for taking the time to do
so! I would send you a beer but since there's no MIME type for
encoding beverages, here is a <virtual handshake> over NTTP.

#include "standard_mob_evasion_techniques.h"

void main()
{
if(above_post == lengthy_but_interesting){

assert(post_author == eric_mutta);

} else {

assert(lynching_evasion_system_active == true);

Weapon *shield = GetShield(BIG_ONE__THIS_COULD_GET_UGLY);

Telephone.Call.Tell.Mum("I wont be home for X-Mas.");

Defence.System.Brace.For.Action(shield);

}
}


Cheers,
Eric Mutta :-)

ericmuttta@email.com (Eric) wrote in message news:<ca5584cb.0407200224.5a463e9@posting.google.c om>...
That's ok, my answer will be short and superficial!

Pascal won 'popularity' in university's and in Borland compilers,
since then it's settled into a steady but smaller niche, even living
on through such things as freepascal. I quite like Pascal with OOP
added in, as in Delphi. I find it easier to read than c-syntax.
Maybe 'X' looks a little like Pascal to me!

as C# is like a Delphi bred with java language i'll stick it in there.
I quite like java, but not the requirement for a JVM (even though
that let's java be used on exotic platforms)

C and C++ built up huge legacy code throughout the 80's an 90's and
like COBOL, it ain't going away!

[]

Or allow native compilation on select platforms. quite a set of
things to maintain though, perhaps align it with gcc's portable
compiler. oops! i said the c word!

[the others read pretty well)

an object is an object, but a thing that isn't isnt!

e.g. a string is an object and array of char is not. Support both.

indeed, but that's nuts anyway!

hmmm....pascal!

Ok... it's really down to preference and 'what you already know'

At the lexical level, this can be done by abbreviations that
i like for ..... each very much, it makes sense when reading it.
[]

....and more by simple inertia (legacy) and tool availability than
marketing.

It was an interesting read and thanks for posting it!

However...
Ada give a whole new meaning to typing!

gswork@mailcity.com (gswork) wrote in message news:<81f33a98.0407200812.314228eb@posting.google. com>...
:-)

<snip>

Great :-). From the little I know about Delphi, if I was to nominate a
non-C-family language that C/C++ folks may tolerate, Object Pascal as
it is in Delphi, seems a good bet and carries a similar spirit
(multi-paradigm, pointers, etc).

I see what you mean. I've been trying to review just how useful Java's
battle cry (WORA - Write Once, Run Anywhere) is. I understand that
*portability* is a Good Thing (tm) and I would want some degree of it
in a language, but its the *binary portability* of WORA that I'm
getting at. What do others feel about WORA in comparison to WOCA
(Write Once, Compile Anywhere)? i.e about binary portability vs.
source portability?

That's probably be the biggest single reason why C/C++ will be with us
forever and ever, Amen. What if languages could be charged for
monopolistic practices eh? <g>

Indeed. I believe there are native compilers even for Java, although
one rarely hears of their use - probably because the whole idea isn't
part of Java's "spirit" (Ohhmmmm...Jaaaaay - Veeeee -
Eeeemmmm...Ohhmmmm).

Yes, I imagine it would be quite a task to get vendors to commit to
the extra worked needed to support both compilation models.

It has become inevitible nowadays :-)

Wheeeew! <Loosens grip on defense shield>.

Indeed, oh Zen-inspired one :-)

Yes, allowing the user to choose the paradigm they want is a sign of a
respectful language designer - it shows they acknowledge that the user
is in the best position to decide what's best for the problem at hand
(regardless of whether that choice is "right" or not).

Insanity, my friend, is still a form of sanity :-D

<snip introductory section on syntax>

And even when writing it too! The "for..each" loop construct seems to
be the best example of simultaneous brevity and clarity.

I've been experimenting with, shall I say, "syntax design" and found
that a simple way to achieve clarity with brevity, is to use the
sentence you'd put in a tutorial, when devising the syntax for a
particular concept. E.g for variable declarations, the process goes
similar to:

*Step 1: write the description for the concept, as it would appear in
a tutorial.

A variable declaration tells the compiler to allocate
some storage for use in storing values of a particular
type, and allows us to refer to that storage location
using a particular name.

*Step 2: list out the keywords of the description in the order they
appear.

Tell, Allocate, Storage, Value, Type, Name

*Step 3: cross out any keywords you can, without reducing the clarity.

Allocate, Storage, Type, Name

*Step 4: abbreviate any keywords where you can do this without
ambiguity.

Alloc, Store, Type, Name

*Step 5: use the remaining keywords in (general) order of appearance
to form the syntax.

Alloc <TypeName> Store <VariableName>

The above syntax then allows brief but clear declarations such as:

Alloc Integer Store MyNumber

The syntax now maps back very closely to its explanation in step 1.

Indeed.

No worries gs, thanks!

Cheers,
Eric Mutta :-)

"Eric" <ericmuttta@email.com> wrote in message
news:ca5584cb.0407202041.4bbc31e4@posting.google.c om...
Well I have to admit I'm sick of trying to find a portable GUI
regardless of language.

"Eric" <ericmuttta@email.com> wrote in message
news:ca5584cb.0407200224.5a463e9@posting.google.co m...
Well, this will not happen for at least the next decade or two, but we can
still have our dreams!!!

Seriously, though, it is really tough to answer you question. I believe this
is because any feature in C/C++ that is good is readily misused and abused.
Take for instance pointers. Any serious C/C++ programmer will rather give
away their left (or right) arm than have to do without pointers. However, at
the same time, pointers are very evil. They cause nasty bugs, frighten away
all beginners, and generally create a maintenance nightmare. It's like
"can't live with 'em, can't live without 'em."

I believe any modern language must deal with the issues of pointers.
Specifically, the language should provide some of the benefits of pointers,
while at the same time avoding most of the pitfalls.

C++ has gone a step in that direction by introducing references. They behave
like pointers, but have certain restrictions builtin to the language. Modern
compilers are able to detect most situations where one is returning a
reference to a local variable. Still, this should simply be an error, not a
warning.

Now we still need a good deterministic garbage collection (as you mention
yourself). Perhaps if we could maintain pointers but restrict some of the
more esoteric features, particularly pointer arithmetic, it would we
possible to put an end to all memory leaks. Perhaps disallowing C-style
pointer casts is enough.

So your language X will look very much like C++, with a few arcane
C-features taken out and a few new features added in. In summary, C++ has
made som good compromises by enhancing the C-language, while at the same
time maintaining (almost) backwards compatibility.

Any new language should have the option of retaining backwards compatibility
with C. Fancy a compiler having options like "-allow-pointer-arithmetic" and
"-allow-c-style-casts". If we remove the backwards compatibility we could
really make a great language, but all the legacy code won't go away
over-night....

-Michael.

"JustSomeGuy" <nope@nottelling.com> wrote in news:zvlLc.75029$ek5.29985
@pd7tw2no:

Yea. Isn't it lovely?

Jim Rogers

"JustSomeGuy" <nope@nottelling.com> wrote in message news:<zvlLc.75029$ek5.29985@pd7tw2no>...
Interesting. I've only had an occassional glance at Ada. How does it
fare for systems programming? Specifically, what is its memory model
like?

LOL, is that typing as in type system or typing as in keystrokes?

Cheers,
Eric Mutta :-)

Jim Rogers <jimmaureenrogers@att.net> wrote in message news:<Xns952D3E2BEE788jimmaureenrogers@127.0.0.1>. ..
:-). I think a trend we will see with future languages is more
sophisticated type systems, but we'll have to work on the complexity
of their definition. I am looking forward to safer and quieter type
systems. Safe means they are defined to prevent operations that are
statically provable to be dubious, while warning about operations that
may fail at run-time. The "quieter" aspect is the most challenging and
refers to making the type system useful without it appearing
pedantic....(oh and please people, lets not have that static vs
dynamic typing debate in this thread).

Some areas that could use work on better type safety:

*enum types

*union types

*aliased types (i.e those created via "typedef")

Any other nominees?

Cheers,
Eric Mutta :-)

anon21h@yahoo.co.uk (Eric) wrote in
news:5ed9ec27.0407211425.69a84da@posting.google.co m:

Ada was developed for use in hard real time embedded systems.
Although Ada is a high level language, it still provides access to
low level features such as the ability to embed assembler routines
in Ada routines, and the ability to specify addresses for variables
and/or constants. Ada also provides extremely precise syntax for
specification of data layouts down to the bit level.

Ada syntax comes from the Algol line, just as the Wirth languages.
One of the reasons many people apparently dislike Ada is that it does
not closely resemble C syntax. For instance, the following example
of Ada record layout control is taken from the Ada Reference Manual:

Example of specifying the layout of a record type:

Word : constant := 4; -- storage element is byte, 4 bytes per word

type State is (A,M,W,P);
type Mode is (Fix, Dec, Exp, Signif);

type Byte_Mask is array (0..7) of Boolean;
type State_Mask is array (State) of Boolean;
type Mode_Mask is array (Mode) of Boolean;

type Program_Status_Word is
record
System_Mask : Byte_Mask;
Protection_Key : Integer range 0 .. 3;
Machine_State : State_Mask;
Interrupt_Cause : Interruption_Code;
Ilc : Integer range 0 .. 3;
Cc : Integer range 0 .. 3;
Program_Mask : Mode_Mask;
Inst_Address : Address;
end record;

for Program_Status_Word use
record
System_Mask at 0*Word range 0 .. 7;
Protection_Key at 0*Word range 10 .. 11; -- bits 8,9 unused
Machine_State at 0*Word range 12 .. 15;
Interrupt_Cause at 0*Word range 16 .. 31;
Ilc at 1*Word range 0 .. 1; -- second word
Cc at 1*Word range 2 .. 3;
Program_Mask at 1*Word range 4 .. 7;
Inst_Address at 1*Word range 8 .. 31;
end record;

for Program_Status_Word'Size use 8*System.Storage_Unit;
for Program_Status_Word'Alignment use 8;

---------------

There appears to be two definitions of the compound type
Program_Status_Word. In fact, there is actually are record definition
followed by a record representation.

The record representation specifies that the field State_Mask starts
at word 0 and occupies bits 0 through 7. Protection_Key occupies bits
10 through 11 of word 0. Machine_State occupies bits 12 through 15 of
word 0. Interrupt_Clause occupies bits 16 through 31 of word 0. The
remaining fields occupy word 1.

The example shows that bits 8 and 9 of word 0 are unused. Notice that
no "filler" field needs to be identified for those unused bits. The
representation clause clearly identifies which bits are used. Anything
left over is clearly not used.

Finally, the size of the type Program_Status_Word is specified,
preventing any unexpected padding by the compiler, and then the
alignment is specified as being on an 8 bit boundary.

The fields System_Mask, Machine_State, and Program_Mask are all
defined as being objects of different Boolean arrays. Ada allows
Boolean arrays to be mapped directly to bits.

The types States and Modes are enumerated types. Ada enumerated types
are not numeric and cannot be used as numeric types. Nonetheless, they
are discrete types, and any discrete type can be used as the index
for an array type.

Thus, the index values for Machine_State are A, M, W, and P, while the
index values for Program_Mask are Fix, Dec, Exp, Signif.

IMHO, these features look pretty good for systems programming.

Jim Rogers

"Eric" <ericmuttta@email.com> schreef in bericht
news:ca5584cb.0407200224.5a463e9@posting.google.co m...

Nice article.

Don't forget, X needs operator overloading!

"Michael Jørgensen" <ingen@ukendt.dk> schreef in bericht
news:40fe05b9$0$174$edfadb0f@dread11.news.tele.dk. ..
Perhaps a better idea would be to construct a new language for which a
correct C->X mapping can exist. That way, legacy code can be converted.

Jim Rogers <jimmaureenrogers@att.net> wrote in message news:<Xns952DC33414307jimmaureenrogers@127.0.0.1>. ..

So exactly where/why/how are you doing systems programming on S/360
with Ada? Inquiring minds want to know! ;-)

Besides, the protection key should really be bits 8-11. (Yes, I know
you meant it as an example).

robertwessel2@yahoo.com (Robert Wessel) wrote in
news:bea2590e.0407220419.7ac97ef2@posting.google.c om:

Does this look familiar to you? :-)

I am not doing any systems programming on S/360. As stated in my
previous posting, I merely copied the example out of the Ada Reference
Manual.

Consider the example targeted to a hypothetical machine cosmetically
similar to S/360.

I used this example because I do not have access to systems programming
code I wrote for work. For instance, I have used Ada to create a
parallel port controller for an embedded system. The system was a
robotic control unit. The parallel port was used by one particular
sensor system. On the same system we had serial port drivers and CAN
bus drivers. All the drivers were written in Ada.

The overall system design could be described as an event-driven,
multi-tasking, dynamically configurable design with tolerance to
system degredation. The robotic system controlled a large bulldozer
used in mine clearing operations. We designed the system expecting
eventual damage to the vehicle and/or its sensors during its normal
operation. The software responsible for handling the damaged bits
would not cause error conditions that interfered with the parts
that still worked within specifications.

Jim Rogers

"Wouter Lievens" <lievenswouter@snotmail.com> wrote in
news:40ffaeed$0$379$ba620e4c@news.skynet.be:

Or more simply, construct a language that can call the legacy C
libraries. That way the new code can be developed using the new
language while retaining the investment in C code. The C code could
be replaced when it needed significant modification.

Jim Rogers

"Wouter Lievens" <lievenswouter@snotmail.com> wrote in news:40ffae6f$0
$31471$ba620e4c@news.skynet.be:

X needs operator overloading to replace C++. C does not provide
operator overloading.

Jim Rogers

"Jim Rogers" <jimmaureenrogers@att.net> wrote in message
news:Xns952E43E9F184Ajimmaureenrogers@127.0.0.1...
You know what bugs me about C++?
I try to do this and it doesn't work:
class myaz
{
private:
static const string x("abc");
};

doesn't work!
tried many syntax and still won't do it...

On Thu, 22 Jul 2004, JustSomeGuy wrote:
You might have started a new thread, you know... and in comp.lang.c++
or alt.comp.lang.learn.c-c++ while you're at it! But anyway, I'm sure
this is a FAQ; the answer is "linker issues," and the solution is

#include <string>
using namespace std;
class myaz {
private: static const string x;
};
const string myaz::x("abc");

(Ask in comp.lang.c++ about "header files" and what ought to go in
them.)

-Arthur

"Arthur J. O'Dwyer" <ajo@nospam.andrew.cmu.edu> wrote in message
news:Pine.LNX.4.58-035.0407221311050.4401@unix42.andrew.cmu.edu...
There was indeed a thread to this end. And it was decided that the
C++ standard just didn't make allowance for this.

"Eric" <ericmuttta@email.com> wrote in message
news:ca5584cb.0407200224.5a463e9@posting.google.co m...
Sure, in fact, I went so far as to design one. The D Programming Language,
spec at www.digitalmars.com/d/


Yup.

Check. I think that virtual machines are overrated, their often touted
benefits are actually due to other things. For example, targetting a VM
doesn't make a language portable, what makes it portable is tightening up
all the 'implementation defined' and 'undefined' behaviors in the language
specification.

In D, classes and arrays are reference types and other types are value
types. But using inout or out parameters will make the parameters by
reference, and of course, pointers are fully supported.

D has these with the exception of bit-fields, which aren't that useful and
easilly emulated.

Not sure what you mean. Certainly, one can define a linked list like:
class List
{ List next;
...
}

D is generally a garbage collected language. However, one can still allocate
on the stack, use malloc/free, statically allocate, or roll your own
allocator on a per-class or case-by-case basis.


Check. D is a multi-paradigm language, and one does not need to use its OOP
facilities.

D is hardly pure, it even directly supports inline assembler!

Check. D can be compiled as efficiently as C++, and offers opportunities for
better optimization since it offers higher level constructs.

D offers garbage collection for automatic memory management. However, one
can still use RAII techniques for resources that are not appropriate for
lazy gc. One can also use stack allocation, explicit malloc/free, etc., as
explained before.

LOL. Pointers are needed now and then, and D fully supports them. D also
supports the bizarre and inscrutable pointer declaration syntax, but also
offers an alternative. Your declaration above could be written as is in D,
or it could be rewritten as:

char** foo(char function(int), int* function()[10] function()** b);

(which reads from right to left).

D's support for arrays is excellent - array lengths are known, arrays are
resizable, can be concatenated, vector operations on arrays, etc., all while
retaining compatibility with C-style arrays.

Yes. Arguments can be 'in' (default), 'inout' (can be read/written by the
function) or 'out' (written by the function).

Yes. 'auto' gives RAII semantics to a class object, meaning it is destructed
on leaving the scope.

int* function(int) p; // p is a pointer to a function taking an int
argument and returning a pointer to int.

int* function(int)* p; // q is a pointer to a pointer to a function
taking an int argument and returning a pointer to int.

Yes, see the List example above.

Not sure what you mean here.

Although D offers const as a storage class, it is not a type modifier. After
many years of experience with C and C++, I haven't found const-correctness
to be a useful attribute of a language. It's never found a single bug in any
of my programs.

Null pointer exceptions are actually good things. I remember the bad old DOS
programming days, where instead of an exception a null pointer would
literally scramble the operating system, requiring a reboot. Awful. Having
an excepetion means I can have a debugger tell me exactly where in my
program it goofed. Sweet.

I don't know what the Null Object pattern is.

D is definitely in the case-sensitivity, curly brace, and semicolon camp. It
definitely is in the C/C++ camp of how code should look.

D is creeping into many corporations from the bottom up <g> as the more
adventurous programmers bring it in from home and just start doing projects
in it.

It's an insightful post you wrote. D doesn't address all of your points, but
it takes a good stab at them. D also addresses many additional crucial
points:

1) internationalization support - D front-to-back supports UTF-8, UTF-16 and
UTF-32 character encodings, leaving behind code pages,
implementation-defined wchar sizes, etc. Internationalization is where the
future is.

2) generic programming - D supports templates, partial specializations,
explicit specializations, etc., and even mixins.

3) inline assembler - while many C/C++ compilers support it, they do so as
incompatible extensions. D supports inline assembler in a defined,
consistent format. Inline assembler is very important for writing system
apps and doing low level support code.

4) D is free. The Digital Mars D compiler is available for Windows and
Linux, and the GNU D compiler (gdc) is available for other platforms as
well.

5) Design by Contract and Unit testing - Eiffel's great contribution was to
think through how to do DbC. DbC is gradually catching on as programmers
become aware of what a huge advance it is in creating robust, reliable code.
D fully supports DbC and adds unit testing capability as well.

6) C ABI compatibility - C is the lingua franca of the programming world. D
recognizes this and fully supports the C ABI (even better than C++ does). C
functions and all C datatypes can be accessed directly without resorting to
wrappers, marshallers, or complex protocols. No need to put the C code in a
separate DLL, either, just link it in.

7) modules - C++ has run into the limits of the inclusion model of
programming (i.e. using #include) as evidenced by the difficulty of
implementing exported templates. D uses instead a module based system.


-Walter
www.digitalmars.com/d/ The D Programming Language
www.digitalmars.com/d/ctod.html comparison with C
www.digitalmars.com/d/cpptod.html comparison with C++
www.digitalmars.com/d/pretod.html comparison with C preprocessor
www.digitalmars.com/d/comparison.html feature comparison table with
C/C++/C#/Java