Hacker Newsnew | comments | show | ask | jobs | submit | quesera's comments login

"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.

I disagree completely.

Any "feature" that encourages people to spend more energy thinking about the reasons for being down voted is just promoting whinging and self-absorbed discontent. (Which, a: no one wants to see, and b: is bad for the people going through it!)

I do feel that down votes should not be used for disagreement, but the practical matter of fact is that they are and will be, both because pg endorses the idea, and because people are people. If they have a negative response to reading something, and a down arrow is convenient, it will be used.

Downvotes are not punishment. They just mean someone didn't like what you wrote, but couldn't be arsed to respond. Maybe what you wrote didn't deserve a response, maybe they were confused, maybe the topic is incredibly important to you but not to them. Who cares? We're adults, ja?

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?

And for new users who might not know why they're being downvoted, how about a link to the rules next to any comment of yours that is score-negative? HN already puts an orange star next to your comments, so the pages are dynamic at least to that extent.

Personally, I use downvotes exclusively for hostility. I upvote any greyed comment that is respectful, coherent, and relevant.

> Personally, I use downvotes exclusively for hostility

IMO, 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 idea

He did at one time mention that. But he also said this:


which seems to not like downvote for disagreement.

> As an alternative, I wouldn't be disappointed if the threshold for greying out was reduced to -3

That 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.

While I was reading the thread, this comment just posted mentioned that the site founder, pg, has endorsed the idea that the site's rules permit downvoting to express disagreement. By the site rules, implicitly, some comments should be downvoted on sight.


"Essentially there are two rules here: don't post or upvote crap links, and don't be rude or dumb in comment threads."

Yes, downvote thoughtfully, and downvote to improve the overall quality of discussion here, but a downvote in an active discussion to silently indicate a comment is 1) uncivil and unconstructive, or 2) factually incorrect, or 3) both is okay.

A comment that is solely on the issue of being downvoted is subject to being downvoted on sight, because those sorts of comments are never constructive to the discussion and disfavored by the site guidelines.


"Resist complaining about being downmodded. It never does any good, and it makes boring reading."

The site founder, pg, (who no longer has an active day-by-day role in moderating the site) has commented that downvotes for disagreement are permitted here.

(In order of time of posting.)

"I think it's ok to use the up and down arrows to express agreement. Obviously the uparrows aren't only for applauding politeness, so it seems reasonable that the downarrows aren't only for booing rudeness."


"IIRC we first had this conversation about a month after launch. Downvotes have always been used to express disagreement."


"I sometimes downvote things that seem mistaken. I think most users do."


"If there's one thing I wish I could do to improve HN, it would be to detect this sort of middlebrow dismissal algorithmically.

. . . .

"The problem with the middlebrow dismissal is that it's a magnet for upvotes. The 'U R a fag's get downvoted and end up at the bottom of the page where they cause little trouble. But this sort of comment rises to the top. Things have now gotten to the stage where I flinch slightly as I click on the 'comments' link, bracing myself for the dismissive comment I know will be waiting for me at the top of the page."


This is an ongoing issue, but the key idea is both to upvote and to downvote (and, for that matter, to submit stories and to post comments) in way that elevates the quality of discussion here. Grow a thick enough skin to learn from other users' behavior here, and develop curiosity about why other users might disagree with you, and all will be well.

> I use downvotes exclusively for hostility

hostility, 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.





Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact