Python evangelists unite!

[Peter Milliken]

"Peter Hansen" <peter at engcorp.com> wrote in message
news:3C0C526A.C7CB4FD0 at engcorp.com...
>
> 1. For the record, I've never met Dave (presumably the "your mate" in your
>    statement above) and we do not work together.  We just seem to have
similar
>    views on some of these issues.  (I realize my comments might have been
>    misleading in this regard.)
>

Actually, "your mate" was meant in the sense of you having placed yourself
(apparently) in the same view. I assumed no other contact :-). I am
Australian, so "your mate" can be an expression that covers many situations
:-). It doesn't necessarily imply a close relationship or otherwise.

> 2. Here's a simple point for you to consider in relation to your claims.
>    I'm the directory of software engineering for a wireless telecom
>    company with 100+ people.  There are fourteen developers here who are
>    using Python (almost exclusively) for some rather large applications,
>    ranging from factory automation through Intranet to embedded Linux
>    stuff for industrial control.  In case this isn't obvious: these
>    are NOT one-person jobs.  Several have involved eight or nine
>    people simultaneously at their peaks.  I'm happy to report from
>    *actual experience* that your statement has *no* implications on the
>    size of the jobs we have undertaken, direct or otherwise.  And
>    as for suitability in other ways: we have had an order of magnitude
>    fewer reported bugs, and have productivity at least two, probably
>    three times, higher than on any project I've worked on in the past.
>    These numbers are largely attributable to Python, and that makes
>    using it good business sense no matter how you look at it.
>

Good to hear your experiences. You look after 14 people - well done, that's
a big team, do you manage to do any development yourself with that number of
people to supervise? I never could with teams that size, it drove me to
distraction......

What is the basis for your comparisons though? You state that you have
achieved fewer bugs and increased productivity using Python. (just for my
information :-)) it would be nice to know over what other language you claim
these improvements. Have you considered that there might be other languages
available that provide similar order of magnitude improvements over Python?
What was the basis for your choice of Python as the development language of
choice? i.e did you perform any studies into available languages, or did
someone recommend it? If it was recommended, what was the basis of the
recommendation? Have you considered mixing languages i.e. Python for the
bits that suit python and some other language for the rest?

As I have stated in other posts here, all is not "black and white" (as
someone else said :-)) and I apologise if I gave that impression in my
original post. Having done some industrial control software when I was a
"pup" what features of Python do you find useful here that you can't find in
some other language? Does the interpreted nature of Python cause any speed
difficulties? What is the required responsiveness of yoir problem domain?

> > As for Python meeting *all* of the software engineering principles you
ever
> > *learned* - well, only you can be the judge of what you did or didn't
learn
> > :-). It certainly fails in a number of important areas that I *learned*
> > about software engineering :-).
>
> While I cannot speak for the grounding your school may have provided,
> the University of Waterloo gave me its usual solid grounding in
engineering
> principles.  Perhaps your school emphasized some areas I would consider
> unimportant.  Or perhaps the advice that a "poor workman should not
> blame his tools" should apply even to those calling themselves software
> engineers.  (If I were you, I would probably have put a smiley here.)
>

I'll put in as many as you want - I intend no offence in any of my comments,
I am pursuing this thread in the hopes of (self) improvement :-). Lets see,
information hiding, type checking, run-time checking, design by 'contract'
(ties in with information hiding), spring to mind as immediate features that
I would like to see in a language and that I was taught are "good features"
to have. Seems you don't find them important, I guess we will have to
disagree as to what is important or not :-)

Personally I love information hiding and coding by 'contract' - it seems
there is always someone in the team who is just plain lazy and wants to
access and modify the behaviour of another object directly rather than using
the agreed interface or requesting that the agreed interface be changed.
Strong typing is wonderful too. My Ada programs have 95%+ of *all* bugs out
of them by the time I get it to compile cleanly - wished I could say the
same of my Python programs! :-) Finding bugs by testing is just so
*expensive*!

> > All you have to do is look at the Pep requests and tools such as
PyChecker
> > to realise the deficiencies of the language.
>
> Actually, I am quite happy ignoring the PEPs, and so far have not
> found it necessary to integrate PyChecker into our development
environment.
> We have done quite well without it so far (although I figure PyChecker
> would be of some small help and we'll probably use it eventually).
> Perhaps our testing processes (part of good software engineering)
> are adequate for the purpose.
>

Do you gather metrics on the problems that PyChecker is meant to cure? i.e.
does anyone record the fact that they lost 1/2 hr to the fact that they
mispelt a variable name? :-) Metrics is the best way to improve your shop -
unfortunately the typical programmer doesn't like to record them :-).

> So your suggestion doesn't seem likely to reveal any significant
> deficiencies to me: if I haven't seen any myself, it must be because
> *for my purposes* there are none!
>

Hmmm.... at the risk of offending, have you considered that you might not
have sufficiently broad experience to be able to determine that? (lots of
smileys here - :-), :-), :-), :-) - there, is that enough? :-) (one more for
good measure)).

> > You could stick with Python as it matures ...
>
> How much more than 10 years old does a language have to be for you
> to call it mature?  (No, that's merely a rhetorical question.)
>

Rhetoric is OK :-) Difficult sometimes to keep it out of these threads :-).
10 years is a long time, I guess from what I have observed in some posts on
the list, people are attempting to state that they would like to see things
like some facility in the language to make it easy for them to type-check
their arguments (one example that springs to mind). I really don't spend too
much time looking for these items though or I might be able to pull up many
more examples :-) Unfortunately, I "skim" these because I know there are
very good languages that already offer these features (and they didn't take
10 years to get there! - which is *not* a slame at Guido - he has done an
excellent job! :-)).

> > ... and as long as you're a one man band that doesn't have to provide
> > long term support for something that you wrote (I mean *long* term - a
10 -
> > 15yr life for many products isn't uncommon - how long will your last job
> > survive in production?). Obviously you haven't worked at the
architectural
> > level of any *large* projects (10's or even 100's of programmers)
otherwise
> > you would never make the statements you do. Ignorance is bliss I guess
:-)
>
> Erm, yes.... well.  Our product design is intended to scale to
> hundreds of systems and have a lifetime of roughly ten years.
> I see no evidence after working on this project for two and
> a half years that we will not fulfill our objectives.  In spite of
> my background in Systems Design Engineering and my professional
> engineering license, I suppose you may be right that I don't have
> what it takes to work on large projects.  Luckily for me, your
> opinion on that matter is unlikely to raise any doubts in my mind,
> although I suppose you're quite welcome to express it.
>

Sorry, no offence intended there. Rhetoric got the better of me :-). I'm
quite sure you could scale up to larger projects - after all it is the same
software engineering principles! :-)

All either of us can do is talk from personal experience. I have a
reasonable amount in that regards but it is limited in the sense of 29 years
work experience in certain fields and situations - first 8 in industrial
control, next 20 in defence (biggest project was 100+ programmers) and the
last year in a "commercial" environment. So I  am trying to gather as much
as I can from other people (we can't learn it all! :-)).

Thankyou for your input. Hopefully I can learn some more from your
experiences in the answers to the questions I pose above. If you feel they
are too "personal" to do through this news group then please feel free to
reply directly to me.

Thanks
Peter

P.S. I have a Degree in Elect. Engineering. Formal software training
consisted of a single semester in Fortran and Basic back sometime around
1977 (I think) - I read a lot though, software is my hobby. I have been
*everything* except project manager (not that stupid! :-)) i.e. test
engineer, QA engineer, Configuration Manager, sub-contract manager, software
engineer, system architect, team leader of everyone of those disciplines etc
etc ad nauseum.....  :-)