A story about Python... sort of

[Max M]

There is a story today on Slashdot
Open Source Project Management Lessons
======================================
http://developers.slashdot.org/artic...e=flat&tid=185

"Paul Baranowski takes a moment to reflect on Open Source Project
Management in his blog. His reflections are based on the first two years
of the Peek-a-booty project." Interesting comments on media coverage,
choice of programming language, when to release a project, and more.
In that article Paul Baranowski has a list of lessons. One being

Engineering Lessons
-------------------
1. C/C++ is no longer a viable development language
He doesn't really say in the article what language should be used
instead. But there is a link to another page:

Which Language Do You Recommend?
================================
http://peek-a-booty.org/Docs/WhichLa...uRecommend.htm
And guess which language it is?
regards Max M

[Egor Bolonev]

Hello, Max!
You wrote on Thu, 03 Jul 2003 11:17:30 +0200:

MM> There is a story today on Slashdot

[Sorry, skipped]

MM> And guess which language it is?

InterEnglish?

With best regards, Egor Bolonev. E-mail: eb******@rol.ru [ru eo en]

[Egor Bolonev]

Hello, Max!
You wrote on Thu, 03 Jul 2003 11:17:30 +0200:

MM> There is a story today on Slashdot

[Sorry, skipped]

MM> And guess which language it is?

InterEnglish?

With best regards, Egor Bolonev. E-mail: eb******@rol.ru [ru eo en]

[Max Khesin]

import flame.*
import sorry.*
Ok, with all my respect to python, the stuff about C++ is a bunch of hooey.
Compilation time is the problem? Give me a break.
1) separate compilation?
2) precompiled headers?
3) tools that allow cluster compilation?
4) ever read 'large-scale c++ development' by Lacos? a must for large c++
project. letter-envelope idiom to help compilation...etc.
Anyway, if you are coding so fast that compilation time becomes a serious
problem you are either
a) the smartest and fastest programmer on earth
b) are not thinking enough

c++ is great when execution speed and memory efficiency is a must. It is
hard to learn, but there are great benefits, and do you really want halfwits
(who can't learn it) involved on your project? It also (by design) makes
previous C programmers productive very fast. Empirically - just look at all
the C++ projects on SF!

max.
--
========================================
Max Khesin, software developer -
ma*@cNvOiSsPiAoMntech.com
[check out our image compression software at www.cvisiontech.com, JBIG2-PDF
compression @
www.cvisiontech.com/cvistapdf.html]
"Max M" <ma**@mxm.dk> wrote in message
news:3f***********************@dread12.news.tele.d k...

There is a story today on Slashdot
Open Source Project Management Lessons
======================================
http://developers.slashdot.org/artic...&mode=flat&tid
=185
"Paul Baranowski takes a moment to reflect on Open Source Project
Management in his blog. His reflections are based on the first two years
of the Peek-a-booty project." Interesting comments on media coverage,
choice of programming language, when to release a project, and more.
In that article Paul Baranowski has a list of lessons. One being

Engineering Lessons
-------------------
1. C/C++ is no longer a viable development language
He doesn't really say in the article what language should be used
instead. But there is a link to another page:

Which Language Do You Recommend?
================================
http://peek-a-booty.org/Docs/WhichLa...uRecommend.htm
And guess which language it is?
regards Max M

[Max Khesin]

I am not a TDD expert, but from what I understand TDD applies to lower-level
code, not to design. Design usually spans separate modules and could have
serious impact on the compilation time, while lower-level code can be
compiled/tested very quickly, albeit not as quickly as python. And yes, many
solutions do indicate that there WAS a problem, but since the solutions
actually do work, the problem is not sufficient (IMO) to be a deal breaker
in terms of programming language choice.
max.

--
========================================
Max Khesin, software developer -
ma*@cNvOiSsPiAoMntech.com
[check out our image compression software at www.cvisiontech.com, JBIG2-PDF
compression @
www.cvisiontech.com/cvistapdf.html]

[Max Khesin]

"BearMan" <ro****@PassTheDairy.net> wrote in message
news:Fi*******************@nnrp1.ptd.net...

Not to mention all the time spent recompiling through out the debugging and troubleshooting process. Has Max ever programmed in Python? How about
Assembly?
Yes to both in varying degree.
The fact of the matter is there is no such thing as one ULTIMATE language. A real programmer will have mastered several languages so as to integrate the best features for any given situation.

IMHO

I am not sure where we disagree. This is exactly my point. The statement
"
Engineering Lessons
-------------------
1. C/C++ is no longer a viable development language
"
is pure rubbish. C++ is still great for certain kinds of projects, and there
are lots of open-source and proprietary projects to prove this. I mean, is
Linux (or Windows) 'not a viable project'?? As I said, this is a very
narrow-minded and conceited statement: rubbish.

max.

[BearMan]

Agreed...

[Dave Brueck]

On Thursday 03 July 2003 07:18 am, Peter Hansen wrote:

Max Khesin wrote:

import flame.*
import sorry.*
Ok, with all my respect to python, the stuff about C++ is a bunch of
hooey. Compilation time is the problem? Give me a break.
1) separate compilation?
2) precompiled headers?
3) tools that allow cluster compilation?
4) ever read 'large-scale c++ development' by Lacos? a must for large c++
project. letter-envelope idiom to help compilation...etc.

