Future of C++

[kwikius]

My hunch is my posts to clc++ are disappearing down a hole, so I post here
instead.

Future of C++ thread on clc++

"Abhishek" <no*******************@yahoo.comwrote in message
news:g7**********@aioe.org...

Hi All,
This is a non-technical off topic post, so please excuse me for that.

I wanted to understand from the Gurus of C++ out here about their opinion
on
the future of C++. I have spent eight plus years in the software industry
working in applications programming on C++/ Windows. My current company is
now moving big time towards Java/ J2EE based technologies. Most of the
other
companies which are writing application software are also moving (or have
alreadt moved) to J2EE or to .Net. So is there no future for C++ in
application software? What do the people on this group feel about it?

I understand that Systems side and Embedded are still the areas where C++
is
being used well. But is that all? What do the people who have invested
time
and energy in C++ should do? Learn Java or C# because a significant
majority
of other developers (apparently) could not free the pointers and found
garbage collector to be a great idea.

Thoughts/ Suggestions/ Criticism?

AFAICS C++ is very much about a "craft" approach to software development.
For one It takes a long time to get good at it. Like any craftsman, say a
carpenter it costs. Once upon a time if you wanted a new door, you asked the
carpenter and he made you one to your spec. These days doors are all
standard sizes and you buy them off the shelf at a hardware superstore. A
similar situation applies with C++ and other languages in respect to
libraries. The modern trend is towards abstracting away the hardware. This
results in a loss of performance but much greater productivity, and
critically libraries which become unofficial standards within the language.
The classic example in C++ is GUI. Often newbies ask about the C++ GUI and
they are vaguely pointed off towards various libraries. In modern languages
there are usually one or two "standard" GUI libraries that everyone uses.

Because C++ is so expressive, if you start a new library ( or even
application ) then you are presented with a huge number of decisions. Do I
use templates or RTTI, Do I use Dll or static libs, Do I worry about cross
platform or target one. This all takes a long time and results in
fragmentation. In other less complicated languages, you don't have to worry
about these things. They have been solved or abstracted away. Hence
languages like Java, and Python have huge libraries because presumably they
are easier to write once in practise. The low level problems that confront
you in C and C++ are abstracted away.

That said C++ and C will be around a long time. For windows they will be
around as long as its around I guess, but I don't see there being as much
demand for C++ programmers.

regards
Andy Little

[Pavel]

Ian Collins wrote:

Pavel wrote:

>Ian Collins wrote:

>>Pavel wrote:

A typedef would be an alternative.
How?

Truly, I am not sure what I meant. Apparently thought of replacing
template parameters. Did not read clear :-).

OK.

>>>But see, Java has BigDecimal and C++ does not.
That's because a programmer can't write BigDecimal with natural
operators in Java, so the language has to provide it.

I think one of us is confused here. Java has BigDecimal as a regular
Java class -- it is in fact written in pure Java and the source is a
part of Sun's JDK distribution.

No, Java BigDecimal *cannot* be used with operators -- my point was
exactly that it cannot and nobody seems to suffer from it, and nobody
seems to even have voted or created a bug to add operator support there.

I didn't realise it was a regular class (I don't do Java!).

>>Other languages
have to add extra built in features because they lack the expressiveness
to enable programmer' to roll their own. Look at the hoops C had to go
through to add a complex number type.

>Now what you refer to as expressiveness seems to be closer to what I
call syntax sugar. And my attitude to syntax sugar is: "nice to have
when it is safe". Safe includes unambiguous (not only technically, but
also from the point of view of some representative population of the
users -- that they understand the code and the consequences).

I still think most C++ programmers are familiar and at ease with
operator overloading. I'd even go so far as to saying they aren't C++
programmers if they are not.

The problem is really not in unfamiliarity or uneasiness (in fact, the
easier a writers make a decision to overload an operator the worse,
IMHO) but in amount of information one needs to unambiguously say what
function or operator is called (not even what it does but what are the
parameters).

Don't forget the C++ design goal of
enabling user defined types to be as close to built in ones as possible.

I know.. I am not sure I would share this goal now -- not without some
checks and controls.

>well, you do not even want to know whether b*b - 4*a*c >= 0 and whether
a is a zero or very close to zero before taking sqrt?

Most of my types are integer and the operations used are basic arithmetic.

integers can be < 0 or == 0. Also, what is sqrt then?

>

>In real programs, you have to introduce breaks often -- you almost never
just translate math formulas into a programming language. Not to mention
you often need to first re-factor formulas for reasons other than
catching pure domain errors; for example for numerical stability or for
efficiency reasons and after such re-factoring they often become
algorithms with much shorter formula-like pieces; but instead become
pliable to factoring out useful functions (think Horner scheme).

I have a number of real world examples where I objects as parameters for
templates that perform basic arithmetic on their type. I'd hate to have
to specialise them for all non-POD types.

>But even assuming such breaks are unnecessary, how really bad something
like

div(add(neg(b), sqrt(sub(mul(b, b), mul(4, mul(a, c))))), mul(2, a));

Close to indecipherable!

Lisp guys would kill you (I am not one of those). Seriously, does not
look too bad for me.

>

