"Small C++" Anyone?

[JohnQ]

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

 

[Ira Baxter]

Should have been:
http://www.semdesigns.com/Products/FrontEnds/CppFrontEnd.html

.... in Flash?

-- IDB

[snip]
See http://www.semdesign.com/Products/FrontEnds/CppFrontEnd.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/
==========================================================

 

[Ian Collins]

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.

 

[Dave Rahardja]

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.

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.

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

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]

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]

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]

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]

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


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

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

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]

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.

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.

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 (!).

C++ _is_ a compromise.

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

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]

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]

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.

 

[JohnQ]

For one thing, using !( ) for template arguments delineation rather than <
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.

I'm not sure what "exported" templates are. Can you quanitify the effort of
implementing templates overall (perhaps without "exported" ones) for D and
C++? (A ballpark estimate is fine).

John

 

[Walter Bright]

I'm not sure what "exported" templates are.

2nd google hit: http://www.comeaucomputing.com/4.0/docs/userman/export.html

Can you quanitify the effort of
implementing templates overall (perhaps without "exported" ones) for D and
C++? (A ballpark estimate is fine).

D - a few months
C++ - a few years (even without export)

 

[Walter Bright]

At one point in time, you were considering a D to C translator. Are
you still considering it?

No. Expressing certain things in C is pretty difficult, like:
1) exception handling
2) COMDATs

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

Since the Gnu D Compiler (GDC) works with the gnu compiler collection
(gcc), a port of GDC to any platform that gcc supports should be
straightforward. There is a newsgroup devoted to this, and you should be
able to find help if you get stuck.

 

[JohnQ]

2nd google hit:
http://www.comeaucomputing.com/4.0/docs/userman/export.html




D - a few months
C++ - a few years (even without export)

And why is that? Less functionality/requirements in D's templates?

John

 

[JohnQ]

No. Expressing certain things in C is pretty difficult, like:
1) exception handling

I didn't see anything about error processing on the mars site. What does D
provide in the way of error processing machinery?

John

 

[Alf P. Steinbach]

* JohnQ:

And why is that? Less functionality/requirements in D's templates?

Why don't you read the thread of articles leading to the above, where
Walter has already explained it several times for you?

 

[JohnQ]

* JohnQ:

Why don't you read the thread of articles leading to the above, where
Walter has already explained it several times for you?

I didn't take the above as a comprehensive answer.

John

 

[Walter Bright]

Someone said there was no market for a "C++ lite".

I did, and there isn't. BTW, you can pick up C++ compilers without
exception handling and templates by getting an older version of Zortech,
Microsoft, or Borland.

Well then why do I want it? Maybe because I have a certain
"domain" in mind. Time will tell.

How much $$$ are you willing to pay for one? <g>

 

[Walter Bright]

And why is that?

I've already explained here some of that.

Less functionality/requirements in D's templates?

D's templates are arguably more powerful than C++'s. You can decide for
yourself: http://www.digitalmars.com/d/template-comparison.html