Defending the Python lanuage...

[Peter Milliken]

"Cliff Wells" <logiplexsoftware at earthlink.net> wrote in message
news:mailman.1012522381.16207.python-list at python.org...

<snip>

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

Too true, the tool should be selected to suit the job - one of my arguments
when I get into the (what seems to be :-)) perrenial arguments about whether
Python is good for a particular job i.e. the one I loved was the question of
whether Python would be appropriate for implementation of an Air Traffic
Control system :-) (No offense to the author of that one intended! :-)).

<snip>

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

Well, you have to assume a "level playing field" here i.e. productivity
shouldn't be measured unless the "common" attributes are even - familiarity
must be considered one of these attributes :-). Otherwise you would never
attempt learning another editor because it would always be a truism that you
are more productive with the one you are using - I occassionally look at
features of editors other than the one I use and if I see something that I
think would make me more productive then I add it to the one I use - thus I
have the benefits of both worlds :-)

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

Too true, the individual involved saw programming as a job that provided
money for the weekends - a very sad case :-)

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

Actually, if you are *good* at what you do, then code review, whilst still
beneficial, is not nearly *that* beneficial. Things like code review (IMO
:-)) is there for the 25-50% of programmers who just plain shouldn't be in
the industry - what they generate is just absolute garbage - code review
will hopefully stop the code from getting into Unit test and beyond the
point of redemption :-).

So, if you are patting yourself on the back then just go right ahead :-)

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

You've tried the wrong ones there mate. I agree, if the tool gets in the way
then it isn't worth the effort. The one I am refering to is fairly
unobtrusive to the programmer i.e. if<fn key of your choice> generates

  if {expression}:
    {statement}...
  [elif_part]...
  [else_part]

The cursor is position within the "{expression}" placeholder automatically
and when you start typing it is automatically deleted by the editor as you
type the first character. Navigate backwards and forwards to the other
"placeholders" with a couple of other function keys and select from menu
choices when you attempt to "expand" a placeholder (such as "statement")
i.e. while, for etc etc. Don't want a placeholder (such as the "elif_part"
above) then hit another function key and the editor moves everything around
(reasonably :-)) correctly :-). Of course, you only get this with Emacs
though...... :-) But that was one of my points - select the tools with the
most productivity features or perhaps graft the features into your tool of
choice :-).

I mean, you have a good point about familiarity etc but assuming a "level
playing field" in that area, the programmer *should* be better off with the
tool that offers the most features. I view programming tools just like any
other trade i.e. use the one best fitted for the job. Many programmers take
the approach of "well, I'm good with a hammer, so that's what I'll use with
this job" - even when the job requires the use of a jigsaw! :-) I know this
is a far fetched analogy but not too far off the mark :-).

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

Agreed with the "Art" - many programmers give one the impression that they
perceive themselves as a Prima Donna of the software industry :-) Ask
someone to look at their code (as in code review) and they look offended -
like you'd just asked for their first born or something :-) A severe lack of
comprehension is the general response - "You want to look at *my* code? What
one earth for! It's perfect (by definition)" :-).

Peter