"Small C++" Anyone?

[JohnQ]

(The "C++ Grammer" thread in comp.lang.c++.moderated prompted this post).

It would be more than a little bit nice if C++ was much "cleaner" (less
complex) so that it wasn't a major world wide untaking to create a toolchain
for it. Way back when, there used to be something called "Small C". I wonder
if the creator(s) of that would want to embark on creating a nice little
Small C++ compiler devoid of C++ language features that make toolchain
(including the compiler) a nightmare to implement (?). Yes, I realize that
would be a subset or a "dialect" of C++. Or not! They could call it
something else and avoid all the flak from the "use all of C++ all of the
time" proponents. I'd try and tackle that myself if I had another 100 years
to live. Alas, I don't so I have to stay focused on what I can produce at a
higher level of usage instead of diving into something new and so low level.

A "new" clean "little" language that is wholly a subset of C++ but is
tremendously easier to implement and to create a toolchain for. That's the
ticket! Could something like that "put C++ out of business"?

John

[Ian Collins]

JohnQ wrote:

(The "C++ Grammer" thread in comp.lang.c++.moderated prompted this post).

It would be more than a little bit nice if C++ was much "cleaner" (less
complex) so that it wasn't a major world wide untaking to create a toolchain
for it. Way back when, there used to be something called "Small C". I wonder
if the creator(s) of that would want to embark on creating a nice little
Small C++ compiler devoid of C++ language features that make toolchain
(including the compiler) a nightmare to implement (?). Yes, I realize that
would be a subset or a "dialect" of C++. Or not! They could call it
something else and avoid all the flak from the "use all of C++ all of the
time" proponents. I'd try and tackle that myself if I had another 100 years
to live. Alas, I don't so I have to stay focused on what I can produce at a
higher level of usage instead of diving into something new and so low level.

A "new" clean "little" language that is wholly a subset of C++ but is
tremendously easier to implement and to create a toolchain for. That's the
ticket! Could something like that "put C++ out of business"?

That sounds a bit like going back to one of the original cfront
compilers, or maybe EC++?

--
Ian Collins.

[Piyo]

JohnQ wrote:

A "new" clean "little" language that is wholly a subset of C++ but is
tremendously easier to implement and to create a toolchain for. That's the
ticket! Could something like that "put C++ out of business"?

John

Not a particularly new discussion. Here is an idea to "simplify" C++
called EC++:

http://en.wikipedia.org/wiki/Embedded_C%2B%2B

I'd have to agree with Stroustrup here. Here are some other alternatives
I could suggest you look into:

a) Scala (if you are a Java man)
http://en.wikipedia.org/wiki/Scala_%...ng_language%29
b) D (if you like C++)
http://en.wikipedia.org/wiki/D_programming_language

BTW, Are you sure it is alright to post things like this on this
newsgroup?

[Dennis \(Icarus\)]

"JohnQ" <jo***********************@yahoo.comwrote in message
news:AQ****************@newssvr23.news.prodigy.net ...

(The "C++ Grammer" thread in comp.lang.c++.moderated prompted this post).

It would be more than a little bit nice if C++ was much "cleaner" (less
complex) so that it wasn't a major world wide untaking to create a

toolchain

for it. Way back when, there used to be something called "Small C". I

wonder

if the creator(s) of that would want to embark on creating a nice little
Small C++ compiler devoid of C++ language features that make toolchain
(including the compiler) a nightmare to implement (?). Yes, I realize that
would be a subset or a "dialect" of C++. Or not! They could call it
something else and avoid all the flak from the "use all of C++ all of the
time" proponents. I'd try and tackle that myself if I had another 100

years

to live. Alas, I don't so I have to stay focused on what I can produce at

a

higher level of usage instead of diving into something new and so low

level.

>
A "new" clean "little" language that is wholly a subset of C++ but is
tremendously easier to implement and to create a toolchain for. That's the
ticket! Could something like that "put C++ out of business"?

I think the very things that make C++ hard to implement (e.g. templates,
namespaces) would wind up being requested or added to the "Small-C++" over
time.

Dennis

[dave_mikesell]

On Mar 9, 5:06 pm, "JohnQ" <[e-mail]>
wrote:

(The "C++ Grammer" thread in comp.lang.c++.moderated prompted this post).

It would be more than a little bit nice if C++ was much "cleaner" (less
complex) so that it wasn't a major world wide untaking to create a toolchain
for it.

We already have D, Java, etc. Just create coding standards for you
and your team to use. No need to dumb down the language. There's
something for everyone in C++.

[kwikius]

On 9 Mar, 22:06, "JohnQ" <[e-mail]:

A "new" clean "little" language that is wholly a subset of C++ but is
tremendously easier to implement and to create a toolchain for. That's the
ticket! Could something like that "put C++ out of business"?

AFAICS there are 2 approaches to programming language design. Either
make it for the compiler writer, or make it for the user.

The end result of the first approach is functional laguages and in
fact these are generally reckoned to be good when you wish to automate
things ( e.g when writing a compiler). C++ is the end result of the
second approach. It is a wonderful language to write code in ( Once
you have learned the main features and acquired some mastery), but a
compiler writers nightmare).

I had a brief dip into D. This aims to do something like what you
want. However it seems that as users discuss their usage and make
feature requests, so D is starting to become more and more complicated
and quirky just like C++ :-)
regards
Andy Little

[throatslasher]

On Mar 9, 2:16 pm, Piyo <[e-mail]:

JohnQ wrote:

A "new" clean "little" language that is wholly a subset of C++ but is
tremendously easier to implement and to create a toolchain for. That's the
ticket! Could something like that "put C++ out of business"?

John

Not a particularly new discussion. Here is an idea to "simplify" C++
called EC++:

http://en.wikipedia.org/wiki/Embedded_C%2B%2B

I'd have to agree with Stroustrup here. Here are some other alternatives
I could suggest you look into:

a) Scala (if you are a Java man)http://en.wikipedia.org/wiki/Scala_%...ng_language%29
b) D (if you like C++)http://en.wikipedia.org/wiki/D_programming_language

BTW, Are you sure it is alright to post things like this on this
newsgroup?

It most certainly is not "alright" to post "things" like this on this
newsgroup. "These" kind of posts really ride my wig off, and I think
you know what I mean. Folks, it is truly a sad day.

[JohnQ]

"Ian Collins" <ia******@hotmail.comwrote in message
news:55**************@mid.individual.net...

JohnQ wrote:

>(The "C++ Grammer" thread in comp.lang.c++.moderated prompted this post).

It would be more than a little bit nice if C++ was much "cleaner" (less
complex) so that it wasn't a major world wide untaking to create a
toolchain
for it. Way back when, there used to be something called "Small C". I
wonder
if the creator(s) of that would want to embark on creating a nice little
Small C++ compiler devoid of C++ language features that make toolchain
(including the compiler) a nightmare to implement (?). Yes, I realize
that
would be a subset or a "dialect" of C++. Or not! They could call it
something else and avoid all the flak from the "use all of C++ all of the
time" proponents. I'd try and tackle that myself if I had another 100
years
to live. Alas, I don't so I have to stay focused on what I can produce at
a
higher level of usage instead of diving into something new and so low
level.

A "new" clean "little" language that is wholly a subset of C++ but is
tremendously easier to implement and to create a toolchain for. That's
the
ticket! Could something like that "put C++ out of business"?

That sounds a bit like going back to one of the original cfront
compilers, or maybe EC++?

EC++ sounds like a good starting point, along with a compiler implementation
complexity analysis of each feature of C++. Surely cfront (but the cfront
implementations are all proprietary as far as I know) and "Inside the C++
Object Model" would be good references for the implementation. Now just to
get someone to actually produce the thing. An open source project? Perhaps
PJ Plauger's outfit has this already done? An open source may be desireable
(or at least available source for those who wanted to flesh out a toolchain
with analyzers and such).

John

[JohnQ]

"Piyo" <cy*********@yahoo.comwrote in message
news:u1*****************@newssvr21.news.prodigy.ne t...

JohnQ wrote:

