Is this a true statement?

[Tim Daneliuk]

"Steven D. Majewski" wrote:
<SNIP>

> Be careful, Tim!
> 
> David was very precise in his wording and we were talking about a
> specific example with no precise requirements. ( Somebody one said
> that vague requirements are easy to fill -- for a *perfectly* vague
> specification, any program will suffice! )
> 
> [ See my other posts for my concession. ]
> 
> I don't retract the statement that the fact that you can compute
> any computable function in any Turing complete does not mean that
> you can *DO* the same thing in any language.
> 
> The one is a theoretical statement that has a formal proof.
> The other is a practical statement that requires a empirical proof.
> ( "DO" means to perform. )
> 
> If you disagree, I'll be happy to provide a challenge task for you
> to perform that will leave you mired in the "Turing Tar-pit" !
> 
> -- Steve Majewski

Well, I'll certainly stipulate that there is a difference between
the definition of a language and its implementation which could
lead to practical limitations.  Similarly, there are also clearly
algorithms which operate only "in principle" in any language: 
the NP-Complete problems leap to mind here.

I also have no doubt that there are some things that are highly impractical
to "do" in Python and that you can also find such an example for any
language.  (As you point out, part of the problem here is a precision
problem.)  However, in principle at least, all T-C languages do exactly
the same things or they wouldn't be T-C.  I think your argument hinges
more upon what is practical to do vs what is possible in principle.
For instance, I would guess that any problem you threw my way to
toss me into the Turing Tar Pit *does* have a solution in Python - it
would just be really complex and ugly (and not worth doing).

So, the real difference is one of how the language is *implemented*,
not how it is defined (assuming it is T-C).  For example, in my
previous post, I suggested you could embedd a Python runtime in
the kernel and thereby write driver code in Python - this has
nothing to do with language per se, but rather how it is realizes.

In any case, I will humbly admit to going off on a theoretical
tangent when the original poster was probably asking a practical
question about what we can "do" with Python...

But to the larger point of the original poster's question: I cannot
conceive of ANY reason to use C++ for ANYTHING and I've felt that way
from the day Stroustrup first exposed it to the rest of us.  It is
an abomination on the face of programming, there were and are much
better choices if you insist on using OO (which I do not think is
the Silver Bullet is has been proclaimed to be), and it has the
worst of all worlds: the complexity of an OO infrastructure, the
ease of self-annihilation of a systems language, and a syntax so awful
as to be virtually unreadable. The answer I should have posted to
the original poster should have been:

For most people, most of the time, and with the exception of
some systems programming problems, Python will "do" what C++
will.  It will require less effort by the programmer, will be
less prone to bugs as it is written, and will be more maintainable
in the long run.  For computationally-intensive problems, the
Python programmer may have to replace selected sections of code
with hand optimized code written in some more runtime-efficient
language such as C or even assembler.  This preceding is not just
a comment on the virtues of Python so much as it is a condemnation
of C++. Any number of languages can (mostly) "do" what C++ does,
only better, faster, and with fewer bugs: Eiffel, Java, Visual Basic
are all in that category IMHO...




-- 
------------------------------------------------------------------------------
Tim Daneliuk
tundra at tundraware.com