Re: [OT] Choosing a scripting language. - Mailing list pgsql-general

On Monday 27 October 2003 07:19, scott.marlowe wrote:
> On Sat, 25 Oct 2003, Marco Colombo wrote:
> > On Fri, 24 Oct 2003, scott.marlowe wrote:
> > > On Fri, 24 Oct 2003, Scott Chapman wrote:
> >
> > [...]
> >
> > > > I also love the indentation to
> > > > differentiate code blocks rather than the junk I'd been used to
> > > > seeing in Perl and previous languages.
> > >
> > > Sorry, that was the one big turnoff for me in Python.  Indentation is
> > > simple to me, I do it linux kernel style, and don't even have to pay
> > > attention to it anymore, it's just automatic for me.  I guess I'm just
> > > used to doing it the old fashioned way.
> >
> > I don't get it. If you already indent code, what's the problem with
> > Python? Python _requires_ correct indentation,
>
> No, it RELIES on it.  I.e. code blocks are marked out by how you indent.
> I.e. it doesn't look for block markers, then make sure indentation is
> right, it uses the indentation to show it where code blocks are.

You two are saying the same thing using different words, I think.  The fact
that Python requires and relies on indentation is, after all, what we're
discussing here! :-)

> The fact that tabs are parsed as 8 spaces by Python, when many editors are
> set to render them as 4 or 6 makes it quite possible to have a file that
> looks like it should run but doesn't.  I'll take good old {} anyday.

From the Python Lang Ref:
/docs/python2.3.2/ref/indentation.html

"First, tabs are replaced (from left to right) by one to eight spaces such
that the total number of characters up to and including the replacement is a
multiple of eight (this is intended to be the same rule as used by Unix)."

I include this to point out that it doesn't arbitrarily replace the tabs with
8 spaces.  Python PEP 8 gives us useful guidelines on indentation (don't use
tabs, basically):

"  Tabs or Spaces?

    Never mix tabs and spaces.  The most popular way of indenting
    Python is with spaces only.  The second-most popular way is with
    tabs only.  Code indented with a mixture of tabs and spaces should
    be converted to using spaces exclusively.  (In Emacs, select the
    whole buffer and hit ESC-x untabify.)  When invoking the python
    command line interpreter with the -t option, it issues warnings
    about code that illegally mixes tabs and spaces.  When using -tt
    these warnings become errors.  These options are highly
    recommended!

    For new projects, spaces-only are strongly recommended over tabs.
    Most editors have features that make this easy to do.  (In Emacs,
    make sure indent-tabs-mode is nil)."

> Just do a google search for "python whitespace tabs" and you'll get about
> 7820 results back...
>
> > so it's a problem only
> > to beginners who don't like indenting (and forces them in doing
> > the Right Thing). If indentation is automatic for you, you're already
> > doing it the Python way.
>
> Not exactly.  I still prefer being able to do simple:
>
> if (something) do one thing; constructs

if x == 1: print "X is equal to 1"
blah (not indented - not part of if construct)

... works in Python.

> Or put in debug lines that ARE NOT indented so they're easier to see:
> function test(var1){
> # delete this test var when testing is done
> $test_var = "set";
>     start of code...
> }
>
> without worrying about the parser complaining about white space.

There are other ways to work around this.  Typically some #commented string
with something visible in it.  Comments can always start at column 1 by the
way for increased visibility.

> Indentation is for ME, not the parser.  Having it count as the block
> marker just feels wrong to me.  I'm not even sure I can explain why
> completely, but my above points are just one small part of it.

I find it humerous that programmers complain about Python's indentation
requirement when all it's really doing is enforcing a basic tenant of decent
code writing anyway.  It does take a bit of adjusting your head around in
order to be comfortable with it for programmers in other languages, but I'm
sure anyone could do this if they put their first impression aside.  Someone
once said, "My first impression of him was not good so I determined to get to
know him better".  The whole "religion" (and subsequent "wars") around
indententation are indeed humerous.  Python has so many strengths that I
certainly wouldn't let the indentation keep me from thoroughly checking out
the language.

' Some good links from Bruce Eckel and Eric Raymond on Python:

http://www.mindview.net/Etc/About/InformITRaw_html
http://mindview.net/FAQ/FAQ-012
http://www.linuxjournal.com/article.php?sid=3882
http://mindview.net/Books/Python/ThinkingInPython.html (The section near the
bottom, "Favorite Quotes").

> I agree with you on using the right tool for the job.  Except Perl.
> The more I use other languages, the less I want to use Perl.  Maybe it was
> a bad experience as a junior developer long ago with it or something :-)

' Going off on another tangent here, regarding "the right tool for the job".
This may be a difference between seriously educated & experienced programmers
and home-brew ones but I don't think so:

I think that the right tool for the job is generally the one you are most
competent with, in programming languages.  Some programmers (the educated &
experienced variety) may have exposure to enough knowlege about programming
languages and problems to be solved that they can actually look at a group of
languages and a problem to be solved and sort out the languages accordingly,
based solely on the language itself (not external factors around it).  I
honestly doubt that this is the case in the vast majority of cases (except in
more obvious situations where I may need the speed and control of assembly or
C vs. the bytecode of Python, for instance).  I doubt that very many
programmers can actually make a reasoned and objective argument that a given
language will work better for the problem than another.  Usually it will be
based on external factors such as "What code libraries are already available
that I'll need so I can get it done faster?" and "Which can I write it in
quickest and best?".  This last case is the one that will drive the majority
of cases, I think, and the answer will be the language I'm most fluent in.

Just my 2 cents worth.

Cordially,
Scott