>A "new" clean "little" language that is wholly a subset of C++ but is
tremendously easier to implement and to create a toolchain for. That's
the ticket! Could something like that "put C++ out of business"?

John

Not a particularly new discussion. Here is an idea to "simplify" C++
called EC++:

http://en.wikipedia.org/wiki/Embedded_C%2B%2B

I'd have to agree with Stroustrup here. Here are some other alternatives
I could suggest you look into:

a) Scala (if you are a Java man)
http://en.wikipedia.org/wiki/Scala_%...ng_language%29

No proprietary environment languages please. I like C++. I don't really want
a different language, just an "improved" C++. (Of course, the standards
folks would say that if it's not in the spec, it's not C++. Call it
whatever, I don't want drastic departure from a subset of C++.)

b) D (if you like C++)
http://en.wikipedia.org/wiki/D_programming_language

I took a cursory look at D and find it a drastic departure from C++. I'm not
looking for a new language lock/stock/barrel, perhaps just a subset with
maybe just a few additions. "A better C++" if you will. But unlike "a better
C", less would be more.

BTW, Are you sure it is alright to post things like this on this
newsgroup?

Why not? Forward-thinking about the future of C++ is on topic. As is
analysis of the complexity of implementing C++ features.

John

[JohnQ]

"throatslasher" <im**********************@hotmail.comwrote in message
news:11**********************@30g2000cwc.googlegro ups.com...

On Mar 9, 2:16 pm, Piyo <[e-mail]:

>JohnQ wrote:

A "new" clean "little" language that is wholly a subset of C++ but is
tremendously easier to implement and to create a toolchain for. That's
the
ticket! Could something like that "put C++ out of business"?

John

Not a particularly new discussion. Here is an idea to "simplify" C++
called EC++:

http://en.wikipedia.org/wiki/Embedded_C%2B%2B

I'd have to agree with Stroustrup here. Here are some other alternatives
I could suggest you look into:

a) Scala (if you are a Java
man)http://en.wikipedia.org/wiki/Scala_%...ng_language%29
b) D (if you like C++)http://en.wikipedia.org/wiki/D_programming_language

BTW, Are you sure it is alright to post things like this on this
newsgroup?

It most certainly is not "alright" to post "things" like this on this
newsgroup.

Why do you think that? Are you one of those that are always typing "don't
reinvent the wheel... if it's not an _STL_ container, it's not C++... blah,
blah"?.

"These" kind of posts really ride my wig off, and I think you know what I
mean.

Why?

Folks, it is truly a sad day.

Sounds like you're over-reacting about something. What's your beef?

John

[Ian Collins]

JohnQ wrote:

"Ian Collins" <ia******@hotmail.comwrote in message
news:55**************@mid.individual.net...

>>
That sounds a bit like going back to one of the original cfront
compilers, or maybe EC++?

EC++ sounds like a good starting point, along with a compiler implementation
complexity analysis of each feature of C++.

EC++ is an abomination. If you want to use a small subset of C++, do
just that. The last thing the world wants is yet another bastardised
language.

Surely cfront (but the cfront
implementations are all proprietary as far as I know) and "Inside the C++
Object Model" would be good references for the implementation. Now just to
get someone to actually produce the thing.

cfront is an historical artefact, we have moved on.

--
Ian Collins.

[JohnQ]

"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:43***************************@KNOLOGY.NET...

"JohnQ" <jo***********************@yahoo.comwrote in message
news:AQ****************@newssvr23.news.prodigy.net ...

>(The "C++ Grammer" thread in comp.lang.c++.moderated prompted this post).

It would be more than a little bit nice if C++ was much "cleaner" (less
complex) so that it wasn't a major world wide untaking to create a

toolchain

>for it. Way back when, there used to be something called "Small C". I

wonder

>if the creator(s) of that would want to embark on creating a nice little
Small C++ compiler devoid of C++ language features that make toolchain
(including the compiler) a nightmare to implement (?). Yes, I realize
that
would be a subset or a "dialect" of C++. Or not! They could call it
something else and avoid all the flak from the "use all of C++ all of the
time" proponents. I'd try and tackle that myself if I had another 100

years

>to live. Alas, I don't so I have to stay focused on what I can produce at

a

>higher level of usage instead of diving into something new and so low

level.

>>
A "new" clean "little" language that is wholly a subset of C++ but is
tremendously easier to implement and to create a toolchain for. That's
the
ticket! Could something like that "put C++ out of business"?

I think the very things that make C++ hard to implement (e.g. templates,
namespaces) would wind up being requested or added to the "Small-C++" over
time.

No, of course they wouldn't. Otherwise there would be no sense in creating
"Small C++": you'd have Std C++! Perhaps fresh and new ideas would be added
though, where they cannot be in Std C++ because of the constraint of
backward compatibility and resistance to reconsider (or throw away) what has
already been implemented (read, C++ is stagnating as an evolving language in
the "taken as gospel" aspects (not AOP), but there are already known lessons
from the implementation that could be improved upon in a "new" language
unencumbered with the Std C++ entrenchment).

There, did I say that right? It's not meant to fluster any feathers.

John

[JohnQ]

<da***********@fastmail.fmwrote in message
news:11**********************@s48g2000cws.googlegr oups.com...

On Mar 9, 5:06 pm, "JohnQ" <[e-mail]>
wrote:

>(The "C++ Grammer" thread in comp.lang.c++.moderated prompted this post).

It would be more than a little bit nice if C++ was much "cleaner" (less
complex) so that it wasn't a major world wide untaking to create a
toolchain
for it.

We already have D, Java, etc. Just create coding standards for you
and your team to use. No need to dumb down the language. There's
something for everyone in C++.

Yes, one could just use the subset of C++ that one wants to. But that still
doesn't make the possibility of more entrants (as well as DIYers) into the
toolchain market. I think there is a lot of good possibilities out there but
the complexity of implementation keeps the number of participants lower than
desireable. It's hard to build better things when you are faced with so much
complexity of implementation at the onset. I'm not suggesting changing C++,
but rather deriving a new, VERY C++-like language. (Aside: "something for
everyone in C++" may be the problem).

Just a thought.

John

[Ian Collins]

JohnQ wrote:

<da***********@fastmail.fmwrote in message
news:11**********************@s48g2000cws.googlegr oups.com...

>>On Mar 9, 5:06 pm, "JohnQ" <[e-mail]>
wrote:

>>>(The "C++ Grammer" thread in comp.lang.c++.moderated prompted this post).

It would be more than a little bit nice if C++ was much "cleaner" (less
complex) so that it wasn't a major world wide untaking to create a
toolchain
for it.

We already have D, Java, etc. Just create coding standards for you
and your team to use. No need to dumb down the language. There's
something for everyone in C++.

Yes, one could just use the subset of C++ that one wants to. But that still
doesn't make the possibility of more entrants (as well as DIYers) into the
toolchain market.

gcc is available just about everywhere. C is a very simple language,
how many people bother to compete in the C toolchain market? Answer,
not many, it is too full. Just about every platform has a proprietary C
compiler as well as gcc. There isn't the demand for alternatives.

--
Ian Collins.

[Ross A. Finlayson]

Ian Collins wrote:

JohnQ wrote:

<da***********@fastmail.fmwrote in message
news:11**********************@s48g2000cws.googlegr oups.com...

>On Mar 9, 5:06 pm, "JohnQ" <[e-mail]>
wrote:

(The "C++ Grammer" thread in comp.lang.c++.moderated prompted this post).

It would be more than a little bit nice if C++ was much "cleaner" (less
complex) so that it wasn't a major world wide untaking to create a
toolchain
for it.

We already have D, Java, etc. Just create coding standards for you
and your team to use. No need to dumb down the language. There's
something for everyone in C++.

Yes, one could just use the subset of C++ that one wants to. But that still
doesn't make the possibility of more entrants (as well as DIYers) into the
toolchain market.

gcc is available just about everywhere. C is a very simple language,
how many people bother to compete in the C toolchain market? Answer,
not many, it is too full. Just about every platform has a proprietary C
compiler as well as gcc. There isn't the demand for alternatives.

--
Ian Collins.

It seems like you want just another pass in the C compiler for the
code generation. Then templates etcetera can be implemented.
Templates can be implemented in C, they're much more concise in C++
with the mangling and etcetera.

Ross F.

--
Finlayson Consulting

[JohnQ]

"kwikius" <an**@servocomm.freeserve.co.ukwrote in message
news:11*********************@64g2000cwx.googlegrou ps.com...

On 9 Mar, 22:06, "JohnQ" <[e-mail]:

>A "new" clean "little" language that is wholly a subset of C++ but is
tremendously easier to implement and to create a toolchain for. That's
the
ticket! Could something like that "put C++ out of business"?

AFAICS there are 2 approaches to programming language design. Either
make it for the compiler writer, or make it for the user.

Beyond those "only 2" are good engineering that considers all the aspects
and creates something practical, elegantly simple. Your "there are only 2
approaches" is myopic or extremism: only seeing endpoints rather than a
range or continuum of possibility. I think maybe C++ suffers from "gold
plating" (the excess functionality of templates for example).

I had a brief dip into D. This aims to do something like what you
want.

Does it? How? I didn't get that impression from reading about it at the
website.

However it seems that as users discuss their usage and make
feature requests, so D is starting to become more and more complicated
and quirky just like C++ :-)

