D

[Hans Aberg]

Is it not time to make a new language D drawing on the experiences from C
and C++?

Specifically, such a language should zip out the parts of C that are
problematic and caused ambiguities and problems in C++. For example, the
many implicit type conversions and problems in the C syntax which are
difficult handle in a C++ high level language style. (There is an example
in the Bison manual in the GLR parser section of a C++ language
ambiguity).

Then one would first get a cleaner C core, not having to worry about
upwards compatibility so much anymore. Further this core can be designed
with respect to more modern CPU structures in mind.

The experiences from C++ will tell mainly how to implement statically
computable user definable structures, including some generic programming
then.

To this, one needs a level above the C++ level, handling parallelism,
distributed programming and better handling of dynamic objects (so it
becomes easier to create Java style polymorphic classes), including ones
choice of GC if needed.

On the level below the C level, one can think of a "portable assembler
level" like C-- and/or a byte code level, which can be used as an
intermediate to an assembler level. This level should also provide hooks
to "universal binary standards" like CORBA and Unicode, which C and C++
carefully avoids due to their history.

See you in comp.std.d. :-)

Hans Aberg * Anti-spam: remove "remove." from email address.
* Email: Hans Aberg <remove.haberg@ member.ams.org>
* Home Page: <http://www.math.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>

[Victor Bazarov]

Re: D

"Hans Aberg" <remove.haberg@ matematik.su.se > wrote...[color=blue]
> Is it not time to make a new language D drawing on the experiences from C
> and C++?[/color]

There is 'D' already. Search for it on the Web.

Victor

[Ioannis Vranos]

Re: D

"Hans Aberg" <remove.haberg@ matematik.su.se > wrote in message
news:remove.hab erg-080703223257000 1@du130-86.ppp.su-anst.tninet.se. ..[color=blue]
> Is it not time to make a new language D drawing on the experiences from C
> and C++?[/color]

There have been many language attempts named "D".




[color=blue]
> Specifically, such a language should zip out the parts of C that are
> problematic and caused ambiguities and problems in C++. For example, the
> many implicit type conversions and problems in the C syntax which are
> difficult handle in a C++ high level language style. (There is an example
> in the Bison manual in the GLR parser section of a C++ language
> ambiguity).
>
> Then one would first get a cleaner C core, not having to worry about
> upwards compatibility so much anymore. Further this core can be designed
> with respect to more modern CPU structures in mind.
>
> The experiences from C++ will tell mainly how to implement statically
> computable user definable structures, including some generic programming
> then.
>
> To this, one needs a level above the C++ level, handling parallelism,
> distributed programming and better handling of dynamic objects (so it
> becomes easier to create Java style polymorphic classes), including ones
> choice of GC if needed.
>
> On the level below the C level, one can think of a "portable assembler
> level" like C-- and/or a byte code level, which can be used as an
> intermediate to an assembler level. This level should also provide hooks
> to "universal binary standards" like CORBA and Unicode, which C and C++
> carefully avoids due to their history.[/color]



There is no need to create a new language which has nothing more to offer
than the existing ones. Also C++ evolution iis based on providing superior
alternatives which you can use in place of the legacy ones.


Take for example exception handling in the place of return value checking.

In essence, what you are telling is to "recreate" a subset of the now
existing C++. Do something better, use the new and superior facilities that
C++ has to offer than the old stuff.




--
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL 1: http://run.to/noicys
* Alternative URL 2: http://www.noicys.cjb.net

[Andrew Edwards]

Re: D

"Hans Aberg" <remove.haberg@ matematik.su.se > wrote in message
news:remove.hab erg-080703223257000 1@du130-86.ppp.su-anst.tninet.se. ..[color=blue]
> Is it not time to make a new language D drawing on the experiences from C
> and C++?
>[/color]

See for yourself:

http://www.digitalmars.com/d

[Richard Bos]

Re: D

remove.haberg@m atematik.su.se (Hans Aberg) wrote:
[color=blue]
> Is it not time to make a new language D drawing on the experiences from C
> and C++?[/color]

