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 hn@ycombinator.com.
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.
My read of that line is, “the person who built this feature left, no team owns it, it needs a full rewrite, but we have other priorities”. It’s not surprising the metrics show the page usage isn’t growing. GitHub’s current UI doesn’t really direct anyone to it. What their metrics don’t show them is how important the page is to the users who do use it, and how important those users are. But it seems they have found out.
Since Microsoft acquisition GitHub quality seems in decline, constant outages, git pushes that doesn't goes through while status page is green and now the attempt to remove trending page...
Is it the end of the original GitHub's spirit as a social coding?
Honestly, I don't really see it. GitHub's availability has never been great and it doesn't really seem worse now aside from having more features to go wrong.
I haven't seen much change at all since the acquisition personally. Probably the only thing I can pick out is their dropping of Atom in favour of vscode.
What have you specifically seen change since the MS acquisition that's likely from MS and not just GitHub?
I don’t agree with this statement. Im happy to see the innovation that have come out from GitHub in the last years.
What im really missing and hoping for is an even more open and extensible community platform. Discussions is a good start, it would love to more innovation there.
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.
In your second example, if you run `send_message(id=1, body)` once and then run `send_message(id=1, body)` again, it behaves differently the second time than the first time, despite receiving the same input. So `send_message` is idempotent, but its behavior is not determined by its inputs (i.e. it is not pure).
If you imagine the hidden state that `send_message` reads and writes to be part of the input, then when you run it the second time, its inputs have changed. So it wouldn't be correct to say you're running it multiple times "on the same input".
These details are not obvious from the given definition, and that's why I say it's uncomfortably close to purity. Idempotence is very much not about purity (though you can have both), and that's why I like the author's goal-oriented explanation better: it makes the role of state very explicit.
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 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."
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.
Thanks for response! So are you looking at Chrome (and Firefox) back to 4-5 years past (via caniuse?), and not using something if they don't support it back that far?
(at least ES6 is, generally, in all current browsers (not IE) as of more than 4 years back at this point. But are you delivering ES6 to browsers, or still limiting yourself to ES5?)
> So are you looking at Chrome (and Firefox) back to 4-5 years past (via caniuse?), and not using something if they don't support it back that far?
I don't think that's whats the author meant, since they mentioned progressive enhancement. The site in question was for making a reservation to volunteer. This could have been written as a simple HTML form and it would have worked on any version of Chrome/Firefox/Safari and most other browsers. Any dynamic feature the site authors wanted to add should have used [feature detection](https://developer.mozilla.org/en-US/docs/Learn/Tools_and_tes...).
You can also use JS modules and `nomodule` script tags to deliver the latest and greatest JS to modern browsers and a compiled ES5 script to older browsers (though that wouldn't work in the case of an older evergreen browser that does support modules)
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.
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.
Yeah, there are several giant dictionaries (variously class to function, string to class, etc.) in just the project I’ve worked on most recently that fit that description.
Though considered from that perspective, it’s actually a bit of a disadvantage that the new match statement is a part of the language. It’s nice to dynamically extend (either as a first party developer or third party user) that sort of dictionary, effectively adding new branches to the implicit switch statement. A match statement is going to be fixed as written. Probably a readability and consistency win to remove spooky-action-at-a-distance, but at the cost of a bit of (ugly, pragmatic) usability
By the way, does anyone here know how Python compiles the match statements under the hood? Are they converted into something equivalent to if-elif, which tries each option in sequence? Or does it do something more clever?
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 hn@ycombinator.com.
[0]: https://news.ycombinator.com/newsguidelines.html [1]: https://news.ycombinator.com/newsfaq.html