Sounds to me that if they've come up with so many and such a wide
range of optimizations to improve compilation time, then it clearly *is*
a problem...

Yep! I just read an article in the July issue of Game Developer that mentioned
this topic (item #3 above) in passing. It was a post-mortem of the project
and they cited as one of their life-savers a tool that used all computers in
the office to assist in the compilation of the game - a compilation farm
basically - so that the full rebuild of the game could be reduced to only 3
minutes. Obviously you don't need to do a "rebuild all" for every change to
the code, but compilation and link time is a very real cost, especially as
the project size grows. Even for small projects though, I'm much more likely
to try out small, incremental changes in a language like Python than when I
did C++ or Java because it's just so quick and easy to try it out.

-Dave

[F. GEIGER]

> (who can't learn it) involved on your project? It also (by design) makes

previous C programmers productive very fast. Empirically - just look at all

[OT] That's not a pro, that's a con on the C++ side. And actually that's the
reason why there's so much bad C++ software. A C programmer first has to
forget C to be able to program in C++ - well, to be able to program OO in
C++.

Best regards
Franz GEIGER

"Max Khesin" <ma*@cNOvSisiPonAtecMh.com> schrieb im Newsbeitrag
news:Kw****************@twister.nyc.rr.com... import flame.*
import sorry.*
Ok, with all my respect to python, the stuff about C++ is a bunch of hooey. Compilation time is the problem? Give me a break.
1) separate compilation?
2) precompiled headers?
3) tools that allow cluster compilation?
4) ever read 'large-scale c++ development' by Lacos? a must for large c++
project. letter-envelope idiom to help compilation...etc.
Anyway, if you are coding so fast that compilation time becomes a serious
problem you are either
a) the smartest and fastest programmer on earth
b) are not thinking enough