It has been that time several times now, if the people shouting from the
wings are to be believed. In fact, several such languages exist,
beginning with C++, but somehow none of them has replaced C. Tell you
what, though: you do the drudge work (a couple of years' hard work
should be enough), and we'll tell you whether we like it or not. Now all
you have to do is make sure that you don't create yet another
C-with-classes.

Richard

[Ioannis Vranos]

Re: D

"Paul Hsieh" <qed@pobox.co m> wrote in message
news:MPG.197559 063bd1876f98971 f@news.sf.sbcgl obal.net...[color=blue]
>
> There is also no way to communicate to the C/C++ faithful here (or other
> similar newsgroups) that a more progressive stance on the evolution of the
> standard (based on lessons learned from *those* languages) could[/color]
significantly[color=blue]
> revitalize the C/C++ languages.[/color]


Check this: http://www.research.att.com/~bs/C++0x_keynote.pdf



If you have new ideas why don't you submit them in the committee or at least
at comp.std.c++ ? :-)



[color=blue]
> Just look at the C99 standard to see where the future of C is. They added
> complex numbers to lure away all those hordes of Fortran programmers ...
> *sigh*.[/color]



Yes i agree with you. C99 is a dead language. Instead of providing complex
and stuff as part of new header files only, they made them built in and with
ugly names!


[color=blue]
>
> You'd probably be better off trying to work on Python, Ruby, LUA, or a[/color]
language[color=blue]
> of your own creation than trying to motivate anyone here to *improve* the[/color]
C[color=blue]
> standard. Nobody cares anymore.[/color]


I disagree with you regarding C++!




--
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL 1: http://run.to/noicys
* Alternative URL 2: http://www.noicys.cjb.net

[Alan Balmer]

Re: D

On Wed, 09 Jul 2003 06:41:51 GMT, qed@pobox.com (Paul Hsieh) wrote:
[color=blue]
>ivr@nothis.ema ils.ru says:[color=green]
>> There is no need to create a new language which has nothing more to offer
>> than the existing ones. Also C++ evolution iis based on providing superior
>> alternatives which you can use in place of the legacy ones.[/color]
>
>"Hans Aberg" <remove.haberg@ matematik.su.se wrote:[color=green][color=darkred]
>> >
>> > See you in comp.std.d. :-)[/color][/color]
>[/color]
<snip>[color=blue]
>There is also no way to communicate to the C/C++ faithful here (or other
>similar newsgroups) that a more progressive stance on the evolution of the
>standard (based on lessons learned from *those* languages) could significantly
>revitalize the C/C++ languages.[/color]

I didn't know they needed "revitalizi ng."[color=blue]
>
>Just look at the C99 standard to see where the future of C is. They added
>complex numbers to lure away all those hordes of Fortran programmers ...
>*sigh*.
>[/color]
Gosh, I didn't even know there was a contest! Do the members of the
standards committee get bonuses if enough programmers use C? Like many
programmers, I use the tool which is best for the job, considering all
relevant factors, and often that's C.
[color=blue]
>You'd probably be better off trying to work on Python, Ruby, LUA, or a language
>of your own creation than trying to motivate anyone here to *improve* the C
>standard.[/color]

That's what jvr said - there's no need to radically change C if there
are other languages to do the job. And no need to invent another
language if what you need already exists.

It seems that you are advocating that C/C++ evolve into the perfect
programming language. There ain't no such animal.

--
Al Balmer
Balmer Consulting
removebalmercon sultingthis@att .net

[llewelly]

Re: D

qed@pobox.com (Paul Hsieh) writes:
[color=blue]
> ivr@nothis.emai ls.ru says:[color=green]
>> There is no need to create a new language which has nothing more to offer
>> than the existing ones. Also C++ evolution iis based on providing superior
>> alternatives which you can use in place of the legacy ones.[/color]
>
> "Hans Aberg" <remove.haberg@ matematik.su.se wrote:[color=green][color=darkred]
>> >
>> > See you in comp.std.d. :-)[/color][/color]
>
> Unforunately, you'll find the above attitude extremely prevalent in this and
> the comp.std.c newsgroups. There's a lot of "C is a systems language" and "use
> the right tool for the right job" nonsense commonly spouted here.[/color]

