"Small C++" Anyone?

[Walter Bright]

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

What kind of errors are you referring to?

 

[Dave Rahardja]

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.

I agree with you that the burden of backward compatibility has made C++ a
suboptimal language. A clean-sheet design could be much better. A brief
reading of D makes me appreciate the clarity of notation that it brings.

However, my post was framed in the context of the OP's desire to create a
"small C++", presumably agreeing on a _selection_ of features in C++ (written
in valid C++) that will benefit the compiler writers, and not rewriting the
language itself.

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.


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.

Both valid points. However, the C++ community constantly exerted pressure on
the compiler writers to be more and more conformant--why? Because the features
that C++ brings are genuinely useful in addressing real-world problems. To
again refer to the OP's assumption, a subset of C++ doesn't seem to satisfy
the consumer, otherwise demand for a fully-conforming compiler would have
ceased when "enough" features were implemented by "most" compiler writers.

An example of a feature that most users can live without is the export keyword
that you mentioned in another post. It seems that demand for it is very low.
Although EDG spent a tremendous amount of time and money implementing it, it
appears that the feature has not turned into a major competetive advantage
over other vendors, who have shown little interest in supporting it.

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

I'm sold on D! However, it was my assumption in this thread that redefining
the syntax of the language was out of the question.

-dr

 

[JohnQ]

What kind of errors are you referring to?

The kind that are traditionally handled in C++ with the exception machinery
or return codes or passed-in errror handlers, etc.

John

 

[JohnQ]

I've already explained here some of that.

So modules and the !() syntax shaved years off of the implementation. That
makes me wonder if the C++ committee consciously made the choice to make the
concession or if they even considered alternatives. Perhaps without a
reference implementation they had no idea how hard it would be to implement
the standard? Maybe modules is too foreign a concept that doesn't stay
compatible with C? Questions, questions.

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

C++'s are probably too "powerful" though already. More is more.

John

 

[JohnQ]

I did, and there isn't.

I think there is. Again, it doesn't have to exclude functionality, just
maybe rethink things like you did with the template syntax. OK, I am
suggesting removing SOME functionality.

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

Well the thought was to have something open for which to build a toolchain
on. That means comprehensible source code must be available.

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

Well stripping one down for the starting point for evolution is the easy
part. I wouldn't know how to specify it at this point (LALR(1) and all that
stuff I am not on top of). I don't think I'd "job it out". That may be a
good "level the playing field" open source or something project. Probably
preceded by a contest to see how little of C++ programmers could engage and
still have very good code (maintainable, reliable, comprehensible, etc.).
But then again, I'm not a big believer in that development model.
Proprietary or independent research is probably the way to go (else it would
be yet another designed-by-committee thing, and of course we already have
that).

John

 

[Dave Rahardja]

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

C++ is indeed difficult to learn. However, _subsetting_ the language is not
the solution--moving to a _different_ language more suitable to the task is.
Remember, the problems that programmers want to solve still exist.

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

The complexity of the language reflects the complexity of the problem domain.
Subsetting the language is not going to make the complexity of the problem
domain go away--it just makes it more difficult for users to express it.

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



Trust me, I did.

If you say so.

I think I've made just about as much of a point as I'm going to manage in this
thread. I'll bow out with this summary of my opinion:

- Complexity in C++ is driven by many things, but primarily by a genuine user
market demand to express more complex problem domains in that language.
- Subsetting C++ will necessarily reduce the problem domains that can be
expressed in the language.
- Having compiler writers deal with the complexity of the language is
preferable to having the users deal with the complexity of the problem domain.
- There are alternative languages that can more simply express similar problem
domains that C++ addresses. However, they are neither C++ nor a subset
thereof.

-dr

 

[Walter Bright]

The kind that are traditionally handled in C++ with the exception machinery
or return codes or passed-in errror handlers, etc.

You can use any of the three methods in D.

 

[JohnQ]

C++ is indeed difficult to learn. However, _subsetting_ the language is
not
the solution--moving to a _different_ language more suitable to the task
is.
Remember, the problems that programmers want to solve still exist.

Well I suggested a subset as a starting point for reimplementation of some
of the hard to implement features and also probably dropping some features.
It may end up another language even though it is a subset. It depends on how
the features were implemented. Most people use just a subset of C++: that is
their coding style. Currently though, because C++ is so complex, only a
handful of people can make surround tools and the like. It's probably pretty
difficult to make even a syntax highlighter for C++. I don't know at this
point, maybe templates are the brick that breaks the camel. Maybe without
that, the implementation isn't that bad. It would be nice to see some
analysis on EC++ vs C++: man years of implementation effort, complexity
metrics, etc.

The complexity of the language reflects the complexity of the problem
domain.
Subsetting the language is not going to make the complexity of the problem
domain go away--it just makes it more difficult for users to express it.

Well if you define "problem domain" as being all things to all people, then
yes, that is complex.

If you say so.

I think I've made just about as much of a point as I'm going to manage in
this
thread. I'll bow out with this summary of my opinion:

- Complexity in C++ is driven by many things, but primarily by a genuine
user
market demand to express more complex problem domains in that language.

Or because there aren't many similar languages instead of just one maybe. Or
too much baggage in one. Or too many features in one.

- Subsetting C++ will necessarily reduce the problem domains that can be
expressed in the language.

Not necessarily a bad thing.

- Having compiler writers deal with the complexity of the language is
preferable to having the users deal with the complexity of the problem
domain.

Again, the better goal is to minimize complexity rather than transfer
responsibility of it.

- There are alternative languages that can more simply express similar
problem
domains that C++ addresses. However, they are neither C++ nor a subset
thereof.

The question becomes: is the day of the general purpose language coming to a
close because it is too unwieldly?

John

 

[JohnQ]

Both valid points. However, the C++ community constantly exerted pressure
on
the compiler writers to be more and more conformant--why? Because the
features
that C++ brings are genuinely useful in addressing real-world problems. To
again refer to the OP's assumption, a subset of C++ doesn't seem to
satisfy
the consumer, otherwise demand for a fully-conforming compiler would have
ceased when "enough" features were implemented by "most" compiler writers.

Well maybe for lack of there being alternatives. Also, all the potential
participants probably aren't in the marketplace because they deem C++ to
inaccessible. If C++ is such a darned good general purpose language, why do
so many use java and C# and ....? (Because templates aren't nearly as
important as the facilities the other languages provide? Is C++ going to
become a "domain-specific language" because the focus is too much on low
level things? An OS-developer's language? Hardly seems like a general
purpose language if no one uses it for high level programming. A low-level
programming language?)

An example of a feature that most users can live without is the export
keyword
that you mentioned in another post. It seems that demand for it is very
low.
Although EDG spent a tremendous amount of time and money implementing it,
it
appears that the feature has not turned into a major competetive advantage
over other vendors, who have shown little interest in supporting it.

I'm sold on D! However, it was my assumption in this thread that
redefining
the syntax of the language was out of the question.

A strict subset wasn't the goal for the final alternative language. An
exercise would be to see how close one could stay with C++ syntax, still
having adequate capability while removing the hard-to-implement things.

John

 

[Walter Bright]

I agree with you that the burden of backward compatibility has made C++ a
suboptimal language. A clean-sheet design could be much better. A brief
reading of D makes me appreciate the clarity of notation that it brings.

D has the advantage of hindsight in redesigning things. The programming
community knows a lot more now than it did 20 years ago.

However, my post was framed in the context of the OP's desire to create a
"small C++", presumably agreeing on a _selection_ of features in C++ (written
in valid C++) that will benefit the compiler writers, and not rewriting the
language itself.
Ok.


Both valid points. However, the C++ community constantly exerted pressure on
the compiler writers to be more and more conformant--why? Because the features
that C++ brings are genuinely useful in addressing real-world problems. To
again refer to the OP's assumption, a subset of C++ doesn't seem to satisfy
the consumer, otherwise demand for a fully-conforming compiler would have
ceased when "enough" features were implemented by "most" compiler writers.

An example of a feature that most users can live without is the export keyword
that you mentioned in another post. It seems that demand for it is very low.
Although EDG spent a tremendous amount of time and money implementing it, it
appears that the feature has not turned into a major competetive advantage
over other vendors, who have shown little interest in supporting it.

Export, by and large, has failed to deliver its promised benefits. I
know several who disagree with me, but I was unconvinced by their
arguments. So I agree with you. I just can't see spending 3 years of my
life on something that doesn't deliver.

I'm sold on D! However, it was my assumption in this thread that redefining
the syntax of the language was out of the question.

I don't believe that deleting a bunch of standard features in DMC++ (or
any other C++ compiler) is going to make it a more attractive product.
It runs contrary to all my experience in this business.

There have been two major attempts at reengineering C++: Java, which
tries to improve things by removing the hard stuff, and D, which tries
to redesign the hard stuff so it isn't hard anymore.

 

[Walter Bright]

A strict subset wasn't the goal for the final alternative language. An
exercise would be to see how close one could stay with C++ syntax, still
having adequate capability while removing the hard-to-implement things.

Sounds to me like Java is for you.

 

[Dennis \(Icarus\)]

writers.

Well maybe for lack of there being alternatives. Also, all the potential
participants probably aren't in the marketplace because they deem C++ to
inaccessible. If C++ is such a darned good general purpose language, why do
so many use java and C# and ....? (Because templates aren't nearly as

I use C# because it deals much more cleanly with Microsoft's COM/Automation
APIs.
If I'm out of that domain, I prefer to use C++.

important as the facilities the other languages provide? Is C++ going to
become a "domain-specific language" because the focus is too much on low
level things? An OS-developer's language? Hardly seems like a general

I don't think so.

purpose language if no one uses it for high level programming. A low-level
programming language?)

So what do you consider "high-level"?

A strict subset wasn't the goal for the final alternative language. An
exercise would be to see how close one could stay with C++ syntax, still
having adequate capability while removing the hard-to-implement things.

And if these "hard-to-implement" things provide nice functionality?
Developers won't loo at the language and say...wow....that was easy to
implement!
They'll say...."darn, it doesn't have xxxxx - I'll look elsewhere"

Dennis

 

[Ed Jensen]

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

Darn. Oh well. Thanks for the reply.

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.

GCC doesn't support, and likely never will, the platform I'm thinking
about.

 

[JohnQ]

Sounds to me like Java is for you.

Nope. That's not a real language. It's a proprietary product for a
proprietary environement.

 

[JohnQ]

I use C# because it deals much more cleanly with Microsoft's
COM/Automation
APIs.
If I'm out of that domain, I prefer to use C++.


I don't think so.


So what do you consider "high-level"?

GUI, DB, business, application programming. (As opposed to device driver or
OS development).

And if these "hard-to-implement" things provide nice functionality?
Developers won't loo at the language and say...wow....that was easy to
implement!
They'll say...."darn, it doesn't have xxxxx - I'll look elsewhere"

There's usually 2 positions (not just for programming languages): you like
all the bells and whistles or you like simply elegant. I'm the latter and
C++ isn't in the latter category.

John

 

[dave_mikesell]

Not necessarily a bad thing.

In fact, it is necessarily a bad thing to emasculate a general purpose
programming language. Use D, C#, Java, or roll your own (which you
probably could have done in the time you spent here). You can't
squeeze C++ back into the tube.

 

[JohnQ]

In fact, it is necessarily a bad thing to emasculate a general purpose
programming language. Use D, C#, Java, or roll your own

That's the point, but to start from a nice subset of C++.

John

 

[Walter Bright]

GCC doesn't support, and likely never will, the platform I'm thinking
about.

What is that platform?

 

[Dennis \(Icarus\)]

GUI, DB, business, application programming. (As opposed to device driver or
OS development).

How about CAD software?
We use C++.

There's usually 2 positions (not just for programming languages): you like
all the bells and whistles or you like simply elegant. I'm the latter and
C++ isn't in the latter category.

<shrug> One person's "bell/whistle" is another's essential feature.

Dennis

 

[Dennis \(Icarus\)]

That's the point, but to start from a nice subset of C++.

Come up with a spec of your nice subset.
Others can come upwith theirs....
Eventually the union of those subsets would, quite likely, approach what we
have today.

Dennis