c++ is great when execution speed and memory efficiency is a must. It is
hard to learn, but there are great benefits, and do you really want halfwits (who can't learn it) involved on your project? It also (by design) makes
previous C programmers productive very fast. Empirically - just look at all the C++ projects on SF!

max.
--
========================================
Max Khesin, software developer -
ma*@cNvOiSsPiAoMntech.com
[check out our image compression software at www.cvisiontech.com, JBIG2-PDF compression @
www.cvisiontech.com/cvistapdf.html]
"Max M" <ma**@mxm.dk> wrote in message
news:3f***********************@dread12.news.tele.d k...

There is a story today on Slashdot
Open Source Project Management Lessons
======================================

http://developers.slashdot.org/artic...&mode=flat&tid =185

"Paul Baranowski takes a moment to reflect on Open Source Project
Management in his blog. His reflections are based on the first two years
of the Peek-a-booty project." Interesting comments on media coverage,
choice of programming language, when to release a project, and more.
In that article Paul Baranowski has a list of lessons. One being

Engineering Lessons
-------------------
1. C/C++ is no longer a viable development language
He doesn't really say in the article what language should be used
instead. But there is a link to another page:

Which Language Do You Recommend?
================================
http://peek-a-booty.org/Docs/WhichLa...uRecommend.htm
And guess which language it is?
regards Max M

[Max Khesin]

[OT] That's not a pro, that's a con on the C++ side. And actually that's the reason why there's so much bad C++ software. A C programmer first has to
forget C to be able to program in C++ - well, to be able to program OO in
C++.
Well, it is documented as one of the original design goals of the language,
if I remember correctly. It is certainly implicitly a goal considering the
sacrifices made to preserve C as a subset.
I think it was important in getting a lot of people on board with c++, but
it certainly there are many problems with it, including the one you
mentioned. Of course the problems would not exist if C++ was never accepted.
It is similar to saying 'how dare my parents embarass me by having sex'.
Take it up with Bjarne :)

max.
Best regards
Franz GEIGER

--
========================================
Max Khesin, software developer -
ma*@cNvOiSsPiAoMntech.com
[check out our image compression software at www.cvisiontech.com, JBIG2-PDF
compression @
www.cvisiontech.com/cvistapdf.html]

[Roy Smith]

Dave Brueck <da**@pythonapocrypha.com> wrote:

If Python were to become too slow or too weird I'd migrate to
another high-level language

I can certainly see situations were Python might be too slow, but too
weird? When would it be too weird?

[Cliff Wells]

On Thu, 2003-07-03 at 06:50, Max Khesin wrote:

import flame.*
import sorry.*
Ok, with all my respect to python, the stuff about C++ is a bunch of hooey.
Compilation time is the problem? Give me a break.
It is *a* problem. I'll agree that it's one of the least.
1) separate compilation?
2) precompiled headers?
3) tools that allow cluster compilation?
4) ever read 'large-scale c++ development' by Lacos? a must for large c++
project. letter-envelope idiom to help compilation...etc.
Anyway, if you are coding so fast that compilation time becomes a serious
problem you are either
a) the smartest and fastest programmer on earth
b) are not thinking enough
Or making simple typos.
c++ is great when execution speed and memory efficiency is a must. It is
hard to learn, but there are great benefits, and do you really want halfwits
(who can't learn it) involved on your project? It also (by design) makes
previous C programmers productive very fast.
I won't disagree that there is a place for languages like C++.
Developing entire applications isn't it.
Empirically - just look at all the C++ projects on SF!

And what percentage of those are incomplete, abandoned, or simply
unusable?

--
Cliff Wells, Software Engineer
Logiplex Corporation (www.logiplex.net)
[phone] [phone]

[Russell Reagan]

"Dave Brueck" <da**@pythonapocrypha.com> wrote

I
mean, is Linux (or Windows) 'not a viable project'??

Well, again, neither of those are "applications level" projects.

There is a rather large industry which I'll call "computer games" that is
rather CPU intensive, and AFAIK the vast majority of those games are written
in C/C++. It really depends on the definition of "application level". If
we're only including things like word processors and web browsers in the
"application level", then there isn't a great need for C++ in the
"application level", but there are certainly areas where speed and memory
efficiency is important.

I will admit that I'm getting tired of writing a lot of the support code,
debugging, etc., most of which Python provides for "free".

[Behrang Dadsetan]

Russell Reagan wrote:

"F. GEIGER" <fg*****@datec.at> wrote

[OT] That's not a pro, that's a con on the C++ side. And actually that's

the

reason why there's so much bad C++ software. A C programmer first has to
forget C to be able to program in C++ - well, to be able to program OO in
C++.

C++ is not an OO language. It is a multi-paradigm language that happens to
support OO features. No one is required to program OO in C++. It's even very
debatable if it's better to program OO in C++.

We are getting very philosophical here and I guess we are getting a
little off-topic, but what is an OO language? Isn't one that supports OO
features? Ok, You can write C code and compile it with a C++ compiler,
but does it disqualify C++ as being a OO language?

The advantages you talk about writing C and using a C++ compiler are
pretty weak. C++ is certainly not just about the "typedef" feature... It
is a very powerfull language that can be used to express exactly what
you want the computer to do, and in the same time kind of abstract
details to a level where you can still see what your program was written
for. Agreed, it is a terrificly complex language all together, but it
has its use. If you actually respect the thousand rules from M. Meyer
plus a few from M. Lakos, you can build very reliable and stable
applications. If you are a genius or have some technique and experience,
you can even have a somewhat bigger code where you still have an overview.

The big disadvantage to its C compatibility is that lots of people
beleive they have C++ experience and present themselves at C++ jobs. You
just need an IT management which has no clue about OO technology/C++
(managers that understand anything at this level are in minority) and
you soon have a C programmer who used a C++ compiler converted into a
Java programmer. Little after you will see something really funny, C
compiled by a Java programmer. Is Java therefore not a OO language? I
mean Java will allow C programmers to build classes with only static
methods, with classes of 6000 lines without constructor and all
variables declared as public class members? I have seen this, and I am
not exagerating at all in the description... it actually took me two
days to understand why I did not understand how the programmer cut the
program. Yes, I was naive enough to think one can only write OO in Java,
like in the advert.

Anyway, let us talk about something else, I hate being reminded how
often our IT industry has been guarenteeing our jobs life-time by making
every thing more complicated and more expensive instead of making things
simpler and cheaper as we were entrusted to do. Note that I do not think
we do that on purpose :-)

