Help a C++ coder see the light

[Dave Brueck]

I'm used to the compiler/linker giving me a lot of reassurance that my
code works.

That's common, but in many cases it's a _false_ sense of reassurance.
Even in C++ I end up checking all uses of a refactored function despite
what the compiler says because it can catch only the simplest of problems.

The more nasty problem is changing a function to have, say, an extra
argument. In C++ I'd just run the code through the compiler and it would
tell me all the places where the code needs updating.

Not necessarily; consider what happens when you change an API that has
default arguments - your compiler may or may not catch bugs that got
introduced. Here's a contrived example of changing this:

void Foo(int x, int y, int alpha=0)

to this:

void Foo(int x, int y, int z, int alpha=0)

Old calls like Foo(x,y) are flagged by the compiler, but old calls like
Foo(x,y,alpha) are not, and are bugs.

In python I'd have to trust grep (and follow up all the cases where the
function was assigned a new name, passed to a callback interface etc.
and/or where the arguments are built somewhere else and just passed in
via "apply").

In reality, in C++ _and_ Python you'd trust your test cases. :)

As far as I can tell, the only way to have the same confidence in ones
code as you'd get with C++ (albeit using code that might take you a lot
longer to write), is to have unit tests that exercise absolute 100% code
coverage. Which is dauntingly difficult to create even in a more static
language like C++.

The law of diminishing returns applies - even if you can't get 100% code
coverage you can get the lion's share of the bugs by focusing on the more
complicated parts of the code, or on parts that have been modified the
most or most recently. Having said that though, it's tough to sleep well
at night when there's lots of holes in your testing, regardless of
language used. :)

However there are large programs out there written in python, so it
obviously can be done.

This discussion comes up a lot, and one aspect of it that we consistently
fail to overlook is that successful large programs have different higher
levels of coupling than small ones. The "can't use Python for large
projects" logic usually goes something like this:

"In a small program, two different functions can call function X, so
without development-type arg and type checking I have to check those two
functions if I change X. Large programs have lots of functions, so I would
have to check and possibly change a million different places. Therefore,
it's not feasible to use Python on a large project because it would take
too much maintenance and risk of breaking things is too high."

In truth, though, in a large project every function _won't_ be allowed to
call any other function, and it's usually through pretty well-defined and
limited interfaces that inter-module "communication" takes place, so
the vast majority of bug fixing, refactoring, etc. code changes are quite
local, or your system is suffering from poor design.

In the cases where refactoring of those more public interfaces is
necessary, then, yes, you do have to do a lot of work to check to make
sure nothing gets broken, but it's certainly no more work than a similar
change in a large C++ program (and that's why a lot more thought goes into
designing those interfaces in the first place).

-Dave

[holger krekel]

I've been coding C++ for years now and Python for a few months.
Incidentally, I'd say that Python's greatest strength is that it took me
about two months to become as competent at Python as I was after two years
of C++.
However, what's nice flexibility in a small Python project (we're using
python to script a callback interface, and its very easy to support
arbitrary functions taking arbitrary arguments) would give me the
screaming heebie-jeebies in a larger project.
I'm used to the compiler/linker giving me a lot of reassurance that my
code works. Python removes that reassurance and just leaves it to runtime
errors.

I understand this situation and had it myself. But i learned
from people here on this list that writing "unit tests" is a
brilliant solution for the problems at hand.

Basically, type checks only ensure correct behaviour at a very
low level. You can cover much more ground if you write little
tests (really twoliners in many cases) that check that your
methods actually perform as expected in a *semantic* way.

myVal = -myVar
CalculateSquareRoot(myVar)

If this would be in a function 'square_root_abs' you would write

def test_square_root_abs(self):
obj = cls()
self.assertEquals(1,square_root_abs(1))
self.assertEquals(1,square_root_abs(-1))
self.assertEquals(2,square_root_abs(4))

Of course you would continue to define what behaviour
you want for floats etc.pp. Now this test catches a lot
more behaviour problems than compile-time type-checking
can do.