>is (especially considering all editors now do parenthesis matching for
you)? Don't get me wrong, I would prefer operators and I will use them
in C++ myself for clearly numeric types -- unfortunately the language
does not limit their use for such types even though it has all the
information about the type at a point where an operator is used.

The most important parser is the human reading the code. We are used to
seeing arithmetic expressed with standard operators and can pretty well
subconsciously parse them.

That's the issue. C++ makes it easy to preserve a familiar syntax but
give it unexpected semantics. '+' means add() for numeric apps and most
people, and '*' means "multiply" for same domain, but a set
theorist/algebraist would not spend a second thought to make them
"union" and "intersection" for some sets in his C++ library and will
think it is cool (because C++ does not provide those special symbols set
theorists use for these operations but algebraically they have same
properties with +/- on numbers). Maybe s/he even implements his/her sets
by lists or vectors (after all, many logically unordered containers in
programming have to be implemented with some sequence underneath) and
someone who used to using "+" for concatenation (see an "Examples" table
in http://en.wikipedia.org/wiki/Concatenation to see what symbol
programmers having different background may find natural for this
operation as well what other C++ operators they may easily confuse with
concatenation or decide it natural to overload them for concatenation of
their types) will read it as concatenation and so will decide that those
sequences are concatenated by '+' operator (whereas they are being
joined, without duplicates). This latter mistake can be discovered quite
late in the game and cost a firm a fortune.

With anything else we have to consciously
parse the expression.

Which is not necessarily a bad thing, especially considering how easy it
is to make a wrong assumption for the meaning of operators (see above).
-Pavel

[Ian Collins]

Pavel wrote:

Ian Collins wrote:

>Pavel wrote:

>I still think most C++ programmers are familiar and at ease with
operator overloading. I'd even go so far as to saying they aren't C++
programmers if they are not.

The problem is really not in unfamiliarity or uneasiness (in fact, the
easier a writers make a decision to overload an operator the worse,
IMHO) but in amount of information one needs to unambiguously say what
function or operator is called (not even what it does but what are the
parameters).

That is provided by the context the expression is used in. If the
expression is inappropriate for the context, it will be rejected by the
programmer's peers.

>Don't forget the C++ design goal of
enabling user defined types to be as close to built in ones as possible.

I know.. I am not sure I would share this goal now -- not without some
checks and controls.

They are called good process. Hackers will hack no matter what.
professional programmers in a professionally run shop do not.

>Most of my types are integer and the operations used are basic
arithmetic.

integers can be < 0 or == 0. Also, what is sqrt then?

Something I don't do on them!

>>But even assuming such breaks are unnecessary, how really bad something
like

div(add(neg(b), sqrt(sub(mul(b, b), mul(4, mul(a, c))))), mul(2, a));

Close to indecipherable!

Lisp guys would kill you (I am not one of those). Seriously, does not
look too bad for me.

Then I guess you re a Lisp programmer and no a C++ one :)

>The most important parser is the human reading the code. We are used to
seeing arithmetic expressed with standard operators and can pretty well
subconsciously parse them.

That's the issue. C++ makes it easy to preserve a familiar syntax but
give it unexpected semantics. '+' means add() for numeric apps and most
people, and '*' means "multiply" for same domain, but a set
theorist/algebraist would not spend a second thought to make them
"union" and "intersection" for some sets in his C++ library and will
think it is cool (because C++ does not provide those special symbols set
theorists use for these operations but algebraically they have same
properties with +/- on numbers). Maybe s/he even implements his/her sets
by lists or vectors (after all, many logically unordered containers in
programming have to be implemented with some sequence underneath) and
someone who used to using "+" for concatenation (see an "Examples" table
in http://en.wikipedia.org/wiki/Concatenation to see what symbol
programmers having different background may find natural for this
operation as well what other C++ operators they may easily confuse with
concatenation or decide it natural to overload them for concatenation of
their types) will read it as concatenation and so will decide that those
sequences are concatenated by '+' operator (whereas they are being
joined, without duplicates). This latter mistake can be discovered quite
late in the game and cost a firm a fortune.

Long paragraph simple answer: context.

--
Ian Collins.

[Pavel]

James Kanze wrote:

>> -- Even in the case of Percentage, the way C++ spells it is
Percentage::operator++()

Does it? Did you solve my puzzle

....

>#include <iostream>
#include <string>
using namespace std;
int main(void) {
string a = "35" + 1;
cout << a << endl;
return 0;
}

>?

What does that have to do with the increment() function? You
seem to be mixing subthreads.

No, I was just trying (unsuccessfully) to return to the original topic
of passing by reference/value ambiguity and you were diverging by saying
that increment(), and even incrementPercentage() should actually be an
operator. I feel now we should have stayed with 'f()' because replacing
the majority of function names and purposes does not make sense (unless
you would state that relatively quite limited number of operators C++
has should be used to represent much bigger set of verbs and phrases
that function names can express) and I hoped to avoid discussion of
operators (simply because they would bring a whole new can of worms --
which they did :-) ). I really dislike broad and generic discussions.

So, I just tried to discourage you from discussing operators by showing
how ambiguous their meaning could be but you saw it as a challenge and
decided to stay to it. :-)

>Perl would give one of intuitively expected answers -- see

>perl -e 'print "35" + 1'

>and Java would give the second one (you can certainly come up
with the code itself).

The "intuitively expected" answer will obviously depend on the
overall philosophy of the language:

No, for C++ programmer, it will depend on his/her background, including
other programming languages, broader professional/educational background
(see set example in another thread) and the purposes for which s/he
overloaded this operator in the past, if s/he did at all.

for untyped languages, such
as Perl, AWK, etc., the intuitively expected response is "36";
for typed languages, such as C++ and Java, the only intuitively
expected response is a compiler error. Which neither Java nor
C++ get right (for different reasons).

Let's admit there is no right/wrong here -- unless it is used in a sense
of more or less ambiguous and any C++ operator may mean the highest
number of different actions.

See, I can write:

// pgm.cpp
#include <iostream>
#include <string>
#include "myheader.h"
using namespace std;

int main() {
string s2 = "255" + 3;
string s1 = "255";
string s3 = s1 + 3;
cout << "s1=" << s1 << " s2=" << s2 << " s3=" << s3 << endl;
return 0;
}
// myheader.h or same code much deeper in included files
#include <sstream>
std::string operator+(const std::string &left, int right) {
std::ostringstream oss;
oss << left << right;
return oss.str();
}

And I would probably expect s1 equal to s3 as a result.

However, depending on how the + operator is defined, C++ can treat s3 as
in C, as in Java (as in the example), as in Perl or AWK or as in any
other way, some of them logical for different people and no writes or
wrongs -- at least for many definitions. And the best C++ programmer
will have no way to know until s/he reads the header file. And even
then, s/he needs to pickup the applicable definition -- which is
possible, but time consuming and requires lining up all included
overloads first. What's worse, the meaning may change after including
some other header file, directly or indirectly.

....

I'm afraid that I don't see any real difference between Java and
C++ here. Not that it's really relevant; neither language is
perfect, and no reasonable person would pretend the contrary.
Both have their flaws. The basic question concerns the
totality, which depends on the application domain, but
doubtlessly favors C++ over Java most of the time.

see the example above

>Of course your "C++ way" goes much further:

>To inter-operate between your Percentage class and other
"glorified" numbers (say, to multiply percentage to some
quantity or whatever) you will have to overload helluva lot of
operators and/or allow same amount of conversions.

And? Designing a good interface does require a bit of typing.
And I'm not sure that you'd need that many overloads for
percentage. Not every operation makes sense on a percentage.

No, but adding a percentage makes sense for a values of different types.
Think of BigDecimals etc you introduced to the dis?ussion earlier; with
a slightly different semantics (say, rounding) of addition, then think
of people who will want to have a conversion from BigDecimals to, say,
doubles (isn't it natural -- all of these are numbers, after all), and
then think which particular operator '+' will be called if you have few
of them defined.

Also you correctly mentioned that the definition of some
application-specific numeric types like Price or Quantity or Money may
migrate from BigDecimal to double.. under all these possibilities do you
still want to use an operator and uniform syntax?

>

>>:-) (but that's really neither here
nor there---there are definitely functions which modify
state, for which there is no pre-defined operator).

>> -- Functions which modify state are normally members. You
don't write increment( object ), but rather
object.increment(). At least in principle: there are times
when, for various reasons, it's not possible, but it does
mean that the number of times the question comes up is
greatly reduced.

>No, you are confusing the number of times you would *use* the
non-const reference as a parameter and the number of times I
had to review the code using such references written by
someone (who was not you).

No. You're confusing your personal experience in poorly run
shops (where any language would fail) with absolute truths.

Well, this does not stand my experience:

1. I am not familiar with a single absolute truth.

2. There was no / is no pure failure -- there are costs related with the
projects in different languages. What you are essentially saying -- "if
you have never worked in a shop where C++ projects could be as
successful as the projects in C / Java etc ("success" can be defined
quite unambiguously in terms of meeting requirements in time at lower
cost etc) -- then you did not work for a well-run shop". I should
probably agree to you then -- I have to really think if I worked for
one, but I might as well agree that I have never worked for such a shop;
the only thing is I do not agree to define "well-run" in terms of
suitability for C++ specifically.

>Until there is no such sanction as disbarment in C++ as opposed to
legalese (even though the former might not be much simpler than the
latter), the easiness with which such mines are planted keeps and will
keep a lot of practitioners and managers away of C++. Not that I would
support such kind of regulation..

>> -- A function named "increment" increments, i.e. it modifies
state. Otherwise, it would have a different name, e.g.
"incrementedValue", or borrowing from Pascal "successor"
(which is better depends on the semantics of the object).
If for some reason it is not a member, it takes a non-const
reference as parameter. Period. You don't have to look
further.

>Then why to look at all? Just assume (as you just did) and put
your signature?

Exactly. Why look further.

And then, when the returned value will be (or not be -- whatever is
contrary to your assumption) the increased argument, you will share the
responsibility for not really reviewing the code; in fact, you will
carry greater responsibility as you were supposed to be a gatekeeper.

>> -- A function which modifies state is not used in more
complicated expressions: if it returns a value, it is the
old value, to allow client code to restore it. In the case
of increment, this is silly, of course, because if you know
the new value, you know the old. But in the case of things
like std::ios_base::setf(), etc., it's very useful. In the
case of member functions of objects with identity, it's
sometimes useful to return *this, to allow chaining, but
that's about the only case I can conceive of where you'd
return the "new" value.

