"Year 1" was originally conceived as "the first year of our lord", which is one reason why there's no "zeroth year ...".Now we're in the "two thousand and fifteenth year of our lord". Imagine all the off-by-one errors if years were zero-indexed.Also, it wasn't until Fibonacci in 1200 or so before the western world developed a working relationship with zero.But natural counting numbers are always 1-indexed anyway. The second dozen starts at 13. Bakers excepted, of course.
 But measurement of a person's age is 0 indexed. It is a year after you are born that you are 1 year old.
 Sure, but while you are 0, you are in your first year of life.
 Natural counting isn't 1-indexed. You usually count things after you tally them, not before. (You don't start counting beans by saying "one bean" and then waiting for that bean to arrive.)Besides, it is not all that clear if someone just says "Jan 1 marks year one" whether it marks the end of the first year or the beginning. With dates, it usually marks the beginning. That's why it is 1-indexed. We hardly count anything else that way, so why would you assume it is 'natural counting'?
 Yeah, sloppy.It's sad that 538 has turned into a pop-stats site that runs on volume and snappy headlines.
 >It's sad that 538 has turned into a pop-stats site that runs on volume and snappy headlines.It's our fault, they're catering to our demands. You can't run a media company any other way. No one wants to read read (although I'd bet on average everyone spends far more time reading). So you get wham-bam, buzzfeed-esque content. Even on HN, long form articles will inevitably be met in the comment section with a "tl;dr?".
 There's nothing wrong with asking for a tl;dr when you're trying to find out if the long form is worth your time. (Most are not.) In academics, the tl;dr is called the abstract, and it would be silly to think that they should be eliminated because people ought to just read everything.
 The real problem seems to be that Nate Silver's (and 538's) brand value exceeded the available payment from NYTimes. So he did the rational thing and tried to capture it in the open market.But Nate's a stats guy, not a marketer. Brand dilution is a thing. I don't begrudge him for selling out. I just wish my domain-based trust filter hadn't been broken in the process.I sure hope they put together some solid election coverage.
 > But Nate's a stats guy, not a marketer. Brand dilution is a thing. I don't begrudge him for selling out.Incidentally, Nate didn't sell out when 538 left the NYT, he sold out when 538 was picked up by the NYT.
 Monetarily, perhaps -- which if true makes the subsequent devaluing all the more disappointing.But content quality was higher (and volume lower) at NYT than post. I've been a reader since well before the NYT imprint, and I don't think the quality went down significantly at NYT.
 Bucky Fuller always inspires disagreement, but I think you'd have a difficult time making the case that the Jamestown Colony from the year 1607 is in any way relevant to this discussion.
 > Personally, I use downvotes exclusively for hostilityIMO, noobs might think HN community is hostile & leave. Not many noobs would ask for reason, if they feel intimidated - https://news.ycombinator.com/item?id=9179609
 >IMO, noobs might think HN community is hostile & leave.I believe the parent was referring to downvoting comments that are hostile in tone, not using downvoting as an outlet for his own hostility.
 He seems to disagree with OP completely. But, I find OP's point about noobs valid:> People who get down voted (esp noobs to the community) have no idea why they were.
 I agree with that part, but disagree with the proposed solution, completely.I suggested an idea to inform new users in a post upthread (link to guidelines next to any comment of yours that is score-negative), but it would probably be better to link to a page with the guidelines plus a blurb about accidents, confusion, and just not taking it too seriously.
 Tone policing is a form of hostility, too.
 Well, yes, then I am intolerant of aggressive behaviour and take action to suppress it and its spread.The simple logic is that hostility obscures the writer's meaning, invites reactive hostility, and pollutes the conversation. I can see no reason to promote it.Slow down, try again without invective, be civil. It works better.We are not the powerless disenfranchised citizens of a dictatorial state with no other means of expression. Some of us might be, actually, but not in this setting.
 Tone policing disenfranchises minority views, period. Doesn't matter whether the context is social justice or database performance; Unless the tone is beyond well-known bounds (e.g. is abusive, flippant, way off-topic, etc.) I don't think it is generally constructive.Edit: I think we're talking past each other on where "tone policing" becomes regular old moderation.
 > both because pg endorses the ideaHe did at one time mention that. But he also said this:https://news.ycombinator.com/item?id=1057347which seems to not like downvote for disagreement.> As an alternative, I wouldn't be disappointed if the threshold for greying out was reduced to -3That feels like a good idea: Don't change the gray level until a post has had 3 downvotes.
 >As an alternative, I wouldn't be disappointed if the threshold for greying out was reduced to -3 or so. And full death at -10?I think this would go a long way toward resolving people's negative attitudes toward downvotes. The fact that one errant idiot could grey out your post and make it harder for others to read is a bit too far IMO.
 > I use downvotes exclusively for hostilityhostility, is subjective.It's easy to block out any thoughts not comfortable to us.It's easy to hide behind consensus than risking the cognitive dissonance associated with the truth.The civil libertarian in me likes to see a bit of heat, expression, emotion; within reason.I want to challenge my impulses. I want to grow.Maybe I'm a maverick, but when most people want to downvote, I'd rather see the elaborate more on their unpopular opinion.
 We agree. Except for the subjective part.I'm not talking about hostility to my beliefs. I'm talking about straightforward aggressive angry spouting that happens occasionally, even here, and destroys any attempt at civility.Up voted. :)
 That's an interesting idea, but I would not call it easy. -----
 Continuations are "easy" (if you have decent language support or can glom it on) but that's keeping state on the server side. The author describes continuation tokens that "never expire", which is incompatible with server-side state.Without state, a token can be a bookmark into a predefined ordered dataset. That's more reliable than an offset, but just as inflexible, and much more expensive on the server side.Or, I'm missing something too. -----
 One thing to note is that while the continuation token is just a blob of data from the clients perspective, the server can actually use it to store the required state information.A simple method would be to take the state information the server needs in order to continue the enumeration (e.g. sorting order, how far along it was in the enumeration, etc.), JSON-encode it, encrypt&sign it, and then base64 encode it.Return that token to the client, and if the client wants more data it can pass that token back to the server, which can decode it into all the information it needs to resume the enumeration. -----
 I like this approach, but this requires storing the rest of the enumeration. I think that you would want to the continuation token to expire after a reasonable period of time (10 minutes to 1 hour). When the token expired, you would remove the rest of the enumeration from your data store.This isn't what the author recommends, but I think this is a good approach. -----
 I don't think this requires storing anything on the server. That was kind of the point of the whole "store the server state in the continuation token"-thing :)You want to store enough information in the token that you can easily reconstruct and resume the enumeration.For example, let us say that the user asked for all comments with a score >= 5 sorted by post time. In that case you could return 100 comments, and a token that encoded something like:`````` { "min_score": 5, "sort": "post_time", "resume_from_post_time": "2015-05-07T05:34:02Z", } `````` To ensure that it is easy to resume the enumeration, the API can fudge the number of returned items so that the returned data always breaks at a nice "post_time" boundary. The goal here is to make it easy for the client to get all the data in the enumeration without implementing all this logic themselves.True, it will only work efficiently for some types of queries, but a lot of the common queries can be reworked into something like that. -----
 Ok, I see the difference.You suggest that the continuation token, is basically an encoding of the query parameters, to fetch results from the API. If you go with this approach, then you don't have to store any state on the server. This is a good approach, because it's simple, but it doesn't solve the issue, where the response from the API changes while you making the paging API calls. The example used in the article is where an order was deleted, while you were calling the API.I was thinking of using a uuid to generate a continuation token, and storing a copy of the results from the API. Subsequent calls that use the continuation token, would take a subset of these results. This requires storing more state on the server, and managing that state. The benefit to this approach is that results you get back from paging are consistent. This solves the issue, where the results from the API change while you are calling the API multiple times. The downside to this approach is that you have to store more state in server. If you are storing the full results for all of these paging API calls, then this could be quite large. -----
 Actually, deleted orders are not a problem with continuation tokens. The deleted order is only an issue if you use traditional paging requests, which was the point of the article.The only case I can currently think of that cannot be solved using continuation tokens sent to the client is where the order of the items that are enumerated may change between calls to the API. For example, imagine that you are fetching items sorted by score, and somebody upvotes or downvotes an item while you are enumerating them. In that case it is very difficult to encode enough information in the continuation token. (I can think of complicated ways to make it work, but the resulting database queries would be horrible.)But for simple stuff like deleted items and similar, it is easy. If you leave out sorting it is trivial to implement as well -- all you need is to enumerate the items based on an internal ID that is guaranteed to always increase, filtering them as required. The continuation token will simply be the ID of the last item you evaluated and the filter that is applied. On the next request you just resume from that ID. If that item ID happens to be deleted in the meantime it is no problem. You just resume from the next one available. I.e.:`` SELECT * FROM items WHERE id > :last_returned_id AND [insert-filter-here] ORDER BY id LIMIT 100;`` -----
 I understand where you're going, but this is not a continuation in the formal sense, and it isn't even usefully similar.If the client stores the state on behalf of the server, the server will potentially be working with a modified dataset on the next request, and we're right back where we started with limit and offset.You can cook up a scheme to make it work for a restricted range of requests, but the compromises are severe. -----
 Multiline text logs are terrible, but you can log JSON in a single line.It's still verbose, but it compresses well. -----
 I think orange juice is the classic example.But orange juice isn't healthy before or after processing, so the point is lost. -----
 Wrong SCO.Caldera renamed themselves The SCO Group after acquiring the name and trademark from The Santa Cruz Operation in 2001.Later, things went south and the new SCO(G) turned litigious. The original SCO was not responsible for the later shenanigans, and it was painful to see their name dragged through the mud.See also: Cingular -> AT&T -----
 Who is dragging what through the mud with Cingular and AT&T? -----
 I think you'd be less dismissive if you were better informed about your topic. -----
 If we're being objective, I think we can agree that having multiple buttons is more basic and more self-evident knowledge than being able to click a button in multiple ways. -----
 ? -----
 More

Search: