3 ms·

> Do the rules for "+", "-", and (if present) "%" change often in most major languages when they are used with built-in types? In terms of dynamic or in terms

by xlii 2y ago

> Do the rules for "+", "-", and (if present) "%" change often in most major languages when they are used with built-in types? In terms of dynamic or in terms of behavior between them? For former - yes they do change, not often, but they do. Even Elixir is right now raising warnings that `-0.0` and `+0.0` will not be equal, which implies also changes in addition and subtraction (e.g. cancelling out event's value in event based system value might impact on system's behavior). If that's the latter then it deserves blog post on its own, because some can add mixed types, some are casting in specfic way, some are copying data, some are mutating data, some are doing heuristic casting, some are crashing, some leak memory, some allow modifying pragmas, some allow implicit overloading. It's a jungle out there. ...and it reminds me about academic joke that '2 + 2 = 5 given extremely high values of 2' - funny one until you spend night trying to figure out why this happens and another two planning vengeance on person who decided that int->float->int is a good trick to use helpful float-taking function on an otherwise perfectly fine integer. The worth of remembering is a concept I perceive a consideration a cost, usefulness and available memory space. I rather remember that in Elixir/BEAM child shutdown and removal is message driven (and thus can cause race condition) than whether I need to use `+` or `++` for concenating lists.

simoncion 2y ago
> If that's the latter then... It's a good thing I asked specifically about built-in types in a particular system, and didn't ask about comparisons between operators in different languages. > For former - yes they do change, not often, but they do. Even Elixir is right now raising warnings that `-0.0` and `+0.0` will not be equal... Sure, that's a change to optional behavior to comparison of floating-point zeros. That doesn't change how equality testing, addition, subtraction, or -if available- modular arithmetic works. As I said: > It's always well worth your time to learn the rules for commonly-used, bedrock parts of a language, major libraries, and runtime systems that you intend to use. Bedrock parts don't substantially change, because if they did, they would invalidate every program ever written against those parts.
- xlii 2y ago
  > > It's always well worth your time to learn the rules for commonly-used, bedrock parts of a language, major libraries, and runtime systems that you intend to use. I disagree. I've been long enough around to see languages sunsetted, libraries sunsetted. Big systems are standing on shamefully old versions. If your job is to work on one language - I agree, but when working with 100s of systems that go over multiple OTP versions, multiple Elixir versions, sprinkled with JavaScript, TypeScript, Ruby 1.0, Elm, Java, "oh my dear is it Python 2 running CoffeeScript?!", then memorizing anything is pointless, because chance is that thing that you memorized is: - not yet in this project - no longer in this project - that tech isn't in the project - project is written in Malboge, everything you know is irrelevant - is explicitly forbidden by code owner (for more or less sensible reason) > Bedrock parts don't substantially change, because if they did, they would invalidate every program ever written against those parts. Been there, done that, bought a t-shirt. I dislike TypeScript for exact that reason [0], but in Elixir the same is true if you rely on --warnings-as-errors flag due to (in my opinion) broken deprecation mechanism. Software is full of leaky abstractions. Do you know that it's not guaranteed that your system clock is monotonic? [1] [0]: https://github.com/microsoft/TypeScript/wiki/Breaking-Changes https://github.com/microsoft/TypeScript/wiki/Breaking-Change... [1]: https://github.com/rust-lang/rust/blob/e2223c94bf433fc38234d1303e88cbaf14755863/src/libstd/time.rs#L205-L232 https://github.com/rust-lang/rust/blob/e2223c94bf433fc38234d...
  - simoncion 2y ago
    > Do you know that it's not guaranteed that your system clock is monotonic? Yes. Wall-clock time is adjustable. That's why there's a monotonic clock function on any serious OS that's running on hardware that makes such a function possible. > ...but when working with 100s of systems that go over multiple OTP versions [it's not worth understanding how anything that's bedrock works]... Welp, let's go back to the behavior of 'supervisor' in 2007... the earliest version of that page of the docs that the Wayback Machine has: <https://web.archive.org/web/20070707071556/http://www.erlang.org/doc/man/supervisor.html https://web.archive.org/web/20070707071556/http://www.erlang...> Hey, look at this description and warning in 'terminate_child/2' > Tells the supervisor SupRef to terminate the child process corresponding to the child specification identified by Id. The process, if there is one, is terminated but the child specification is kept by the supervisor. This means that the child process may be later be restarted by the supervisor. The child process can also be restarted explicitly by calling restart_child/2. Use delete_child/2 to remove the child specification. Hell, read the rest of that document... notice that the behavior described from nearly twenty years in the past is the same as now. (And I bet you One American Nickel that the behavior described in 1997 is also the same.) If you don't consider that to be bedrock functionality and worth familiarizing yourself with, I don't know what to tell you.