It makes better sense to use the wrong tool for the job? If you mean
to say that C should be improved to handle new jobs, then say that.
[color=blue]
>
> The people who were previously in the position of detesting C and C++ have long
> since left and created their own pet languages (Java, Perl, Python, etc.) And
> all those who remain here either don't care or don't realize realize that this
> has happened.[/color]

Or we are happy that new languages have filled needs C and C++ did not
meet well. If you look at the goals of those languages, and
compare them to the goals of C++ (as described in D&E by
Stroustrup) or the goals of C, you will find they aim at very
different areas.

In particular, D&E makes it clear that Stroustrup has always believed
there are places for languages other than C++; he says 'use the
right tool for the right job' many different times in many
different ways.
[color=blue]
> There is also no way to communicate to the C/C++ faithful here (or other
> similar newsgroups) that a more progressive stance on the evolution of the
> standard (based on lessons learned from *those* languages) could significantly
> revitalize the C/C++ languages.[/color]
[snip]

I do not know about the C community, but some of the C++ community is
still smarting from the too fast and too poorly communicated evolution
of the current standard - yes, I do mean the evolution that took
place in the early to mid 1990s, almost a decade ago. For whatever
reason, good information spreads slowly in the C++ community.

[Ioannis Vranos]

Re: D

"dbtid" <dbtid@dev-null.us> wrote in message
news:3615f6768f d452fc3a38c286d f573322@free.te ranews.com...[color=blue]
>
> Then why are you here?[/color]


Basically "i am" in c.l.c++.

[color=blue]
> I see it's true that leopards don't change their stripes, even
> after all these years.[/color]


Hrrrr (as cats purr).



--
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL 1: http://run.to/noicys
* Alternative URL 2: http://www.noicys.cjb.net

[pete]

Re: D

Paul Hsieh wrote:
[color=blue]
> What I am saying is that the C (89, 99 whatever) standard
> as it is is severely flawed. Why not at least bring it up to the
> level of not being so flawed?[/color]

Seems more like a topic for
news:comp.std.c

--
pete

[Paul Hsieh]

Re: D

"Ioannis Vranos" <ivr@nothis.ema ils.ru> wrote:[color=blue]
> "Paul Hsieh" <qed@pobox.co m> wrote:[color=green]
> > There is also no way to communicate to the C/C++ faithful here (or other
> > similar newsgroups) that a more progressive stance on the evolution of the
> > standard (based on lessons learned from *those* languages) could
> > significantly revitalize the C/C++ languages.[/color]
>
> Check this: http://www.research.att.com/~bs/C++0x_keynote.pdf[/color]

I had not seen this before. He raises a lot of good and important
points, lots of them that I have tried to make. His most important
one, the one about safety, is something that I've become seriously
obsessed with over the past year or so.
[color=blue]
> If you have new ideas why don't you submit them in the committee or at least
> at comp.std.c++ ? :-)[/color]

Well, he's asking for libraries and safety, and has pointed out the
buffer overflow problem related to safety -- that's an obvious queue
my "better string library":

http://bstring.sourceforge.net/

Its implemented in both C and C++. Now, I am far from an expert in
C++, and had some assistance in creating the C++ portion. If there
are fundamental design flaws with it, let me know, or modify it
yourselves or whatever.

The point of the bstring library, especially in comparison to the
numerous other string libraries out there, is that its high
performance, it carries absolutely no extra baggage with it, while
remaining totally interoperable with the char * buffer style strings.
It brings up the functionality level to nearly that of Python/Perl
(though I'm obviously missing regex's) with no dramatic compromises.

