Hacker News Reader

Comment by spangry | Hacker News Reader

It's hard to disagree with the author's assessment of asyncio. It may just be because I'm stupid, but I cannot get asyncio to fit in my brain no matter how many attempts I make to learn it.

Another HN thread on python strings got me thinking about the print() function. This is going to sound a bit trivial but bear with me. Although I agree that print() is more consistent with how functions are called in Python, I can totally see how irritating it would be for a Python 2 programmer. It's also just generally disruptive to typing flow: when you've finished typing the word 'print' your hands are 'out of position', making it a bit jarring to type the open parenthesis.

This has me wondering: is there a language out there where deliberate thought has been put towards typing ergonomics and fluency? And I wonder if such a language would have a material impact on developer productivity?

View on HN

> I cannot get asyncio to fit in my brain

I found it extremely (to the point of a frustration-induced mental breakdown) hard. I still can't fit it all in my brain, but I got enough so that my code works. The best explanation I can give is by analogy: think of the kernel of an OS, and how it spreads CPU time across all the processes. Sometimes processes know they dont need to work, say they're waiting for a disk read, or a network message, so they surrender and say "ok kernel, I'm done for now, let someone use CPU". Thats like what the "yield" command does in asyncio, although yield requires a context. So you say "yield until this function does something interesting" (I think it's called 'await' now), then a mini-"kernel" (the io service) stops executing that function and polls all the other functions to see if any of their yields have changed state. It just keeps polling till it finds some work it can do. I dont yet fully grok the futures yet, but I think they're just a way of packaging up the "work item" produced when a yield actually gives you something.

* Disclaimer: I barely understand this, so if I'm spreading bad information I apologize in advance.

I have nothing against asyncio in python, I think its presence helps put python in the "big leagues" of languages, and not just a toy for noobs with arduinos. It's an additional language feature, like C++ templates. You dont have to use it, so the noobs can keep doing their thing. But it prevents more experienced devs from outgrowing the language and having to learn a new one, or port working code to a new language.

That makes sense to me, thanks for the explanation. I don't suppose you do guided tours of the Python standard library documentation? :)

And I get what you're saying about having nothing against asyncio being in the standard lib: I mostly agree. You can ignore it if you don't like it. And it does allow the more skillful python devs to do pretty amazing things (e.g. sanic, that uvloop pgsql driver etc.). I guess the small niggle I have with asyncio is similar to the one have with the standard library documentation (and Gnome, for that matter): I can't understand what the authors/developers were trying to achieve when writing it.

Take the std lib documentation for instance. It's only my opinion, but there seems to be very little consistency between libraries, and much of the documentation reads like a stream of consciousness punctuated by the occasional "oh and there's this thing too". This makes it very difficult to learn about what is being documented.

I mean, that's fine, it's their project and their prerogative and it isn't all bad. But it just seems self-defeating to write documentation that is incomprehensible. I suppose one could view technical documentation as a work of art that has some kind of intrinsic artistic value... Otherwise it just seems like wasted effort to write documentation that doesn't convey information in a useful way.

Sorry this turned a bit ranty. I'm only speaking for myself here; it's entirely possible I just happen to think in a way that is very different to how the std lib doc authors do.

I get what you're saying, that the docs dont really follow an overarching theme. Thankfully, stackoverflow fills in the rest.

> I can't understand what the authors/developers were trying to achieve when writing it.

I can't speak for them, but event-driven designs are a great alternative to procedural polling / event loop designs. I am not sure, but I think there's a relationship to the functional programming style where you say "when there's data, do this to it". So I think what they're trying to accomplish is to enable FP paradigms in python. You could write a coroutine that says "yield until there's data, when there is, transform it".

I used it with zeromq [1] to route messages between a few C++ programs that all work together. So my python program is a "supervisor" task that sends heartbeat messages to my binary programs over zeromq. Asyncio is handy for timing the heartbeats (because you can say "in 2 seconds, do this") and reading the message queue. I also hooked it up to inotify, so I can do "echo SOME_COMMAND > command.txt" and as soon as command.txt is written to, my supervisor gets a notification, reads the file, and processes the command. I almost lost my sanity to get it working, but once I got it, I really like it. One tip though, dont try to mix async and sync programming. Go big or stay home.

[1] http://zeromq.org/

Oftentimes the people who understand the module being documented aren't able to put themselves in a contextless reader's shoes.

I've never had 'yield' explained to me so succinctly :) Thanks!

So little time in programming is spent typing that it would make little sense to optimize a general purpose language for typing speed. Reading, modifying and reasoning about programs are much, much more important.

I can relate to how having print be "special" becomes a habit - but I think on balance, print() is simpler.

Now, going down the rabbit hole of "no syntax" in the end one walks by lisp/scheme and end up at lamdba calculus (or brainfuck...).

Smalltalk has very little syntax.

I've been thinking a bit about how simple is is simple enough for useful computer languages, with an emphasis on reading and writing. The Apl people claim dense notation is good, while I think that "pseudo code" should be enough - syntax is for communicating with humans, the machines have machine and byte code.

Other [ed: "real" languages with rather concise syntax] are Julia, Kotlin and Nim.

I find that using whitespace for blocks (or begin/end) is generally preferable to brackets - we generally only use parentheses in prose and poetry - typing []{}<> is invariably a little complicated with interfaces developed for typing text. @ is actually a little easier thanks to the rise of email (addresses).

I'm biased though, as I generally use a Norwegian keyboard layout - making room for the three extra letters "æøå" exiles [{'< somewhat, which in turn pushes the backtick and a few other "easily available" punctuation marks firmly into repetitive stress syndrome territory.

I've seen Nim pop up a couple of times now. Perhaps I should go check it out (and this Kotlin thing too). Thanks for the leads :)

Strongly recommend the Nim "How I start" article:

https://howistart.org/posts/nim/1

Reply on news.ycombinator.com