Defending the Python lanuage...

[Cliff Wells]

On Fri, 1 Feb 2002 09:04:42 +1100
Peter Milliken wrote:

> I guess that is me then (jaded for life, I mean :-)). I have seen
managers
> advocating the use of a language purely based upon the fact that they
> believed they could hire programmers with the appropriate experience more
> easily and programmers advocating the use of a language because it would
> look good on their resume. So much of what you say here Cliff, I don't
> believe or agree with :-) I am too "jaded" :-). For instance, I have
never,
> ever seen a language choice based upon technical merit and with a decent
> study into what is or isn't available - something that managers would
like
> to see and something that programmers should do! In over 20 years of
> programming I have only ever seen the choice made for one (or more) of
the
> above decisions i.e. "I can get more programmers for language X than
> language Y" or "language X on my resume makes me more employable" - BTW,
> both arguments are perfectly valid but hardly take into account the "big
> picture".

Please, please, please don't rain on my optimism! ;-)   Believe me, I've
had my share of that type:  "we have to run Nyetware on our server because
--insert reason that has nothing to do with server function/performance--".
 I even worked at a site where a perfectly functioning Linux server was
replaced with thousands of dollars worth of proprietary software/hardware
that didn't provide any additional functionality.  Linux just didn't seem
"professional" enough for them (this was back in the 1.2 days).

> I have even seen managers rejecting a language because they tried it
> themselves one afternoon and couldn't get something to compile! The
language
> was a strongly type checked language i.e. you had to actually sit down
and
> think and plan before you attempted to dash out some code - that is why
he
> failed because he wasn't used to thinking about his code before hand :-).

While I don't disbelieve you (I know they're out there), I am merely
claiming that there are an equal if not greater number of managers who just
want to get the job done (in a timely fashion, at the least possible
expense) and are willing to rely on the expertise of their engineers to
accomplish that.  I myself have experienced both ends of the spectrum (and
some in between).  A manager who thinks he or she can test these tools
themselves are fooling themselves.  Perhaps Bob from accounting could
evaluate debuggers while the manager is testing language features?

> How many programmers or managers can at least point to a paper comparing
> various languages? Not too many, I'll bet! :-) Yet we should *all* be
able
> to do it just as a professional piece of knowledge. How many "papers" do
you
> have in your desk drawers that contain information about
benefits/drawbacks
> of different languages? (I am using "you" and "your" in the generic sense
> here, no personal attack or comment implied :-)). I don't know any
> programmers that I have worked with over the last 20+ years who have any
> such information ferreted away for when they need it (of course there
must
> be some, otherwise we wouldn't be having discussions like this and there
> wouldn't be newsgroups like comp.software-eng :-)).

True, to a certain extent.  Probably most do like I do: I see a review (in
Python's case I saw it in Linux Journal sometime in the mid-90's) and they
decide to evaluate it on a test application.  While this may not be the
most thorough research, it's probably the most practical, given the
time-crunch most of us operate under.  The unfortunate truth is that very
few individuals can make a real evaluation of a language in a short period.
 I doubt that these studies amount to much as there is obviously more to a
language than the language itself.  Even if a language is the best ever and
studies show that it increases productivity 2000% (on what? developing
quicksort routines?), it's worthless if it can't do X and we need X.  For
instance, if I were to set out to develop a graphical email client, would
Dylan be a good choice?  Maybe.  What GUI toolkits does it support?  On
what platforms?  Does it have an SMTP library?  These would be the sort of
question I would be asking, even if I had already decided that Dylan was
the greatest language ever and had built a small shrine to it in my bedroom
(next to Winona Ryder's, of course... ah wait, that's supposed to be a
secret...)

> > However, your last statement that managers make _all_ the decisions was
an
> > unfortunate one.  It's better if the technicians make the decisions and
> > then managers _approve_ them.  This may be splitting hairs, but when it
> > comes to deciding on things like what language to develop in, who is
going
> > to be better informed: the people /using/ that language or someone who
is
> > more focused on the overall picture?  Tool choices are a detail and
best
> > left to those using the tools.  Managers should focus on personnel
> > coordination, feature specifications, overall design, etc - the big
> > picture.  It's when they start trying to specify which
> > editor/debugger/compiler will be used that friction occurs.  Granted,
if
> > you have a team and one person wants to do things differently than
> everyone
> > else, management needs to step in, but if there is a general consensus
> > amongst your developers, then you need to listen, or be prepared to
look
> > for new developers when your existing ones start looking elsewhere for
> > employment.  If you won't use the technology they prefer, they'll find
> > someone who will.
> 
> Agreed (somewhat :-)), a managers job is to "smooth the way", however,
they
> do have a vested interest in productivity - I think we would all agree to
> that one? :-)

Absolutely.  If that isn't the manager's primary interest then they're in
the wrong job.  I simply question whether they know enough about the
details to really make an informed decision about these relatively
low-level things (the customer won't know what editor/language was used to
develop the application... unless you put "Python Powered" on it
somewhere).

> Interesting point here about tools - in my experience ( :-)) programmers
> rarely look for the most productive tools, they seem to be very narrow
> minded when it comes to tools at the personal level i.e. editors are your
> prime example - I have seen many cases of a more efficient (and more
> productive) editor being bypassed by programmers because they happend to
use
> editor X. 

Then again, whether an editor is productive is usually more a matter of how
proficient you are in that editor than any special features the editor has
(unless it's notepad.exe we're talking about).

I have even walked behind people retyping the same line over and
> over again (with appropriate minor variations) and totally ignoring the
> cut/paste option of the editor! :-) At the time I believe it was a simple
> reflection of boredom, but you can lead a horse to water but you can't
make
> him drink! :-)

I thought I qualified my statements about engineers with the word
"competent" :)  I question your analogy because anyone that incompetent
/must/ drink... heavily.

 Witness the debate about code reviews - you can dig up piles
> of literature and statistics that show code reviews are good for
> productlivity but it is a rare programming shop that pays anything but
lip
> service to it (if they pretend to do them at all!) For those who want to
> dispute this one, when was the last time you spent an hour reviewing
every
> 150 lines of code? :-)

Got me there ;)  Does staring at a lovely piece of code and patting
yourself on the back count as a code review?

> For example, who uses an editor with language sensitive features i.e. it
> generates code templates for you? Everyone acknowledges that many initial
> passes through a compiler (or interpretor) are aborted due to a missing
':'
> or ';' - the statistics are there, so why don't we all use an editor that
> generates this stuff for us? Not many people (in my experience :-)) use
such
> a tool, but the productivity benefits are obvious.

Usually the problem with these sort of tools is that it takes too much time
to set up and use them, and further, I suspect that the benefits are
somewhat negated by consistently having to "hit key sequence to generate
template, go back and edit template" versus occasionally "make a typo that
I have to fix".  Then again, I suppose taking the time to become proficient
with these tools would probably make a difference, so I won't disagree.

> So, I'll remain at one of my earlier statements to this newsgroup :-),
the
> software industry is not a profession, it is a cottage industry and looks
to
> remain that way for some considerable time :-).

No doubt the terms "engineer" and "science" are stretched to their limits
in this field.  "Art" seems more appropriate, although I've seen some code
that would defy that categorization as well.  I seem to recall a study that
showed that language skills were a better indicator of an individual's
potential to become proficient in programming than mathematics or
engineering skills, so perhaps that's not surprising.

-- 
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