3 ms·

There's a lot wrong with Javascript's Date, but the fact that it's an object is is not really in the top 10. Would it have been nice if the Date object had bee

There's a lot wrong with Javascript's Date, but the fact that it's an object is is not really in the top 10. Would it have been nice if the Date object had been immutable? Sure, but the fact that changing the mutable object does indeed change the object shouldn't be a shock

chowells 9mo ago
It's definitely a shock when something else changes the date object you've been holding on to. The problem with mutable values has never been when you (that is, the local context) change them. It's always that you can't trust that nothing else (some very non-local code) does.
- petesergeant 9mo ago
  That’s how every other object works, why would that be surprising?
  - kortilla 9mo ago
    The lack of const means having objects as arguments is pretty dangerous
    - ruszki 9mo ago
      What parent commenter meant was language level support of immutable objects. There is const, in for example JavaScript, but it supports only immutability of variables, not objects themselves. That later one is possible in C++ for example, where const can be used for both. Of course, it’s still possible to fake immutability with interfaces in some languages, or have a real one forced by implementation (like with Temporals), but it’s much nicer to have an indicator forcing that. I would like to add, that both variable and object immutability should be the default, and mutability should have a keyword, not other way around how in C++ and Java.
  - arthens 9mo ago
    That's a fair observation, and yet anecdotally I agree with the parent comment. In my career I fixed quite a few bugs about dates being passed around and unexpectedly modified, while I struggle to remember the same problem with objects in general (could be a case of selective memory). If I had the guess, I'd say it's a combination of: - the difference between the mental model and the implementation. Dates are objects but "feel" like values: dates are parsed from a single value, and when stored/printed they collapse back to a single value (as opposed to custom objects which are generally a bag of properties, and when printed/stored they still look like an object) - most common date operations causes the original date object to be mutated, which implicitly causes developers to mutate the passed value even if that's not what they explicitly meant So the default combination is a calling code that expects date to be treated as a value, and the called code accidentally mutating the data because it's convenient to do so. If anything then causes the original value to be saved back in the db, the data gets corrupted. Most experienced developers will remember to make a copy of the date object both in the calling code and in the receiving code, but the default remains dangerously easy to get wrong.
- agos 9mo ago
  also: there is a certain popular library for web app development that is based on diffing state between renders based on object equality
RedShift1 9mo ago
What happened to me is I passed a date to an external library, and then after that library did its work, that date was changed. Super annoying even if you know that it's a mutable object.
bilekas 9mo ago
This is a skill issue imo. Yes, if you change the referenced object you get a different value. Just because you are not paying attention to the change does not a problem of the language make. There are million other things legitimately wrong wit JS, developers being bad at understanding referenced objects is not one of them.

chowells 9mo ago

It's definitely a shock when something else changes the date object you've been holding on to. The problem with mutable values has never been when you (that is, the local context) change them. It's always that you can't trust that nothing else (some very non-local code) does.

petesergeant 9mo ago
That’s how every other object works, why would that be surprising?
- kortilla 9mo ago
  The lack of const means having objects as arguments is pretty dangerous
  - ruszki 9mo ago
    What parent commenter meant was language level support of immutable objects. There is const, in for example JavaScript, but it supports only immutability of variables, not objects themselves. That later one is possible in C++ for example, where const can be used for both. Of course, it’s still possible to fake immutability with interfaces in some languages, or have a real one forced by implementation (like with Temporals), but it’s much nicer to have an indicator forcing that. I would like to add, that both variable and object immutability should be the default, and mutability should have a keyword, not other way around how in C++ and Java.
- arthens 9mo ago
  That's a fair observation, and yet anecdotally I agree with the parent comment. In my career I fixed quite a few bugs about dates being passed around and unexpectedly modified, while I struggle to remember the same problem with objects in general (could be a case of selective memory). If I had the guess, I'd say it's a combination of: - the difference between the mental model and the implementation. Dates are objects but "feel" like values: dates are parsed from a single value, and when stored/printed they collapse back to a single value (as opposed to custom objects which are generally a bag of properties, and when printed/stored they still look like an object) - most common date operations causes the original date object to be mutated, which implicitly causes developers to mutate the passed value even if that's not what they explicitly meant So the default combination is a calling code that expects date to be treated as a value, and the called code accidentally mutating the data because it's convenient to do so. If anything then causes the original value to be saved back in the db, the data gets corrupted. Most experienced developers will remember to make a copy of the date object both in the calling code and in the receiving code, but the default remains dangerously easy to get wrong.
agos 9mo ago
also: there is a certain popular library for web app development that is based on diffing state between renders based on object equality

RedShift1 9mo ago

What happened to me is I passed a date to an external library, and then after that library did its work, that date was changed. Super annoying even if you know that it's a mutable object.

bilekas 9mo ago

This is a skill issue imo. Yes, if you change the referenced object you get a different value. Just because you are not paying attention to the change does not a problem of the language make. There are million other things legitimately wrong wit JS, developers being bad at understanding referenced objects is not one of them.