Having a lot of tests like this makes a programmer's live
really less stressfull. And python is good language to
write down simple tests. With C++ & Java i never really
cared that much for fine-grained tests. It was just to
painful especially during refactoring.

holger

[Lulu of the Lotus-Eaters]

|> Probably-this-very-post-has-bugs-ly yours, Lulu...

|Ah - the old "indirect boasting technique". Very nicely applied,
|but I spotted it!

Not quite, I think. The boasting-by-satirical-self-deprecation
technique isn't QUITE the same thing as the boasting-through-indirection
technique. They are certainly in the same family, but take a look at
the book _Braggadocio Patterns_ for a discussion of the difference in
application.

Self-exemplification-is-an-aspect-not-a-pattern-ly yours, Lulu...

--
mertz@ | The specter of free information is haunting the `Net! All the
gnosis | powers of IP- and crypto-tyranny have entered into an unholy
.cx | alliance...ideas have nothing to lose but their chains. Unite
| against "intellectual property" and anti-privacy regimes!
-------------------------------------------------------------------------

[holger krekel]

Post by holger krekel
With C++ & Java i never really
cared that much for fine-grained tests. It was just to
painful

I write such tests in C++ all the time. What's the big deal? How are you
going to know your 3D graphics math is correct unless you actually display
it on the screen and take a look-see? Sure, my coding progress is slow.

That's it, i guess. Of course you can write tests in any language
but some make it easy and fast and others make it tiresome.

But it's also bug-free.

That's a bold statement which even brilliant programmers tend to avoid.

That's the fully loaded cost of development: you
can either pay less now or more later. I agree that testing is what people
need to do, but it's a totally language-neutral solution.

Theoretically, yes. Practically, development time does matter.

holger

[Lulu of the Lotus-Eaters]

holger krekel <pyth at devel.trillke.net> wrote previously:
|> But it's also bug-free.
|That's a bold statement which even brilliant programmers tend to avoid.

I would go even further than Holger. I think it a pretty firm rule that
the more experienced and talented a programmer is, the LESS likely s/he
is to claim her code is bug free.

Probably-this-very-post-has-bugs-ly yours, Lulu...

--
mertz@ | The specter of free information is haunting the `Net! All the
gnosis | powers of IP- and crypto-tyranny have entered into an unholy
.cx | alliance...ideas have nothing to lose but their chains. Unite
| against "intellectual property" and anti-privacy regimes!
-------------------------------------------------------------------------

[Alexander Schmolck]

The more nasty problem is changing a function to have, say, an extra
argument. In C++ I'd just run the code through the compiler and it would
tell me all the places where the code needs updating. In python I'd have
to trust grep (and follow up all the cases where the function was assigned
a new name, passed to a callback interface etc. and/or where the arguments
are built somewhere else and just passed in via "apply").

Are you talking of this case?

def aTest():
print "HI"
def bTest():
return aTest(3)

pychecker seems to handle that fine:

/home/hobbes3/aschmolc/py/test.py:4: Invalid arguments to (aTest), got 1, expected 0

If you use a recent version of python-mode in emacs, you can do C-c C-w to run
pychcker like and jump to the offending files and lines by just clicking on
the error messages (I submitted a patch some time, which Barry has
incorporated -- it might still be only available from CVS, though).

Anyway, the right solution to this problem is not so much compile time
checking but a refactoring browser. If you don't want to switch to smalltalk,
try http://bicyclerepair.sourceforge.net/ for python, which however still is
alpha.


alex

[Alan Morgan]

In article <m3of5yf6hs.fsf at ferret.object-craft.com.au>,

