"sins" (aka, acknowledged language problems)

[skaller]

Alex Martelli wrote:

> But that's just because I'm a newbie in this Python
> language -- you should see me operate in realms
> I'm more confident about!-)  [Despite my verbal
> prowess, I've been unable to help others find strong
> enough superlatives of "arrogant" to describe my
> attitude when experience backs me up:-)].

I'm more arrogant, since I don't care if experience
backs me up or not, only if there is a good argument :-)
 
> But as soon as they published, and the book was
> such an instant success, I started using their
> design pattern names with abandon (with a biblio
> reference in a comment, when I remembered:-).

	I found the book interesting, and nothing
more. I gained no enlightenment from it, other than
the mild assertion than some patterns could not
be encoded IN the language. It turns out this
assertion is false in general -- it is language specific.
Functional languages have no problem encoding it.

> But for this to be effective, it does need to be
> widely known.  "condition and iftrue or iffalse"
> is perceived by many as an unreadable way
> to express a ternary operation, although IMHO
> it has it all over C's "condition?iftrue:iffalse",
> for the sole reason that the latter has had much
> exposure (any C programmer has NEEDED to
> learn about it), while the former has not -- if
> such idioms were more widely promoted in
> widespread Python literature, their actual
> "readability" would improve... without needing
> to change anything in the idiom itself nor in the
> Python interpreter.

	You're right: are these really equivalent?
I'd have to go and think a long time about it.
Hey, Guido used that once, in some code,
and I rewrote it just so I could figure it out.
 
> > functions available, and (b) in except clauses,
> > to make the exception available.
> >
> *blink* isn't that what sys.exc_info() is for...?

	try: ...
	except TypeError, x: print x

Here, the 'x' is the actual exception object.
It is not in global scope. It is not in local scope.
At least, not in my implementation (Viper).
It is available ONLY in the exception handler.
At least, I assumed that: I never bothered to check this :-)

> I particularly appreciated Java's abandonment
> of classical rules for nested lexical scopes -- the
> idea that an identifier in an inner scope hides the
> existing outer one silently.  Java makes it an
> error to have such a 'hiding', and although the
> idea was totally novel to me when I tried Java out,
> I think it substantially reduced mistakes without any
> real cost in expressiveness.

	Yeah, but the scopes still nest and control
object lifetimes accordingly, right? The fact that
shadowing generates an error may have some
advantages, but it also has disadvantages too:
hiding supports 'cut and paste'.
 
> On meeting Python's simplified approach to scoping
> (although you tell me that the "simplicity" is really a
> misconception), it seemed to me that this would have
> similar but even stronger advantages.

	All I can say is: first, Viper has proper
lexical scoping, and it immediately feels cleaner and
simpler than Python's hackery. Secondly, I am FINALLY
using a real programming language, namely ocaml,
in which scopes nest correctly.

	The ocaml people reckon that ocaml code
is ten times more expressive than C/C++.
(You can do the same job in 1/10th the number of lines).

	It is so much easier to do things when scopes
nest properly. I abandoned C++, and a book I was 
writing about it, because they do not nest properly
in C++. The lack of proper lexical scoping makes
templates more or less useless.

> If the wrappers are standardized, readability is no
> problem.  

	Most people think highly bracketted expressions
are unreadable (eg LISP :-)

	Or, (did I (actually) mean), that, (most),
(people are (finding (that (highly (bracketed)))))
expressions are hard to read. :-)

	Python tries to avoid this:

	for i in len(x):

is already much worse than, say,

	for i in x.length():

[and now, make 'x' itself an expression ..]

	I personally think most people
like OO for no other good reason than the
use of reverse polish syntax:

	x.y().z()

is more readable than

	z(y(x()))

>And efficiency need not be, either; why
> cannot you parse and optimize:
> 
>         for key,value in kv_enum(sequence):
> 
> just as easily as
> 
>         ifor key,value in sequence:
 

	Well, in Python 'kv_enum' could be
anything. It may default to a standard function,
but the client can write:

	kv_enum = myfunction

This cannot be done for the 'ifor' form, since 'ifor'
is a keyword.
 
> >       Quite a lot of the time, you CAN provide the y:
> > using functional programming with map and reduce etc.
> >
> Yep -- and O-O wrappings work for it, too.

	The difference is that the 'OO' wrappings, in general,
cannot be localised. This leads to spagetti.
 
> > This works well in functional programming languages,
> > but it doesn't work nearly as well in python
> > What I mean  is, the 'y' becomes so cluttered the reader
> > isn't sure what is happening.
> >
> Why would it be less cluttered in a functional PL?

	At least in ML languages, function calling does
not require brackets. Of course, you still need them
to override the default precedence. :-(
 
-- 
John Skaller, mailto:skaller at maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia
homepage: http://www.maxtal.com.au/~skaller
voice: 61-2-9660-0850