>And so you would just assume the person who wrote the code you
are reviewing conceived same way as you and write your name on
the dotted line?

I would assume that any code which passed code review was
conform to the conventions in use in the company.

No, the code has not been reviewed yet, you are reviewing it now. Will
you just assume the effect corresponds to the name or you will go seek
the applicable definition? And if you have to go see the definition,
won't your performance be impeded by this (as comparing to C, in which
case you will not have to go see definition if you see the argument is
passed by value).

>>For the rest, expressivity is there for you to use, when
appropriate. It can obviously be abused, but that's not the
point.

>That exactly is my point that you are trying to avoid by all
means. I already agreed with all your points that C++ has a
lot of powerful and "cool" features (you can call them
expressive but I would be more comfortable if you used this
term consistently with some definition preliminary agreed on
between us.

Which is, after all, exactly what software engineering is all
about. If you don't do that, you might as well pack it up and
go home; no language is going to work for you.

>>If you want to discuss specific problems in C++, fine.
There's certainly no lack of subject matter. But too much
expressivity is NOT a defect, it's a definite advantage.

>No, seriously, let's define "expressivity".

The ability to say exactly what you want, clearly and concisely.

Does it include the ability of the reader to understand what you wanted
to say, clearly, easily and unambiguously? If not, I agree with all you
said about expressivity but do not think it is an advantage; if yes, I
disagree that C++ is more expressive than other languages; I would
rather argue it is one of the least expressive languages as the
understanding is most difficult and ambiguous although sometimes
deceptively clear.

>Again, your definition of "advantage" seems to be different
from mine and close to "having more useful features" (please
correct me if I am wrong).

My definition of "advantage" is, in the end, something that
reduces the cost of software development. Expressing exactly
what you want, clearly and concisely, definitely reduces the
cost of software development, and so is an advantage.

See my answer above

>Java has less (syntactic) features than C++, no doubts here;
however this is one of its properties that makes it attractive
to project managers (who need to hire people, maintain old
code, all at fixed costs, etc).

There are two things which make Java attractive to project
managers: the first is simply that it is more or less
"in"---it's not a good reason, but it's probably the most wide
spread one. The second is the support structure which is
available for certain types of applications.

There are many reasons, I agree, but low entry barrier and simple, less
error-prone syntax are clearly a big one.

Most algorithm courses changed their algorithm-teaching classes from
everything (Algol/Pascal/C++/MIX) to Java -- why if not for Java is
easier to learn and does not make a student to think too much on a
syntax, by that leaving more brain power to think on the problem). If
C++ were just "more expressive" but did not carry prohibitive costs with
it, they would be taught in C++.

(And no, it is not only because students can nicely present their
results as applets -- I am saying that because most assignments I saw on
the Internet ask to output the results on the console or file, probably
to spare them having to learn a lot of things irrelevant to the
algorithm course).

BTW, the fact that most students study Java as their first language has
some significance for the future of C++, too. I mean, to be popular with
Universities would definitely help a language to survive / prevail /
stay in wide use / grow -- the right verb depends on its current
standing in the industry.

>

>BTW It can still express all the same programs except for
system-level ones (the latter is not due to the lack of
features).

Sure. It's Turing complete. You just can't express them as
clearly and concisely.

Again see the paragraph above about your definition of expressivity.

>>(One last comment, with respect to using forward declarations in
C. Been there, done that. While they're obviously the way to
go for entity objects, you can't implement true value semantics
using forward declarations. Which is a major drawback if you
want or need value semantics.)

>Certainly not. If I need *pure* value semantics I can simply use
structures.

A structure doesn't necessarily have the semantics you want in
your pure value.

>And for "hybrids" (say, structures with integral and
variable-length strings data members) it is always safer and
often more efficient to honestly treat them as "entities" (I
am not sure this is a common term, I would use "objects" but
let it be) which they are -- in any language.

And that's simply wrong. A value is a value, and has entirely
different characteristics than an entity. Look at
java.lang.String, for example, for an example of a well designed
value in Java. (Note that it is final, has no mutable members
and... has overloaded operators.)

You are confusing me. I think you are introducing new concepts to the
discussion on purpose. Please defined them first. You complained that
with C you have to cross your fingers that nobody manipulates the fields
of the structures which you only wanted to be manipulated via functions.
I told you it can be assured by exposing forward declaration only and
hiding definition in the implementation files. How does such code change
make these structures entities from values in this sense in which you
started using them now (still not sure what it is, precisely)?

Also, why I cannot represent the analog to Java string in C if I hide
its declaration (but, I assume, I can do it if I do not hide it?)?

-Pavel

[Pavel]

Ian Collins wrote:

Pavel wrote:

>Ian Collins wrote:

>>Pavel wrote:

>>I still think most C++ programmers are familiar and at ease with
operator overloading. I'd even go so far as to saying they aren't C++
programmers if they are not.

>The problem is really not in unfamiliarity or uneasiness (in fact, the
easier a writers make a decision to overload an operator the worse,
IMHO) but in amount of information one needs to unambiguously say what
function or operator is called (not even what it does but what are the
parameters).

That is provided by the context the expression is used in. If the
expression is inappropriate for the context, it will be rejected by the
programmer's peers.

