Hacker News Reader

Comment by noobermin | Hacker News Reader

Why remove a feature that could be useful? That makes no sense.

Just because it isn't named in a way people find intuitive doesn't mean it isn't useful.

> Why remove a feature that could be useful? That makes no sense.

It makes sense in the way that a language which is strongly biased to readability and consistent expectations makes sense. It is also how a language which minimizes programmer error makes sense.

For languages that refuse to remove anything, and thus suffer from unnecessary challenges, see C++.

Several things have been removed from C++, including auto_ptr, exception specifications, unary/binary_functions, trigraphs.

I think the extreme difficulty and indeed controversy that the committee stared down when removing trigraphs, which are a useless feature that the vast majority of C++ programmers will never once encounter, speaks well to GP's point that C++ is very conservative in how it removes features. Maybe not JS-level careful. But still.

Of course, JS has a problem in this regard that while it looks like a language, it is also a (de facto) assembler for the browsers. So disabling anything in JS will break lots of sites which will never be fixed.

However as far as programming is concerned, many things have been deprecated through transpilers and linters (for example "==" throws a warning in ESlint).

Most legacy cpp features and language semantics will never be removed, despite what many prominent voices in the community think.

Unintuitive features that "could be useful" sounds like the antithesis of good design.

And it sounds like a common problem in the software industry.

>Why remove a feature that could be useful? That makes no sense.

Cleaning up a language "makes no sense"?

Besides "could be useful" can be said for anything. Features should prove their usefulness (and in this case Guido regrets even adding it), we don't just keep them around in the off chance that they might be. That's hoarding.

You want a major version bump on very widely used software just to remove something that causes a minor confusion on the rare occasion it is used? In what world does that sound like a good idea?

It's one thing to make a change like this along with a bunch of other breaking changes, but there is no way this justifies breakage by itself.

>You want a major version bump on very widely used software just to remove something that causes a minor confusion on the rare occasion it is used?

No, I want a deprecation warning, and an eventual removal when for 4.0 lands.

>In what world does that sound like a good idea?

In a world where we don't pile crap upon crap forever, like with POSIX, X-Windows, or C++.

There are reason those systems are still widespread in use today, strong compatibility is one of them.

There are also reasons those systems have tons of accidental complexity that frustrate users and wastes endless workhours. Strong compatibility is one of them.

> Why remove a feature that could be useful? That makes no sense.

Everything has a cost. In maintenance, in documentation, in support, in limiting the design space or constraining further development for other reasons (performance, for example).

Nothing is truly free. Everything has to be balanced regarding costs and benefits.

Here's the first sentence of the spec of the Scheme programming language:

"Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary."

It's interesting how Lisp languages get criticized for lack of maintainable because of their power to let you essentially add new features, but then every popular modern language with the exception of Go piles on new features over time.

Go is still relatively young.

That grand statement is made possible by banishing needed Scheme features into numerous SRFI documents, and into implementations.

I find it hard to argue it’s (the else block) any more useful than just using the `else` block’s logic in the try block.

    try:
        import uvloop
        asyncio.set_event_loop_policy(uvloop.EventLoopPolicy)
    except ImportError:
        pass

Does the handler for if the try succeeds need to be in an else, separated from the success logic?

Generally you can't be sure that the second statement does not also raise ImportError, where you do not want to catch it.

You can actually use else for try statements. Doesn't answer question but it's something I learned relatively recently and may help some others.

    try:
        import uvloop
        asyncio.set_event_loop_policy(uvloop.EventLoopPolicy)
    except ImportError:
        pass
    else:
        print("well that didn't work")

I'm not sure about what the message in that print() refers to (else fires if the import succeeded) so here's another example

    $ python3
    >>> try:
          1/0
        except ZeroDivisionError:
          print("exception")
        else:
          print("surprise")
        
    exception
    >>> try:
          1/1
        except ZeroDivisionError:
          print("exception")
        else:
          print("normal")
        
    1.0
    normal

The choice of the name else is unfortunate because it's activated under the same circumstances of a then branch of an "if". Maybe its name should really be "then". That would also look like a .then of a JavaScript Promise, which would make sense nowadays and was obviously impossible to foresee back in 1991. However the name "else" makes sense if it refers to "except": it's what happens when no "except" fire. I still don't understand why it should be "else" for a "for" that succeeded: it should be a "then" there.

In the case of a for loop, you are modeling "a for which did not break". The cases where you want that block are typically when you are looping through a list trying to find something, so "if I found it I broke, else do this default logic".

That's the intended use case but it works also when there is no break

    $ python3
    >>> for i in [1,2,3]:
          print(i)
        else:
          print("completed")
        
    1
    2
    3
    completed

That should be a "then", but admittedly a very useless one.

I agree that for the intended use case "else" is a better choice. It's like the else of the if that failed to find 2 in this code:

    >>> for i in [1,2,3]:
          if i == 2:
            break
        else:
          print("we didn't find 2")

Still "else" doesn't hint much at what's going on, especially if the body of the loop is long. Maybe "nobreak" would make it immediately understandable to everybody? However in the best Python tradition I would make it very explicit, remove the feature from the language and use boolean flags. They are less compact but easier to understand than a feature that (probably) very few people know about.

    >>> we_found_2 = False # this is a valid assertion now 
    >>> for i in [1,2,3]:
          if i == 2:
            we_found_2 = True
            break
        if not we_found_2:
          print("we didn't find 2")

That's also the only way to do it if there are multiple break in the loop on different conditions.

yeah you are right, it should be

print("well that's done")

By the way, try also has an else clause that behaves like the one in if https://docs.python.org/3/reference/compound_stmts.html

It behaves more like the main branch of “if” unless you construe “try” as “try to produce an exception”; outside of “if”, Python’s “else” pretty consistently implies exactly the wrong picture of normal flow.

I guess I wasn’t clear, because my point is generally that moving the logic to an else block in any supported control structures (if, for, try, ...) doesn’t necessarily make it clearer or cleaner.

Because readability counts, and id at the core of Python.

Goto is also useful... See why now?

This comment contains more snark than content, but I'll reply anyway:

Goto is considered harmful, but it's important to recognize the context of that decision rather than parroting the idea. It's not an obvious idea and if the discussion had happened today with modern languages[0] instead it's not at all obvious the same conclusions would be reached.

This write-up does a pretty fair job of translating the original paper to something more modern without a lot of bias. http://david.tribble.com/text/goto.html

[0]: Modern languages of course learned from this paper, so that's not a fair comparison. In fact golang contains a goto, but it behaves well according to Dijkstra's concerns and occasionally results in more readable code. I would be shocked if Dijkstra took any issue with go's implementation.

Reply on news.ycombinator.com