Defending the Python lanuage...

[brueckd at tbye.com]

Great response, Cliff!

-Dave

On Wed, 30 Jan 2002, Cliff Wells wrote:

> On 30 Jan 2002 00:26:05 -0800
> Rony wrote:
>
> > I din't answer all the answers one by one because they all make a
> > point somehow ... but seem to miss my point. Perhaps i wasn't clear
> > enough, this could be because english is not my native language.
>
> I would never have known.  I thought you were very clear, I just think you
> are perhaps trying to apply your own position to others who are perhaps not
> in the same position.
>
> > What i mean is that IMHO very often the wrong questions are aked here,
> > or perhaps it depends of the job of the person who is asking the
> > question.
>
> What I was getting at is that perhaps the questions only seem wrong to you.
>  On the one hand you state that much more must be considered before
> deciding whether a language or tool is appropriate for a particular job
> (which I wholeheartedly agree with), but then you turn around and assume
> that these people don't know the right questions to ask when you know
> nothing about what they are trying to accomplish.  When someone asks "is
> Python good for X" it's best to assume they've already considered the
> aspects of Python relevant to their application and they are simply
> wondering if X is going to be a stumbling block.  To assume that they are
> _only_ considering X is assuming too much, and worse, seems to assume that
> the person asking the question is "stupid".
>
> > I myself i'm a manager of a software developping company, so i see
> > these from a managment point of view. If, tomorrow, my chief software
> > engineer comes to me and says "from now on i would like to use
> > language X for our development", my questions would be :
> > - Why ? What are the benefits and why should we change or add this
> > language
>
> If your engineer is competent, he's probably already considered these
> things.  This is _why_ he came to you.  He sees definite benefits to
> switching.  While engineers can have their judgement impaired by enthusiasm
> for new technology, usually that enthusiasm is generated by having suddenly
> seen possibilities for accomplishing things they hadn't thought practical
> before.
>
> > - What happens with the thousands of lines of code we wrote for our
> > standard librarys and wich we are using for every project. And THIS is
> > a very important question i think, because you're talking money here
> > (sorry for the open source guys here <wink> ). If, as a company, you
> > have to trow away a couple of thousand hours of investment because
> > your development team wants to change you need a serious reason for
> > this.
>
> Well, consider this scenario: you have a working product that is written in
> a well-established language (let's say C).  You have hundreds of customers
> using this product.  The problem is that your developers are spending all
> their time doing maintenance on the existing code rather than adding
> features, or that features they would like to add are extremely
> time-consuming in the existing framework.  Sticking with a technology for
> too long will eventually cause stagnation in your product's development.
> Eventually another company, starting from scratch using newer technologies,
> will rapidly achieve what took you years to develop.  Worse, they will soon
> surpass you in features as you struggle with a code base rooted in the
> past.
>
> The basic problem is that no one (except maybe Guido ;) can see into the
> future.  Customers will demand things that your architecture and tools were
> never meant to support and you will end up hacking your existing
> architecture into an unrecognizable mess trying to add them (or fail to add
> them at all).
>
> And this goes even further than that, another point is how good
> > will it be supported ? Here i don't mean only the language it self but
> > allso his librarys. Take Python as an example. The language itself is
> > going trough a *normal* growing cycle and is very well supported, but
> > imaging that with version Python 3000 (:)the "community" has decided
> > that the Tkinter library won't be supported any more.. I can assure
> > you that this would be a very expensive decission for us, our whole
> > GUI library is based on that now. And isn't this a risk with many open
> > source projects ?
>
> The strength of Open Source is that you have the source.  If the Python
> community decided to dump Tkinter, you could continue development on it
> yourself.  Of course, if MS dumps MFC or Win32 (or maybe Sun and HP dump
> Motif), you're out in the cold without even a .so or .dll to warm yourself
> by.
>
> > - What will be the investment for training of our development team and
> > how much time will it take
>
> Good questions.  Don't let them be the deciding factor.
>
> > - Do we have a 'small ' project we can use as a testcase and what do
> > we have to do if we where wrong ?!!
>
> A small project is good.  Being wrong is a danger we all have to live with,
> and a small test case can help reduce or evaulate that danger.
>
> > As i wanted to point out here there are a couple of other important
> > questions that are very rarely asked here .... and who are IMHO more
> > important as question but allso as answer and argument to use Python
> > than the fact that you don't have to declare variables ... (as a
> > stupid example)
>
> If the questions that go unasked are the questions you layed out above,
> then they aren't answerable by anyone not involved in the project in
> question.  They have little to do with Python, but rather are specific to
> the problem you are looking to solve and the people you have working on it.
>  Good questions, but not appropriate to this list.
>
>
> Regards,
>
>