Ahhh yes, the excellent safety net of the compiler/linker. It
compiles, my work is done...
- - calculate-wage.c - - - - - - - - - - - - - - - - - - - - -
#include <stdio.h>
float calculate_weekly_wage(float hours, float rate)
{
if (hours > 37.5)
return 37.5 * rate + (37.5 - hours) * rate * 1.5;
return hours * rate;
}
int main(int argc, char *argv[])
{
float hours = 45.0;
float rate = 10.0;
printf("Worked %.2f hours at $%.2f hourly rate.\n", hours, rate);
printf(" -> wage (including overtime) is $%.2f.\n",
calculate_weekly_wage(hours, rate));
return 0;
}
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
% cc calculate-wage.c -o calculate-wage
% ./calculate-wage
Worked 45.00 hours at $10.00 hourly rate.
-> wage (including overtime) is $262.50.
What!!! How can that be!!! It passed through the compiler/linker
safety net.

It's obvious. You had the arguments to calculate_weekly_wage backwards.

You should have written

printf(" -> wage (including overtime) is $%.2f.\n",
calculate_weekly_wage(rate, hours));

Alan

[Neil Hodgson]

Post by Alan Morgan
It's obvious. You had the arguments to calculate_weekly_wage backwards.
You should have written
printf(" -> wage (including overtime) is $%.2f.\n",
calculate_weekly_wage(rate, hours));

No, it's obvious that there should be explicit Rate and TimeDelta classes
with well defined combining operators, no conversion operators, and an
operator- that takes a TimeDelta on the left hand side and a float on the
RHS. But no operator- for the other way around.

Neil

[Dave Cole]

Post by Dave Brueck

I'm used to the compiler/linker giving me a lot of reassurance
that my code works.

That's common, but in many cases it's a _false_ sense of
reassurance.

Brandon> It kills many problems before they arise.

Post by Dave Brueck
Even in C++ I end up checking all uses of a refactored function
despite what the compiler says because it can catch only the
simplest of problems.

Brandon> Sounds like your functions must do an awful lot if they need
Brandon> so much checking. Maybe your functions should be smaller,
Brandon> more incremental, easier to verify?

Ahhh yes, the excellent safety net of the compiler/linker. It
compiles, my work is done...

- - calculate-wage.c - - - - - - - - - - - - - - - - - - - - -
#include <stdio.h>

float calculate_weekly_wage(float hours, float rate)
{
if (hours > 37.5)
return 37.5 * rate + (37.5 - hours) * rate * 1.5;
return hours * rate;
}

int main(int argc, char *argv[])
{
float hours = 45.0;
float rate = 10.0;

printf("Worked %.2f hours at $%.2f hourly rate.\n", hours, rate);
printf(" -> wage (including overtime) is $%.2f.\n",
calculate_weekly_wage(hours, rate));
return 0;
}
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

% cc calculate-wage.c -o calculate-wage
% ./calculate-wage
Worked 45.00 hours at $10.00 hourly rate.
-> wage (including overtime) is $262.50.

What!!! How can that be!!! It passed through the compiler/linker
safety net.

Ahh... This gcc is crap. Maybe I need to use the intel compiler.

- Dave

[Dave Cole]

Dennis> Dave Cole fed this fish to the penguins on Thursday 30 January

Worked 45.00 hours at $10.00 hourly rate.

-> wage (including overtime) is $262.50.

What!!! How can that be!!! It passed through the compiler/linker
safety net.

Dennis> I had to go back to spot that error -- I was blinded
Dennis> by "... TWO return statements? How ugly... How might I do
Dennis> it...

In Python rather than C?

Dennis> return (hours * rate) + (max(0, hours - 37.5) * rate * 0.5)

Dennis> (obviously this formulation also corrected for the error <G>)

Yeah, and I bet you used the Intel compiler too!

- Dave

[Brandon Van Every]

What!!! How can that be!!! It passed through the compiler/linker
safety net.

I'm not even going to try to read/understand your code. I will note that
you're using printf, which is not a typed printing method. Try <iostream>

--
Cheers, www.3DProgrammer.com
Brandon Van Every Seattle, WA

20% of the world is real.
80% is gobbledygook we make up inside our own heads.

[Geoff Gerrietts]

You know, I've only sorta been following this thread, so I can't
respond to the original, and I can't be 100% sure my points haven't
already been raised, but that's not going to stop me from making them
(ooh, ouch, does this make me a bad person?)