See, so it's hardly what I hint at.

John

[JohnQ]

"Ian Collins" <ia******@hotmail.comwrote in message
news:55**************@mid.individual.net...

JohnQ wrote:

>"Ian Collins" <ia******@hotmail.comwrote in message
news:55**************@mid.individual.net...

>>>
That sounds a bit like going back to one of the original cfront
compilers, or maybe EC++?

EC++ sounds like a good starting point, along with a compiler
implementation
complexity analysis of each feature of C++.

EC++ is an abomination.

Why?

If you want to use a small subset of C++, do
just that. The last thing the world wants is yet another bastardised
language.

Sounds like passion rather than objectivity.

>Surely cfront (but the cfront
implementations are all proprietary as far as I know) and "Inside the C++
Object Model" would be good references for the implementation. Now just
to
get someone to actually produce the thing.

cfront is an historical artefact, we have moved on.

Or "stagnated"? :P Dish it out and take it. LOL. To someone wishing to
create "a better C++" and not wanting to reinvent the wheel, cfront may save
some people some time.

John

[JohnQ]

"Ross A. Finlayson" <ra*@tiki-lounge.comwrote in message
news:11*********************@j27g2000cwj.googlegro ups.com...

>
Ian Collins wrote:

>JohnQ wrote:

<da***********@fastmail.fmwrote in message
news:11**********************@s48g2000cws.googlegr oups.com...

On Mar 9, 5:06 pm, "JohnQ" <[e-mail]>
wrote:

(The "C++ Grammer" thread in comp.lang.c++.moderated prompted this
post).

It would be more than a little bit nice if C++ was much "cleaner"
(less
complex) so that it wasn't a major world wide untaking to create a
toolchain
for it.

We already have D, Java, etc. Just create coding standards for you
and your team to use. No need to dumb down the language. There's
something for everyone in C++.
Yes, one could just use the subset of C++ that one wants to. But that
still
doesn't make the possibility of more entrants (as well as DIYers) into
the
toolchain market.

gcc is available just about everywhere. C is a very simple language,
how many people bother to compete in the C toolchain market? Answer,
not many, it is too full. Just about every platform has a proprietary C
compiler as well as gcc. There isn't the demand for alternatives.

--
Ian Collins.

It seems like you want just another pass in the C compiler for the
code generation. Then templates etcetera can be implemented.
Templates can be implemented in C, they're much more concise in C++
with the mangling and etcetera.

To be honest, I don't know what "Small C++" would look like. I just know it
would start out as a subset of C++ with some substitutional features
probably. It would be a good exercise if nothing else.

John

[JohnQ]

"Ian Collins" <ia******@hotmail.comwrote in message
news:55**************@mid.individual.net...

JohnQ wrote:

><da***********@fastmail.fmwrote in message
news:11**********************@s48g2000cws.googleg roups.com...

>>>On Mar 9, 5:06 pm, "JohnQ" <[e-mail]>
wrote:

(The "C++ Grammer" thread in comp.lang.c++.moderated prompted this
post).

It would be more than a little bit nice if C++ was much "cleaner" (less
complex) so that it wasn't a major world wide untaking to create a
toolchain
for it.

We already have D, Java, etc. Just create coding standards for you
and your team to use. No need to dumb down the language. There's
something for everyone in C++.

Yes, one could just use the subset of C++ that one wants to. But that
still
doesn't make the possibility of more entrants (as well as DIYers) into
the
toolchain market.

gcc is available just about everywhere.

But, I assume, pretty unapproachable at the source code level. You see, the
whole point is to not have to wade through the mud of complexity for
features that are undesireably in "Small C++".

C is a very simple language,
how many people bother to compete in the C toolchain market? Answer,
not many, it is too full. Just about every platform has a proprietary C
compiler as well as gcc. There isn't the demand for alternatives.

You won't really know that until you create "that other thing", now will
you.

John

[Dennis \(Icarus\)]

"JohnQ" <jo***********************@yahoo.comwrote in message
news:Kc*****************@newssvr19.news.prodigy.ne t...

>
"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:43***************************@KNOLOGY.NET...

"JohnQ" <jo***********************@yahoo.comwrote in message
news:AQ****************@newssvr23.news.prodigy.net ...

(The "C++ Grammer" thread in comp.lang.c++.moderated prompted this

post).

>
It would be more than a little bit nice if C++ was much "cleaner" (less
complex) so that it wasn't a major world wide untaking to create a

toolchain

for it. Way back when, there used to be something called "Small C". I

wonder

if the creator(s) of that would want to embark on creating a nice

little

Small C++ compiler devoid of C++ language features that make toolchain
(including the compiler) a nightmare to implement (?). Yes, I realize
that
would be a subset or a "dialect" of C++. Or not! They could call it
something else and avoid all the flak from the "use all of C++ all of

the

time" proponents. I'd try and tackle that myself if I had another 100

years

to live. Alas, I don't so I have to stay focused on what I can produce

at

a

higher level of usage instead of diving into something new and so low

level.

>
A "new" clean "little" language that is wholly a subset of C++ but is
tremendously easier to implement and to create a toolchain for. That's
the
ticket! Could something like that "put C++ out of business"?

I think the very things that make C++ hard to implement (e.g. templates,
namespaces) would wind up being requested or added to the "Small-C++"

over

time.

No, of course they wouldn't. Otherwise there would be no sense in creating
"Small C++": you'd have Std C++! Perhaps fresh and new ideas would be

added

though, where they cannot be in Std C++ because of the constraint of
backward compatibility and resistance to reconsider (or throw away) what

has

already been implemented (read, C++ is stagnating as an evolving language

in

Templates (generics) solve a nice set of real-world problems.
I'd expect that, were this not a part of "small-c++" a tempalte/generic sort
of mechanism would be rather quickly requested.

Same with namespaces.

the "taken as gospel" aspects (not AOP), but there are already known

lessons

from the implementation that could be improved upon in a "new" language
unencumbered with the Std C++ entrenchment).

Indeed.

>
There, did I say that right? It's not meant to fluster any feathers.

Dennis

[Ian Collins]

JohnQ wrote:

"Ian Collins" <ia******@hotmail.comwrote in message
news:55**************@mid.individual.net...

>>
EC++ is an abomination.

Why?

See

http://www.research.att.com/~bs/bs_faq.html#EC++

for some good arguments. In my opinion, the inability to use the
standard library or any form of generic programming is a huge retrograde
step.

>

>>If you want to use a small subset of C++, do
just that. The last thing the world wants is yet another bastardised
language.

Sounds like passion rather than objectivity.

I'd say its the truth. Languages evolve for a reason.

>

>>
cfront is an historical artefact, we have moved on.

Or "stagnated"? :P Dish it out and take it. LOL. To someone wishing to
create "a better C++" and not wanting to reinvent the wheel, cfront may save
some people some time.

But why bother? We have been there and moved on. I've used cfront
compilers, they were a good thing in their day, giving a better C. But
users wanted more, so the language grew to meet the demand, not just for
the sake of growing.

--
Ian Collins.

[Ian Collins]

JohnQ wrote:

"Ian Collins" <ia******@hotmail.comwrote in message
news:55**************@mid.individual.net...

>>
gcc is available just about everywhere.

But, I assume, pretty unapproachable at the source code level. You see, the
whole point is to not have to wade through the mud of complexity for
features that are undesireably in "Small C++".

It's not too bad. I have worked on a port ans once you get into the
code, it isn't any worse than any other code base.

>

>>C is a very simple language,
how many people bother to compete in the C toolchain market? Answer,
not many, it is too full. Just about every platform has a proprietary C
compiler as well as gcc. There isn't the demand for alternatives.

You won't really know that until you create "that other thing", now will
you.

Can you name any EC++ only compliers, that is ones that aren't part of a
tool suite that includes a full C++ compiler? If no one wants a
standardised subset, who's going to want an ad hoc one?

--
Ian Collins.

[JohnQ]

"Ian Collins" <ia******@hotmail.comwrote in message
news:55**************@mid.individual.net...

JohnQ wrote:

>"Ian Collins" <ia******@hotmail.comwrote in message
news:55**************@mid.individual.net...

>>>
EC++ is an abomination.

Why?

See

http://www.research.att.com/~bs/bs_faq.html#EC++

I've read that a few times. And every time I do, I have to say "take it with
a grain of salt". Because he's "in the box" rather than outside of it. (No
offense Bjarne!). Perhaps only because "I don't know any better". But ya
never know until you try. It sounds to me it went something like this:
multi-million dollar capable implementors applauded it, but that left out
those who could not enter the market at that level. Is it necessarilly
complex or designed to be complex? Personally, I like simple and elegant
solutions. With it's implementation requirements, C++ is definitely a pile
driver in comparison. (Please remember though that I like C++ a lot. I may
be getting a bit long in the tooth though). I think C++ has evolved into
some kind of "end" instead of the "means" it should be/should have been.

for some good arguments. In my opinion, the inability to use the
standard library or any form of generic programming is a huge retrograde
step.

It kinda bothers me that there is only one. Seems stifling. I just wonder
what else could be (and even could have been) if all the eggs weren't in one
basket.

>>>If you want to use a small subset of C++, do
just that. The last thing the world wants is yet another bastardised
language.

Sounds like passion rather than objectivity.

I'd say its the truth. Languages evolve for a reason.

Surely more than ONE reason. Was that a freudian? ;)

>>>cfront is an historical artefact, we have moved on.

Or "stagnated"? :P Dish it out and take it. LOL. To someone wishing to
create "a better C++" and not wanting to reinvent the wheel, cfront may
save
some people some time.

But why bother? We have been there and moved on.

I don't think anyone "has been there" because at some point in the early
evolution, there could have been other roads to take (forks in the road!),
but the one that was chosen was the current one. So I'm curious about what's
down those other paths. And yes, I've read D&E, pretty much when it was
first published. And I agree with most of it. A lot came after that though.

I've used cfront
compilers, they were a good thing in their day, giving a better C. But
users wanted more, so the language grew to meet the demand, not just for
the sake of growing.

Well I'm not suggesting anyone go back to cfront and call it a day. I too
don't see any reason to make C an intermediate language between the C++ code
and the assembler/machine code. If I was a language implementer (pseudo
compiler developer), I think I'd want to play around with cfront though. I
guess I'm thinking (aside, now) about language development tools. Stroustrup
translated into C, which was good solution that allowed him to experiment
with his ideas. Is there something else now? Or could cfront be useful to
language designers/creators/experimentors? If so, maybe HP would like to
open source theirs?

John

[JohnQ]

"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:5e***************************@KNOLOGY.NET...

"JohnQ" <jo***********************@yahoo.comwrote in message
news:Kc*****************@newssvr19.news.prodigy.ne t...

>>
"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:43***************************@KNOLOGY.NET. ..

"JohnQ" <jo***********************@yahoo.comwrote in message
news:AQ****************@newssvr23.news.prodigy.net ...
(The "C++ Grammer" thread in comp.lang.c++.moderated prompted this

post).

>>
It would be more than a little bit nice if C++ was much "cleaner"
(less
complex) so that it wasn't a major world wide untaking to create a
toolchain
for it. Way back when, there used to be something called "Small C". I
wonder
if the creator(s) of that would want to embark on creating a nice

little

>Small C++ compiler devoid of C++ language features that make toolchain
(including the compiler) a nightmare to implement (?). Yes, I realize
that
would be a subset or a "dialect" of C++. Or not! They could call it
something else and avoid all the flak from the "use all of C++ all of

the

>time" proponents. I'd try and tackle that myself if I had another 100
years
to live. Alas, I don't so I have to stay focused on what I can produce

at

a
higher level of usage instead of diving into something new and so low
level.

A "new" clean "little" language that is wholly a subset of C++ but is
tremendously easier to implement and to create a toolchain for. That's
the
ticket! Could something like that "put C++ out of business"?

I think the very things that make C++ hard to implement (e.g.
templates,
namespaces) would wind up being requested or added to the "Small-C++"

over

time.

No, of course they wouldn't. Otherwise there would be no sense in
creating
"Small C++": you'd have Std C++! Perhaps fresh and new ideas would be

added

>though, where they cannot be in Std C++ because of the constraint of
backward compatibility and resistance to reconsider (or throw away) what

has

>already been implemented (read, C++ is stagnating as an evolving language

in

Templates (generics) solve a nice set of real-world problems.
I'd expect that, were this not a part of "small-c++" a tempalte/generic
sort
of mechanism would be rather quickly requested.

I tend to agree with you. But maybe newly considered with implementation
criteria? Maybe the current templates are the 100% solution, but maybe some
would opt for the 80% solution knowing that the implementation is simple and
elegant not requiring many man years of effort to figure out how to
implement them.

Same with namespaces.

For something seemingly so "wrapped around everything else", I am very
surprised to learn that implementing namespaces is difficult.

John

[JohnQ]

"Ian Collins" <ia******@hotmail.comwrote in message
news:55**************@mid.individual.net...

JohnQ wrote:

>"Ian Collins" <ia******@hotmail.comwrote in message
news:55**************@mid.individual.net...

>>>
gcc is available just about everywhere.

But, I assume, pretty unapproachable at the source code level. You see,
the
whole point is to not have to wade through the mud of complexity for
features that are undesireably in "Small C++".

It's not too bad. I have worked on a port ans once you get into the
code, it isn't any worse than any other code base.

>>

>>>C is a very simple language,
how many people bother to compete in the C toolchain market? Answer,
not many, it is too full. Just about every platform has a proprietary C
compiler as well as gcc. There isn't the demand for alternatives.

You won't really know that until you create "that other thing", now will
you.

Can you name any EC++ only compliers, that is ones that aren't part of a
tool suite that includes a full C++ compiler? If no one wants a
standardised subset, who's going to want an ad hoc one?

Well I certainly didn't suggest that EC++ would be enough to make it
compelling. That (or something close to that) may be the starting point of
"the fork in the road" though. Do you see what I mean?

John

[Ian Collins]

JohnQ wrote:

"Ian Collins" <ia******@hotmail.comwrote in message
news:55**************@mid.individual.net...

>>JohnQ wrote:

>>>"Ian Collins" <ia******@hotmail.comwrote in message
news:55**************@mid.individual.net...

EC++ is an abomination.

Why?

See

http://www.research.att.com/~bs/bs_faq.html#EC++

I've read that a few times. And every time I do, I have to say "take it with
a grain of salt". Because he's "in the box" rather than outside of it. (No
offense Bjarne!). Perhaps only because "I don't know any better". But ya
never know until you try. It sounds to me it went something like this:
multi-million dollar capable implementors applauded it, but that left out
those who could not enter the market at that level.

gcc is a $0 implementation.