As to his comment about GC, I have thought about it, but I can't think
of a way to implement it properly with high performance *and* support
the typical malloc/free paradigm at the same time. Even if you could
make it work, the fact that C/C++ still cannot *guarantee* prevention
of buffer overflows leading to undefined behavior, add a GC background
thread and this is likely to manifest itself in programing errors that
are *truly* impossible to debug. Some C/C++ programmers are also used
to the idea that "encoded pointers" shouldn't lead to unexpected
behavior (though most C-based GC solutions fail when you do things
like this.)

The real goal of GC is eliminate the memory leaks, and simplify code
somewhat. So as an alternative to GC, why not just significantly
extend the heap management semantics? So many programmers write their
own "debug wrappers" for malloc/realloc/free anyhow, why not just
decide on a one useful set of very general extensions, provide sample
code for the vendors to use, and add it to the language standard. I
have some ideas here that have worked very well for me in practice, if
the C++ people are truly open to these ideas.
[color=blue][color=green]
> > Just look at the C99 standard to see where the future of C is. They added
> > complex numbers to lure away all those hordes of Fortran programmers ...
> > *sigh*.[/color]
>
> Yes i agree with you. C99 is a dead language.[/color]

Not just me! Ask the compiler vendors ... they seem to agree as well!

This calls to question one point in the slides above -- Bjarne
Stroustrup seems to be lamenting this inevitable split between C and
C++ that has been caused by C99. Perhaps he has to consider the
possibility that backward compatibility with C is no longer worth it.
There is no way to sufficiently mutate C++ to be acceptable for C89,
C99, and old C++. I think its fair to assume that C99 will not pick
up a sufficient audience at all. Simply dropping sufficient C99
compatibility is probably unavoidable anyway, so I'd say just pick up
whatever useful things from C99 (obviously "restrict", and perhaps the
vararrays, VARARG preprocessor stuff, etc) and move forward.

I.e., pining on about it isn't going to help. Make the cut as clean
as possible, and don't let yourselves be trapped by it.
[color=blue]
> [...] Instead of providing complex
> and stuff as part of new header files only, they made them built in and with
> ugly names![/color]

Yeah, that too. Not to put too much of a political spin on this, but
I see the C99 spec as analogous to Saddam's 11K+ page declaration of
all his weapons program prior to the US ignoring it and crushing his
regime like a bug anyway. A technicality, a distraction, destined to
be forgotten, and ultimately irrelevant. (I emphasize again, I'm
*not* making a political statement about what I think about the whole
Iraq thing, just noting this one interesting aspect of it.)
[color=blue][color=green]
> > You'd probably be better off trying to work on Python, Ruby, LUA, or a
> > language of your own creation than trying to motivate anyone here to
> > *improve* the C standard. Nobody cares anymore.[/color]
>
> I disagree with you regarding C++![/color]

Well, I was unaware of C++'s openess to suggestions. My previous
interaction with Mr. Stroustrup was not very productive, as we clearly
seemed to be talking past each other.

Anyhow, lets start with my string and heap suggestions above and see
what people think. Is there some more formal way that I should be
making these suggestions?

--
Paul Hsieh

http://www.pobox.com/~qed/

http://bstring.sourceforge.net/

[Mirek Fidler]

Re: D

> The point of the bstring library, especially in comparison to the[color=blue]
> numerous other string libraries out there, is that its high
> performance, it carries absolutely no extra baggage with it, while
> remaining totally interoperable with the char * buffer style strings.
> It brings up the functionality level to nearly that of Python/Perl
> (though I'm obviously missing regex's) with no dramatic compromises.[/color]

Is there anything that makes bstring superior to usual C++
interface/implementation, like std::string ?

Mirek

[Andrew Edwards]

D: Current State, Approval Ratings

In following a previous thread on the so called flawed state of the C99
standard and inadequacies of the C++ language, Richard Bos wrote:

"It has been that time several times now, if the people
shouting from the wings are to be believed. In fact,
several such languages exist, beginning with C++, but
somehow none of them has replaced C. Tell you what, though:
you do the drudge work (a couple of years' hard work should
be enough), and we'll tell you whether we like it or not.
Now all you have to do is make sure that you don't create
yet another C-with-classes."