The lack of type checking and name declaration in python offers great
flexibility, but it does come at a cost. The cost can largely be
mitigated by writing unit testing, and test-first development does
seem to result in shorter development cycles. This efficiency is even
higher in python, since it's easy to write unit tests (see another
opinionated post by me, dated today).

The lack of type checking and name declaration does present some
challenges, but nothing nearly as challenging as the memory management
issues offered by C++. Any way you want to draw the comparisons, these
pitfalls are by far worse, and the bigger the software project, the
more likely you'll encounter them. These errors are easier to
accidentally encounter, with things like implicit copy creation,
direct pointer management, and direct memory allocation. They are also
generally more severe, producing unrecoverable crashing defects, and
potentially generating mammoth-sized security holes.

Sometimes, I miss a type checker, especially since I've had trouble
getting many "favorite" python development tools to work with some of
my projects. Sometimes, I miss the ease of distribution offered by a
compiled program, or the execution speed.

But then I go spend some time programming in those other languages,
the ones I think I missed, and I remember why it is I like to write
all my code in Python. Some of it is about the dynamic flexibility,
but mostly, it's the lack of horrifying pitfalls.

If you're the sort who tends to fumblefinger the typing a couple times
a day, or the sort who never leaks memory or segfaults, or the sort
whose software designs are so brilliantly done that changes rarely
requires recompilation of more than a single file at a time -- if
you're one of a billion different sorts of programmers, that I am not,
you may find the type checking to be an insurmountable barrier. I
don't, and I'm willing to bet most won't.

--G.

[Mongryong]

Check out PyChecker: http://pychecker.sourceforge.net/

Then, write lots of unit tests.

If you're concern about type-checking, don't be. If a paramter does not
support a 'feature', an exception is thrown and you can figure out where
the fault is. Remember, Python is all about polymorhism and re-use.

Oh, there is a way to do run-time type-checking in Python but its
needless overhead and very bad. It's one of the many ways in Python
that you'll end up shooting yourself in the foot or blowing off your
leg.

[Ville Vainio]

As far as I can tell, the only way to have the same confidence in ones
code as you'd get with C++ (albeit using code that might take you a lot

You have confidence in the code you write in C++? Now that's what I
call misplaced optimism...

Seriously though, even though the error you mention might require
extra testing, at least the errors can be fixed immediately when they
occur. When my C++ program crashes (in production environment w/o
debugging tools), I get annoyed because I know I have to try to
replicate the error and tighten the logging to pin down the location.
When a Python program crashes (which it does, instead of happily
continuing after writing garbage to adjacent memory buffer), I'm happy
because I have found and immediately squashed yet another bug. There
is no need for heavy debugging machinery, someone just sends you a
traceback via email or whatever.

However there are large programs out there written in python, so it
obviously can be done. So are folks here just preternaturally good

When my python programs get bigger, I feel more and more happy that
the program is indeed in Python, not C++. One tends to write more OO
code in Python, while in C++ programming in OO style is awkward, which
tends to increase the amount of lazy hacks that harm the growth
potential of the program. You can also totally ignore many security
considerations of large bodies of C/C++ code (buffer overflows).

[holger krekel]

Post by Ville Vainio

As far as I can tell, the only way to have the same confidence in ones
code as you'd get with C++ (albeit using code that might take you a lot

You have confidence in the code you write in C++? Now that's what I
call misplaced optimism...
Seriously though, even though the error you mention might require
extra testing, at least the errors can be fixed immediately when they
occur. When my C++ program crashes (in production environment w/o
debugging tools), I get annoyed because I know I have to try to
replicate the error and tighten the logging to pin down the location.
When a Python program crashes (which it does, instead of happily
continuing after writing garbage to adjacent memory buffer), I'm happy
because I have found and immediately squashed yet another bug. There
is no need for heavy debugging machinery, someone just sends you a
traceback via email or whatever.