>>Don't forget the C++ design goal of
enabling user defined types to be as close to built in ones as possible.

>I know.. I am not sure I would share this goal now -- not without some
checks and controls.

They are called good process. Hackers will hack no matter what.
professional programmers in a professionally run shop do not.

>>Most of my types are integer and the operations used are basic
arithmetic.

>integers can be < 0 or == 0. Also, what is sqrt then?

Something I don't do on them!

>>>But even assuming such breaks are unnecessary, how really bad something
like

div(add(neg(b), sqrt(sub(mul(b, b), mul(4, mul(a, c))))), mul(2, a));

Close to indecipherable!

>Lisp guys would kill you (I am not one of those). Seriously, does not
look too bad for me.

Then I guess you re a Lisp programmer and no a C++ one :)

>>The most important parser is the human reading the code. We are used to
seeing arithmetic expressed with standard operators and can pretty well
subconsciously parse them.

>That's the issue. C++ makes it easy to preserve a familiar syntax but
give it unexpected semantics. '+' means add() for numeric apps and most
people, and '*' means "multiply" for same domain, but a set
theorist/algebraist would not spend a second thought to make them
"union" and "intersection" for some sets in his C++ library and will
think it is cool (because C++ does not provide those special symbols set
theorists use for these operations but algebraically they have same
properties with +/- on numbers). Maybe s/he even implements his/her sets
by lists or vectors (after all, many logically unordered containers in
programming have to be implemented with some sequence underneath) and
someone who used to using "+" for concatenation (see an "Examples" table
in http://en.wikipedia.org/wiki/Concatenation to see what symbol
programmers having different background may find natural for this
operation as well what other C++ operators they may easily confuse with
concatenation or decide it natural to overload them for concatenation of
their types) will read it as concatenation and so will decide that those
sequences are concatenated by '+' operator (whereas they are being
joined, without duplicates). This latter mistake can be discovered quite
late in the game and cost a firm a fortune.

Long paragraph simple answer: context.

I agree. I started this thread with the example where following C++ code
required studying the biggest non-local context -- as opposed to even an
equivalent C code. Can we at least agree that, given equal other
features, the language that requires studying less context to follow the
program wins in productivity and scalability?

-Pavel

[LR]

Pavel wrote:

Ian Collins wrote:

Too much, uh, context snipped?

>Long paragraph simple answer: context.

I agree. I started this thread with the example where following C++ code
required studying the biggest non-local context -- as opposed to even an
equivalent C code.

Could you please comment on this little C snippet, as I'm curious to
know what you think of it.

int doWhat(char *s, int n) {
return printf(s,n);
}

Can we at least agree that, given equal other features,

What are these equal features? PL/I's varying string vs Fortran's
CHARACTER vs C++'s std::string vs C's strcpy etc?

the language that requires studying less context to follow the
program wins in productivity and scalability?

In context? I'm not sure. How would you prove this claim? It seems
like an argument about how programmers work vs how they claim they work
vs how they think they work.
LR

[LR]

Pavel wrote:

1. I am not familiar with a single absolute truth.

See 1. above.

Most algorithm courses changed their algorithm-teaching classes from
everything (Algol/Pascal/C++/MIX) to Java --

Can you please tell me what your source for this is?

why if not for Java is
easier to learn and does not make a student to think too much on a
syntax, by that leaving more brain power to think on the problem). If
C++ were just "more expressive" but did not carry prohibitive costs with
it, they would be taught in C++.

I was under the impression that universities pick languages for many
reasons and not just some "technical" superiority. For example, a
professor might like one language and not another, or because of
pressure from local industry or parents who are worried about, or at
least claim to be worried about, the careers of the students. But I'm
not an academic. I snipped it, but I think that you made a similar
point about why companies choose certain languages. In fact, I think
this is a FAQ.

BTW, the fact that most students study Java as their first language has
some significance for the future of C++, too. I mean, to be popular with
Universities would definitely help a language to survive / prevail /
stay in wide use / grow -- the right verb depends on its current
standing in the industry.

Yes. Of course. You might find what Joel Spolsky has to say about C and
pointers instructive:
http://www.joelonsoftware.com/articl...000000073.html

Come to it, you might find what he has to say about Java as a teaching
tool instructive as well:
http://www.joelonsoftware.com/articl...vaSchools.html

Also, why I cannot represent the analog to Java string in C if I hide
its declaration (but, I assume, I can do it if I do not hide it?)?

I'm not sure that I follow that, but assuming I do, how could you
accomplish that?
LR

[stan]

LR wrote:

Pavel wrote:

>1. I am not familiar with a single absolute truth.

See 1. above.

>Most algorithm courses changed their algorithm-teaching classes from
everything (Algol/Pascal/C++/MIX) to Java --

Can you please tell me what your source for this is?

I'd be interested in that source also. The claim is totally opposite
from my experience. In fact the issue came up recently and after a few
phone calls we couldn't locate a single university in state that was
using java for algorithms. In fact all but one university was
considering dropping java as the introductory class. One of the issues
was that java isn't really that much fun when you stop using the
libraries. The trend seems to be to finish merging the computer science
with the computer engineering schools. While some computer science
classes seem to still use java for an introductory class, some are using
c++. All the computer engineering schools were using c++ for
introductory classes. Both the computer science and computer engineering
schools seem to be using c++ or more accurately a subset of c++ for the
algorithms classes.

