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.
The only problem with this attitude is that JSON APIs are meant to be interoperable, and as the OP showed, you can't rely on the systems you interoperate with to uniformly have the same understanding of JSON numbers, and misinterpreting numbers because of system incompatibilities will cause some really bad headaches that are totally avoidable by just forcing everyone to interop in terms of decimal numbers encoded as strings.
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).
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.