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.)
The technique I personally use, as a full-stack developer, is if I can get features planned out into weekly chunks, segment days to backend vs frontend work, and move forward.
Monday is backend, Tuesday is frontend integration, Wednesday is front-end adjustments, Thursday and Friday are refactoring and further integration days.
Also I batch my issues, so if I'm planning to work on something that day, I'll look for other issues that may be in the same code area. Then I'll work on all of them throughout the day, as I can with primary focus on the issue I started with.
Refactoring happens any time you look at the code if you can see a need.
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