for / while else doesn't make sense

[Rustom Mody]

On Saturday, May 21, 2016 at 1:51:19 AM UTC+5:30, Christopher Reimer wrote:
> On 5/20/2016 8:59 AM, Zachary Ware wrote:
> 
> > On Fri, May 20, 2016 at 3:09 AM, Erik  wrote:
> >> On 20/05/16 00:51, Gregory Ewing wrote:
> >>> It's not so bad with "else" because you need to look back
> >>> to find out what condition the "else" refers to anyway.
> >>
> >> With my tongue only slightly in my cheek, if it was desirable to
> >> "fix"/clarify this syntax then I would suggest adding some optional
> >> (existing) trailing keywords to 'else' in this context that spells it out:
> >>
> >> for item in seq:
> >>      if foo(item):
> >>          break
> >> else if not break:
> >>      nomatch()
> > With tongue firmly cheeked, you can always use the special `:#` operator:
> >
> >     for item in seq:
> >         if foo(item):
> >             break
> >     else:# if no break:
> >         nomatch()
> >
> > This has the benefit that you can use whatever syntax you like after
> > the `:#`, and use it in any version of Python you want.
> 
> According to "Effective Python: 59 Specific Ways to Write Better Python" 
> by Brett Slatkin, Item 12 recommends against using the else block after 
> for and while loops (see page 25): "Avoid using else blocks after loops 
> because their behavior isn't intuitive and can be confusing."
> 
> Until I read the book, I wasn't aware of this feature (or bug). Doesn't 
> seem like a feature I would use since it's not commonly found in other 
> programming languages. As the author demonstrates in his book, I would 
> probably write a helper function instead.
> 
> Item 13 does recommend using the else block for try/except/else/finally 
> in exception handling. :)

Firstly: let me say that for the specific case of loop-else I am in violent
agreement: I find it so confusing that I dont even know what/how it works

Coming to the more general attitude expressed above,  this view can be 
eminently sensible or dangerously retrogressive depending...

It is a sound and sane view because the field of computer science exists
and legitimately so.
Which means that, even though when we look around at the field of programming
languages what we are struck by is a bedlam of
- advertising
- fanboyism
- latest and bestest koolaid
- holy (cow) wars

And a corresponding deficit of anything really conceptual, real advances, real
understanding; in short truckloads of BS.

OTOH the fact that the field of CS exists and is not (only) BS is a good thing.

IOW sticking to the well-established canonical core is sound policy compared to
jumping onto the latest loud-rattling bandwagon.

And yet...
Human beings have the propensity of sticking to the norm rather than deviating
even when the norm is grievously in error.
The following lists some amazingly long lasting errors:
http://blog.languager.org/2016/01/how-long.html

This is related to the pedagogic principle called "Law of Primacy":

| Things learned first create a strong impression in the mind that is difficult 
| to erase. For the instructor, this means that what is taught must be right 
| the first time.

Given that for the most part, most of us are horribly uneducated [
http://www.creativitypost.com/education/9_elephants_in_the_classroom_that_should_unsettle_us
]
how do we go about correcting our wrong primacies?

Given that you imagine Lisp is a historical curiosity (have you heard of clojure?)
And java (and presumably OOP) is relevant
[see Stepanov on OOP: https://en.wikipedia.org/wiki/Object-oriented_programming#Criticism
]
I suggest you start with:
http://blog.languager.org/2016/01/primacy.html