The survey was informal and done out of curiosity after a similar claim
to the one above was made and questioned.

>

>why if not for Java is
easier to learn and does not make a student to think too much on a
syntax, by that leaving more brain power to think on the problem). If
C++ were just "more expressive" but did not carry prohibitive costs with
it, they would be taught in C++.

I don't know what "prohibitive costs" are being refered to here so I
can't comment. But I can say as noted above that the local university is
teaching in c++.

[Paavo Helde]

Pavel <dot_com_yahoo@paultolk_reverse.yourselfkirjutas :

[...]

That's the issue. C++ makes it easy to preserve a familiar syntax but
give it unexpected semantics. '+' means add() for numeric apps and
most people, and '*' means "multiply" for same domain, but a set
theorist/algebraist would not spend a second thought to make them
"union" and "intersection" for some sets in his C++ library and will
think it is cool (because C++ does not provide those special symbols
set theorists use for these operations but algebraically they have
same properties with +/- on numbers).

The example makes the issue much clearer: the problem is not the presence
of operator overloading in C++, but the fact that it is too restricted. The
number of different operator symbols is much less than a number of
different function names. In this light the solution is also obvious: there
is an entire Unicode range of mathematical operator symbols; one could just
make these legal for overloading in C++.

Yes I know this will not happen. What I wanted to say is that the operator
overloading is not bad by itself; it's just the current implementation in
C++ which has some drawbacks.

regards
Paavo

[Matthias Buelow]

Ian Collins wrote:

That's simply not true. My (and other teams) experience is that a pair
is more productive then two individuals.

You're insane, or your examples are trivial.
Do you really think you can make a programming job attractive to people
if they have someone else looking over their shoulder all the time?
Sounds like programmer's hell to me.

[Matthias Buelow]

James Kanze wrote:

And on what types of projects---I find
that at certain points, the limiting factor of my production is
typing speed.

If that is the case, then you're simply using a level of abstraction
that isn't high enough. I never found that _typing_ is a limiting factor
of programming, I'm not a secretary, after all.

[Joe Greer]

James Kanze <ja*********@gmail.comwrote in news:a0094446-7f6c-4f79-aba7-
a9**********@k13g2000hse.googlegroups.com:

course, compared with all of the rest.) Get rid of pointer
arithmetic, and C++ does the right thing. Get rid of the
conversions of numeric types to string in Java, and the Java
version does the right thing.

I think the problem isn't so much pointer arithmetic as it is that C++
doesn't have a built-in string type and there is only so much you can do
with a library only solution. Personally, I think that strings are so
fundamental that we really need a literal that represents a string and not
an array of chars.

joe

[Ian Collins]

Matthias Buelow wrote:

Ian Collins wrote:

>That's simply not true. My (and other teams) experience is that a pair
is more productive then two individuals.

You're insane, or your examples are trivial.
Do you really think you can make a programming job attractive to people
if they have someone else looking over their shoulder all the time?
Sounds like programmer's hell to me.

What part of working together don't you understand?

--
Ian Collins.

[Matthias Buelow]

Ian Collins wrote:

What part of working together don't you understand?

The part about "pair programming". I have nothing against "working
together", if that means interaction and cooperation between programmers
working on individual parts of a project. However, the idea of two
people sitting in front of a machine and trying to program as a pair
sounds just silly, imho. For that to work, you'd need to connect the two
brains with a high-bandwidth, low-latency interconnect, which verbal
communication certainly isn't. In addition, you'd need the two people to
have congruent ways of thinking about problems. Most likely this would
only be possible with very experienced people, who likely are more
productive if each worked on his own part. Maybe the method works with
unsophisticated projects such as constructing GUIs and programs which
exhibit simple, pattern-like relationships between their constituents.

[Ian Collins]

Matthias Buelow wrote:

Ian Collins wrote:

>What part of working together don't you understand?

The part about "pair programming". I have nothing against "working
together", if that means interaction and cooperation between programmers
working on individual parts of a project. However, the idea of two
people sitting in front of a machine and trying to program as a pair
sounds just silly, imho.

From that I can see you have never tried it.

For that to work, you'd need to connect the two
brains with a high-bandwidth, low-latency interconnect, which verbal
communication certainly isn't. In addition, you'd need the two people to
have congruent ways of thinking about problems.

Nope, the more diverse the better.

Most likely this would
only be possible with very experienced people, who likely are more
productive if each worked on his own part.

Nope, mixed levels of experience work well together, as do programmers
and domain experts.

Maybe the method works with
unsophisticated projects such as constructing GUIs and programs which
exhibit simple, pattern-like relationships between their constituents.

Nope, the more complex the problem, the better it works. Trivial tasks
often consist of little more than typing.

--
Ian Collins.

[stan]

Ian Collins wrote:

Matthias Buelow wrote:

>Ian Collins wrote:

>>What part of working together don't you understand?

The part about "pair programming". I have nothing against "working
together", if that means interaction and cooperation between programmers
working on individual parts of a project. However, the idea of two
people sitting in front of a machine and trying to program as a pair
sounds just silly, imho.

From that I can see you have never tried it.