Is it necessarilly
complex or designed to be complex? Personally, I like simple and elegant
solutions. With it's implementation requirements, C++ is definitely a pile
driver in comparison. (Please remember though that I like C++ a lot. I may
be getting a bit long in the tooth though). I think C++ has evolved into
some kind of "end" instead of the "means" it should be/should have been.

Don't mistake the language with its use, something which can be an
elegant one liner in C++ would be an inelegant mess in assembler. The
better a language enables the programmer to express abstract concepts,
the more elegant the programmers solution will be.

>

>>for some good arguments. In my opinion, the inability to use the
standard library or any form of generic programming is a huge retrograde
step.

It kinda bothers me that there is only one. Seems stifling. I just wonder
what else could be (and even could have been) if all the eggs weren't in one
basket.

Feel free to roll your own, but either way, it will come down to templates.

--
Ian Collins.

[Dave Rahardja]

On Sat, 10 Mar 2007 18:44:59 -0600, "JohnQ"
<jo***********************@yahoo.comwrote:

>
"kwikius" <an**@servocomm.freeserve.co.ukwrote in message
news:11*********************@64g2000cwx.googlegro ups.com...

>On 9 Mar, 22:06, "JohnQ" <[e-mail]:

>>A "new" clean "little" language that is wholly a subset of C++ but is
tremendously easier to implement and to create a toolchain for. That's
the
ticket! Could something like that "put C++ out of business"?

AFAICS there are 2 approaches to programming language design. Either
make it for the compiler writer, or make it for the user.

Beyond those "only 2" are good engineering that considers all the aspects
and creates something practical, elegantly simple. Your "there are only 2
approaches" is myopic or extremism: only seeing endpoints rather than a
range or continuum of possibility. I think maybe C++ suffers from "gold
plating" (the excess functionality of templates for example).

I admire your enthusiasm, but I am more than a little amused by your naivet.
You're not the first one to want to make a better mousetrap, and you've fallen
into the trap of seeing "a good subset" as the one that works best _for you_.

To me, a complex language such as C++ is the result of a process to conquer
complexity. It is there to capture and express concepts that reflect the
complex nature of programming. Chopping up the standard to a subset will
likely mean excluding certain programming domains as well.

C++ is very economical in its specification. Although it is difficult to
implement a compiler for it, the difficulty lies in the problem domain that
the language addresses, and not in the language itself. Again, I challenge you
to excise portions of the language and not end up excluding certain
programming domains as well.

Making things easier for compiler writers is hardly a worthy goal if it comes
at the expense of the users of the language, and it doesn't even make economic
sense. Look: Assembly language is probably the simplest language to write a
compiler for, yet you don't see scads of competition in that field. C is much
simpler to compile, yet there are about as many C compiler vendors as C++.
Programmers buy tools that help them solve _their_ problems, not the compiler
vendor's.

Of course, I could be mistaken and you could be a genius. However, I'd like to
see some concrete examples of how you would "simplify" the language before I'm
convinced.

-dr

[Dennis \(Icarus\)]

"JohnQ" <jo***********************@yahoo.comwrote in message
news:GV*****************@newssvr13.news.prodigy.ne t...

>
"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:5e***************************@KNOLOGY.NET...

"JohnQ" <jo***********************@yahoo.comwrote in message
news:Kc*****************@newssvr19.news.prodigy.ne t...

>
"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:43***************************@KNOLOGY.NET...
"JohnQ" <jo***********************@yahoo.comwrote in message
news:AQ****************@newssvr23.news.prodigy.net ...
(The "C++ Grammer" thread in comp.lang.c++.moderated prompted this

post).

>
It would be more than a little bit nice if C++ was much "cleaner"
(less
complex) so that it wasn't a major world wide untaking to create a
toolchain
for it. Way back when, there used to be something called "Small C".

I

wonder
if the creator(s) of that would want to embark on creating a nice

little

Small C++ compiler devoid of C++ language features that make

toolchain

(including the compiler) a nightmare to implement (?). Yes, I

realize

that
would be a subset or a "dialect" of C++. Or not! They could call it
something else and avoid all the flak from the "use all of C++ all

of

the

time" proponents. I'd try and tackle that myself if I had another

100

years
to live. Alas, I don't so I have to stay focused on what I can

produce

at

a
higher level of usage instead of diving into something new and so

low

level.

A "new" clean "little" language that is wholly a subset of C++ but

is

tremendously easier to implement and to create a toolchain for.

That's

the
ticket! Could something like that "put C++ out of business"?

I think the very things that make C++ hard to implement (e.g.
templates,
namespaces) would wind up being requested or added to the "Small-C++"

over

time.

No, of course they wouldn't. Otherwise there would be no sense in
creating
"Small C++": you'd have Std C++! Perhaps fresh and new ideas would be

added

though, where they cannot be in Std C++ because of the constraint of
backward compatibility and resistance to reconsider (or throw away)

what

has