Note, though, that with complex python programs you can get tracebacks
that carry not much more information than a segmentation fault.
E.g. Zope sometimes presents tracebacks that are not easy to
interprete unless you know the internals pretty well.

Of course, Python makes it easier to present errors gracefully
and i agree with your other points.

holger

[Cameron Laird]

In article <mailman.1043956135.5480.python-list at python.org>,
Dave Brueck <dave at pythonapocrypha.com> wrote:
.
.
.

Post by Dave Brueck
In the cases where refactoring of those more public interfaces is
necessary, then, yes, you do have to do a lot of work to check to make
sure nothing gets broken, but it's certainly no more work than a similar
change in a large C++ program (and that's why a lot more thought goes into
designing those interfaces in the first place).
-Dave

Folks have done a great job of following up in this thread.
I'll toss in the proposition that Python is *better* than
C++ for programming in the large. Without time now to argue
the point, I'll just observe that big Python programs aren't
as big as their functional equivalents in C++.

[Brandon Van Every]

Post by holger krekel
With C++ & Java i never really
cared that much for fine-grained tests. It was just to
painful

I write such tests in C++ all the time. What's the big deal? How are you
going to know your 3D graphics math is correct unless you actually display
it on the screen and take a look-see? Sure, my coding progress is slow.
But it's also bug-free. That's the fully loaded cost of development: you
can either pay less now or more later. I agree that testing is what people
need to do, but it's a totally language-neutral solution.

Post by holger krekel
especially during refactoring.

Write a small amount of new code. Leave the small amount of old code and
the old test alone. You might need to go *back* to that tried-and-true
it-works it's-been-tested thing! Only refactor something out of existence
when you're sure that you'll never need it again and it's The Correct Thing
To Do.

--
Cheers, www.3DProgrammer.com
Brandon Van Every Seattle, WA

20% of the world is real.
80% is gobbledygook we make up inside our own heads.

[Mark Charsley]

I've been coding C++ for years now and Python for a few months.
Incidentally, I'd say that Python's greatest strength is that it took me
about two months to become as competent at Python as I was after two years
of C++.

However, what's nice flexibility in a small Python project (we're using
python to script a callback interface, and its very easy to support
arbitrary functions taking arbitrary arguments) would give me the
screaming heebie-jeebies in a larger project.

I'm used to the compiler/linker giving me a lot of reassurance that my
code works. Python removes that reassurance and just leaves it to runtime
errors.

The most annoying is typos along the lines of:

if myVar < 0:
myVal = -myVar
CalculateSquareRoot(myVar)

which I believe PyChecker (and probably other tools) can catch.

The more nasty problem is changing a function to have, say, an extra
argument. In C++ I'd just run the code through the compiler and it would
tell me all the places where the code needs updating. In python I'd have
to trust grep (and follow up all the cases where the function was assigned
a new name, passed to a callback interface etc. and/or where the arguments
are built somewhere else and just passed in via "apply").

As far as I can tell, the only way to have the same confidence in ones
code as you'd get with C++ (albeit using code that might take you a lot
longer to write), is to have unit tests that exercise absolute 100% code
coverage. Which is dauntingly difficult to create even in a more static
language like C++.

However there are large programs out there written in python, so it
obviously can be done. So are folks here just preternaturally good
programmers that don't need the safety net of a compiler/linker? Are there
some handy python code-coverage tools of which I am unaware? Or do they
just trust to lots of testing and fixing run-time errors as and when they
occur (which, I grant you, also happens in the C++ world with errors
beyond the powers of cl.exe to catch)?

[Brandon Van Every]

Post by Dave Brueck

I'm used to the compiler/linker giving me a lot of reassurance that
my code works.

That's common, but in many cases it's a _false_ sense of reassurance.

It kills many problems before they arise.

Post by Dave Brueck
Even in C++ I end up checking all uses of a refactored function
despite what the compiler says because it can catch only the simplest
of problems.

Sounds like your functions must do an awful lot if they need so much
checking. Maybe your functions should be smaller, more incremental, easier
to verify?

