Defending the Python lanuage...

[Cliff Wells]

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,

-- 
Cliff Wells
Software Engineer
Logiplex Corporation (www.logiplex.net)
(503) 978-6726 x308
(800) 735-0555 x308

"Then with your new power you'll accomplish all sorts of cool stuff 
 in no time, and We'll All Be Sorry.  At that point you can either 
 gloat a bit, and then relent, or go ahead and send the robot army 
 after us." - Quinn Dunkan