Python training time (was)

[Brandon Van Every]

Andy Freeman wrote:
> "Brandon Van Every" <vanevery at 3DProgrammer.com> wrote in message
> news:<GTV%9.7673$ek4.753437 at newsread2.prod.itd.earthlink.net>...
>> Andy Freeman wrote:
>>> "Brandon Van Every" <vanevery at 3DProgrammer.com> wrote in message
>>> news:<fZD_9.914$ek4.91595 at newsread2.prod.itd.earthlink.net>...
>>>> So, how much time do you have to put into Python before you've
>>>> mastered
>>>> *every* aspect of the language?  I do mean "every."  Less than a
>>>> year?  6 months?  3 months?  Be honest.
>>>
>>> That's the wrong question.
>>
>> It isn't "the wrong question," it is exactly the question I intended
>> to ask.
>
> Of course it was - you're trying to play "gotcha".

Whatever you say, Mr. Mindreader.  If you don't accept my "upper bound"
explanation that's your problem.

>> Useful questions, but they have no inherent rightness.
>
> Actually, they do, as YOUR standards are "getting work done".

My standards have nothing to do with the inherent rightness or wrongness of
questions.  A question is posed to gain information about the topic it
addresses.  "Upper bound" complexity of a language means something.

>> You can probably observe something about the relative complexity of
>> languages if you compare the upper bounds of their learning curves.
>
> You can't observe anything useful at that point because no one gets
> there.

I knew *every* aspect of C++ in 1994, but since then the language has grown.
:-)  In 1996 I took a job that did only C.  I discovered how much I could
get done with only C.  In 1998 I resumed C++ on my own.  I didn't bother to
catch up to the current C++ standard until fairly recently.  The only
"newfangled" thing I make use of is exception handling.  I'm peripherally
aware of various cast and operator tricks, but the need for them just hasn't
come up.  Back in the day, STL wasn't worth considering because it wasn't
really standard and tended to be broken.  Even today, I hear that vendors'
STLs tend to be broken, so I am leery of trusting any long term development
to them.  I'd say the yawning gap in my C++ knowledge is STL.  Other than
that, I'd say I know 90% of the language.

I'd estimate modern C++ at a 2 year learning curve to know every aspect of
the language.  In 1994 it was a 1 year learning curve.

>> There are
>> some kinds of simple, pedal-to-the-metal, yet object oriented
>> problems that Python will never be as good a choice for.
>
> Interestingly enough, we've shown that to be false,

How can you possibly disprove the statement "there are some kinds...?"
You'd have to prove "there are no kinds...."  So your 3D graphics knowledge
is that good, huh?

> unless, of course,
> you want to argue that C++ runs slower than C++.  (Hint: Martelli
> described one technique for developing in Python and delivering C++
> that is faster than developing in C++ and I described another.)

I'm not going to buy that writing in Python then converting to C++ is faster
than writing in C++ in the first place for fairly simple problems.

--
Cheers,                         www.3DProgrammer.com
Brandon Van Every               Seattle, WA

20% of the world is real.
80% is gobbledygook we make up inside our own heads.