by xlii 2y ago

simoncion 2y ago

> If that's the latter then... It's a good thing I asked specifically about built-in types in a particular system, and didn't ask about comparisons between operators in different languages. > For former - yes they do change, not often, but they do. Even Elixir is right now raising warnings that `-0.0` and `+0.0` will not be equal... Sure, that's a change to optional behavior to comparison of floating-point zeros. That doesn't change how equality testing, addition, subtraction, or -if available- modular arithmetic works. As I said: > It's always well worth your time to learn the rules for commonly-used, bedrock parts of a language, major libraries, and runtime systems that you intend to use. Bedrock parts don't substantially change, because if they did, they would invalidate every program ever written against those parts.

xlii 2y ago
> > It's always well worth your time to learn the rules for commonly-used, bedrock parts of a language, major libraries, and runtime systems that you intend to use. I disagree. I've been long enough around to see languages sunsetted, libraries sunsetted. Big systems are standing on shamefully old versions. If your job is to work on one language - I agree, but when working with 100s of systems that go over multiple OTP versions, multiple Elixir versions, sprinkled with JavaScript, TypeScript, Ruby 1.0, Elm, Java, "oh my dear is it Python 2 running CoffeeScript?!", then memorizing anything is pointless, because chance is that thing that you memorized is: - not yet in this project - no longer in this project - that tech isn't in the project - project is written in Malboge, everything you know is irrelevant - is explicitly forbidden by code owner (for more or less sensible reason) > Bedrock parts don't substantially change, because if they did, they would invalidate every program ever written against those parts. Been there, done that, bought a t-shirt. I dislike TypeScript for exact that reason [0], but in Elixir the same is true if you rely on --warnings-as-errors flag due to (in my opinion) broken deprecation mechanism. Software is full of leaky abstractions. Do you know that it's not guaranteed that your system clock is monotonic? [1] [0]: https://github.com/microsoft/TypeScript/wiki/Breaking-Changes https://github.com/microsoft/TypeScript/wiki/Breaking-Change... [1]: https://github.com/rust-lang/rust/blob/e2223c94bf433fc38234d1303e88cbaf14755863/src/libstd/time.rs#L205-L232 https://github.com/rust-lang/rust/blob/e2223c94bf433fc38234d...
- simoncion 2y ago
  > Do you know that it's not guaranteed that your system clock is monotonic? Yes. Wall-clock time is adjustable. That's why there's a monotonic clock function on any serious OS that's running on hardware that makes such a function possible. > ...but when working with 100s of systems that go over multiple OTP versions [it's not worth understanding how anything that's bedrock works]... Welp, let's go back to the behavior of 'supervisor' in 2007... the earliest version of that page of the docs that the Wayback Machine has: <https://web.archive.org/web/20070707071556/http://www.erlang.org/doc/man/supervisor.html https://web.archive.org/web/20070707071556/http://www.erlang...> Hey, look at this description and warning in 'terminate_child/2' > Tells the supervisor SupRef to terminate the child process corresponding to the child specification identified by Id. The process, if there is one, is terminated but the child specification is kept by the supervisor. This means that the child process may be later be restarted by the supervisor. The child process can also be restarted explicitly by calling restart_child/2. Use delete_child/2 to remove the child specification. Hell, read the rest of that document... notice that the behavior described from nearly twenty years in the past is the same as now. (And I bet you One American Nickel that the behavior described in 1997 is also the same.) If you don't consider that to be bedrock functionality and worth familiarizing yourself with, I don't know what to tell you.