already been implemented (read, C++ is stagnating as an evolving

language

in

Templates (generics) solve a nice set of real-world problems.
I'd expect that, were this not a part of "small-c++" a tempalte/generic
sort
of mechanism would be rather quickly requested.

I tend to agree with you. But maybe newly considered with implementation
criteria? Maybe the current templates are the 100% solution, but maybe

some

would opt for the 80% solution knowing that the implementation is simple

and

elegant not requiring many man years of effort to figure out how to
implement them.

IIRC, some of the complexity for the compiler writer (partial template
specialization?) eased the implementation of the C++ standard library
container classes.

>

Same with namespaces.

For something seemingly so "wrapped around everything else", I am very
surprised to learn that implementing namespaces is difficult.

It may not be. Just that if absent, it'd soon be requested to resolve
conflicts.

Dennis

[Ira Baxter]

"JohnQ" <jo***********************@yahoo.comwrote in message
news:AQ****************@newssvr23.news.prodigy.net ...

(The "C++ Grammer" thread in comp.lang.c++.moderated prompted this post).

It would be more than a little bit nice if C++ was much "cleaner" (less
complex) so that it wasn't a major world wide untaking to create a

toolchain

for it. ...

If you want to program in a fresh new language, you are welcome to do this.
Most of the world wants to program in languages for which there are already
tools: compilers, debuggers, IDES, ..., or are forced to program in
languages
that somebody chose for the current application sometime in the past.

If you follow that line of thought, you really have to build toolchains for
the langauges
in use. And yes, C++ is a royal pain (worse because it comes in 11
different
flavors, and each flavor changes a bit every year, ... how many dialects
of C++ has MS offered...?)

It does take a "world-wide undertaking" to make a tool chain for real
languages
like C++ and all the dialects. The approach we took was to build a
tool-chain generator,
so that we could build tools for a variety of langauges, and thus amortize
the cost for everybody. You can build your tool on top of ours,
for quite a wide variety of tools.

See http://www.semdesign.com/Products/Fr...pFrontEnd.html
--
Ira Baxter, CTO
www.semanticdesigns.com

[Adrian Hawryluk]

Ira Baxter wrote:

[snip]
See http://www.semdesign.com/Products/Fr...pFrontEnd.html

The link doesn't work, and your entire site seems to be in flash. Yuck!
Adrian

--
================================================== ========
Adrian Hawryluk BSc. Computer Science
----------------------------------------------------------
Specialising in: OOD Methodologies in UML
OOP Methodologies in C, C++ and more
RT Embedded Programming
__--------------------------------------------------__
----- [blog: http://adrians-musings.blogspot.com/] -----
'--------------------------------------------------------'
My newsgroup writings are licensed under the Creative
Commons Attribution-Noncommercial-Share Alike 3.0 License
http://creativecommons.org/licenses/by-nc-sa/3.0/
================================================== ========

[Roberto Waltman]

"JohnQ" wrote:

>... creating a nice little
Small C++ compiler devoid of C++ language features that make toolchain
(including the compiler) a nightmare to implement (?).
...

Somebody already did. "Lightweight C++":

http://students.ceid.upatras.gr/~sxanth/lwc/

It seems the author moved on to other interests, (the mailing list
carries little traffic, mostly spam)

I though of doing something like this myself, at the time when C++
compilers were not as common as today. (In particular for the 8 bit
processors I worked with.) Never got started since either g++ or
proprietary compilers were available for almost all processors I have
used in the last 10 years.

You may take a look at Objective-C, as an easier to implement language
if you give up C++ compatibility.

Roberto Waltman

[ Please reply to the group,
return address is invalid ]

[JohnQ]

"Ian Collins" <ia******@hotmail.comwrote in message
news:55**************@mid.individual.net...

JohnQ wrote:

>It kinda bothers me that there is only one. Seems stifling. I just wonder
what else could be (and even could have been) if all the eggs weren't in
one
basket.

Feel free to roll your own, but either way, it will come down to
templates.

Well that's the first time I've seen someone wrap up the value of C++ into
just one of its features. Interesting. I know templates get a lot of
newsgroup space, but still.

John

[JohnQ]

"Dave Rahardja" <dr****************************@pobox.comwrote in message
news:qd********************************@4ax.com...

On Sat, 10 Mar 2007 18:44:59 -0600, "JohnQ"
<jo***********************@yahoo.comwrote:

>>
"kwikius" <an**@servocomm.freeserve.co.ukwrote in message
news:11*********************@64g2000cwx.googlegr oups.com...

>>On 9 Mar, 22:06, "JohnQ" <[e-mail]:

A "new" clean "little" language that is wholly a subset of C++ but is
tremendously easier to implement and to create a toolchain for. That's
the
ticket! Could something like that "put C++ out of business"?

AFAICS there are 2 approaches to programming language design. Either
make it for the compiler writer, or make it for the user.

Beyond those "only 2" are good engineering that considers all the aspects
and creates something practical, elegantly simple. Your "there are only 2
approaches" is myopic or extremism: only seeing endpoints rather than a
range or continuum of possibility. I think maybe C++ suffers from "gold
plating" (the excess functionality of templates for example).

I admire your enthusiasm, but I am more than a little amused by your
naivet.
You're not the first one to want to make a better mousetrap, and you've
fallen
into the trap of seeing "a good subset" as the one that works best _for
you_.

Indeed. So at what point does a language become too unwieldy by trying to be
all things to all people?

To me, a complex language such as C++ is the result of a process to
conquer
complexity. It is there to capture and express concepts that reflect the
complex nature of programming. Chopping up the standard to a subset will
likely mean excluding certain programming domains as well.

Just hiding the complexity or shifting it over to another group of people
(compiler developers) doesn't seem optimimum at all.

C++ is very economical in its specification. Although it is difficult to
implement a compiler for it, the difficulty lies in the problem domain
that
the language addresses, and not in the language itself. Again, I challenge
you
to excise portions of the language and not end up excluding certain
programming domains as well.

Well maybe "domain-specific languages" are a potential solution.

Making things easier for compiler writers is hardly a worthy goal if it
comes
at the expense of the users of the language, and it doesn't even make
economic
sense.

I don't know what the range of possibility is. Is there some kind of "80% of
the way there point" that would be a better compromise?

Look: Assembly language is probably the simplest language to write a
compiler for, yet you don't see scads of competition in that field. C is
much
simpler to compile, yet there are about as many C compiler vendors as C++.
Programmers buy tools that help them solve _their_ problems, not the
compiler
vendor's.

Of course, I could be mistaken and you could be a genius. However, I'd
like to
see some concrete examples of how you would "simplify" the language before
I'm
convinced.

I'm not sure I didn't just "one up" myself by bringing in the concept of
domain-specific languages. On the flip side, I don't have the resources to
go off on such an R&D quest (beyond all the time I've got into it already
that is).

John

[Ian Collins]

JohnQ wrote:

"Ian Collins" <ia******@hotmail.comwrote in message
news:55**************@mid.individual.net...

>>JohnQ wrote:

>>>It kinda bothers me that there is only one. Seems stifling. I just wonder
what else could be (and even could have been) if all the eggs weren't in
one
basket.

Feel free to roll your own, but either way, it will come down to
templates.

Well that's the first time I've seen someone wrap up the value of C++ into
just one of its features. Interesting. I know templates get a lot of
newsgroup space, but still.

Don't quote me out of context. The bit you removed was, in reference to
EC++:

"In my opinion, the inability to use the standard library or any form of
generic programming is a huge retrograde step."

EC++ removed templates, stripping the language of one of its core
components and forcing users to reinvent everything in the C++ standard
library.

A language with a strong type system, but without any form of generics
is doomed.

--
Ian Collins.

[JohnQ]

"Roberto Waltman" <us****@rwaltman.netwrote in message
news:38********************************@4ax.com...

"JohnQ" wrote:

>>... creating a nice little
Small C++ compiler devoid of C++ language features that make toolchain
(including the compiler) a nightmare to implement (?).
...

Somebody already did. "Lightweight C++":

http://students.ceid.upatras.gr/~sxanth/lwc/

He appears to have "created" another cfront! The one good thing about
requiring C as intermediate code is that it inherently limits complexity.
Giving someone the whole compiler space to create in will result in pushing
complexity to the limit (no limit!) of native implementation. That's what
happened with C++? Also, the complexity and lack of standards at the
implementaion level wreaks havoc with binary compatibility (read, there is
no compatibility). Instead of trying to make implementations binary
compatible after giant complex things have been built, wouldn't that have
been a good criteria the the outset? I understand that existing code bases
are tied to the complexity they built on top of. For new development though,
given the lessons learned (and still being learned) from C++, a new (well,
not entirely new at all, --C++? ;) ) language makes sense, IMO. Surely some
codebases would also migrate if there was value. Rreduced software
maintenance costs surely would be on such possibility for migration.

You may take a look at Objective-C, as an easier to implement language
if you give up C++ compatibility.

I don't think that drastic of a departure is necessary or desireable.

John

[JohnQ]

"Ira Baxter" <id******@semdesigns.comwrote in message
news:et********@enews4.newsguy.com...

"JohnQ" <jo***********************@yahoo.comwrote in message
news:AQ****************@newssvr23.news.prodigy.net ...

>(The "C++ Grammer" thread in comp.lang.c++.moderated prompted this post).

It would be more than a little bit nice if C++ was much "cleaner" (less
complex) so that it wasn't a major world wide untaking to create a

toolchain

>for it. ...

It does take a "world-wide undertaking" to make a tool chain for real
languages
like C++ and all the dialects. The approach we took was to build a
tool-chain generator,
so that we could build tools for a variety of langauges, and thus amortize
the cost for everybody. You can build your tool on top of ours,
for quite a wide variety of tools.

See http://www.semdesign.com/Products/Fr...pFrontEnd.html

How would that not be just building upon the existing complexity though? (It
wouldn't).

John

[JohnQ]

"Ian Collins" <ia******@hotmail.comwrote in message
news:55*************@mid.individual.net...

JohnQ wrote:

>"Ian Collins" <ia******@hotmail.comwrote in message
news:55**************@mid.individual.net...

>>>JohnQ wrote:

>>>>It kinda bothers me that there is only one. Seems stifling. I just
wonder
what else could be (and even could have been) if all the eggs weren't in
one
basket.
Feel free to roll your own, but either way, it will come down to
templates.

Well that's the first time I've seen someone wrap up the value of C++
into
just one of its features. Interesting. I know templates get a lot of
newsgroup space, but still.

Don't quote me out of context. The bit you removed was, in reference to
EC++:

"In my opinion, the inability to use the standard library or any form of
generic programming is a huge retrograde step."

EC++ removed templates, stripping the language of one of its core
components and forcing users to reinvent everything in the C++ standard
library.

I thought the STL was controversial anyway (?): some like it and use it,
some don't like it but use it, others don't like it and don't use it. I
did't miquote you: you are implying that templates are pivotal/most
important. Perhaps if you see everything as a template (if you just have a
hammer...). I didn't suggest removing templates or any of the things that
EC++ takes away for that matter. I only suggested that going back to that
point may be a good starting point to do things better (or, yes, perhaps
indeed eliminate some things). Do I think that the template concept in its
present incarnation would survive the axe if I was doing the chopping, no.
Just jettisoning backward compatibility may be a boon.

A language with a strong type system, but without any form of generics
is doomed.

Well that's not to say that the highly intricate C++ implementation is the
only way to skin that cat. Maybe it's just the large target market of C++
that makes some of those things so difficult and not the concepts at all.

John

[Ian Collins]

JohnQ wrote:

"Ian Collins" <ia******@hotmail.comwrote in message
news:55*************@mid.individual.net...

>>JohnQ wrote:

>>>"Ian Collins" <ia******@hotmail.comwrote in message
news:55**************@mid.individual.net...
JohnQ wrote:

>It kinda bothers me that there is only one. Seems stifling. I just
>wonder
>what else could be (and even could have been) if all the eggs weren't in
>one
>basket.
>

Feel free to roll your own, but either way, it will come down to
templates.

Well that's the first time I've seen someone wrap up the value of C++
into
just one of its features. Interesting. I know templates get a lot of
newsgroup space, but still.

Don't quote me out of context. The bit you removed was, in reference to
EC++:

"In my opinion, the inability to use the standard library or any form of
generic programming is a huge retrograde step."

EC++ removed templates, stripping the language of one of its core
components and forcing users to reinvent everything in the C++ standard
library.

I did't miquote you: you are implying that templates are pivotal/most
important.

Nonsense, I was saying that EC++ made a huge mistake in removing
templates and the standard library. This sub-thread started when you
asked my why I consider EC++ to be an abomination, I answered that question.

--
Ian Collins.

[Walter Bright]

JohnQ wrote:

I'm not suggesting changing C++,
but rather deriving a new, VERY C++-like language.

And one exists, it's the D programming language. There's even a GPL open
source version of it (GDC).

-Walter
Digital Mars
http://www.digitalmars.com/d/ The D Programming Language

[JohnQ]

"Ian Collins" <ia******@hotmail.comwrote in message
news:55*************@mid.individual.net...

JohnQ wrote:

>"Ian Collins" <ia******@hotmail.comwrote in message
news:55*************@mid.individual.net...

>>>JohnQ wrote:

"Ian Collins" <ia******@hotmail.comwrote in message
news:55**************@mid.individual.net...
>JohnQ wrote:

>>It kinda bothers me that there is only one. Seems stifling. I just
>>wonder
>>what else could be (and even could have been) if all the eggs weren't
>>in
>>one
>>basket.
>>
>
>Feel free to roll your own, but either way, it will come down to
>templates.

Well that's the first time I've seen someone wrap up the value of C++
into
just one of its features. Interesting. I know templates get a lot of
newsgroup space, but still.
Don't quote me out of context. The bit you removed was, in reference to
EC++:

"In my opinion, the inability to use the standard library or any form of
generic programming is a huge retrograde step."

EC++ removed templates, stripping the language of one of its core
components and forcing users to reinvent everything in the C++ standard
library.

I did't miquote you: you are implying that templates are pivotal/most
important.

Nonsense, I was saying that EC++ made a huge mistake in removing
templates and the standard library. This sub-thread started when you
asked my why I consider EC++ to be an abomination, I answered that
question.

But I was responding to where you said the following:

"Feel free to roll your own, but either way, it will come down to
templates."

Whatever context it is in, to me, that sounds like you think templates are
paramount: the maker/breaker of the success of any new language.

John

[JohnQ]

"Walter Bright" <wa****@digitalmars-nospamm.comwrote in message
news:r7******************************@comcast.com. ..

JohnQ wrote:

>I'm not suggesting changing C++, but rather deriving a new, VERY C++-like
language.

And one exists, it's the D programming language. There's even a GPL open
source version of it (GDC).

I took a cursory look at it awhile back and gathered that it was a drastic
departure from C++ and of "equivalent" implementation complexity. Hardly a
"simple" language that is "easy" to implement. Rather than say D is "a
better C++", I'd say that it is _another_ C++ (I gather that from the
cursory look). I think that by "simple", I mean, for one thing, moving the
line dividing language and tools. My "guess" is that D moves in the opposite
direction from what I would opt for.

John

[Ian Collins]

JohnQ wrote:

>
But I was responding to where you said the following:

"Feel free to roll your own, but either way, it will come down to
templates."

Whatever context it is in, to me, that sounds like you think templates are
paramount: the maker/breaker of the success of any new language.

Well I don't.

End of thread.

--
Ian Collins.

[Dave Rahardja]

On Mon, 12 Mar 2007 15:52:46 -0500, "JohnQ"
<jo***********************@yahoo.comwrote:

>I admire your enthusiasm, but I am more than a little amused by your
naivet.
You're not the first one to want to make a better mousetrap, and you've
fallen
into the trap of seeing "a good subset" as the one that works best _for
you_.

Indeed. So at what point does a language become too unwieldy by trying to be
all things to all people?

When its _users_ find it difficult to express the solution to their problem,
not its compiler writers.

>To me, a complex language such as C++ is the result of a process to
conquer
complexity. It is there to capture and express concepts that reflect the
complex nature of programming. Chopping up the standard to a subset will
likely mean excluding certain programming domains as well.

Just hiding the complexity or shifting it over to another group of people
(compiler developers) doesn't seem optimimum at all.

Sure it is. There are many more users than there are compiler writers. Fewer
people dealing with complexity is more economical than lots of people dealing
with complexity.

>C++ is very economical in its specification. Although it is difficult to
implement a compiler for it, the difficulty lies in the problem domain
that
the language addresses, and not in the language itself. Again, I challenge
you
to excise portions of the language and not end up excluding certain
programming domains as well.

Well maybe "domain-specific languages" are a potential solution.

Domain-specific languages are by definition not general-purpose languages. One
of C++'s strengths is that it is a general-purpose language.

On the other hand, see "C++ Template Metaprogramming" by Abrahams and Gurtovoy
to see how DSELs (domain specific embedded languages) can be implemented using
template metaprogramming within C++.

>Making things easier for compiler writers is hardly a worthy goal if it
comes
at the expense of the users of the language, and it doesn't even make
economic
sense.

I don't know what the range of possibility is. Is there some kind of "80% of
the way there point" that would be a better compromise?

C++ _is_ a compromise.

>I'm not sure I didn't just "one up" myself by bringing in the concept of
domain-specific languages. On the flip side, I don't have the resources to
go off on such an R&D quest (beyond all the time I've got into it already
that is).

You didn't.

This thread has come a long way without you giving an example of something
that you would excise from the language and how it would benefit the
programming community at large (not just the compiler writers, who are a very
small part of the programming community). Do you have an example?
-dr

[Walter Bright]

JohnQ wrote:

"Walter Bright" <wa****@digitalmars-nospamm.comwrote in message
news:r7******************************@comcast.com. ..

>JohnQ wrote:

>>I'm not suggesting changing C++, but rather deriving a new, VERY C++-like
language.

And one exists, it's the D programming language. There's even a GPL open
source version of it (GDC).

I took a cursory look at it awhile back and gathered that it was a drastic
departure from C++ and of "equivalent" implementation complexity.

Since I've implemented both a C++ and a D compiler, I can
authoritatively say that a D compiler is much simpler to implement.
Heck, it takes 3 years to just do one C++ feature (exported templates).
You can write a whole D front end in that time (though you don't have
to, since the front end is open source).

Hardly a "simple" language that is "easy" to implement.

Relative to C++, it's easy to implement.

Rather than say D is "a
better C++", I'd say that it is _another_ C++ (I gather that from the
cursory look). I think that by "simple", I mean, for one thing, moving the
line dividing language and tools. My "guess" is that D moves in the opposite
direction from what I would opt for.