>For that to work, you'd need to connect the two
brains with a high-bandwidth, low-latency interconnect, which verbal
communication certainly isn't. In addition, you'd need the two people to
have congruent ways of thinking about problems.

Nope, the more diverse the better.

>Most likely this would
only be possible with very experienced people, who likely are more
productive if each worked on his own part.

Nope, mixed levels of experience work well together, as do programmers
and domain experts.

>Maybe the method works with
unsophisticated projects such as constructing GUIs and programs which
exhibit simple, pattern-like relationships between their constituents.

Nope, the more complex the problem, the better it works. Trivial tasks
often consist of little more than typing.

Very bold and emphatic claims. Seems you leave very litle possibility
that it might not be the best solution in every case. IMHO I see no
reason to believe this isn't simply yet another software development
silver bullet. Only time will provide a valid answer, everything else is
marketing hype and speculation..

[Ian Collins]

stan wrote:

Ian Collins wrote:

>Matthias Buelow wrote:

>>Ian Collins wrote:

What part of working together don't you understand?
The part about "pair programming". I have nothing against "working
together", if that means interaction and cooperation between programmers
working on individual parts of a project. However, the idea of two
people sitting in front of a machine and trying to program as a pair
sounds just silly, imho.

From that I can see you have never tried it.

>>For that to work, you'd need to connect the two
brains with a high-bandwidth, low-latency interconnect, which verbal
communication certainly isn't. In addition, you'd need the two people to
have congruent ways of thinking about problems.

Nope, the more diverse the better.

>>Most likely this would
only be possible with very experienced people, who likely are more
productive if each worked on his own part.

Nope, mixed levels of experience work well together, as do programmers
and domain experts.

>>Maybe the method works with
unsophisticated projects such as constructing GUIs and programs which
exhibit simple, pattern-like relationships between their constituents.

Nope, the more complex the problem, the better it works. Trivial tasks
often consist of little more than typing.

Very bold and emphatic claims. Seems you leave very litle possibility
that it might not be the best solution in every case. IMHO I see no
reason to believe this isn't simply yet another software development
silver bullet. Only time will provide a valid answer, everything else is
marketing hype and speculation..

I don't make any silver bullet claims. I'm just reporting my personal
experience on non-trivial (6-10 people, 3years+) C++ projects.

--
Ian Collins.

[stan]

Ian Collins wrote:

stan wrote:

<snip>

>Very bold and emphatic claims. Seems you leave very litle possibility
that it might not be the best solution in every case. IMHO I see no
reason to believe this isn't simply yet another software development
silver bullet. Only time will provide a valid answer, everything else is
marketing hype and speculation..

I don't make any silver bullet claims. I'm just reporting my personal
experience on non-trivial (6-10 people, 3years+) C++ projects.

I'm reasonably certain you've been programming longer than 3 years; so
have I so we'll just dispense with cv's and if I can be so bold I'll
stipulate that we are both experienced. You dont say but I'm guessing
form the above that you haven't seen it fail. Ok. I have seen it fail.
Maybe it wasn't done right or possibly failure was due to some other
reason I can't fathom. My point is that in 30 years we'll have a clear
answer if the "pair" paradigm is the correct way to go or if it is more
like the hula hoop or disco. I'll even concede that you may have to wait
some time to get a good read on how well it holds up because many of the
current generation aren't used to it and will oppose a change in the way
they are used to doing things.

I'm not saying you are wrong. I don't really know. I have seen a lot of
ideas about how to program come and go almost like seasons. I keep
rereading Fred Brooks and finding that we keep repeating past mistakes.
It's pretty scary how well his writings describe programming shops. Of
course I find Dilbert to be a little close for comfort also.

[coal]

On Aug 15, 4:33*am, James Kanze <[e-mail]:

On Aug 15, 6:12 am, Pavel <dot_com_yahoo@paultolk_reverse.yourself>
wrote:

-- and will with the probability increasing with the size of
the project. It is just an incredible luck to never have a
person who does not care enough or simply does not fully
understand the [complex] process on a team of a significant
size during a significant time period (both are required for
sizable projects).

I can see you've never worked with any sort of process. *It's
extremely rare to find someone who intentionally wants to make
life hard for others.

Twenty years ago I think there was some truth to that.
Increasingly though due to a drop in morality there are
problems like this:

Cockpit conflicts 'threatening safety'
Younger pilots allegedly bullying older airmen
into resigning or retiring to save their own jobs
http://www.aftenposten.no/english/lo...cle2615859.ece

I saw some of this coming years ago and started Ebenezer
Enterprises to avoid the crappy work environments those
pilots face. I'm thankful to G-d for leading me to start
the company.

Brian Wood
http://webEbenezer.net

[James Kanze]

On Aug 18, 1:48 pm, Matthias Buelow <[e-mail]:

James Kanze wrote:

And on what types of projects---I find
that at certain points, the limiting factor of my production is
typing speed.

If that is the case, then you're simply using a level of
abstraction that isn't high enough. I never found that
_typing_ is a limiting factor of programming, I'm not a
secretary, after all.

If you've done the design an analysis, the programming (coding)
itself is pretty much just typing. If it isn't, then you've not
done enough design up front.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Ian Collins]

James Kanze wrote:

On Aug 18, 1:48 pm, Matthias Buelow <[e-mail]:

>James Kanze wrote:

>>And on what types of projects---I find
that at certain points, the limiting factor of my production is
typing speed.

>If that is the case, then you're simply using a level of
abstraction that isn't high enough. I never found that
_typing_ is a limiting factor of programming, I'm not a
secretary, after all.

If you've done the design an analysis, the programming (coding)
itself is pretty much just typing. If it isn't, then you've not
done enough design up front.

Or you follow a different process.

--
Ian Collins.

[stan]

Ian Collins wrote:

James Kanze wrote:

>On Aug 18, 1:48 pm, Matthias Buelow <[e-mail]:

>>James Kanze wrote:
And on what types of projects---I find
that at certain points, the limiting factor of my production is
typing speed.

>>If that is the case, then you're simply using a level of
abstraction that isn't high enough. I never found that
_typing_ is a limiting factor of programming, I'm not a
secretary, after all.

If you've done the design an analysis, the programming (coding)
itself is pretty much just typing. If it isn't, then you've not
done enough design up front.

Or you follow a different process.

I question that typing before thinking qualifies as a process.

[coal]

On Aug 31, 2:09*pm, Ian Collins <[e-mail]:

James Kanze wrote:

On Aug 18, 1:48 pm, Matthias Buelow <[e-mail]:

James Kanze wrote:
And on what types of projects---I find
that at certain points, the limiting factor of my production is
typing speed.

If that is the case, then you're simply using a level of
abstraction that isn't high enough. I never found that
_typing_ is a limiting factor of programming, I'm not a
secretary, after all.

If you've done the design an analysis, the programming (coding)
itself is pretty much just typing. *If it isn't, then you've not
done enough design up front.

I think this would be improved by taking out the words
"pretty much just." The typing process is more complicated
than any man-made system. A brain injury is helpful in
reminding you of the difficulty we endure to acquire
dexterity.

We go through an iterative process of design and
programming where we improve the design based on what we
learn from implementing the design and from testing both
the design and implementation. If you try to bite off
more than you can chew, you can become bogged down in
the design work.

Or you follow a different process.

I don't recommend putting monkeys in a room and
hoping they'll eventually solve the problem.
Brian Wood
http://webEbenezer.net

[Ian Collins]

stan wrote:

Ian Collins wrote:

>James Kanze wrote:

>>On Aug 18, 1:48 pm, Matthias Buelow <[e-mail]:
James Kanze wrote:
And on what types of projects---I find
that at certain points, the limiting factor of my production is
typing speed.
If that is the case, then you're simply using a level of
abstraction that isn't high enough. I never found that
_typing_ is a limiting factor of programming, I'm not a
secretary, after all.
If you've done the design an analysis, the programming (coding)
itself is pretty much just typing. If it isn't, then you've not
done enough design up front.

Or you follow a different process.

I question that typing before thinking qualifies as a process.

Where did I say anything about typing before thinking?

--
Ian Collins.

[Chris H]

In message <48**********@mk-nntp-2.news.uk.tiscali.com>, kwikius
<an**@servocomm.freeserve.co.ukwrites

>That said C++ and C will be around a long time. For windows they will be
around as long as its around I guess, but I don't see there being as much
demand for C++ programmers.

C and C++ are separate languages. C will be around for a very long
time and it is very widely used in some rather large areas. Particularly
those where there is no C++ It will outlast C++ by a long way as there
is nothing like Java, C#. .Net and other languages snapping at it's
heels
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[Hydra-Boy]

Uzytkownik "Chris H" <ch***@phaedsys.orgnapisal w wiadomosci
news:VC**************@phaedsys.demon.co.uk...

In message <48**********@mk-nntp-2.news.uk.tiscali.com>, kwikius
<an**@servocomm.freeserve.co.ukwrites

>>That said C++ and C will be around a long time. For windows they will be
around as long as its around I guess, but I don't see there being as much
demand for C++ programmers.

C and C++ are separate languages. C will be around for a very long time
and it is very widely used in some rather large areas. Particularly those
where there is no C++ It will outlast C++ by a long way as there is
nothing like Java, C#. .Net and other languages snapping at it's heels
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

C++ is the best programming language ever... :). Why it is so good?
Cuz you can do everything in C++ what you want.
If you will look closer at other programming languages you will see that
most of them base on C++.
Other programming languages have different syntax, keywords but end of ends
they are C++.

Yeah, I know... I am a big fan of C++ ;).
-- Posted on news://freenews.netfront.net - Complaints to ne**@netfront.net --

[Walter Bright]

Pavel wrote:

(plus, an equivalent C program usually compiles 10
times faster than C++ -- because "smart guys" like inserting templates
and meta-programming wherever they don't need them or at least they will
include a couple of "cool" headers -- so a change/compile/debug
iteration in C is much shorter than in C++).

Not sure how to break this vicious cycle -- it seems the more powerful a
language is the more it gets abused and the more it hurts the
productivity.

The compilation speed issue C++ is not the inevitable result of its
power, it is the result of not having a proper module system and the
migration of implementation code into the headers. It is also the result
of the template metaprogramming system having to do far too much work.

----------------------
Walter Bright
Digital Mars
http://www.digitalmars.com
C, C++, D programming language compilers