"sins" (aka, acknowledged language problems)

[William Tanksley]

On Tue, 28 Dec 1999 00:27:13 +0100, Alex Martelli wrote:
>John Skaller writes:

[talking about the Python equivalent of C's ?:]

>But the more we talk about it, the more readable
>it becomes -- because the general acquaintance

Urgh.  I think it's vile and nasty.  I hope nobody ever ever uses it.  It
does NOT say what it means.  Unlike myself :).

>> shadowing generates an error may have some
>> advantages, but it also has disadvantages too:
>> hiding supports 'cut and paste'.

>And this is bad because...?

>The "cut and paste" style of "code re-use" is a
>blight (and I've done enough code inspections
>of allegedly "production" code, and code built
>by pretty brilliant people too, to make me
>_very_ arrogantly sure of this specific issue:-).

The fact that it's so common implies something about it.

>If Java's "no hiding" rule really discourages it
>(and I'm not sure it does -- somebody is sure,
>alas!, to invent some "smart editor" that will
>rename local variables on the fly as you paste
>the code...!-), then I would count that as a
>pretty major advantage.

I'm not sure that discouraging it is the right approach -- I think that
making it unneeded is better.  OO gave a start at that; Aspect Orientation
makes another dent in the problem (www.aspectj.com).

And BTW, there is already a program which handles variable renaming --
although not for the purpose of copy'n'paste, but rather for cut'n'paste
(so you can move methods and variables from one class to another).  Right
now the only fully functional refactoring browser is for Smalltalk, but
Java's time will come.

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

>I'll pass on this.  I think the record for "most
>work done in fewest lines" is still with bad old
>APL, at least for the kind of jobs it handled
>best.  And, of course, right with it goes the record
>for "most non-intentionally obfuscated code":-).

It's a good language.  I hate that character set, but even it has its uses.

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

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

>Yep, with the exception of rabid LISP'ers.

Unreadable is an exaggeration.  Harder than it should be ... yes.  I like
Lisp, though.

>Would you thereby argue that the utter lack
>of brackets in FORTH makes it the MOST
>readable language?

No, but I would argue that it makes it more convenient to read than a
fully bracketed language (such as Lisp).

>Or, is it an issue of striking a happy medium?

Naw.  It's about having a syntax, semantics, and set of conventions which
fit well together.  Lisp has a decent combo, so long as you ignore the
parens.  Rebol has a nice combo as well, as long as your lines are
reasonably short (which implies a greater use of variables).  And so on.

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

>The only language I've used extensively, where function
>calling does not require parentheses, is the 4-letter
>language above alluded to, which shall here remain
>nameless.  (Well, and Forth, too, but "that was in 
>another country", and, besides, the machine I ran 
>_that_ on is dead).  I must say that the usage one
>finds there does not particularly argue for the lack
>of parentheses enhancing readability, but that is
>perhaps not a fair test-bed for such a quality:-).

Forth and Rebol both actively minimize parentheses.  Both are highly
readable, assuming that one follows the basic conventions set up by the
community.

>Alex

-- 
-William "Billy" Tanksley, in hoc signo hack