--
Cheers, www.3DProgrammer.com
Brandon Van Every Seattle, WA

20% of the world is real.
80% is gobbledygook we make up inside our own heads.

[Dave Brueck]

Post by Dave Cole

Post by Dave Brueck

I'm used to the compiler/linker giving me a lot of reassurance that
my code works.

That's common, but in many cases it's a _false_ sense of reassurance.

It kills many problems before they arise.

Well, you didn't really elaborate so I can only guess what you meant, but
I can't think of any real-world problems it finds that aren't caught just
as adequately in the tests. Plus, it certainly doesn't catch algorithmic
errors, which tests do.

In any case, I don't think anyone is arguing that the compile-time checks
provide _zero_ benefit, only that the benefits are often overrated and are
sometimes mixed signals (such as the default arg example I cited earlier).

Post by Dave Cole

Post by Dave Brueck
Even in C++ I end up checking all uses of a refactored function
despite what the compiler says because it can catch only the simplest
of problems.

Sounds like your functions must do an awful lot if they need so much
checking.

Why do you say that? What do you mean by "so much checking"? For some it's
a matter of just looking at the function call, for others it's walking
through the code. It really depends on what the refactorization was, no?

Post by Dave Cole
Maybe your functions should be smaller, more incremental, easier to
verify?

You're kidding, right?

-Dave

[Grzegorz Adam Hankiewicz]

[...] C++ has the industrial weight behind it and that's terribly
important to my business and long-term goals. I'd drop any
consideration of Python in a second if I thought it was likely to
disappear over the next 25 years.

If "industrial weight" is what you really need, you might as well
program your 3d game in java <shudder>.

[Brandon Van Every]

Post by Dave Brueck

Post by Dave Cole

Post by Dave Brueck

I'm used to the compiler/linker giving me a lot of reassurance that
my code works.

That's common, but in many cases it's a _false_ sense of
reassurance.

It kills many problems before they arise.

Well, you didn't really elaborate so I can only guess what you meant,

That's ridiculous. You jolly well know what I meant, you're just
pooh-poohing the engineering value of it.

Post by Dave Brueck
but I can't think of any real-world problems it finds that aren't
caught just as adequately in the tests.

But I don't have to *write* the compiler typechecking. I do have to write
the tests. Anal retentive as I am, I don't have time to write *all* tests.

Post by Dave Brueck

Post by Dave Cole

Post by Dave Brueck
Even in C++ I end up checking all uses of a refactored function
despite what the compiler says because it can catch only the
simplest of problems.

Sounds like your functions must do an awful lot if they need so much
checking.

Why do you say that?

I can't help you on how to engineer things properly and incrementally. It's
way too big a discussion topic and requires specifics.

Post by Dave Brueck
It really depends on what the refactorization was, no?

Sure. Don't make a mess out of it. Refactoring is supposed to *simplify*
your life.

Post by Dave Brueck

Post by Dave Cole
Maybe your functions should be smaller, more incremental, easier to

verify?

Post by Dave Brueck
You're kidding, right?

No.

--
Cheers, www.3DProgrammer.com
Brandon Van Every Seattle, WA

20% of the world is real.
80% is gobbledygook we make up inside our own heads.

[Brandon Van Every]

Post by Grzegorz Adam Hankiewicz
If "industrial weight" is what you really need, you might as
well program your 3d game in java <shudder>.

You're failing to understand what's mainstream in the games industry
for 3D graphics tasks. Hint: DirectX is a C++ interface. Well,
ok, nowadays they're doing Visual Basic and C# as well.

Oh, I know a lot of people who would say mainstream is OpenGL,
but then, it's a matter of point of view, or who-pays-you-for-what.

Not in the PC games industry. And the consoles don't use OpenGL, they're
proprietary. OpenGL has lost the war of game developer mindshare.
Actually, even 5 years ago they were never in the running. That doesn't
mean people won't use it; for instance I will, because I'm API agnostic.
But to say OpenGL is "mainstream" in commercial games is just plain flat out
wrong.

