Hacker News Reader

Comment by ak217 | Hacker News Reader

I like to call this cognitive compatibility - the amount of effort required from an uninitiated English-speaking observer to understand what a program does. Most people who are deeply familiar with a language will have a tendency to discount this effort, but really it is essential because it minimizes the translation layer that your brain has to use any time you read code.

Python encourages code which is readable in English and reasonably brief. Having readability, consistency, and the "principle of least surprise" as primary language and community principles ultimately saves developers time and makes them more efficient.

And the maturing of PyPy is incredibly exciting.

View on HN

I want to make what I think is an important qualification which conflicts with a reading of your comment: Python is readable to people who are familiar with conventional Algol-based programming, i.e. every modern programmer. That does not make it readable to an arbitrary English-speaker, which is an assertion I sometimes hear: "Oh, Python is so much like English, people who aren't even programmers can read some of it!" Which I can say from experience is not the case in the slightest. If it were, my job—which involves teaching Python to non-programmers—would be inestimably easier.

Python is simple and easy because it takes everything you know from other languages and systems and makes those things simple and easy and pleasant to do. I've even seen Python used as a kind of runnable pseudocode for projects that would eventually be written in other object-oriented Algol-based imperative languages, which is a testament to how well it distills those concepts down and makes programming simple. But it is not "readable in English." It is readable in pseudo-Algol.

Thankyou! So many programmers seem to forget they have an enormous base of syntax and logic which is not at all like natural language. They see python and say, oh wow this is so easy to read, just like English! But its only an easier way to express a syntax that really is nothing like what a nonprogrammer would consider English.

It varies.

When I was helping @limedaring learn Python, I'd read source with her and explain what it does. Quite often I'd feel somewhat embarrassed when explaining what a line does by verbatim reading what it says.

"for user in users: ..."

"if user.is_admin: ..."

It was especially nice that the topic of "what code block does this condition apply to?" did not even occur to either of us. The indentation-based blocks made it completely organic. (Try explaining Bash to someone and when to use do/done, if/else/fi, case/esac.)

But sure, things get weird with decorators and generators and other advanced features.

IMHO, decorators, although very useful are a big departure away from python's "simplicity" in syntax. I remember having lots of headaches several years ago wile trying to fit it in my brain. Even after I realized it is something as simple as JavaScript's myfun(fun(){}), my brain somehow continued denying to absorb it.

Agreed that they can be tricky initially and hard to debug, but I think they're totally worth it for eliminating repetitive code. And IMO as long as there isn't a bug in the decorator itself, code with decorators can be just as readable (if not more so) to someone else (e.g. decorating your functions with @authenticated instead of if self.user.is_authenticated: # blah, blah blah)

if Python had better function syntax and anonynous functions, decorators wouldn't even be a 'thing'

Can you elaborate on that? The more I use Python, the more I find it to be a well thought out language with a very consistent feel, allowing me to write code without thinking. Well, except when it comes to decorators. How would you propose to improve the syntax?

> if Python had better function syntax and anonynous functions, decorators wouldn't even be a 'thing'

Better function syntax? What's wrong with python's function syntax and how does it relate to decorators?

Python does have anonymous functions, though they are limited: You can have only 1 expression, you can't have statements, and you can't have local variables. The reasoning is lambdas should be used for small operations; for everything else, named functions should be used.

The reasoning behind lambdas is arguable, but it still doesn't explain how it affects decorators.

Consider:

    def memoize(fn):
        from functools import wraps
        @wraps(fn)
        def memoized_fn(*args):
            if not memoized_fn.cache.has_key(args):
                memoized_fn.cache[args] = fn(*args)
            return memoized_fn.cache[args]
        memoized_fn.cache = {}
        return memoized_fn

    @memoize
    def fib(n):
        if n < 2: return n
        return fib(n-1) + fib(n-2)

    print fib(100)

What would a better function syntax and anonymous functions do so that memoize decorator won't be a thing?

Less restricted anonymous functions would allow stuff like this:

    fib=memoize(function...)

So the @ shortcut for:

    def fib():
        ...
    fib=memoize(fib)

wouldn't be necessary to 'clean up' the decoration of the function.

Even if it were possible, I would stick with

    @memoize
    def fib:
        pass

fib = memoize(function ...) has unnecessary nesting, and @memoize is cleaner IMO.

I am curious - do you find @memoize confusing? Personally for me and anyone I have talked to, @memoize is vanilla - the confusing part is the decorator itself, especially one that takes arguments; that coupled with the fact that classes(which override __call__) and functions are both used as decorators.

No, I don't find it confusing. But I read craigyk as mostly talking about the special decorator syntax, not function decoration in general.

Yes - I agree with you in principle. Python is not the perfect combination of computer language design and cognitive compatibility - it's just that I think it's doing better at it than anything else that has traction right now. Hopefully something better will come along and improve on it!

Why, I have a feeling that teaching Python to non-programmers is easy, very easy when they want to learn. For instance a friend of mine just sent me a pong game his son and daughter wrote last Sunday. Apart from maybe Logo, I can't imagine using anything else than Python.

Python code is superficially easy to read, but to know what a piece of code really does can be extremely hard, specially when metaclassed, generators and the like are involved.

Also there is plenty of Python code that is not particularly readable even superficially, particularly convoluted uses of list comprehension come to mind.

And I don't think 'consistency' is one of python's main qualities, when even in the stdlib there are plenty of very different naming styles. (Yes, this is improving in Python 3, but has been a big issue for a very long time.)

+1 for the metaclasses example... list comprehension doesn't seem that big a deal, but then am biased way too much.. Also agree with consistency part.... but personally python is beginning to lose some of it's charm with the move towards consistency...

This is the kind of reasoning that lies behind LFMs: that it is better to cater to someone who knows nothing about the language (but maybe has a few mainstream languages under their belt already) than to someone who has put in the work to understand it. I'd rather pay to learn a difficult but more abstract language feature just one time, than pay all the time for its absence.

A programming language being similar to spoken english isn't necessarily a good thing. SQL being a prime example of this.

I could not agree more with this comment and just wanted to thank you for expressing this so clearly.

Reply on news.ycombinator.com