Jay Parlar <[EMAIL PROTECTED]> wrote: ... > Because in all of my own industry experience, it's been MUCH easier to > jump into someone else's Python code than someone else's C++ code (and > at my last job, I had to do a lot of both). I find Python to be much > more self-documenting, because there's not so much scaffolding all over > the place obfuscating the true intention of the code.
In the average, you're right. However, if you can rely on ALL the code in question being brilliantly well designed, written by programmers of unbelievably high quality, in full and strict adherence to rigorous coding-style guides (which absolutely forbid the use of LARGE slices of each language) and a reasonably thorough process (mandatory code reviews before anything is committed, mandatory testing, the works), the issue is substantially ameliorated. It does remain true that the amount of Python code needed to implement any given functionality X is smaller than the amount of C++ code needed for the same purpose, of course; the amount of effort to understand a codebase of uniformly high quality being roughly proportional to the size of that codebase, Python will still be advantageous. But by, oh, some small factor (maybe a factor of 2? surely not as high as 5), NOT orders of magnitude. If the design, the programmers, the coding-style, and-or the process are of lesser quality, then you're in trouble either way, and I will concede that the situation degrades faster for C++ -- not only does it offer people more ways to get themselves into trouble, but unless you can count on uniformly high quality the effort is not just linearly proportional to the size of the codebase, it grows much faster than that, so the "lack of scaffolding" and other factors making Python more expressive do matter more. Still, if I was back to working as a freelance consultant and got hired to fix a problem situation, I wouldn't _start_ by recommending a switch from Java or C++ to Python as the highest-urgency issue: I would first focus on people (both as individual and teams), process, design, and tack language (including style) and other technological issues (including choice of tools, frameworks, libraries, etc) as being, while undoubtedly important, of slightly lesser urgency. Don't get me wrong: using the most appropriate technologies does make a big difference; but it's too easy a temptation to focus on technological "silver bullets" and assume they can "just fix things" if ``softer'' but at least as crucial problems are left to keep festering in the background. Alex -- http://mail.python.org/mailman/listinfo/python-list