This made me curious as to the community's approval rating of the current
effort to replace both the C and C++ languages. D was concocted in 1999 by
Walter Bright (www.walterbright.com) of Digital Mars (www.digitalmars.com),
and continues to evolve with helpful suggestions and critiques. It was
publicly revealed it in a heated debate on slashdot.com in August 2001
(http://slashdot.org/article.pl?sid=01/08/15/234223). Walter followed this
with a cover story (http://www.ddj.com/articles/2002/0202/) in the February
2002 issue of Dr. Dobbs.

Here is an overview of D the language:

http://www.digitalmars.com/d/overview.html

The entire language specification is located here:

http://www.digitalmars.com/d/

Their newsgroup is located here:
news://news.digitalmars.com/D

You may download a copy of the compiler (which is available in two flavors:
Win32 and x86 Linux) here:

http://www.digitalmars.com/d/changelog.html

Regards,
Andrew

[Mark McIntyre]

Re: D

On 9 Jul 2003 19:35:40 -0700, in comp.lang.c , qed@pobox.com (Paul
Hsieh) wrote:
[color=blue]
>You must live in an extremely skewed world -- there are very few
>projects left today where you can justify simply starting in the C
>language.[/color]

ahahahahahahah. Thats a funny joke, that is.
[color=blue]
>About the only places where this makes sense is where you
>have no other compilers available, and its either that or assembly.[/color]

I wonder, out of idle interest, how many embedded systems there are
out there. ISTR that many games are written in C too.
[color=blue][color=green]
>> That's what jvr said - there's no need to radically change C if there
>> are other languages to do the job. And no need to invent another
>> language if what you need already exists.[/color]
>
>And this is what I said that you and others would say.[/color]

So someone states the bleeding obvious, and you agree. So why did you
ask teh question in the first place? Clue: you're a large stone
creature that is allergic to sunlight.
[color=blue]
>Look, my point of view is simple: C/C++ is clearly *faster* than just
>about every other language, but its also clearly far less safe,[/color]

Nope.
[color=blue]
>difficult to learn,[/color]

only for people who find it hard counting to eleven without using
their toes.
[color=blue]
>extremely lacking features, etc., etc.[/color]

Nope.
[color=blue]
>Why do the
>two have to go hand in hand?!?! In particular why can't I be *even
>faster*, and *safer* at the same time?[/color]

you can. Please feel free to write a new langage, distribute it, and
if it takes off, well done.
[color=blue]
>It is you people who say
>things like "right tool for the right job" that implicitely ignore
>this as a possibility![/color]

Actually thats what "the right tool for the right job" means, but
you're too argumentative to realise that.
[color=blue]
>*I* want features, more safety, and I want a heck of a lot more
>performance than C gives me! The thing is, there is no *technical*
>reason why C cannot be modified in small ways in the core language,
>and rather more serious (and badly needed) ways in the library to
>provide this.[/color]

Please do submit this to teh committee, along with demostration that
you won't lose portability to the currently supported platforms.
[color=blue]
>I do not need the 100% safety of Java, but I could use
>a little more than the 0% provided by C. And why am I resorting to
>inline assembly any time I want real performance out of my state of
>the art C compiler?[/color]

Because you're a bad programmer? I've no idea.
[color=blue]
>For example, there is almost no C standard library function that I
>cannot rewrite, or respecify to improve both performance and program
>safety.[/color]

Then why aren't you working for MS or Borland, raking in megabucks
improving their std lib implementations .
[color=blue]
>Almost the entire stdlib is of a "first hack" quality,
>practically enforced by the standard.[/color]

Only if you have a crapola version of the standard library. Its a poor
workman who blames his tools.

*Threadplonk*
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.c om/ms3/bchambless0/welcome_to_clc. html>


----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

[Mirek Fidler]

Re: D

> *I* want features, more safety, and I want a heck of a lot more[color=blue]
> performance than C gives me! The thing is, there is no *technical*[/color]

May I ask you a humble question why you are not using C++ instead ?
I agree there is no technical reason and that is what C++ is about....

Mirek