Python vs. C++ Builder - speed of development

[Jacob Hallen]

In article <tB3%9.3147$6P2.351830 at newsread1.prod.itd.earthlink.net>,
Brandon Van Every <vanevery at 3DProgrammer.com> wrote:
>Alex Martelli wrote:
>> Brandon Van Every wrote:
>>    ...
>>> really do feel that most of my time right now is spent on design,
>>> and that no
>>> language would allow me to code any more rapidly than any other.
>>> C++ just
>>
>> Python has the potential to make your design more productive, too.
>> Whenever you have to choose between (algorithms, data structures,
>> or more generally "approaches") A, B and C, Python makes it quite
>> feasible to code them all and then choose between them on the basis
>> of actual experience, rather than mere theories.
>
>There's nothing remotely theoretical about my current C++ development.
>
>>> If you Keep It Simple Stupid in C++, it ain't that bad.
>>
>> But you can't keep C++ all that "simple", really.
>
>Yes you can, when you're solo coding.
>
>> You cannot "simply not use" ``worry about who owns what'' in C++.
>> SOME object X has to hold THE owning-pointer (e.g. auto_ptr) to
>> another object Y, while other pointers to Y don't "own" it -- you
>> have to KNOW when Y gets freed; or else you get to reimplement
>> reference counting and/or other approaches to garbage collection,
>> infrastructure which Python gives you in a much better developed
>> and usable state.
>
>I haven't written anything in my entire code base that uses reference
>counting at all.  I do not live in a "I must spawn this zillions of times!"
>world.  Not yet, at any rate.  I may need it later, but by then I will have
>"poured a strong foundation."
>
>> Of course you don't use nested functions in C++ -- it does not
>> support them.  That's a _handicap_ of C++, by the way.
>
>I've yet to design anything that needed nested functions.
>
>> If you don't use templates in C++, that's your loss -- they're
>
>It is not a loss when your overriding goal is to get 1 code path working
>well.  I do not believe in a bazillion code paths, you can't optimize them
>all.  I have a RISC mentality.  So first you get the 1 code path working
>well, you do everything that you possibly can with it, and only much much
>much later after the design is proven do you worry about templates.
>
>I also don't believe in trying to solve everybody's problems in some
>general-purpose way up front.  Solve the specific problem you're working on.
>Don't start out writing templates, it's a bad impulse.  Make a template out
>of something with proven utility, that you need to extend to a more general
>case.  Templates should be code *reuse*, not code anticipation.
>
>> And I do *NOT* believe you
>> do not use any casts in your C++ code, _particularly_ if you
>> make no use of templates.
>
>At the stage of development I'm at, it's a true statement.  Well, I cast
>some ints to floats to do various calculations, but I'm sure that's not what
>you meant.  Really, there's nothing that needs any shoehorning in my current
>design.

This whole debate is rather interesting. In one corner we have a sole person
who has made significant development in C++ and essentially none in Python.
In the other corner we have several people with experience from major
projects in both C++ and Python. The sole man claims that there is no
significant improvement in using Python in the development, while the
group is unanimous about major productivity improvements.

I wonder which side should get my ear...

Jacob Hallén


--