I think you'll find that there is no market for a "C++ lite". People who
use C++ tend to want all of it sooner or later. And my experience with D
is that the more powerful it becomes, the more people use it.

[Walter Bright]

Dave Rahardja wrote:

C++ is very economical in its specification. Although it is difficult to
implement a compiler for it, the difficulty lies in the problem domain that
the language addresses, and not in the language itself.

There is a lot of complexity in C++ that exists not to serve the problem
domain but to be backwards compatible with design decisions made 20-25
years ago. If you're willing to give up backwards source compatibility,
a lot of simplification can be done that does not give up the problem
domain.

Here's one small example: the use of < to delineate template
arguments. It results in grammatical ambiguities, with wacky kludges to
work around them, and adds no power.

Here's a one huge example: exported templates. EDG reports taking 3 man
years just to implement that, whereas if C++ used a module system, then
one gets exported templates for free.

Again, I challenge you
to excise portions of the language and not end up excluding certain
programming domains as well.

I think D demonstrates that the preprocessor can be excised.

Making things easier for compiler writers is hardly a worthy goal if it comes
at the expense of the users of the language, and it doesn't even make economic
sense.

C++'s implementation difficulties have caused C++ users a decade of
troubles with incompatible, incomplete implementations. Being hard to
implement most definitely affects users in a negative way.