--
Cheers, www.3DProgrammer.com
Brandon Van Every Seattle, WA

20% of the world is real.
80% is gobbledygook we make up inside our own heads.

[Donn Cave]

Quoth "Brandon Van Every" <vanevery at 3DProgrammer.com>:
| Dennis Lee Bieber wrote:
...
| > Well, an even better reason to drop C++... and code it in Ada.
|
| Sure... if I knew Ada, and if it was relevant to the commercial games
| industry. But it isn't. C++ has the industrial weight behind it and that's
| terribly important to my business and long-term goals. I'd drop any
| consideration of Python in a second if I thought it was likely to disappear
| over the next 25 years.
|
| The typecasting in C++ is strong enough for my purposes. And everyone will
| agree it's stronger than what Python offers.

I bet you meant "type checking", not "typecasting".

I personally think neither are satisfactory. I think the problems with
Python's lack of static typing are worse than people here are willing to
let on, but C++ is not a good role model. The languages I've seen that
really put static typing to work for the programmer combine very strong
typing with type inference. Maybe it isn't for everyone, but I need a
compiler that works with me to create a structurally sound program -
just like I need automatic storage management and exception based error
handling to keep me out of other types of trouble. Unfortunately the
best I can do for languages with these attributes is Objective CAML,
which is a nice implementation but I'm afraid is too unattractive
syntactically to ever really catch on, and should mention Haskell here
too which is the opposite, will never go far for practical reasons.

Donn Cave, donn at drizzle.com

[Brandon Van Every]

Post by Grzegorz Adam Hankiewicz

[...] C++ has the industrial weight behind it and that's terribly
important to my business and long-term goals. I'd drop any
consideration of Python in a second if I thought it was likely to
disappear over the next 25 years.

If "industrial weight" is what you really need, you might as well
program your 3d game in java <shudder>.

You're failing to understand what's mainstream in the games industry for 3D
graphics tasks. Hint: DirectX is a C++ interface. Well, ok, nowadays
they're doing Visual Basic and C# as well.

--
Cheers, www.3DProgrammer.com
Brandon Van Every Seattle, WA

20% of the world is real.
80% is gobbledygook we make up inside our own heads.

[Grzegorz Adam Hankiewicz]

Post by Grzegorz Adam Hankiewicz
If "industrial weight" is what you really need, you might as
well program your 3d game in java <shudder>.

You're failing to understand what's mainstream in the games industry
for 3D graphics tasks. Hint: DirectX is a C++ interface. Well,
ok, nowadays they're doing Visual Basic and C# as well.

Oh, I know a lot of people who would say mainstream is OpenGL,
but then, it's a matter of point of view, or who-pays-you-for-what.

[Brandon Van Every]

Brandon Van Every fed this fish to the penguins on Friday 31 January

Post by Brandon Van Every
But I don't have to *write* the compiler typechecking. I do have to write
the tests. Anal retentive as I am, I don't have time to write *all* tests.

Well, an even better reason to drop C++... and code it in Ada.

Sure... if I knew Ada, and if it was relevant to the commercial games
industry. But it isn't. C++ has the industrial weight behind it and that's
terribly important to my business and long-term goals. I'd drop any
consideration of Python in a second if I thought it was likely to disappear
over the next 25 years.

The typecasting in C++ is strong enough for my purposes. And everyone will
agree it's stronger than what Python offers.

--
Cheers, www.3DProgrammer.com
Brandon Van Every Seattle, WA

20% of the world is real.
80% is gobbledygook we make up inside our own heads.

[Delaney, Timothy]

From: Lulu of the Lotus-Eaters [mailto:mertz at gnosis.cx]
I would go even further than Holger. I think it a pretty
firm rule that
the more experienced and talented a programmer is, the LESS
likely s/he
is to claim her code is bug free.
Probably-this-very-post-has-bugs-ly yours, Lulu...

Ah - the old "indirect boasting technique". Very nicely applied, but I
spotted it!

Tim Delaney