kag0
Joined 10 years ago
Joined 10 years ago
As the article said
> 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.
oh, TIL that you can support large numbers with the default JavaScript JSON library https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
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.
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.
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.
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 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
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.