Python vs. C++ Builder - speed of development
aleax at aleax.it
Thu Jan 30 11:01:43 CET 2003
Brandon Van Every wrote:
> Alex Martelli wrote:
>> You assertion is simply false. I'm an expert in both C++ and Python,
>> and I have experimented writing GUI's with both Qt driven by C++, and
>> PyQt driven by Python: Python's productivity advantage for this task
>> is about a factor of two in my experience --
>> (Personally, I'm more productive CODING a GUI [even in C++ plus
>> Qt...] than PAINTING it [say with Qt Designer] --
>> indeed I'm almost the last person you should want to DESIGN a GUI
>> in the first place -- but, these are totally separate issues).
> You're sending conflicting signals here. Maybe the middle ground is that
> for your GUI design and coding style, Python is an advantage. For my GUI
> design and coding style, perhaps not. I'm quite comfortable with
> designing things visually, using pencil-and-paper as my prototype, and I
> don't often
> design stuff I don't need. Maybe it's fair to say Python will help *some*
> kinds of coders disproportionately, but not others?
Python will only help those coders who write code, when they write
code. It will help designers and analysts in as much as writing
code helps them: as I also indicated elsewhere, if you handcuff
yourself into a metodology where no code at all ever gets written,
then it does indeed make no difference whatsoever whether the code
that never eventuates is unwritten in Python, C++, or Intercal.
On GUI development specifically: those parts of your GUI that you
choose to have code-generated for you by some "GUI painter" program
take you just the same amount of time whatever language your GUI
painter code-generates into. It's only when you want to modify (or
enrich by inheritance, often a better choice) the generated code,
e.g. to make the GUI *DO* anything (whether directly related to
your appication, or indirectly as in a "proof of concept" prototype),
that the language used for the modifications or enrichment matters.
When it DOES matter, Python shines.
> This all sounds like an argument about spontaneous vs. architectural
> coding styles.
Your ears are playing you false. While Python supports "spontaneous"
(interactive, exploratory) coding PRETTY well (not QUITE as well -- in
terms of available environments as opposed to the language itself --
as languages that typically come with IDE's centered on the "workspace"
concept, such as APL, Smalltalk, Lisp; but definitely better than
e.g. Java, C++, Fortran), this does not imply it has any problem at
all with supporting "architectural" (systematic, goal-directed) coding.
I have noticed similar orders of magnitude in the productivity boost
that Python gives me (compared with, for example, C++ or Java) in
either case. For example, re-coding in Python -- with fixed design
and functionality -- a project already existing and working in other
languages, in order to use Python for all future developments. One
would normally "wrap" the existing, working code, rather than
re-code it, but the choice to re-code may be preferable when one
already knows that deep re-factorings and design and architectural
changes will soon be necessary. Anyway, such a re-coding is one
of the most "architectural, systematic" tasks one can imagine --
I've done it a reasonable amount of times, e.g. both ways between
C++ and Java -- and Python offers higher productivity for the task
than either C++ or Java, in my experience and observations.
More information about the Python-list