Look: Assembly language is probably the simplest language to write a
compiler for, yet you don't see scads of competition in that field. C is much
simpler to compile, yet there are about as many C compiler vendors as C++.
Programmers buy tools that help them solve _their_ problems, not the compiler
vendor's.

The advent of C++ saw a major shrinkage in the number of compiler
vendors - at one point in the 80's there were 30 (thirty) C compiler
vendors for the IBM PC. Where are they now? The implementation
difficulties of C++ were a factor in putting them out of business. Fewer
vendors is not to the users' benefit.

Of course, I could be mistaken and you could be a genius. However, I'd like to
see some concrete examples of how you would "simplify" the language before I'm
convinced.

Here are some things that can be simplified:
http://www.digitalmars.com/d/template-comparison.html

[JohnQ]

"Walter Bright" <wa****@digitalmars-nospamm.comwrote in message
news:3d******************************@comcast.com. ..

Dave Rahardja wrote:

There is a lot of complexity in C++ that exists not to serve the problem
domain but to be backwards compatible with design decisions made 20-25
years ago. If you're willing to give up backwards source compatibility, a
lot of simplification can be done that does not give up the problem
domain.

Here's one small example: the use of < to delineate template arguments.
It results in grammatical ambiguities, with wacky kludges to work around
them, and adds no power.

Here's a one huge example: exported templates. EDG reports taking 3 man
years just to implement that, whereas if C++ used a module system, then
one gets exported templates for free.

OK, now there's some answer to the question I posed to you in another post.
I had a feeling that backward compatibility (jettisoning it) was an area to
look at. D is a "more is more" language rather than a "less is better" one
though. I'd be more inclined to "jump ship" from C++ if it was the latter.
And I'd categorize some of the major features in D as things to build with a
language rather then things to build into the language. So I'm still hoping
for a "Small C++" (and no, I don't think I'll personally be embarking on
such a project).

John

[JohnQ]

"Walter Bright" <wa****@digitalmars-nospamm.comwrote in message
news:Jp******************************@comcast.com. ..

JohnQ wrote:

>"Walter Bright" <wa****@digitalmars-nospamm.comwrote in message
news:r7******************************@comcast.com ...

>>JohnQ wrote:
I'm not suggesting changing C++, but rather deriving a new, VERY
C++-like language.
And one exists, it's the D programming language. There's even a GPL open
source version of it (GDC).

I took a cursory look at it awhile back and gathered that it was a
drastic departure from C++ and of "equivalent" implementation complexity.

Since I've implemented both a C++ and a D compiler, I can authoritatively
say that a D compiler is much simpler to implement. Heck, it takes 3 years
to just do one C++ feature (exported templates). You can write a whole D
front end in that time (though you don't have to, since the front end is
open source).

>Hardly a "simple" language that is "easy" to implement.

Relative to C++, it's easy to implement.

Why would implementing the same or similar features for D be easier than for
C++?

>

>Rather than say D is "a better C++", I'd say that it is _another_ C++ (I
gather that from the cursory look). I think that by "simple", I mean, for
one thing, moving the line dividing language and tools. My "guess" is
that D moves in the opposite direction from what I would opt for.

I think you'll find that there is no market for a "C++ lite". People who
use C++ tend to want all of it sooner or later. And my experience with D
is that the more powerful it becomes, the more people use it.

John

[JohnQ]

"Dave Rahardja" <dr****************************@pobox.comwrote in message
news:lm********************************@4ax.com...

On Mon, 12 Mar 2007 15:52:46 -0500, "JohnQ"
<jo***********************@yahoo.comwrote:

>>I admire your enthusiasm, but I am more than a little amused by your
naivet.
You're not the first one to want to make a better mousetrap, and you've
fallen
into the trap of seeing "a good subset" as the one that works best _for
you_.

Indeed. So at what point does a language become too unwieldy by trying to
be
all things to all people?

When its _users_ find it difficult to express the solution to their
problem,
not its compiler writers.

C++ is already difficult to learn, use and maintain. I disagree about
implementation not being a concern.

>>To me, a complex language such as C++ is the result of a process to
conquer
complexity. It is there to capture and express concepts that reflect the
complex nature of programming. Chopping up the standard to a subset will
likely mean excluding certain programming domains as well.

Just hiding the complexity or shifting it over to another group of people
(compiler developers) doesn't seem optimimum at all.

Sure it is. There are many more users than there are compiler writers.
Fewer
people dealing with complexity is more economical than lots of people
dealing
with complexity.

And of course minimizing the complexity is the best solution of all.

>>C++ is very economical in its specification. Although it is difficult to
implement a compiler for it, the difficulty lies in the problem domain
that
the language addresses, and not in the language itself. Again, I
challenge
you
to excise portions of the language and not end up excluding certain
programming domains as well.

Well maybe "domain-specific languages" are a potential solution.

Domain-specific languages are by definition not general-purpose languages.
One
of C++'s strengths is that it is a general-purpose language.

Depends on the granularity of "domain". ("domain" != industry verticals the
way I was using it).

On the other hand, see "C++ Template Metaprogramming" by Abrahams and
Gurtovoy
to see how DSELs (domain specific embedded languages) can be implemented
using
template metaprogramming within C++.

I'll pass on that one (!).

>>Making things easier for compiler writers is hardly a worthy goal if it
comes
at the expense of the users of the language, and it doesn't even make
economic
sense.

I don't know what the range of possibility is. Is there some kind of "80%
of
the way there point" that would be a better compromise?

C++ _is_ a compromise.

Well probably not to the degree that I'd prefer then.

>>I'm not sure I didn't just "one up" myself by bringing in the concept of
domain-specific languages. On the flip side, I don't have the resources to
go off on such an R&D quest (beyond all the time I've got into it already
that is).

You didn't.

Trust me, I did.

This thread has come a long way without you giving an example of something
that you would excise from the language and how it would benefit the
programming community at large (not just the compiler writers, who are a
very
small part of the programming community). Do you have an example?

Yes, but I didn't start the thread to discuss the details (that always gets
into those round-and-round discussions). Someone said there was no market
for a "C++ lite". Well then why do I want it? Maybe because I have a certain
"domain" in mind. Time will tell.

John

[Ed Jensen]

Walter Bright <wa****@digitalmars-nospamm.comwrote:

And one exists, it's the D programming language. There's even a GPL open
source version of it (GDC).

At one point in time, you were considering a D to C translator. Are
you still considering it? I'm asking for two reasons:

1. I'd like to try using D for a certain project, but I'll be
targeting multiple platforms, including one that D doesn't support
and likely won't for quite some time (if ever). If I could convert
D to C, I could target that additional platform, as well.

2. It would reduce the risk my colleagues perceive of using D. That
is, if D went away tomorrow, they feel the risk would be reduced
because we could always fall back on the translated C code (even
though we're aware the translated code may be ugly).

[Walter Bright]

JohnQ wrote:

"Walter Bright" <wa****@digitalmars-nospamm.comwrote in message
news:Jp******************************@comcast.com. ..

>JohnQ wrote:

>>Hardly a "simple" language that is "easy" to implement.

Relative to C++, it's easy to implement.

Why would implementing the same or similar features for D be easier than for
C++?

For one thing, using !( ) for template arguments delineation rather than
< means a lot less complexity in the parser, because there are no
ambiguities with the former. I already mentioned how having imports
gives one exported templates for free, rather than taking an extra 3
years to implement.