In my experience DRY and many (any?) other coding principles are only problematic when misused. They're typically misused because the user doesn't understand the motivation or underlying value of the principle in the first place.
I think the example in the article does a bit of that as well. The example sets a deadline on a thing (a task or payment) by validating the deadline against the current time, and then presumably doing something else that isn't shown. The article argues that in the future a task might have different validation requirements than a payment, and they're only coincidentally the same today; so it would be foolish to abstract the deadline setting logic today.
BUT, the reality is that the real coincidence is that payments and tasks have the same set of validations, not that the logic to validate a deadline is coincidentally the same. In my opinion "good" code would be fine to have separate set_task_deadline and set_payment_deadline methods, but only one validate_deadline_is_in_future (or whatever) method, alongside other validation methods which can be called as appropriate by each set_x_deadline implementation.
Disclaimer: the code is so short and trivial that it doesn't matter, I think we can all assume that this concept is extrapolated onto a bigger problem.
I've never heard this one before, but I love it. Unfortunately we've also got "Don't Abstract Methods Prematurely" and "Descriptive And Meaningful Phrases".
> RFC 8259 raises the important point that ultimately implementations decide what a JSON number is.
Any implementation dealing with money or monetary rates should know that it needs to deal with precision and act accordingly. If you want to use JavaScript to work with money, you need to get a library that allows you to represent high precision numbers. It's not unreasonable to also expect that you get a JSON parsing library that supports the same.
No. A rolling shutter deals with different parts of the sensor being exposed at different times within one frame. It generally requires a much faster object (think airplane propeller or light with PWM).
This is effectively multiple frames captured normally and a mistake in the algorithm stitching them into one frame.
This is exactly what I think of when considering actual remote work expenses for myself. I live in 600sqft which is not bad for a place to live. But not great for one, let alone two people to work. In terms of quality of life, I think having to work a) within 10 feet of my bed , b) on the kitchen table, having to clean the table of work before every meal, or c) on the couch which is not at all ergonomic; are all huge steps down from the office.
If you already have an office/den to work from, I can see how it's not a big deal. But if you're looking at buying a first home and your requirements go from one or two bedrooms to three bedrooms/1 bedroom & two offices, that's brutal.
From the link
> Although the law regarding these expenses is not yet decided, remote California workers may also be entitled to reimbursement for:
> * the cost of dedicated home office space (reimbursement is more likely if the employee was renting or had plans to rent the space to a third party prior to beginning remote work). (Cal. Lab. Code § 2802 (2022).)
If that actually happens I would be very shocked/impressed. But I'm highly cynical of how wants vs needs are going to be interpreted there. To me the mental health benefit of being able to physically leave work is a need, but I know not everyone is likely to see it that way.
disclaimer: I'm not a big rust programmer, but I appreciate it.
I think it's a matter of perspective/background. Depending what language you're coming from you might appreciate a lot of the more modern language features, or binary size, or performance. On the other hand, you might already be working with a pretty cutting edge language with a garbage collector or other and decide that Rust has some cool benefits but not worth the switch.
There are a lot, the most mainstream are going to fall under "socialism". But to give you a specific answer, check out "Alternatives to Capitalism: Proposals for a Democratic Economy". It's a debate between Robin Hahnel and Erik Olin Wright around their personal ideas.
More broadly speaking, any number of systems could compensate people for innovation and problem solving (note I don't think competition should be rewarded in its own right, and risk taking isn't necessary in many systems) by providing them an elevated quality of life.
The main difference to our capitalist system today is that rather than trying to accumulate as much personal capital as possible, value created from innovation would only go to the individual as needed to incentivize them. The rest would go to improving the world and lives of the people around them.
Of course this requires the individual have some agency in that improvement, which we find lacking in the Soviet Union or other failed communist states.
> Immutable data does not necessarily let you answer the "what state does this value hold" question easier than mutable data.
Yes, it does. You're right that you still have a chain of operations to figure out first. But with mutable data you need to do that, as well as know when you're looking at the data, and what else is running in the system that has access to that data.
It doesn't grant superhuman insight into program state, but it is orders of magnitude simpler than mutable data (perhaps several orders depending on the scope of the data).
This is a false dilemma. There's no need to choose between ugly buildings with climate control and attractive buildings with poor climate control.
It can be very hot in Las Vegas and the buildings shown in the article have climate control more than capable of making you cold in the summer.
Losing your job is a big deal to the average person, but a salary cut is immaterial to a big tech executive. An executive salary cut would save hundreds of jobs.
People are laid off because the company is trying to spend less. There are multiple people in the same role and the headcount can be decreased to decrease spend on overall salary without decreasing the salary of individuals. But just because there is only one person in each executive role does not mean that money can't be saved on executive salaries.
Hardware like TVs are especially insidious because unlike a service you don't simply decide to stop using it one day and the ad revenue stops. Rather ad revenue continues for the lifetime of the TV and there is very little chance that a company will forgo that recurring ad revenue in exchange for an increase in up-front MSRP
> change patentable subject matter to (effectively) exclude computer software
I don't necessarily disagree with you, but what makes software unique in that it would be effectively excluded by changes while other subject matter (presumably) wouldn't be affected?
But once users spend a lot of time in an area wearing the device, they have a better ability to navigate that area even with the device removed. I imagine it's similar to how you would be able to navigate your home in low light
> a book with instructions on how to use the chemical to attempt suicide
I'm not an Amazon apologist. But if someone is adding a book on how to commit suicide to their cart then my first worry is not going to be what an online vendor suggests to bundle with that.
> “knowingly assisting in the deaths of healthy children by selling them suicide kits.”
I think it shows a wild conception of health if we think someone buying a book on how to commit suicide and tools to go with it is healthy
it can be good / a relief to find out you've been doing it wrong the whole time, because it means that now you can do it right and you may yet reach your objective
I think the example in the article does a bit of that as well. The example sets a deadline on a thing (a task or payment) by validating the deadline against the current time, and then presumably doing something else that isn't shown. The article argues that in the future a task might have different validation requirements than a payment, and they're only coincidentally the same today; so it would be foolish to abstract the deadline setting logic today. BUT, the reality is that the real coincidence is that payments and tasks have the same set of validations, not that the logic to validate a deadline is coincidentally the same. In my opinion "good" code would be fine to have separate set_task_deadline and set_payment_deadline methods, but only one validate_deadline_is_in_future (or whatever) method, alongside other validation methods which can be called as appropriate by each set_x_deadline implementation.
Disclaimer: the code is so short and trivial that it doesn't matter, I think we can all assume that this concept is extrapolated onto a bigger problem.