2015-11-18
VCS bisection steps should always be reversible
So this happened:
@thatcks: I think I just ruined my bisect run with one errant 'hg bisect --bad', because I can't see a way to recover from it in the Mercurial docs.
This is my extremely angry face. Why the hell won't Mercurial give me a list of the bisect operations I did? Then I could fix things.
Instead I appear to have just lost hours of grinding recompilation to a UI mistake. And Mercurial is supposed to be the friendly VCS.
VCS bisection is in general a great thing, but it's also a quite mechanical, repetitive process. Any time you have a repetitive process that's done by people, you introduce the very real possibility of error; when you do the same thing five times in a row, it's very easy to accidentally do it the sixth time. Or to just know that you want the same command as the time before and simply recall it out of your shell's command history except that nope, your reflexes were a bit fast off the mark there.
(It's great when bisection can be fully automated but there are plenty of times when it can't because one or more of the steps requires human intervention to run a test, decide if the result is correct, or the like. Then you have a human performing a series of steps over and over again but they're supposed to do different things at the end step. We should all know how that one goes by now.)
So inevitably, sooner or later people are going to make a mistake during the bisection process. They're going to reflexively mark the point under testing as good when it's actually bad, or mark it as bad when they just intended to skip it, or all of the other variants. It follows directly that a good bisection system that's designed for real people should provide ways to recover from this, to say 'whoops, no, I was wrong, undo that and go back a step' (ideally many steps, all the way back to the start). Bisection systems should also provide a log, so that you can see both what you did and the specific versions you marked in various ways. And they should document this clearly, of course, because stressed out people who have just flubbed a multi-hour bisection are not very good at carefully reading through three or four different sections of your manual and reasoning out what bits they need to combine, if it's even possible.
Of course, this sort of thing is not strictly speaking necessary. Bisection works just fine without it, provided that people don't make mistakes, and if people make mistakes they can just redo their bisection run again from the start. A bisection system with no log and no undo has a pleasantly mathematical sort of minimalism. It's just not humane, as in 'something that is intended to be used by actual humans and thus to cope with their foibles and mistakes'.
Overall, I suppose I shouldn't be surprised. Most version control systems are heavily into mathematical perfection and 'people should just do it right' in general.
(This is a terrible misunderstanding but that's another entry.)
Increasingly, I no longer solidly and fully know Python
There once was a time where I felt that I more or less solidly knew and understood Python. Oh, certainly there were dark corners that I wasn't aware of or that I knew little or nothing about, but as far as the broad language went I felt that I could say that I knew it. Whether or not this was a correct belief, it fed my confidence in both writing and reading Python code. Of course the wheels sort of started to come off this relatively early, but still I had that feeling.
For various reasons, it's clear to me that those days are more and more over. Python is an increasingly complicated language (never mind the standard library) and I have not been keeping up with its growth. With Python 3 I'm basically hopeless; I haven't been attempting to follow it at all, which means that there's whole large areas of new stuff that I have no idea about. But even in Python 2 I've fallen out of touch with new areas of the language and core areas of the standard library. Even when I know they're there, I don't know the detailed insides of how they work in the way that I have a relatively decent knowledge of, say, the iterator protocol.
(One example here is context managers and the "with" statement.)
I'm pretty sure that this has been part of my cooling and increased ambivalence with Python. Python has advanced and I haven't kept up with it; there's a distance there now that I didn't feel before. Python 3 is an especially large case because it feels that lots has changed and learning all about it will be a large amount of work. Part of me wonders if maybe Python (at least Python 3) is now simply too large for me to really know in the way that I used to.
You might ask if actually knowing a language this way is even important. My answer is that it is for me, because knowing a language is part of how I convince myself that I'm not just writing Fortran in it (to borrow the aphorism that you can write Fortran in any language). The less I know a language, the less I'm probably writing reasonably idiomatic code in it and the more I'm writing bad code from some other language. This especially matters for me and Python 3, because if I'm going to write Python 3 code, I want to really write in Python 3; otherwise, what's the point?
(I don't have any answers here, in part because of a circular dependency issue between my enthusiasm for writing stuff in Python and my enthusiasm for coming back up to full speed on Python (2 or 3).)