That said, python does make life easier in many occasions, so there is
maybe some hope that a little tiny community of our IT industry is not
reaping off our dear sponsors (IT users including IT people).

Thanks pyguys for your beautiful contribution, please continue just as
you are now. You have been doing a wonderful job. If you could only
replace VB for all the usages it has now, and convince the planet of
that as well, I would be thankful for ever. :)

Ben.

[Aahz]

In article <Yg3Na.97773$R73.11565@sccrnsc04>,
Russell Reagan <rr*****@attbi.com> wrote:

There is a rather large industry which I'll call "computer games" that
is rather CPU intensive, and AFAIK the vast majority of those games are
written in C/C++. It really depends on the definition of "application
level". If we're only including things like word processors and web
browsers in the "application level", then there isn't a great need for
C++ in the "application level", but there are certainly areas where
speed and memory efficiency is important.

At the same time, more and more of those games are switching to using
C/C++ only for the rendering engine and using a scripting language (Lua
or Python) for the gameplay itself.
--
Aahz (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/

Usenet is not a democracy. It is a weird cross between an anarchy and a
dictatorship.

[Paul Boddie]

"Max Khesin" <ma*@cNOvSisiPonAtecMh.com> wrote in message news:<dG********************@twister.nyc.rr.com>.. .

I am not sure where we disagree. This is exactly my point. The statement
"
Engineering Lessons
-------------------
1. C/C++ is no longer a viable development language
"
is pure rubbish. C++ is still great for certain kinds of projects, and there
are lots of open-source and proprietary projects to prove this.

I wouldn't agree with you unreservedly here. In many respects, the
choice of C++ for projects is often an educational problem with the
developers - people choose it because it's what they know, potentially
not very well in many cases. So one could say that it's really
something they just know something about - it seems like the
right/safe choice, presumably because their peers/acquaintances who
are just as badly informed tell them so.

Those of us who are used to more high-level languages would think
twice about writing a large application using a language/library
combination without decent (ie. modern) support for memory management,
for example. I can imagine that many developers find it challenging
and even rewarding to think up interesting schemes for allocating and
freeing memory - perhaps they even think that this (and lots of other
unnecessary wheel reinvention) is what programming is all about.
Personally, I'd rather get on with implementing the actual system
concerned.

So, I'd rephrase the original statement: C/C++ are frequently
suboptimal choices for application development. Why? Poor support for
near-essential features found in contemporary languages combined with
the absence of timely, effective standardisation of useful library
functionality.

Paul

[John J. Lee]

aa**@pythoncraft.com (Aahz) writes:

In article <Yg3Na.97773$R73.11565@sccrnsc04>,
Russell Reagan <rr*****@attbi.com> wrote: [...] At the same time, more and more of those games are switching to using
C/C++ only for the rendering engine and using a scripting language (Lua
or Python) for the gameplay itself.

Is this true of big-$ commercial games? What sort of market share do
high-level / interpreted languages have there?

Never having been a (graphical) games player, I don't know the first
thing about how games developers do things.
John

[Aahz]

In article <87************@pobox.com>, John J. Lee <jj*@pobox.com> wrote:

aa**@pythoncraft.com (Aahz) writes:

At the same time, more and more of those games are switching to using
C/C++ only for the rendering engine and using a scripting language (Lua
or Python) for the gameplay itself.

Is this true of big-$ commercial games? What sort of market share do
high-level / interpreted languages have there?

Depends what you mean by big-$. Humongous Entertainment has recently
switched to requiring Python for all new games. Lua is even more
prevalent; see http://www.lua.org/uses.html
--
Aahz (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/

Usenet is not a democracy. It is a weird cross between an anarchy and a
dictatorship.

[Peter Hansen]

Aahz wrote:

In article <87************@pobox.com>, John J. Lee <jj*@pobox.com> wrote:

aa**@pythoncraft.com (Aahz) writes:

At the same time, more and more of those games are switching to using
C/C++ only for the rendering engine and using a scripting language (Lua
or Python) for the gameplay itself.

Is this true of big-$ commercial games? What sort of market share do
high-level / interpreted languages have there?

Depends what you mean by big-$. Humongous Entertainment has recently
switched to requiring Python for all new games. Lua is even more
prevalent; see http://www.lua.org/uses.html

Well, you can't get any bigger than "humongous", can you? ;-)

[Dave Brueck]

On Thursday 03 July 2003 11:48 pm, Russell Reagan wrote:

"Dave Brueck" <da**@pythonapocrypha.com> wrote

I
mean, is Linux (or Windows) 'not a viable project'??
Well, again, neither of those are "applications level" projects.

There is a rather large industry which I'll call "computer games" that is
rather CPU intensive, and AFAIK the vast majority of those games are
written in C/C++. It really depends on the definition of "application
level". If we're only including things like word processors and web
browsers in the "application level", then there isn't a great need for C++
in the
"application level",

Actually, games are a particularly good example to illustrate the point:

1) In the movement away from a lower-level language, games are probably one of
the last hold-outs since performance often means so much. Still, even games
do make the transition - the transition away from assembly being the main
example.

2) Even the most performance-intensive games of today are already
transitioning towards higher-level languages - is there any major
first-person shooter or real-time strategy game coming out these days that
doesn't boast a powerful scripting language? With each new generation of
games the developers try to push more and more of the functionality into
their scripting engine leaving as little as possible behind in C/C++ - the
render loop, *some* of the AI, etc. Not only is the game customizable by the
customers, the developers themselves prefer it because of fewer bugs and it
makes it much easier to try new and cool stuff out.

3) More and more of the performance-intensive work is handled by hardware
nowadays anyway - both video and audio. Furthermore, the game itself usually
relies on a pretty rich and powerful supporting library like OpenGL or even
DirectX, which depending on the route you take can supply a ton of the
functionality that the game developer would normally write in C or C++.

4) All of the above mean that in many cases you already *can* do some pretty
elaborate games in higher-level languages (the games listed on Pygame are a
great example), and there's every indication that the trend will continue.

There came a time when it was no longer economically viable to develop an
entire game in assembly, and IMO we've *already* passed the point where it's
no longer economically viable to develop most games entirely in C++ - the
time to market is too long, it's too expensive to add new features,
recovering from early incorrect decisions is too costly, etc. Games are
moving to higher-level languages as much as they can because it's a
competitive advantage to do so.
but there are certainly areas where speed and memory
efficiency is important.

Oh, nobody disagrees with that. But due to increases in efficiency and
decreases in prices, the number of cases is shrinking wherein speed and
memory constraints require you to drop to a lower-level language.

-Dave

[Ben Finney]

On Mon, 07 Jul 2003 02:02:06 GMT, Russell Reagan wrote:

Anyway, I know of one chess program written in python, and it is
dreadfully slow compared to *any* program written in C/C++ (that I've
seen anyway).
Have you looked at the code for it? Have you profiled it to see where
its bottlenecks are? It's often the case that a program is low because
of poor design, or simply choosing a slow algorithm.

Until profiling, of course, you can't know which algorithms are too slow
for the program.
The things that make a chess program fast aren't really python's
strengths, but hopefully I'm being pessimistic due to my lack of
python/c knowledge.
My suggestion for those who want to write programs that do something
quickly:

- Write a program that does the job at all, paying attention to
simplicity and readability and *no* attention to optimisation.

- Debug the program so it does everything it's supposed to do, albeit
slowly.

- Once the program is correct, and not before, profile it to see where
it's slow.

- Pick the biggest bottleneck and make it faster, by one or more of:

- Choose a faster algorithm, perhaps sacrificing readability or
simplicity
- Re-implement in C

- Iterate the previous step until the program is fast enough or you
run out of (time|money).

You'll have a program that is quite readable, except in the places where
it needs to be fast. In my experience, those places are surprisingly
few, and are surprisingly different to where you expected them to be.
import chess
chess.run_program_in_c
print "Thanks for playing! Bye!"

It may well be that all the "real" chess-thinking stuff may be too slow
in Python; you might end up with the move-evaluation routine in C, for
example.

But discover that by profiling a Python implementation first! If it
turns out to be too slow, at least you've debugged a working algorithm,
and can treat it as pseudocode for the port to C. If it turns out that
the bottlenecks are somewhere else entirely, you've saved yourself a
huge misguided optimisation effort.

--
\ "My roommate got a pet elephant. Then it got lost. It's in the |
`\ apartment somewhere." -- Steven Wright |
_o__) |
http://bignose.squidly.org/ 9CFE12B0 791A4267 887F520C B7AC2E51 BD41714B

[Russell Reagan]

I didn't investigate the python chess program a great deal, since I'm still
learning the language, but it is very likely that it wasn't an efficient
implementation. It takes years to learn how a chess program works, and to
learn all of the tricks you can do to speed things up (and even then you
have to have the programming skill to implement those things).

I agree that it is not good to worry about optimization prematurely, but
computer chess might be a bit of a unique area. Computer chess is the most
heavily researched area of artificial intelligence ever, and as such, there
are tons of "standard" low level tricks or data representations that you can
use to your advantage. For instance, you can use board representation A and
get thing B for "free" (B might be fast attack detection, or the ability to
evaluate some complex aspect of a position quickly). When designing a chess
engine, you have to decide what you want to do, then use the data
representation that gives you the most things you want to do for "free".

This is also why OOP might not be of much use for chess programming. The
goal of OOP is to write correct code by being able to more easily make
modifications to the code by data hiding, writing generalized routines, etc.
Computer chess is so heavily researched, that there are several "standard"
board representations that people use, and they're low level, involving lots
of bit fiddling. Making a board object that doesn't know how a piece object
is implemented serves little purpose other than to slow things down. Part of
a fast chess program is that every part knows how everything else is
implemented, and exploiting that. I'm not discounting anything you said. I'm
just saying that computer chess may be one of the few areas where the
generally good advice doesn't always apply, due to the ridiculous amount of
research. Heck, computer chess was being researched before computers even
existed!

- Write a program that does the job at all, paying attention to
simplicity and readability and *no* attention to optimisation.
In general, this is good advice, but for reasons explained above, paying no
attention to optimization might be the equivalent of choosing a bad design
for this specific problem. By not paying any attention to efficiency early
on, you effectively limit your top speed later on.
- Once the program is correct, and not before, profile it to see where
it's slow.
Since computer chess is so heavily researched, I can tell you that the area
consuming the biggest chunk of time will be position evaluation, unless your
program doesn't use a lot of the well known tricks for things like attack
detection, in which case it might spend a ton of time doing that, ensuring
that a move doesn't leave your king in check, that kind of stuff. There is
really not a lot you can do to improve either of those short of starting
over from scratch and creating your data structures in such a way as to
exploit lots of low level tricks.
at least you've debugged a working algorithm,
and can treat it as pseudocode for the port to C.

For reasons explained above, I'm not sure that you can make the direct
translation between "python pseudocode" to "C/C++". It sounds like you're
thinking, "I'll just implement this python program in C/C++, and then it
will be faster," but I'm not sure that is the case. Sure it will be faster,
but probably still pretty slow. Making a really fast chess program would
require changing the data structures significantly, and I'm not sure what
use the python code would be after you made a big overhaul of the data
representations.

What do you think? I may be way off. Maybe I'm putting too much emphasis on
speed.

[Dave Brueck]

On Monday 07 July 2003 02:02 am, Russell Reagan wrote:

There came a time when it was no longer economically viable to develop an
entire game in assembly, and IMO we've *already* passed the point where
no longer economically viable to develop most games entirely in C++ - the
time to market is too long, it's too expensive to add new features,
recovering from early incorrect decisions is too costly, etc. Games are
moving to higher-level languages as much as they can because it's a
competitive advantage to do so.

After thinking about it I tend to agree. I'm a little partial to C/C++
because I develop (as a hobby) a chess playing program, and I like
tinkering with it to see how fast it can go, and finding clever ways of
doing things. A chess program is different from a 3D game in that with a 3D
game, you can stop at some point and say, "ok, this is fast enough." There
is little point in making the game run at 1000 frames per second if no
human eye can see more than 60 (or whatever the number is).

True, although rather than let the frame rate continue up the game designers
will simply add more polygons, more actors, more textures, greater viewable
distance, etc. so they won't ever reach the "fast enough" point either.
Instead you always reach the "fast enough for now" limit.

There will remain *some* cases where you need a lower-level language in order
to get more speed, but those cases are becoming less frequent - for each one
there comes a time when the cost of that extra speed becomes too much. Also,
some projects (like Pysco) open the possibility of on-par (or even greater,
in theory) speed by using a higher-level language.

But my main point was that, at least for the stuff I do, there's never any
point in writing all or even most of an application in C++ anymore (and the
few parts that do need more speed would be in a dumbed-down, simplified C++
at that). If I were writing the chess game I'd probably write the entire
thing in Python to begin with anyway, just to get it working. Having a slow,
but working app would either help maintain my interest in the project or let
me know early on that it's not something I really want to do.

If I kept at it then I could, at some point, move some speed-critical code to
C or C++, but I'd try to avoid it for as long as possible. For example, you
mentioned that your interest was at least in in part about finding ways to do
things faster or to make the game smarter. In a higher-level language like
Python that sort of expermimentation is relatively cheap - in C++ you might
avoid radical experiments because the cost of change is too high. Your
biggest speed and smartness improvements after picking the low-hanging fruit
are likely to be algorithmic in nature (e.g. using a more ingenious heuristic
to reduce the search space of next moves) as opposed to low-level tuning of
loops or data storage, so it would be advantageous to do that work at as high
a level as possible (and you can always translate those algorithmic
optimizations to a lower-level language someday if you want).

Just my two cents of course,
-Dave