as a layman, wouldn't you need a more-accurate clock to measure the accuracy of a clock? How is clock accuracy measured when the clock is the most accurate clock?
Readit Newsrenlo commented on NIST ion clock sets new record for most accurate clock nist.gov/news-events/news... · Posted by u/voxadam
felt more like an article legitimizing an origin myth than authorship
renlo commented on I Built a Mechanical Calculator [video] youtube.com/watch?v=E0pJS... · Posted by u/lispybanana
Great video, I really enjoyed how down to earth it was. It reminded me of The Secret Life of Machines [1], where we get to peek behind the curtain and see how seemingly "magical" machines (in your case a digital computer) emerges from simple fundamental concepts.
[1] https://en.wikipedia.org/wiki/The_Secret_Life_of_Machines
renlo commented on Add "fucking" to your Google searches to neutralize AI summaries gizmodo.com/add-fcking-to... · Posted by u/jsheard
I work with ML and I am bullish with AI in general; said that, I would pay between 5 to 10 USD a feature or toggle called “No AI” for several services.
For myself I noticed 2 bad effects in my daily usage:
- Search: impossible to reach any original content in the first positions. Almost everything sounds like AIsh. The punctuation, the commas, the semicolon, the narro vocabulary, and the derivative nature of the recent internet pages.
- Discovery: (looking directly to you Spotify and Instagram) here I would add in the “No AI” feature another one “Forget the past…” and then set the time. I personally like to listen some orthogonal genres seasonally. But once that you listen 2 songs in a very spontaneous manner Spotify will recommend that for a long time. I listened out of curiosity some math rock, and the “Discovery Weekly” took 9 weeks to not recommend that anymore.
Spotify used to have a "dislike" button for their Discover Weekly which helped with pruning music you don't like, but with the natural law of tech enshitification they removed that feature a month ago.
Deleted Comment
3 ways to declare functions? I am probably blanking but I can only think of:
``` function foo () {} const foo = () => {} ```
function x() {/* ... */}
const x = function() {/* ... */}
const x = function foo() {/* ... */}
const x = (function() {/* ... */}).bind(this)
const x = (function foo() {/* ... */}).bind(this)
const x = () => {/* ... */}
const x = () => /* ... */renlo commented on What 10k Hours of Coding Taught Me: Don't Ship Fast sotergreco.com/what-10000... · Posted by u/thunderbong
Agree that the repository/service pattern is a good way to adhere to separation of concerns and make refactoring and readability easier.
That said, I really disagree with any precommit checks. Committing code should be thought of as just saving the code, checks should be run before merging code not saving code. It'd be like Clippy preventing you from saving a Word document because you have a spelling error. It's a frustrating experience.
I can make sure my code is good before I submit it for review, not when I'm just trying to make sure my work has been saved so I can continue working on it later (commit).
EU citizens: We don't want our data in the US, where it can be siphoned off to other companies.
US company: siphons data
EU: You can't do that.
HN commenter: Damn these fiefdoms wanting their cut, what has the internet become? I pine for a simpler time, when I could do anything I wanted with data against people's will and nobody could stop me, that truly was the golden age.
He was saying that Uber will no longer operate in NL/EU, the pining was for "equal access to US services", not your data. FWIW, I am annoyed myself about having to accept GDPR popups on every website I visit, so I too pine for a day where US companies have nothing to do with "EU citizens".
"Fast" is the feature people always wanted, but absent better information, they have to assume that is what they already got. That is why "fast" marketing works so well. It reveals that what they thought was pretty good actually wasn't. Adding the missing kitchen sink doesn't offer the same emotional reaction.
This is what people are missing. Even those "slow" apps are faster than their alternatives. People demand and seek out "fast", and I think the OP article misses this.
Even the "slow" applications are faster than their alternatives or have an edge in terms of speed for why people use them. In other words, people here say "well wait a second, I see people using slow apps all the time! People don't care about speed!", without realizing that the user has already optimized for speed for their use case. Maybe they use app A which is 50% as fast as app B, but app A is available on their toolbar right now, and to even know that app B exists and to install it and learn how to use it would require numerous hours of ramp up time. If the user was presented with app A and app B side by side, all things equal, they will choose B every time. There's proficiency and familiarity; if B is only 5% faster than A, but switching to B has an upfront cost in days to able to utilize that speed, well that is a hidden speed cost and why the user will choose A until B makes it worth it.
Speed is almost always the universal characteristic people select for, all things equal. Just because something faster exists, and it's niche, and hard to use (not equal for comparison to the common "slow" option people are familiar with), it doesn't mean that people reject speed, they just don't want to spend time learning the new thing, because it is _slower_ to learn how to use the new thing at first.