If you want to read more about this kind of thing, there's a book named "Move Along, Please" by Mark Mason, who travelled from Land's End to John O'Groats (i.e, from one end of Great Britain to the other) using only buses. Took more than 24 hours, though.
+1 on the astonishingness (hm...) of mechanics in general, and Linotypes in particular. Some time ago I watched a fairly good movie on how they work. I think it was this one: https://www.youtube.com/watch?v=EzilaRwoMus . Those things not jamming every fifteen seconds is nothing short of a miracle. Some useless knowledge for everyone who is curious. =)
I'm not sure where I'm going with this, and I may be completely off the mark but: Pandas, like SQL, feels like it doesn't compose very well. If you know some basic programming language — including Basic! — you've got a set of building blocks that let you, at least in principle, implement any algorithm. But in Pandas (and SQL) everything needs a new keyword or method or something. We need a better way of expressing high-level concepts, but if I knew what that was, I'd be a high-flying professor somewhere, not an anonymous commenter on HN!
So, we have (at least) different evaluation orders, different meanings of the % operator (How are negative numbers handled?), different meanings of the / operator (is 10/3=3 or 3.3333 — notice that Python3 joins the 8.29e+12 fold!). This shows two things: 1) Even though it is syntactically correct in N different languages, it does not necessarily mean the same thing, and 2) floating-point math has many traps. Neither should be news to the HN readership.
I got bitten by that prank when copying code from a question, to see what it did (it was something obviously harmless). I was rather annoyed for about two seconds before I realized what date it was. :)
I remember first reading about these. My reactions were something like:
Ok, they had video projectors in the late sixties. Fine.
Wait a minute. I hadn't even seen a video projector until the late eighties. They were non-existent at my university in the early nineties. I saw a small-lecture-hall one in 2000, and that was a large, hot and expensive-looking device. And these fellows had them thirty years earlier?
I just leave the cursor wherever it happens to be. With link-dense pages, as Wikipedia tends to have, that very often causes a fairly large box to pop up.
Also, when scanning a page looking for info and links, I seem to both read and keep the mouse pointer somewhere close to the center of the window, increasing the risk of annoying pop-ups. (Moving the mouse too far away often causes the wrong thing to scroll whey you use the wheel, perhaps not on Wikipedia but on many other sites.)
Reading this finally made me figure out how to turn this feature off (to be fair, it was quite straightforward). I find it extremely annoying when there are always things popping up over the text you are trying to read.
Lately I have been wondering whether a "fear" (for want of a better word) of hand-drawn diagrams are causing diagrams in general to be under-used. We're used to having everything typed, TeX:ed, machine drawn, perfect, and we want our diagrams to look like that, too, but using drawing software is hard and time consuming, so we don't diagram at all. But we could just whip out pencil and paper! You don't have to be an artist to draw some boxes and arrows. And the problem of archiving and revision control is solved now that everyone has a digital camera in their pocket (and a JPEG file of an A4/letter page isn't very big by today's standards).
I am positive I saw a picture ages ago (late 1980:s, when keypad phones were starting to become mainstream in Sweden) where someone had "solved" the problem by building a pocket calculator with a rotary dial. I'm not sure whether it was a mock-up or an actual device. :)
Sweden did an... interesting version of calendar change. Like Britain, we stuck with the Julian calendar for quite some time. Then we decided to catch up with the Gregorian calendar by omitting leap days, starting from 1700 (this would have taken 40 years!). To make matters worse, the scheme was forgotten and 1704 and 1708 were leap years. In 1712, Charles XII decided to sync back to the Julian calendar by having an extra leap day, making a 30-day February, which I think is unique. We then finally went Gregorian by omitting 12 days at the end of February 1753.
One favourite of mine in this genre is applications who use both command-[ and option-command-[. On a Swedish mac keyboard, [ is on option-8, so it is impossible to type just command-[ without the option key...
Last time I looked at autoconf et al. from a developer's view -- which is, admittedly, probably 20 years ago -- the documentation was quite good. The discoverability of, for example, the C standard library is also quite poor if you do not read the manual.
My main gripe with autotools these days is that there seems to be no standard mechanism for specifying non-standard locations for dependencies. (Or if there is, that no packages use it...) If I build something from source, it is nearly always because I want a newer version than what is available from the appropriate package repositories, which usually means that I will want newer versions of the dependencies too, or because I want a built-from-source version of one of those dependencies. If I'm really lucky, pkg-config will pick them up. Sometimes just setting LDFLAGS=-L/my/build CPPFLAGS=-I/my/build will work. Sometimes I have to say --with-gnomovision=/my/build, sometimes I will have to say --with-gnomovision-includes=/my/build/include, ...
Neither following nor playing either sport I'm on thin ice here (or maybe that's exactly what I'm not!), but isn't bandy sort of like hockey but with soccer-sized goals (and a ball instead of a puck)?
To a certain extent, yes. However, with a binary protocol, at least the syntactic level tends to be fairly solidly locked down, simply because you have to. Two bytes bing-endian unsigned integer of that, four bytes big-endian signed integer of that, etc. The confusion happens at the semantic level. With text protocols, the confusion starts in the parser (see other comments about continuation lines in HTTP, for example).
And I forgot to say in my first comment: If you design a text-based protocol that can carry textual data, make sure it can handle any text you throw at it (and preferrably any byte sequence), i.e. decide and implement a good quoting convention from the start. I have seen a text format, initially used to store config data, but later extended to other things in the system because it was there, that used <<< and >>> as string delimiters. Then some client named something <<<foo>>>. (This was early 90:s, so JSON wasn't invented yet!). And yesterday I spent a large chunk of my working day sorting out problems originally caused by a system exporting semicolon-separated almost-CSV, and an enterprising tester putting a semicolon in a text field.
The obvious risk with plain-text protocols is that you don't write a rigorous spec, and don't write a strict parser, but some hack up least-effort thing with a few string.split() and whatever. This means there is a lot of slack in what is actually accepted, and unless you are in full control of both ends of the protocol, that slack will be taken advantage of, and unless you are more powerful than whoever is at the other end (which you aren't, if they're your clients and you are not Google or Facebook), you have to support it forever. So write plain-text protocols if you like, but make sure to have a rigorous spec, and a parser with the persicketyness of... I don't know.
Right now, it's evening in Europe, meaning that those who have been out collecting data during the day have now come home, had a shower (or brushed the snow off, in my case), relaxed a bit, downloaded their GPX tracks to their computers, and started editing. In the US, those doing boots-on-the-ground mapping are still out.
The relative sizes depend on the relative distance from the camera. Say you have two persons, one standing one meter in front of the other, and the photographer standing one meter in front of the frontmost person, shooting with a wide-angle lens so that the nearest person fills the frame. The far person is then twice as far away as the near person (2m vs. 1m), and will appear half the size of the near person (assuming they're the same size in reality!). The photographer then moves 50 meters away, and shoots with a (really!) long telephoto lens, so that the nearest person still fills the frame. The near person is now 50 meters away and the far person is 51 meters away, and will appear 50/51 of the near persons's size.
(This would still happen if the photographer kept the wide-angle lens, but then a lot more of the surroundings would have been included in the frame, making it obvious that the persons were far away. Whether tele/wide-angle "affects perspective" is a favourite topic of endless debate on photo-related Internet forums. The answer hinges on which parameters you maintain constant, and which ones you allow to vary.)
Trivia: The names "Stephens" and "Huseby" probably ring a bell with some Swedes because of the scandal around the management of the estate in the mid-20:th century: https://en.wikipedia.org/wiki/Florence_Stephens .
OSM:s biggest problem seems to be that it offers a product — a map database — that very few people need, and even fewer people can use, while still relying on millions of ordinary people for data collection (which means understanding the data model, which is getting hideously complex, because it tries to encode everything that can be located).
At least it circumvents https://xkcd.com/1987/ to some extent. It sometimes feels like half the [python] questions on Stack Overflow are from persons confused about how and where packages get installed and what Python they are actually running.
I believe most makefiles I see these days — pretty much all except the ones I write myself — are the monstrosities that come out of automake. If that is the first impression new programmers get of make, then make is dead, because nobody is going to want to touch it with a bargepole.