The posts are [Dead], which means they're only available for the submitter or individuals with "Show Dead" available on their account.
My guess: The domain is too similar to HN itself, or the fact it's a lower-value aggregator regurgitating content from other sources, got the article killed.
The posts are [Dead], not a regex issue, nor is it an issue with administration.
From the FAQ:
>What does [dead] mean?
>The post was killed by software, user flags, or moderators.
>Dead posts aren't displayed by default, but you can see them all by turning on 'showdead' in your profile.
>If you see a [dead] post that shouldn't be dead, you can vouch for it. Click on its timestamp to go to its page, then click 'vouch' at the top. When enough users do this, the post is restored. There's a small karma threshold before vouch links appear.
As for the other one and your recent comments, it's a failure to follow the guidelines[0].
>Please don't post on HN to ask or tell us something. Send it to [email protected].
I do find it a little odd all the comments in this thread are focusing on it as though it was a straight telemetry/metric decision.
From the update, this feels more like it was problem area for maintenance purposes, then had its telemetry assessed for decision.
"The data pipeline that powers the page has historically proven problematic to maintain and so given the low usage, we decided to switch off the Trending page."
The maintainers likely considered the resources and effort in maintaining it were too high. When they looked at the telemetry and saw it wasn't utilized considerably, they assessed it was better to cut it, than keep it or create an alternative.
If it didn't have a cost associated with it, it would likely have never become a target.
Yeah, my example was bad. I was more trying to point out that determinism of the intrinsic action is a pre-condition to the idempotency, in order to make and verify the assurance required.
You could easily split the deterministic action, and comparison/verification against existing state into two different Pure functions. Being able to perform the verification separately is valuable for addressing the "at most once", "at least once", and "exactly once" assurance described in another comment in this the thread.
I was casually opening my scope up to the outer state, in the example, to express the "assurance" portion of the definition. But you're correct, it's an erroneous example that doesn't pass the more rigorous definition of Pure Determinism, when applied the local scope of the function.
It's not really uncomfortably close to determinism, it is baseline deterministic which is necessary for the verification. The powerful part of idempotence is that it's deterministic + a verified assurance "as if we run it only once."
Deterministic (but not idempotent): send_message(id=1, body) without verifying the state of id, could result in the message being received multiple times.
Idempotent: send_message(id=1, body) would verify that the id token hadn't been consumed, before acting, thus only allowing the message to be sent one time.
It was mentioned in the third paragraph, just not expounded upon further.
"Patryn, who changed his legal name twice, was the co-founder of QuadrigaCX, a Canadian exchange that shut down after Patryn's partner Gerald Cotten suddenly died in India in 2018 while owing users around $190 million in crypto at the time’s exchange rate."
These days I look up individual features, and use the date-relative view, to assess how long it's been available. Normally I'll start porting features once they're solid across the main browser set, but with a polyfill or some alternative based on feature detection.
I held off on delivering ES6 native until 2017-2018, and used mainly Bable or sometimes hand written polys up to that point if I wanted to use features from cutting edge. There's some influence from your user-agent analytics as well to determine if there is a meaningful regression to leave people behind.
5 years is just the rough grasp, sometimes the new features are worth integrating sooner if they provide actual functional improvements for users. Generally, syntactic sugar is given less precedence especially when it would negatively impact usability of the product. Saving a few hours for development is far less valuable than saving even a few hundreds of users hours of frustration.
As someone who started doing web development in 2003-2004, I've always aimed for a 5 year support window. This is largely because of how long IE6-IE8 upgrades took for many SMB's and governments to upgrade from in those days.
Back then browsers updated closer to 2-4 times a year, with far lower inertia in how drastic the changes would be. You could learn and mostly remember what features were safe for roughly that period. These days, I tend to look at feature release dates and support on CanIUse or MDN, to see if somethings been in broad use for the past 4-5 years.
It seems like an unusual rephrasing of the saying "reasonable on the face", which means "reasonable upon first appearance, without considering deeper aspects."
This already kind of existed prior to the pandemic'.
If you bought premium tickets to a show, often you would get placed into VIP list with the venue and/or artist. Venue perks included contact with a VIP manager that could help lock in seating pre-sale, occasionally get discounts, if you asked, and other perks.
It's in the venue's interest to KYC and maintain these higher value relationships. And if you don't patronize them for a period they'll stop reaching out or providing access.
Yeah, I think the author focused a bit too much on structural pattern matching being a replacement/alternative for if...elif blocks.
It will be much more useful as an alternative to dispatch dictionaries, which are more a side-effect of the language lacking any case based control-flow.
This is the correct answer and is actually somewhat visible if you also look at the DJIA and NASDAQ figures.
The S&P 500 and DJIA are limited to a fixed number of corporations. The NASDAQ is allowed to expand it's number of listed companies over time.
If you look at the NASDAQ figures it's able to show considerable and relevant growth, as more companies have listed. (Still not at 2000's peak, but much closer than the S&P or DJIA.)
I explained it pretty clearly what you get when you add a month on January 31st. You get February 31st.
A month is a discrete unit of measure. It is not decomposable into any number of days.
When you increment a month, you get YYYY - (MM+1). Any higher significance is maintained, but irrelevant to the operation. (This applies to the hypothetical statement in the doctor's office, the specific day is indeterminant, but can be assumed the same as current day next month.)
The fact that not all possible days exist is orthogonal to the singular meaning of the operation. It's obviously not greatly valuable to an end-user, but the method of addressing the ambiguity involves a second operation that ensures validity.
End-users want an method that does both the addition and coercion, but you can create consistency if you follow the simple path I laid out in GP.
I'll use your syntax but with the strictly correct definition of the operation.
Datetime x = new DateTime(2021, 1, 31);
x.AddMonths(1); // DateTime(2021, 2, 31)
x.AddMonths(2); // DateTime(2021, 3, 31)
x.AddMonths(1).AddMonths(1); //DateTime(2021, 3, 31)
// Ensure Valid, using a coerce to clamp overflows
DateTime(2021, 2, 31).EnsureValid(); // Feb 28
DateTime(2021, 3, 31).EnsureValid(); // Mar 31
DateTime(2021, 4, 31).EnsureValid(); // Apr 30
I agree those are the technically correct way to do it.
But if the reason people are wanting to use the library, is they want something to handle the complexity for them, coercing the data is good for simplication.
There is actually another option, that provides idempotent/associative consistency and implicit coercion to valid values.
This option, which discards some use cases (days beyond 28, when manipulating months), you coerce all values 29..31 to 28. This isn't even as technically correct, as the original option, but it removes the inconsistency and holds to the simplification contract to users.
But nobody really wants that, because it's not a valid date. So implicitly the library is deciding to return a valid date.
A library could be written to just provide invalid dates, and let the end user handle any errors. That library could also include an explicit validation method that takes a date and returns a valid one.
"2021-02-31".coerceToValid() => "2021-02-28" // Overflow == Max
"2021-02-31".coerceToValid(asDays=True) => "2021-03-03" // Overflow Carries (to the right)
In fact the library, that provides an ignorant response and no contract on validity would hold to the associative property, it just wouldn't be as ergonomic.
If you're adding 1 month, you're working on the month's location, e.g. 2021 - (02) - 28.
When you increment the month, the result would be 2021-03-28.
The only time you'd modify the day, is if the day became invalid due to an overflow, during that increment. If, when, you overflow the days you'd set the value of days to the maximum in that month.
If I tell someone, I'll get to that in a month, they expect by this day in the next month, the next calendar page, not 30/31 days.
This has been a thing since Google did their RankBrain update 5 years ago. They essentially released a system that used ML to negotiate unknown "long-tail" queries into more common queries and then returned the common queries results.
One of the immediate effects was quoted strings became less relevant, sometimes completely ignored, and a lot of the other tools for negotiating with system were lost. It's only continued to progressively get worse since then.
My guess: The domain is too similar to HN itself, or the fact it's a lower-value aggregator regurgitating content from other sources, got the article killed.
The posts are [Dead], not a regex issue, nor is it an issue with administration.
From the FAQ:
>What does [dead] mean?
>The post was killed by software, user flags, or moderators.
>Dead posts aren't displayed by default, but you can see them all by turning on 'showdead' in your profile.
>If you see a [dead] post that shouldn't be dead, you can vouch for it. Click on its timestamp to go to its page, then click 'vouch' at the top. When enough users do this, the post is restored. There's a small karma threshold before vouch links appear.
As for the other one and your recent comments, it's a failure to follow the guidelines[0].
>Please don't post on HN to ask or tell us something. Send it to [email protected].
[0]: https://news.ycombinator.com/newsguidelines.html [1]: https://news.ycombinator.com/newsfaq.html