Re: Python discussion, anybody?

["Stephen J. Turnbull" <turnbull@example.com>]

>>>>> "Todd" == Todd Rudick <Todd.Rudick@example.com> writes:

    Todd>  I have a half-baked idea that this sort of checking belongs
    Todd> to a separate lint-type utility.

But who would run it?  The typical result would be that the code would
be delivered to the customer today, while checking over the lint
output (6 times as long as the source code ;-) won't be done until
next week!

Also, you should try capturing the make output from v19-era Emacs
build sometime.  The number of byte-compiler errors (this isn't
defined, this isn't used) thrown is quite impressive---so impressive,
in fact, that they normally never get fixed, people just ignore them.[1]
That's LISP, of course, but the principles apply to scripting
languages.

    Todd>   Does that make sense? Do any of the smalltalk like
    Todd> "see-what-happens" weakly typed OO languages have this sort
    Todd> of feature/utility?

Lisp byte-compilers do this.

But gcov is more what you want in a RAD environment.

    Todd> P.S. On the original point, I agree that not catching typos
    Todd> until runtime (worse, not catching them at all) is a recipe
    Todd> for disaster. That little 'my' in Perl goes a long way.

First, there is _no_ equivalent to `my' in Python because all
assignments in a Python function take place in the local namespace.
You can play tricks to get access to the global namespace, but it's
very obvious what you're doing.  And class names can't leak; you have
to qualify them explicitly, even inside the class definition.  (Python
programmers conventionally use the Smalltalk term "self" for this
purpose, rather than C++'s "this".)

Second, in languages like LISP and Python, "from now until runtime"
can and should be shorter than "from now until compile" in languages
like C.

When developing in Emacs LISP, you can actually evaluate any
sexp, in the editing buffer, with one key sequence C-x C-e:

(insert (format "%u" (* 256 256 256)))^X^E -->

(insert (format "%u" (* 256 256 256)))16777216

It's, like, RAD, you know, man.  Other LISPs are handled by the
so-called "inferior LISP" mode[2], and similarly allow you to build your
LISP environment incrementally by evaluating individual forms.  I
think Python mode provides a similar facility, communicating with a
persistent Python process, but I haven't done that much Python
programming to use that feature yet.  (I typically pollute the
environment so much with my mistakes I need to restart a fresh
interpreter every time; not all that big a penalty.)

Third, as for not catching syntax errors at all, Watts Humphrey points
out that 9% of C syntax typos (in a sample of his own programs) are
not caught by the compiler because the result of the typo is still
valid C syntax.  (The = vs == in conditionals that GCC is so urusai
about probably accounts for most of them.)  It's surely much worse in
Perl.

Simon gave me an example the other day:

		 perl -e 'print reverse "backwards"'

produces

			      backwards

on output.  Why?  Reverse operates on arrays.  "backwards" is a
string, and therefore scalar.  But Perl promotes that scalar to a
one-element array, and reverses it.  And then, covering its tracks,
converts the result back to a scalar and returns it.  Ouch.

Does "use strict" fix that?  "my" certainly won't, since it didn't
use any variables.  ;-)

    Todd> * The next step is editor support for displaying a big
    Todd> left-side bracket or verticle bar to highlight your
    Todd> blocks. Then let people fold (open/close) those
    Todd> blocks. Anything (i.e., in a vi or emacs) like this yet?

In Emacs, I don't know how to do it cc-mode, but in PSGML you can fold
any SGML element; it would be easy to do the same for LISP sexps.
There is allegedly an editor which changes the background color
according to the depth of nesting.  I came into the thread, which
proposed adding the feature to [X]Emacs's font-lock, in the middle, so
I don't know what the name of it is. :(



Footnotes: 
[1]  XEmacs isn't as impressive, sorry.  rms glories in those
warnings.  Us anal XEmacs types actually try to fix, or at least
reduce, the chatter so the warnings that do come up are significant.

[2]  "Inferior" refers to the fact that the LISP interpreter lives in
a subprocess of the Emacs, not to the LISP's quality.  ;-)

-- 
University of Tsukuba                Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences       Tel/fax: +81 (298) 53-5091
_________________  _________________  _________________  _________________
What are those straight lines for?  "XEmacs rules."