(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
Mar 9 '07
169  8928 
Should have been: http://www.semdesigns.com/Products/F...pFrontEnd.html
.... in Flash?
-- IDB
"Adrian Hawryluk" <ad**************************@nospam.comwrote in message
news:_vdJh.66028$Du6.32240@edtnps82...
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/
================================================== ========
"Walter Bright" <wa****@digitalmars-nospamm.comwrote in message
news:pY******************************@comcast.com. ..
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.
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
JohnQ wrote:
"Walter Bright" <wa****@digitalmars-nospamm.comwrote in message
news:pY******************************@comcast.com. ..
>JohnQ wrote:
>>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.
I'm not sure what "exported" templates are.
2nd google hit: http://www.comeaucomputing.com/4.0/d...an/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)
Ed Jensen wrote:
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?
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.
"Walter Bright" <wa****@digitalmars-nospamm.comwrote in message
news:yI******************************@comcast.com. ..
JohnQ wrote:
>"Walter Bright" <wa****@digitalmars-nospamm.comwrote in message
news:pY******************************@comcast.com ...
>>JohnQ wrote:
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.
I'm not sure what "exported" templates are.
2nd google hit:
http://www.comeaucomputing.com/4.0/d...an/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)
And why is that? Less functionality/requirements in D's templates?
John
"Walter Bright" <wa****@digitalmars-nospamm.comwrote in message
news:SK******************************@comcast.com. ..
Ed Jensen wrote:
>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?
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
* JohnQ:
"Walter Bright" <wa****@digitalmars-nospamm.comwrote in message
news:yI******************************@comcast.com. ..
>JohnQ wrote:
>>"Walter Bright" <wa****@digitalmars-nospamm.comwrote in message
news:pY******************************@comcast.co m...
JohnQ wrote:
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.
I'm not sure what "exported" templates are.
2nd google hit:
http://www.comeaucomputing.com/4.0/d...an/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)
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?
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
"Alf P. Steinbach" <al***@start.nowrote in message
news:55*************@mid.individual.net...
>* JohnQ:
>"Walter Bright" <wa****@digitalmars-nospamm.comwrote in message
news:yI******************************@comcast.com ...
>>JohnQ wrote:
"Walter Bright" <wa****@digitalmars-nospamm.comwrote in message
news:pY******************************@comcast.c om...
JohnQ wrote:
>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.
I'm not sure what "exported" templates are.
2nd google hit:
http://www.comeaucomputing.com/4.0/d...an/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)
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?
I didn't take the above as a comprehensive answer.
John
JohnQ wrote:
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>
JohnQ wrote:
"Walter Bright" <wa****@digitalmars-nospamm.comwrote in message
news:yI******************************@comcast.com. ..
>JohnQ wrote:
>>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)
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
JohnQ wrote:
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?
On Tue, 13 Mar 2007 02:20:30 -0700, Walter Bright
<wa****@digitalmars-nospamm.comwrote:
>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.
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.
>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.
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.
>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
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
"Walter Bright" <wa****@digitalmars-nospamm.comwrote in message
news:WZ******************************@comcast.com. ..
JohnQ wrote:
>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?
The kind that are traditionally handled in C++ with the exception machinery
or return codes or passed-in errror handlers, etc.
John
"Walter Bright" <wa****@digitalmars-nospamm.comwrote in message
news:WZ******************************@comcast.com. ..
JohnQ wrote:
>Someone said there was no market for a "C++ lite".
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.
>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>
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
"Walter Bright" <wa****@digitalmars-nospamm.comwrote in message
news:WZ******************************@comcast.com. ..
JohnQ wrote:
>"Walter Bright" <wa****@digitalmars-nospamm.comwrote in message
news:yI******************************@comcast.com ...
>>JohnQ wrote:
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)
And why is that?
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.
>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
C++'s are probably too "powerful" though already. More is more.
John
On Tue, 13 Mar 2007 11:08:56 GMT, "JohnQ"
<jo***********************@yahoo.comwrote:
>>>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.
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.
>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.
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.
>C++ _is_ a compromise.
Well probably not to the degree that I'd prefer then.
Obviously!
>>>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.
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
JohnQ wrote:
"Walter Bright" <wa****@digitalmars-nospamm.comwrote in message
news:WZ******************************@comcast.com. ..
>JohnQ wrote:
>>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?
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.
"Dave Rahardja" <dr****************************@pobox.comwrote in message
news:lo********************************@4ax.com...
On Tue, 13 Mar 2007 11:08:56 GMT, "JohnQ"
<jo***********************@yahoo.comwrote:
>>>>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.
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.
>>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.
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.
>>C++ _is_ a compromise.
Well probably not to the degree that I'd prefer then.
Obviously!
>>>>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.
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
"Dave Rahardja" <dr****************************@pobox.comwrote in message
news:l4********************************@4ax.com...
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
Dave Rahardja wrote:
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.
>>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
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.
JohnQ wrote:
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.
"JohnQ" <jo***********************@yahoo.comwrote in message
news:X8*****************@newssvr19.news.prodigy.ne t...
>
"Dave Rahardja" <dr****************************@pobox.comwrote in
message
news:l4********************************@4ax.com...
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
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"?
>
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.
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
Walter Bright <wa****@digitalmars-nospamm.comwrote:
>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
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.
On Mar 14, 1:31 am, "JohnQ" <johnqREMOVETHISprogram...@yahoo.com>
wrote:
"Dave Rahardja" <drahardja_atsign_pobox_dot_...@pobox.comwrote in message
- Subsetting C++ will necessarily reduce the problem domains that can be
expressed in the language.
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.
"Walter Bright" <wa****@digitalmars-nospamm.comwrote in message
news:BM******************************@comcast.com. ..
JohnQ wrote:
>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.
Nope. That's not a real language. It's a proprietary product for a
proprietary environement.
"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:a7**************************@KNOLOGY.NET...
"JohnQ" <jo***********************@yahoo.comwrote in message
news:X8*****************@newssvr19.news.prodigy.ne t...
>>
"Dave Rahardja" <dr****************************@pobox.comwrote in
message
>news:l4********************************@4ax.com.. .
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
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"?
GUI, DB, business, application programming. (As opposed to device driver or
OS development).
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.
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
<da***********@fastmail.fmwrote in message
news:11**********************@n76g2000hsh.googlegr oups.com...
On Mar 14, 1:31 am, "JohnQ" <johnqREMOVETHISprogram...@yahoo.com>
wrote:
>"Dave Rahardja" <drahardja_atsign_pobox_dot_...@pobox.comwrote in
message
- Subsetting C++ will necessarily reduce the problem domains that can
be
expressed in the language.
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
That's the point, but to start from a nice subset of C++.
John
"JohnQ" <jo***********************@yahoo.comwrote in message
news:C3*****************@newssvr12.news.prodigy.ne t...
>
"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:a7**************************@KNOLOGY.NET...
<snip>
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"?
GUI, DB, business, application programming. (As opposed to device driver
or
OS development).
How about CAD software?
We use C++.
>
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.
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.
<shrugOne person's "bell/whistle" is another's essential feature.
Dennis
"JohnQ" <jo***********************@yahoo.comwrote in message
news:05*****************@newssvr12.news.prodigy.ne t...
>
<da***********@fastmail.fmwrote in message
news:11**********************@n76g2000hsh.googlegr oups.com...
On Mar 14, 1:31 am, "JohnQ" <johnqREMOVETHISprogram...@yahoo.com>
wrote:
"Dave Rahardja" <drahardja_atsign_pobox_dot_...@pobox.comwrote in
message
- Subsetting C++ will necessarily reduce the problem domains that can
be
expressed in the language.
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
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
Ed Jensen wrote:
Walter Bright <wa****@digitalmars-nospamm.comwrote:
>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.
What is that platform?
"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:f5**************************@KNOLOGY.NET...
"JohnQ" <jo***********************@yahoo.comwrote in message
news:05*****************@newssvr12.news.prodigy.ne t...
>>
<da***********@fastmail.fmwrote in message
news:11**********************@n76g2000hsh.googleg roups.com...
On Mar 14, 1:31 am, "JohnQ" <johnqREMOVETHISprogram...@yahoo.com>
wrote:
"Dave Rahardja" <drahardja_atsign_pobox_dot_...@pobox.comwrote in
message
- Subsetting C++ will necessarily reduce the problem domains that
can
be
expressed in the language.
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
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.
And again, maybe a language that tries to be all things to all developers is
not desireable. Some subsetting is already available in the form of compiler
switches to turn off capabilities: exceptions, templates, RTTI, etc. And I
think that is good. Perhaps if I know I will never use those things, I
should be able to get a compiler that simply does not have those things in
there. Maybe someone wants such a compiler system and source code to base
their own work upon. C++ is too big to be foundational or seminal in that
way. Having various degrees of compliance (subsetting) would make R&D in the
language and toolchain space ("the C++ family of languages") accessible to
wider audience. That last point is key I think. Think "language/toolchain
development toolkit" based upon a subset (maybe the EC++ subset) of C++.
John
"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:e5***************************@KNOLOGY.NET...
"JohnQ" <jo***********************@yahoo.comwrote in message
news:C3*****************@newssvr12.news.prodigy.ne t...
>>
"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:a7**************************@KNOLOGY.NET.. .
<snip>
>
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"?
GUI, DB, business, application programming. (As opposed to device driver
or
>OS development).
How about CAD software?
We use C++.
A lot of the shrink wrap gets pretty intense. I can't see doing that in a
higher level language. C++ seems like a good fit for creating shrink-wrapped
CAD software. I wouldn't consider CAD software "low level", but it's hardly
a common GUI/DB-type (say AddressBook) program. I was suggesting that higher
level programming is moving away from (or will move away from) C++ as it's
complexity increases as it should not require one to be a scientist to
create all/any software. It's valid for IT department managers to be afraid
of C++ development projects when they know their relatively simple
application could turn into one of those "C++ projects from hell" in short
order because the language feature set is so huge. What, though, if they had
"Small C++" that enabled them without requiring programmers that all have
PhDs? I know what you're going to say: use another language or tool for
that. To which I'd reply: then C++ is "a low level language and is being
relegated to such" rather than being a "general purpose language"?
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.
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.
<shrugOne person's "bell/whistle" is another's essential feature.
And so C++ should include them all? I don't think anyone has actually tried
to map language features to specific development "arena" needs (IT
department vs. device driver developer, for example). More research on that
may show that there is no need for all the complexity all of the time. Maybe
then a nice set of compatible C++ languages would evolve out of that: C++
for IT departments, C++ for devices, and on. How a language can purport to
be "general purpose" and lob off a entire domains of development because of
extreme skill requirements, escapes me. Accessibility is a key goodness
criteria for a language IMO.
John
Walter Bright <wa****@digitalmars-nospamm.comwrote:
What is that platform?
iSeries (formerly AS/400).
JohnQ wrote:
><shrugOne person's "bell/whistle" is another's essential feature.
And so C++ should include them all? I don't think anyone has actually
tried to map language features to specific development "arena" needs (IT
department vs. device driver developer, for example). More research on
that may show that there is no need for all the complexity all of the
time. Maybe then a nice set of compatible C++ languages would evolve out
of that: C++ for IT departments, C++ for devices, and on.
You don't need a specialized version for that. Just don't use the features
you don't want. Define the subset you are comfortable with, and limit
yourself or your team to that subset. When you have that subset well proved
and successfully applied to several problems, maybe someone will start to
have some interest in write compilers or tools specialized for it.
Or if you think that EC++ is already an adequate subset for your tasks, just
use EC++.
--
Salu2
On Mar 14, 5:06 pm, Julián Albo <JULIANA...@terra.eswrote:
JohnQ wrote:
<shrugOne person's "bell/whistle" is another's essential feature.
And so C++ should include them all? I don't think anyone has actually
tried to map language features to specific development "arena" needs (IT
department vs. device driver developer, for example). More research on
that may show that there is no need for all the complexity all of the
time. Maybe then a nice set of compatible C++ languages would evolve out
of that: C++ for IT departments, C++ for devices, and on.
You don't need a specialized version for that. Just don't use the features
you don't want. Define the subset you are comfortable with, and limit
yourself or your team to that subset. When you have that subset well proved
and successfully applied to several problems, maybe someone will start to
have some interest in write compilers or tools specialized for it.
Or if you think that EC++ is already an adequate subset for your tasks, just
use EC++.
That's my take as well. Also, what if you did use a sanctioned
"subset" for a project and then later requirements need something in
another "subset"? You have to integrate a different toolchain in
your development process.
"Julián Albo" <JU********@terra.eswrote in message
news:45********@x-privat.org...
JohnQ wrote:
>><shrugOne person's "bell/whistle" is another's essential feature.
And so C++ should include them all? I don't think anyone has actually
tried to map language features to specific development "arena" needs (IT
department vs. device driver developer, for example). More research on
that may show that there is no need for all the complexity all of the
time. Maybe then a nice set of compatible C++ languages would evolve out
of that: C++ for IT departments, C++ for devices, and on.
You don't need a specialized version for that. Just don't use the features
you don't want. Define the subset you are comfortable with, and limit
yourself or your team to that subset. When you have that subset well
proved
and successfully applied to several problems, maybe someone will start to
have some interest in write compilers or tools specialized for it.
I am doing that, but I'm thinking ahead.
John
<da***********@fastmail.fmwrote in message
news:11*********************@e65g2000hsc.googlegro ups.com...
"On Mar 14, 5:06 pm, Julián Albo <JULIANA...@terra.eswrote:
JohnQ wrote:
<shrugOne person's "bell/whistle" is another's essential feature.
And so C++ should include them all? I don't think anyone has actually
tried to map language features to specific development "arena" needs (IT
department vs. device driver developer, for example). More research on
that may show that there is no need for all the complexity all of the
time. Maybe then a nice set of compatible C++ languages would evolve out
of that: C++ for IT departments, C++ for devices, and on.
You don't need a specialized version for that. Just don't use the features
you don't want. Define the subset you are comfortable with, and limit
yourself or your team to that subset. When you have that subset well
proved
and successfully applied to several problems, maybe someone will start to
have some interest in write compilers or tools specialized for it.
Or if you think that EC++ is already an adequate subset for your tasks,
just
use EC++.
That's my take as well. Also, what if you did use a sanctioned
"subset" for a project and then later requirements need something in
another "subset"? You have to integrate a different toolchain in
your development process."
****************+
By "subset", I mean that which has been determined to be adequate for the
domain in which it is used. Not simply, "oh I didn't use templates for this
application, so I'll never ever need them". Perhaps the subset doesn't have
C++ exceptions but rather a replacement for them at the library level (as
far fetched as that example seems). Let's say that's one thing, and then
there's another thing and another. Eventually C++ implementations begin to
look like way overkill and one wonders if it would be good to fork away from
the standard and even develop a C++ minus those unused features. Why? Well
because it's deemed decidedly better (by those who created and use the
subset+) and C++ is encumbered with backward compatibility (with itself and
C) and cannot be state of the art, while the subset users don't want to be
held back by standard concerns.
(I keep saying "subset" but I mean that there is a subset of C++ and then
some replacements for some or most of jettisoned functionality. The subset
is just the starting point. And it's not to say that the replacements for
the jettisoned functionality wouldn't be in a library or something and
therefor still be C++ compilable. At some point though, it may indeed take
on a life of its own apart from C++).
John
Ed Jensen wrote:
Walter Bright <wa****@digitalmars-nospamm.comwrote:
>What is that platform?
iSeries (formerly AS/400).
I don't know anything about it :-(
"JohnQ" <jo***********************@yahoo.comwrote in message
news:w9****************@newssvr13.news.prodigy.net ...
>
"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:e5***************************@KNOLOGY.NET...
"JohnQ" <jo***********************@yahoo.comwrote in message
news:C3*****************@newssvr12.news.prodigy.ne t...
>
"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:a7**************************@KNOLOGY.NET...
<snip>
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"?
GUI, DB, business, application programming. (As opposed to device
driver
or
OS development).
How about CAD software?
We use C++.
A lot of the shrink wrap gets pretty intense. I can't see doing that in a
higher level language. C++ seems like a good fit for creating
shrink-wrapped
CAD software. I wouldn't consider CAD software "low level", but it's
hardly
a common GUI/DB-type (say AddressBook) program. I was suggesting that
higher
level programming is moving away from (or will move away from) C++ as it's
complexity increases as it should not require one to be a scientist to
create all/any software. It's valid for IT department managers to be
afraid
of C++ development projects when they know their relatively simple
application could turn into one of those "C++ projects from hell" in short
order because the language feature set is so huge. What, though, if they
had
Just because its there doesn't mean you have to use it.
Don't get me wrong, if you want to create another language, using C++ (or a
subset of C++) as a starting poiint, more power to you.
After all, thats how things evolve.
"Small C++" that enabled them without requiring programmers that all have
PhDs? I know what you're going to say: use another language or tool for
that. To which I'd reply: then C++ is "a low level language and is being
relegated to such" rather than being a "general purpose language"?
To which I'd reply, no, since there are still lots of folks doing high level
work in C++.
>
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.
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.
<shrugOne person's "bell/whistle" is another's essential feature.
And so C++ should include them all? I don't think anyone has actually
tried
to map language features to specific development "arena" needs (IT
department vs. device driver developer, for example). More research on
that
may show that there is no need for all the complexity all of the time.
Maybe
then a nice set of compatible C++ languages would evolve out of that: C++
for IT departments, C++ for devices, and on. How a language can purport to
be "general purpose" and lob off a entire domains of development because
of
extreme skill requirements, escapes me. Accessibility is a key goodness
criteria for a language IMO.
Maybe you've said this in a message I've not read, but what exactlyis the
complexity that you find so abhorrent?
I'm pretty sure an IT department would find generic collection classes
useful, so templates would be there
I'm pretty sure a device driver writer would find generics useful as well.
Both would find strings useful.
Exception handling would be used in both arenas.
What subset of features would be needed by an IT developer and not by a
device driver writer and vice-versa?
Dennis
"JohnQ" <jo***********************@yahoo.comwrote in message
news:w9*****************@newssvr13.news.prodigy.ne t...
>
"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:f5**************************@KNOLOGY.NET...
"JohnQ" <jo***********************@yahoo.comwrote in message
news:05*****************@newssvr12.news.prodigy.ne t...
>
<da***********@fastmail.fmwrote in message
news:11**********************@n76g2000hsh.googlegr oups.com...
On Mar 14, 1:31 am, "JohnQ" <johnqREMOVETHISprogram...@yahoo.com>
wrote:
"Dave Rahardja" <drahardja_atsign_pobox_dot_...@pobox.comwrote in
message
- Subsetting C++ will necessarily reduce the problem domains that
can
be
expressed in the language.
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
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.
And again, maybe a language that tries to be all things to all developers
is
not desireable. Some subsetting is already available in the form of
compiler
switches to turn off capabilities: exceptions, templates, RTTI, etc. And I
think that is good. Perhaps if I know I will never use those things, I
should be able to get a compiler that simply does not have those things in
there. Maybe someone wants such a compiler system and source code to base
And, quite likely, the compiler vendor would give you the same compiler with
the swith just set to off and not have the ability to turn it on.
their own work upon. C++ is too big to be foundational or seminal in that
way. Having various degrees of compliance (subsetting) would make R&D in
the
language and toolchain space ("the C++ family of languages") accessible to
wider audience. That last point is key I think. Think "language/toolchain
development toolkit" based upon a subset (maybe the EC++ subset) of C++.
So it sounds like you have what you want then.
Heck, gcc is freely available.
Dennis
"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:cb***************************@KNOLOGY.NET...
"JohnQ" <jo***********************@yahoo.comwrote in message
news:w9*****************@newssvr13.news.prodigy.ne t...
>>
"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:f5**************************@KNOLOGY.NET.. .
"JohnQ" <jo***********************@yahoo.comwrote in message
news:05*****************@newssvr12.news.prodigy.ne t...
<da***********@fastmail.fmwrote in message
news:11**********************@n76g2000hsh.googleg roups.com...
On Mar 14, 1:31 am, "JohnQ" <johnqREMOVETHISprogram...@yahoo.com>
wrote:
"Dave Rahardja" <drahardja_atsign_pobox_dot_...@pobox.comwrote in
message
- Subsetting C++ will necessarily reduce the problem domains that
can
be
expressed in the language.
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
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.
And again, maybe a language that tries to be all things to all developers
is
>not desireable. Some subsetting is already available in the form of
compiler
>switches to turn off capabilities: exceptions, templates, RTTI, etc. And
I
think that is good. Perhaps if I know I will never use those things, I
should be able to get a compiler that simply does not have those things
in
there. Maybe someone wants such a compiler system and source code to base
And, quite likely, the compiler vendor would give you the same compiler
with
the swith just set to off and not have the ability to turn it on.
>their own work upon. C++ is too big to be foundational or seminal in that
way. Having various degrees of compliance (subsetting) would make R&D in
the
>language and toolchain space ("the C++ family of languages") accessible
to
wider audience. That last point is key I think. Think "language/toolchain
development toolkit" based upon a subset (maybe the EC++ subset) of C++.
So it sounds like you have what you want then.
Heck, gcc is freely available.
But you see, with all the complexity of a full ISO compiler instead of an
EC++ one, that source code and grammar is probably pretty nightmarish
(inaccessible).
John
"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:a5***************************@KNOLOGY.NET...
"JohnQ" <jo***********************@yahoo.comwrote in message
news:w9****************@newssvr13.news.prodigy.net ...
>>
"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:e5***************************@KNOLOGY.NET. ..
"JohnQ" <jo***********************@yahoo.comwrote in message
news:C3*****************@newssvr12.news.prodigy.ne t...
"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:a7**************************@KNOLOGY.NET.. .
<snip>
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"?
GUI, DB, business, application programming. (As opposed to device
driver
or
OS development).
How about CAD software?
We use C++.
A lot of the shrink wrap gets pretty intense. I can't see doing that in a
higher level language. C++ seems like a good fit for creating
shrink-wrapped
>CAD software. I wouldn't consider CAD software "low level", but it's
hardly
>a common GUI/DB-type (say AddressBook) program. I was suggesting that
higher
>level programming is moving away from (or will move away from) C++ as
it's
complexity increases as it should not require one to be a scientist to
create all/any software. It's valid for IT department managers to be
afraid
>of C++ development projects when they know their relatively simple
application could turn into one of those "C++ projects from hell" in
short
order because the language feature set is so huge. What, though, if they
had
Just because its there doesn't mean you have to use it.
Yeah, but how do you control a wild team of C++ programmers? Also, what if
the IT managers are up to running a project with a milder subset/higher
level toolchain but don't have the years of C++ project management skill to
embark on such a project? Well then they either job it out/get consultants,
don't do it, or use something else. That's how C++ gets pushed out of the
picture.
Don't get me wrong, if you want to create another language, using C++ (or
a
subset of C++) as a starting poiint, more power to you.
After all, thats how things evolve.
>"Small C++" that enabled them without requiring programmers that all have
PhDs? I know what you're going to say: use another language or tool for
that. To which I'd reply: then C++ is "a low level language and is being
relegated to such" rather than being a "general purpose language"?
To which I'd reply, no, since there are still lots of folks doing high
level
work in C++.
A study with "market share" pie charts for various types of development
projects would be nice to have.
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.
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.
<shrugOne person's "bell/whistle" is another's essential feature.
And so C++ should include them all? I don't think anyone has actually
tried
>to map language features to specific development "arena" needs (IT
department vs. device driver developer, for example). More research on
that
>may show that there is no need for all the complexity all of the time.
Maybe
>then a nice set of compatible C++ languages would evolve out of that: C++
for IT departments, C++ for devices, and on. How a language can purport
to
be "general purpose" and lob off a entire domains of development because
of
>extreme skill requirements, escapes me. Accessibility is a key goodness
criteria for a language IMO.
Maybe you've said this in a message I've not read, but what exactlyis the
complexity that you find so abhorrent?
The gargantuan project of implementing a compiler system for the language.
(I know, the thoughts in my previous post drifted a bit from that
sentiment). I just gave the "IT dept/driver" example because they seems so
removed from each other. At the hardware level, one needs a language that
lets one get close to the hardware. Does the IT programmer building a GUI
program need that or need to be concerned with all of the hardware
portability issues? (Yeah, I know, that's not "a feature" that can be
toggled, but you get my point surely).
I'm pretty sure an IT department would find generic collection classes
useful, so templates would be there
And a bunch of C++ programmers exploiting all the possibilities of templates
is a scary thought to the IT manager.
I'm pretty sure a device driver writer would find generics useful as well.
Both would find strings useful.
Exception handling would be used in both arenas.
What subset of features would be needed by an IT developer and not by a
device driver writer and vice-versa?
To be determined. Perhaps some nice library can obsolete some functionality
and reduce the IT manager's control requirement and anxiety. You mentioned
templates. Templates can be exploited such that maintainability of code is
reduced. Maybe do containers the C way and turn off templates. Exceptions
would be a bit harder to eliminate: how about defining "exception" as an
abort condition and use it only when required (constructors, operators)
using other handling elsewhere. It would require some thought, but it may be
plausible (?).
So if one could axe "just" templates and exceptions as easily as I wrote it,
how much easier would it be to program maintainable code?
John
"JohnQ" <jo***********************@yahoo.comwrote in message
news:%4****************@newssvr29.news.prodigy.net ...
>
"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:a5***************************@KNOLOGY.NET...
<snip>
Just because its there doesn't mean you have to use it.
Yeah, but how do you control a wild team of C++ programmers? Also, what if
Same way you do a wild team of Java, Eiffel, Lisp, Fortran or COBOL
programmers.
the IT managers are up to running a project with a milder subset/higher
level toolchain but don't have the years of C++ project management skill
to
embark on such a project? Well then they either job it out/get
consultants,
don't do it, or use something else. That's how C++ gets pushed out of the
picture.
Is C++ project management really that different from managing a Java
project?
C++ is a tool for getting a job done. For me, what I do, its the right tool
the vast majority of the time.
When ts not, e.g dealing with MS COM/Automation, I'll use C#.
>
Don't get me wrong, if you want to create another language, using C++
(or
a
subset of C++) as a starting poiint, more power to you.
After all, thats how things evolve.
"Small C++" that enabled them without requiring programmers that all
have
PhDs? I know what you're going to say: use another language or tool for
that. To which I'd reply: then C++ is "a low level language and is
being
relegated to such" rather than being a "general purpose language"?
To which I'd reply, no, since there are still lots of folks doing high
level
work in C++.
A study with "market share" pie charts for various types of development
projects would be nice to have.
This has bar graphs, not pie charts. http://www.infoworld.com/article/05/...html?s=feature
>
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.
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.
<shrugOne person's "bell/whistle" is another's essential feature.
And so C++ should include them all? I don't think anyone has actually
tried
to map language features to specific development "arena" needs (IT
department vs. device driver developer, for example). More research on
that
may show that there is no need for all the complexity all of the time.
Maybe
then a nice set of compatible C++ languages would evolve out of that:
C++
for IT departments, C++ for devices, and on. How a language can purport
to
be "general purpose" and lob off a entire domains of development
because
of
extreme skill requirements, escapes me. Accessibility is a key goodness
criteria for a language IMO.
Maybe you've said this in a message I've not read, but what exactlyis
the
complexity that you find so abhorrent?
The gargantuan project of implementing a compiler system for the language.
(I know, the thoughts in my previous post drifted a bit from that
sentiment). I just gave the "IT dept/driver" example because they seems so
removed from each other. At the hardware level, one needs a language that
lets one get close to the hardware. Does the IT programmer building a GUI
program need that or need to be concerned with all of the hardware
portability issues? (Yeah, I know, that's not "a feature" that can be
toggled, but you get my point surely).
Depends on what they're doing. You can avoid hardware portability issues if
you target just one platform, regardless of language.
Still have 32-bit vs 64-bit, so if you want to lock your code to only one of
those two platforms, then you don;t have to worry about'
portability. Otherwise, you do.
If your program writes binary data that's to be read on a different platform
where byte-ordering is different, at some point it'll have
to worry about conversion.
A GUI built on an Intel system, where data is written to a file, and that
file is later read on a Motorola system...
Shortly after I graduated I was working in a data procesing center. We got a
tape from a company that used 6-bit characters, instead of the 8-bit EBCDIC
our system used.
We had a conversion chart, but I had to write program in COBOL to do the
conversion. Ugly code.
Wouldve been much cleaner in C++.
>
I'm pretty sure an IT department would find generic collection classes
useful, so templates would be there
And a bunch of C++ programmers exploiting all the possibilities of
templates
is a scary thought to the IT manager.
<shrugsounds like the IT manager isn't managing then.
>
I'm pretty sure a device driver writer would find generics useful as
well.
Both would find strings useful.
Exception handling would be used in both arenas.
What subset of features would be needed by an IT developer and not by a
device driver writer and vice-versa?
To be determined. Perhaps some nice library can obsolete some
functionality
and reduce the IT manager's control requirement and anxiety. You mentioned
Im really starting to think that the IT manager may need to get some
therapy, or maybe find another line of work.
templates. Templates can be exploited such that maintainability of code is
reduced. Maybe do containers the C way and turn off templates. Exceptions
And unmaintainable code can be written is just about any language.
would be a bit harder to eliminate: how about defining "exception" as an
abort condition and use it only when required (constructors, operators)
using other handling elsewhere. It would require some thought, but it may
be
plausible (?).
So if one could axe "just" templates and exceptions as easily as I wrote
it,
how much easier would it be to program maintainable code?
Not very, if instead of using the template-based classes one had to resort
to writing the collection classes themselves.
std::vector<MyObjectCollection
Since std::vector is a standard part of the langaueg, I know immediately
what operations are available, how it can be used, etc.
MyOwnVector Collection2.
Ok, here its sometthing that may act like a collection of objects, though it
might also be a mathematical vector. If the latter, does it use floats or
doubles?
What operations are available? New hires would have to get up to speed on
the company's collection classes.
Or just use std::vector. But they use templates, which aren't in your
"small-c++".
What about operator overloading? That can lead to messy code as well.
It can also lead to very elegant code too - e.g. the IOStream operations or
if one is defining math library.
You don't have "native types" being written via one API and
classes/structures written out by another.
They can all use << amd >>.
Dennis
On Mar 15, 12:38 am, "JohnQ" <johnqREMOVETHISprogram...@yahoo.com>
wrote:
Yeah, but how do you control a wild team of C++ programmers?
I'm picturing drunk programmers riding horses around in circles in the
middle of town, firing six-shooters into the air shouting "Yee-hah!" a
lot.
And a bunch of C++ programmers exploiting all the possibilities of templates
is a scary thought to the IT manager.
<snip>
Sounds like you're trying to solve the age-old problem of
undisciplined, inexperienced, less-talented development staff by
dumbing down the tools. That's always the wrong solution in my
humble opinion. Bad programmers will write bad code in any language.
And if you give them a language that "increases productivity", they'll
simply write more bad code in a shorter period of time.
Open the wallet and hire better programmers. And screen them
rigorously during the interview process. Can't tell you how many
interviews I've been on when they simply take me at my word that I
have the experience I say I have. I often ask them if they want to
ask me anything more about my experience. They just want bodies in
most IT shops, where projects are heavily date driven.
Problem is, there are too many programmers in the world writing too
much bad code. Outsourcing is just exacerbating the problem. IT
departments think a programmer is a programmer and will always hire
the cheapest. You get what you pay for. I'm guessing that's why so
much IT code I've seen in the last ten years is an unmaintainable,
brittle mess. da***********@fastmail.fm wrote:
>Yeah, but how do you control a wild team of C++ programmers?
I'm picturing drunk programmers riding horses around in circles in the
middle of town, firing six-shooters into the air shouting "Yee-hah!" a
lot.
And motorcycles... and his head burning (because of so much template
metraprogramming).
And then John Wayne enter the picture saying: "Time to return to ansi Cobol,
boys".
--
Salu2
"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:23**************************@KNOLOGY.NET...
"JohnQ" <jo***********************@yahoo.comwrote in message
news:%4****************@newssvr29.news.prodigy.net ...
>>
"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:a5***************************@KNOLOGY.NET. ..
<snip>
>
Just because its there doesn't mean you have to use it.
Yeah, but how do you control a wild team of C++ programmers? Also, what
if
Same way you do a wild team of Java, Eiffel, Lisp, Fortran or COBOL
programmers.
>the IT managers are up to running a project with a milder subset/higher
level toolchain but don't have the years of C++ project management skill
to
>embark on such a project? Well then they either job it out/get
consultants,
>don't do it, or use something else. That's how C++ gets pushed out of the
picture.
Is C++ project management really that different from managing a Java
project?
Not for a seasoned software development project manager. But for an IT
department manager who manages everything, either one of those may be tough.
C++ is a tool for getting a job done. For me, what I do, its the right
tool
the vast majority of the time.
When ts not, e.g dealing with MS COM/Automation, I'll use C#.
>>
Don't get me wrong, if you want to create another language, using C++
(or
a
subset of C++) as a starting poiint, more power to you.
After all, thats how things evolve.
"Small C++" that enabled them without requiring programmers that all
have
>PhDs? I know what you're going to say: use another language or tool
for
that. To which I'd reply: then C++ is "a low level language and is
being
>relegated to such" rather than being a "general purpose language"?
To which I'd reply, no, since there are still lots of folks doing high
level
work in C++.
A study with "market share" pie charts for various types of development
projects would be nice to have.
This has bar graphs, not pie charts.
http://www.infoworld.com/article/05/...html?s=feature
Looks like C++ use is declining.
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.
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.
<shrugOne person's "bell/whistle" is another's essential feature.
And so C++ should include them all? I don't think anyone has actually
tried
to map language features to specific development "arena" needs (IT
department vs. device driver developer, for example). More research on
that
may show that there is no need for all the complexity all of the time.
Maybe
then a nice set of compatible C++ languages would evolve out of that:
C++
>for IT departments, C++ for devices, and on. How a language can
purport
to
be "general purpose" and lob off a entire domains of development
because
of
extreme skill requirements, escapes me. Accessibility is a key
goodness
criteria for a language IMO.
Maybe you've said this in a message I've not read, but what exactlyis
the
complexity that you find so abhorrent?
The gargantuan project of implementing a compiler system for the
language.
(I know, the thoughts in my previous post drifted a bit from that
sentiment). I just gave the "IT dept/driver" example because they seems
so
removed from each other. At the hardware level, one needs a language that
lets one get close to the hardware. Does the IT programmer building a GUI
program need that or need to be concerned with all of the hardware
portability issues? (Yeah, I know, that's not "a feature" that can be
toggled, but you get my point surely).
Depends on what they're doing. You can avoid hardware portability issues
if
you target just one platform, regardless of language.
Still have 32-bit vs 64-bit, so if you want to lock your code to only one
of
those two platforms, then you don;t have to worry about'
portability. Otherwise, you do.
If your program writes binary data that's to be read on a different
platform
where byte-ordering is different, at some point it'll have
to worry about conversion.
A GUI built on an Intel system, where data is written to a file, and that
file is later read on a Motorola system...
Shortly after I graduated I was working in a data procesing center. We got
a
tape from a company that used 6-bit characters, instead of the 8-bit
EBCDIC
our system used.
We had a conversion chart, but I had to write program in COBOL to do the
conversion. Ugly code.
Wouldve been much cleaner in C++.
I can't think of all the things that C++ doesn't take for granted, such as
8-bit bytes, but if a language was more platform-specific, it would be
easier to program in also.
I'm pretty sure an IT department would find generic collection classes
useful, so templates would be there
And a bunch of C++ programmers exploiting all the possibilities of
templates
>is a scary thought to the IT manager.
<shrugsounds like the IT manager isn't managing then.
Maybe/probably can't, but we should he have to micro-manage and assume
everyone is on their honor to follow the coding standard (which would
probably be way too intricate if all the ways templates could be used were
excluded... well, maybe not: just list hot they CAN be used). Still,
switching them off is one method of control, though extreme.
I'm pretty sure a device driver writer would find generics useful as
well.
Both would find strings useful.
Exception handling would be used in both arenas.
What subset of features would be needed by an IT developer and not by a
device driver writer and vice-versa?
To be determined. Perhaps some nice library can obsolete some
functionality
>and reduce the IT manager's control requirement and anxiety. You
mentioned
Im really starting to think that the IT manager may need to get some
therapy, or maybe find another line of work.
C++ is hard to learn. To manage projects where it is used, one should know
how to use it very well IMO. That may be too big of a pill to swallow for an
IT manager (or for that career path).
>templates. Templates can be exploited such that maintainability of code
is
reduced. Maybe do containers the C way and turn off templates. Exceptions
And unmaintainable code can be written is just about any language.
It's much easier in C++ (to write unmaintainable code)!
>would be a bit harder to eliminate: how about defining "exception" as an
abort condition and use it only when required (constructors, operators)
using other handling elsewhere. It would require some thought, but it may
be
>plausible (?).
So if one could axe "just" templates and exceptions as easily as I wrote
it,
>how much easier would it be to program maintainable code?
Not very, if instead of using the template-based classes one had to resort
to writing the collection classes themselves.
I didn't say axe the container library, just templates. Other non-template
containers would replace the template ones. But then, without templates
being available to the programmers, they can't exploit the template
machinery.
What operations are available? New hires would have to get up to speed on
the company's collection classes.
Or the vendor's or "Small C++"''s standard library.
Or just use std::vector. But they use templates, which aren't in your
"small-c++".
That doesn't solve the problem we were trying to solve above.
What about operator overloading? That can lead to messy code as well.
Indeed! Use with caution (mostly, don't use).
It can also lead to very elegant code too - e.g. the IOStream operations
or
if one is defining math library.
For math they make a lot more sense. I haven't thought about operators in
regards to decreasing complexity of implementation. From the maintainable
code standpoint, I don't think juat that reason is enough to axe operator
overloading (Who know's, maybe that is next!).
You don't have "native types" being written via one API and
classes/structures written out by another.
They can all use << amd >>.
John
Dnia Wed, 14 Mar 2007 16:05:54 +0000, JohnQ napisał(a):
GUI, DB, business, application programming.
But that's not the language issue, but the libraries issue!
There are platforms which don't use graphics display. Why
should the programmer of that platform have to deal with
GUI stuff forced on him by the language itself?
Even on the platforms supporting graphics and GUI toolkits,
there are differences in supported features and graphic
capabilities, so the One True language GUI couldn't handle
all of them one way [though I think some standardization
of that domain will be helpful here].
The things you mentioned should never be the part of the
core language - external libraries are for that. The core
language is only a tool for expressing algorithms, general
concepts, program organization and stuff like that.
(As opposed to device driver or OS development).
OS/drivers developers also use libraries/system APIs.
The language had always been not enough for that.
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.
C++ is elastic language. You can program in a low level if
you want/need, but you can also program in a high-level
with full OOP and generic programming stuff. C++ has a
features to use that nasty low-level things efficiently, but
it has also a features to hide it under the hood of elegant
and easy-to-use interfaces ;) [according to Stroustrup].
You can use only a small subset if you don't want/need all
the rest. But if you want/need - it's all there, waiting
for you ;) and you probably won't be happy if you need those
extended functionality but someone gave you a "C++ light"
version cropped to only a small subset of C++ ;J
C++ is a language which gives you a freedom of choice.
--
SasQ
"JohnQ" <jo***********************@yahoo.comwrote in message
news:51*****************@newssvr13.news.prodigy.ne t...
>
"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:23**************************@KNOLOGY.NET...
"JohnQ" <jo***********************@yahoo.comwrote in message
news:%4****************@newssvr29.news.prodigy.net ...
>
"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:a5***************************@KNOLOGY.NET...
<snip>
Just because its there doesn't mean you have to use it.
Yeah, but how do you control a wild team of C++ programmers? Also, what
if
Same way you do a wild team of Java, Eiffel, Lisp, Fortran or COBOL
programmers.
the IT managers are up to running a project with a milder subset/higher
level toolchain but don't have the years of C++ project management
skill
to
embark on such a project? Well then they either job it out/get
consultants,
don't do it, or use something else. That's how C++ gets pushed out of
the
picture.
Is C++ project management really that different from managing a Java
project?
Not for a seasoned software development project manager. But for an IT
department manager who manages everything, either one of those may be
tough.
So its the IT manager experience/competence level that's more important?
Thats kind of what I was thinking.
>
C++ is a tool for getting a job done. For me, what I do, its the right
tool
the vast majority of the time.
When ts not, e.g dealing with MS COM/Automation, I'll use C#.
>
Don't get me wrong, if you want to create another language, using C++
(or
a
subset of C++) as a starting poiint, more power to you.
After all, thats how things evolve.
"Small C++" that enabled them without requiring programmers that all
have
PhDs? I know what you're going to say: use another language or tool
for
that. To which I'd reply: then C++ is "a low level language and is
being
relegated to such" rather than being a "general purpose language"?
To which I'd reply, no, since there are still lots of folks doing
high
level
work in C++.
A study with "market share" pie charts for various types of development
projects would be nice to have.
This has bar graphs, not pie charts.
http://www.infoworld.com/article/05/...html?s=feature
Looks like C++ use is declining.
It also shows Win32 as having a shrinking user base. :-)
Scripting and HTML had the greatest increase.
From the article, the reason was the reduction in application complexity,
such as automatic garbage collection.
There are garbage collecting systems for C++, IIRC, and looks like it'll be
in the version 2.0 of the standard. http://www.infoworld.com/article/05/...html?s=feature
Now, memory leaks are a problem, surely. Though realistically any resource
can fail to be managed properly, not just memory.
Manage these resources through classes, se STL collections and string
objects.....is it really that much more complex than Java?
<snip>
Shortly after I graduated I was working in a data procesing center. We
got
a
tape from a company that used 6-bit characters, instead of the 8-bit
EBCDIC
our system used.
We had a conversion chart, but I had to write program in COBOL to do
the
conversion. Ugly code.
Wouldve been much cleaner in C++.
I can't think of all the things that C++ doesn't take for granted, such as
8-bit bytes, but if a language was more platform-specific, it would be
easier to program in also.
And if it were more platform-specific it would be much more difficult to
move programs to different platforms when they came out.
Or are you not just referring to word sizes and such, but stuff like GUI
and/or databases?
>
I'm pretty sure an IT department would find generic collection
classes
useful, so templates would be there
And a bunch of C++ programmers exploiting all the possibilities of
templates
is a scary thought to the IT manager.
<shrugsounds like the IT manager isn't managing then.
Maybe/probably can't, but we should he have to micro-manage and assume
everyone is on their honor to follow the coding standard (which would
probably be way too intricate if all the ways templates could be used were
excluded... well, maybe not: just list hot they CAN be used). Still,
switching them off is one method of control, though extreme.
Far too extreme. Code reviews are a good, useful technique - can even find
problems before they get into the code base.
And you can get tools that can analyze a cde base for compliance to code
standards.
And a manager is either micromanaging becase they doesn't trust their
developers to do the right thing, or they do.
Code reviews, even on just a few projects, can provide "spot-checks".
That's a personnel/management issue though.
>
I'm pretty sure a device driver writer would find generics useful as
well.
Both would find strings useful.
Exception handling would be used in both arenas.
What subset of features would be needed by an IT developer and not by
a
device driver writer and vice-versa?
To be determined. Perhaps some nice library can obsolete some
functionality
and reduce the IT manager's control requirement and anxiety. You
mentioned
Im really starting to think that the IT manager may need to get some
therapy, or maybe find another line of work.
C++ is hard to learn. To manage projects where it is used, one should know
how to use it very well IMO. That may be too big of a pill to swallow for
an
IT manager (or for that career path).
Yes, one should know how to use the language (any language) well,
particularly to manage projects being written in it.
>
templates. Templates can be exploited such that maintainability of code
is
reduced. Maybe do containers the C way and turn off templates.
Exceptions
And unmaintainable code can be written is just about any language.
It's much easier in C++ (to write unmaintainable code)!
I dont know of any other language that has an obfuscated code contest - no,
wait, that's C.
C, without classes, overloading, or templates. :-)
>
would be a bit harder to eliminate: how about defining "exception" as
an
abort condition and use it only when required (constructors, operators)
using other handling elsewhere. It would require some thought, but it
may
be
plausible (?).
So if one could axe "just" templates and exceptions as easily as I
wrote
it,
how much easier would it be to program maintainable code?
Not very, if instead of using the template-based classes one had to
resort
to writing the collection classes themselves.
I didn't say axe the container library, just templates. Other non-template
containers would replace the template ones. But then, without templates
being available to the programmers, they can't exploit the template
machinery.
Microsoft had a set of non-template containers, IIRC. In order to be used
didn't they have to all deive from CObject or some such?
And without templates being available to the programmers, it'd be difficult
for 'em to come up with their own generic classes that fit their needs.
Even if you don't trust the regular developers to handle templates, there
may be some developers responsible for developing the internal framework
that may need to create a generic class for others to use. So if templates
aren't available, then the framework couldn't be developed unless there's a
way to say
"its ok for this, but not for that" section of code.
>
What operations are available? New hires would have to get up to speed
on
the company's collection classes.
Or the vendor's or "Small C++"''s standard library.
Or just use std::vector. But they use templates, which aren't in your
"small-c++".
That doesn't solve the problem we were trying to solve above.
What about operator overloading? That can lead to messy code as well.
Indeed! Use with caution (mostly, don't use).
I approach it with a "use when needed".
If + is being overloaded, it had best clearly represent an "addition"
concept.
Lets say you have multiple heaps, and you gather memory usage stats on each
heap into a class.
A total can be represented in the same class, and two stats can be added
together
Total += HeapStats;
>
It can also lead to very elegant code too - e.g. the IOStream operations
or
if one is defining math library.
For math they make a lot more sense. I haven't thought about operators in
regards to decreasing complexity of implementation. From the maintainable
code standpoint, I don't think juat that reason is enough to axe operator
overloading (Who know's, maybe that is next!).
Hm.....lets see...no generics, overloading may be axed as well.....
Consider C as your base, instead of C++?
But then you're still at risk having your programmers writing obfuscated
code contest entries.
Dennis
"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:da**************************@KNOLOGY.NET...
"JohnQ" <jo***********************@yahoo.comwrote in message
news:51*****************@newssvr13.news.prodigy.ne t...
>>
"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:23**************************@KNOLOGY.NET.. .
"JohnQ" <jo***********************@yahoo.comwrote in message
news:%4****************@newssvr29.news.prodigy.net ...
"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:a5***************************@KNOLOGY.NET. ..
<snip>
Just because its there doesn't mean you have to use it.
Yeah, but how do you control a wild team of C++ programmers? Also,
what
if
Same way you do a wild team of Java, Eiffel, Lisp, Fortran or COBOL
programmers.
the IT managers are up to running a project with a milder
subset/higher
level toolchain but don't have the years of C++ project management
skill
to
embark on such a project? Well then they either job it out/get
consultants,
don't do it, or use something else. That's how C++ gets pushed out of
the
>picture.
Is C++ project management really that different from managing a Java
project?
Not for a seasoned software development project manager. But for an IT
department manager who manages everything, either one of those may be
tough.
So its the IT manager experience/competence level that's more important?
Thats kind of what I was thinking.
Let's see... BigCompany can either 1.) Develop departmental software with
C++ and a high-powered (read, expensive) IT manager, or 2.) Use a different
tool and omit the specialist requirement. Which are they going to choose?
C++ is a tool for getting a job done. For me, what I do, its the right
tool
the vast majority of the time.
When ts not, e.g dealing with MS COM/Automation, I'll use C#.
Don't get me wrong, if you want to create another language, using
C++
(or
a
subset of C++) as a starting poiint, more power to you.
After all, thats how things evolve.
"Small C++" that enabled them without requiring programmers that
all
have
PhDs? I know what you're going to say: use another language or tool
for
that. To which I'd reply: then C++ is "a low level language and is
being
relegated to such" rather than being a "general purpose language"?
To which I'd reply, no, since there are still lots of folks doing
high
level
work in C++.
A study with "market share" pie charts for various types of
development
projects would be nice to have.
This has bar graphs, not pie charts.
http://www.infoworld.com/article/05/...html?s=feature
Looks like C++ use is declining.
It also shows Win32 as having a shrinking user base. :-)
Scripting and HTML had the greatest increase.
From the article, the reason was the reduction in application complexity,
such as automatic garbage collection.
There are garbage collecting systems for C++, IIRC, and looks like it'll
be
in the version 2.0 of the standard.
http://www.infoworld.com/article/05/...html?s=feature
Now, memory leaks are a problem, surely. Though realistically any resource
can fail to be managed properly, not just memory.
Manage these resources through classes, se STL collections and string
objects.....is it really that much more complex than Java?
But STL requires templates and that could lead to unmaintainable code if the
manager can't keep the programmers on a leash.
>
<snip>
>
Shortly after I graduated I was working in a data procesing center. We
got
a
tape from a company that used 6-bit characters, instead of the 8-bit
EBCDIC
our system used.
We had a conversion chart, but I had to write program in COBOL to do
the
conversion. Ugly code.
Wouldve been much cleaner in C++.
I can't think of all the things that C++ doesn't take for granted, such
as
8-bit bytes, but if a language was more platform-specific, it would be
easier to program in also.
And if it were more platform-specific it would be much more difficult to
move programs to different platforms when they came out.
But if it's known it won't be moving, why not use the easy-to-use language
for that platform?
Or are you not just referring to word sizes and such, but stuff like GUI
and/or databases?
No, just language-level things.
I'm pretty sure an IT department would find generic collection
classes
useful, so templates would be there
And a bunch of C++ programmers exploiting all the possibilities of
templates
is a scary thought to the IT manager.
<shrugsounds like the IT manager isn't managing then.
Maybe/probably can't, but we should he have to micro-manage and assume
everyone is on their honor to follow the coding standard (which would
probably be way too intricate if all the ways templates could be used
were
excluded... well, maybe not: just list hot they CAN be used). Still,
switching them off is one method of control, though extreme.
Far too extreme. Code reviews are a good, useful technique - can even find
problems before they get into the code base.
And you can get tools that can analyze a cde base for compliance to code
standards.
Ouch, I sure wouldn't want to be the one to examine microscopically all that
template code the programmers wrote.
And a manager is either micromanaging becase they doesn't trust their
developers to do the right thing, or they do.
The manager needs to be able to control the product. It shouldn't be at the
whim of any/all of the programmers.
Code reviews, even on just a few projects, can provide "spot-checks".
Again, too labor intensive.
That's a personnel/management issue though.
It is with C++ because there is no way to harness it.
I'm pretty sure a device driver writer would find generics useful as
well.
Both would find strings useful.
Exception handling would be used in both arenas.
What subset of features would be needed by an IT developer and not
by
a
device driver writer and vice-versa?
To be determined. Perhaps some nice library can obsolete some
functionality
and reduce the IT manager's control requirement and anxiety. You
mentioned
Im really starting to think that the IT manager may need to get some
therapy, or maybe find another line of work.
C++ is hard to learn. To manage projects where it is used, one should
know
how to use it very well IMO. That may be too big of a pill to swallow for
an
>IT manager (or for that career path).
Yes, one should know how to use the language (any language) well,
particularly to manage projects being written in it.
And it takes more experience and years and therefor costs more with C++
because of all the ins and outs of it.
>templates. Templates can be exploited such that maintainability of
code
is
reduced. Maybe do containers the C way and turn off templates.
Exceptions
>
And unmaintainable code can be written is just about any language.
It's much easier in C++ (to write unmaintainable code)!
I dont know of any other language that has an obfuscated code contest -
no,
wait, that's C.
C, without classes, overloading, or templates. :-)
That's different: they are trying to make obfuscated code. With C++ and
templates and other features, the obfuscation is almost built-in to the
language! ;)
>would be a bit harder to eliminate: how about defining "exception" as
an
>abort condition and use it only when required (constructors,
operators)
using other handling elsewhere. It would require some thought, but it
may
be
plausible (?).
So if one could axe "just" templates and exceptions as easily as I
wrote
it,
how much easier would it be to program maintainable code?
Not very, if instead of using the template-based classes one had to
resort
to writing the collection classes themselves.
I didn't say axe the container library, just templates. Other
non-template
containers would replace the template ones. But then, without templates
being available to the programmers, they can't exploit the template
machinery.
Microsoft had a set of non-template containers, IIRC. In order to be used
didn't they have to all deive from CObject or some such?
Have to? Why would they have to? Obviously you can make cosmic hierarchies
or not.
And without templates being available to the programmers, it'd be
difficult
for 'em to come up with their own generic classes that fit their needs.
Who says "Small C++" wouldn't have generics? They just won't be so
exploitable and won't be difficult to implement.
It can also lead to very elegant code too - e.g. the IOStream
operations
or
if one is defining math library.
For math they make a lot more sense. I haven't thought about operators in
regards to decreasing complexity of implementation. From the maintainable
code standpoint, I don't think juat that reason is enough to axe operator
overloading (Who know's, maybe that is next!).
Hm.....lets see...no generics, overloading may be axed as well.....
Consider C as your base, instead of C++?
At least "C with classes". ;)
But then you're still at risk having your programmers writing obfuscated
code contest entries.
At least they won't be trained to do it and think that is good coding for
production software.
John
JohnQ wrote:
"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:da**************************@KNOLOGY.NET...
But STL requires templates and that could lead to unmaintainable code if the
manager can't keep the programmers on a leash.
Bollocks. The code has nothing to do with a manager, it should be the
domain and responsibility of the development team.
>
>>
Far too extreme. Code reviews are a good, useful technique - can even find
problems before they get into the code base.
And you can get tools that can analyze a cde base for compliance to code
standards.
Use pair programming and collective code ownership and none of this crap
is necessary.
>
Ouch, I sure wouldn't want to be the one to examine microscopically all that
template code the programmers wrote.
>>And a manager is either micromanaging becase they doesn't trust their
developers to do the right thing, or they do.
The manager needs to be able to control the product. It shouldn't be at the
whim of any/all of the programmers.
No he doesn't. He may be responsible for its delivery, but certainly
not its implementation.
>
>>Code reviews, even on just a few projects, can provide "spot-checks".
Again, too labor intensive.
>>That's a personnel/management issue though.
It is with C++ because there is no way to harness it.
What?
--
Ian Collins. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: lawrence |
last post by:
I'm trying to read up on the rfc's that govern form inputs. Much of
what I'm reading is stuff I didn't know before and some of it is
alarming. This one left with me questions:
...
|
by: Harag |
last post by:
Hi all
Classic ASP,
Textpad
Local "test" WebServer. IIS5
Well my MS script debugger isn't running and I can't findout why. I'm
sick of it failing on me so was looking for an alternative. I...
|
by: penguin732901 |
last post by:
Checking back for discussions, there was a lot of talk about 2000 being
slower than 97, but not so much lately. What is the latest opinion?
Anyone care to set up a poll for how many NG members...
|
by: Hai Nguyen |
last post by:
I'm learning C sharp and do not like vb much. I'm creatiing a wepage using
panel to test myself. I tried to use these code below, which is written in
VB, and to transform them to c sharp but I got...
|
by: Skc |
last post by:
Hullo
Just like to check whether anyone has tried RentACoder. I intend to farm
out a small job that must use C#, WinForms, ADO.Net for around US$400, but
don't know whether RentACoder is...
|
by: Dgates |
last post by:
Has anyone typed up an index for the O'Reilly book "C# and VB.NET
Conversion?"
I'm just learning C#, and often using this little book to see which
VB.NET terms translate directly to some term in...
|
by: Gareth |
last post by:
I cannot find a reference anywhere to anyone having done this
successfully... can anyone enlighten me on how you get a SSL login page
working with ASP.NET and forms authentication. I have...
|
by: Bruno Alexandre |
last post by:
Hi guys,
does anyone know where is the Website used in the MSDN "Lear ASP.NET 2.0
with Jeff Prosise"
(http://msdn.microsoft.com/asp.net/beta2/multimedia/default.aspx) events?
The website used...
|
by: tony |
last post by:
I'm using PHP 5 on Win-98 command line (ie no web server involved)
I'm processing a large csv file and when I loop through it I can process
around 275 records per second.
However at around...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
| |
