3 ms·

I guess I'm not that good a programmer, because I don't really understand why variables that can't be varied are useful, or why you'd use that. How do you writ

I guess I'm not that good a programmer, because I don't really understand why variables that can't be varied are useful, or why you'd use that. How do you write code that actually works?

mleo 1y ago
It forces you to consider when, where and why a change occurs and can help reason later about changes. Thread safety is a big plus.
- ErroneousBosh 1y ago
  Okay, so for example I might set something like "this bunch of parameters" immutable, but "this 16kB or so of floats" are just ordinary variables which change all the time? Or then would the block of floats be "immutable but not from this bit"? So the code that processes a block of samples can write to it, the code that fills the sample buffer can write to it, but nothing else should?
  - stickfigure 1y ago
    Sounds like you have a data structure like `Array<Float>`. The immutable approach has methods on Array like: Array<Float> append(Float value); Array<Float> replace(int index, Float value); The methods don't mutate the array, they return a new array with the change. The trick is: How do you make this fast without copying a whole array? Clojure includes a variety of collection classes that "magically" make these operations fast, for a variety of data types (lists, sets, maps, queues, etc). Also on the JVM there's Vavr; if you dig around you might find equivalents for other platforms. No it won't be quite as fast as mutating a raw buffer, but it's usually plenty fast enough and you can always special-case performance sensitive spots. Even if you never write a line of production Clojure, it's worth experimenting with just to get into the mindset. I don't use it, but I apply the principles I learned from Clojure in all the other languages I do use.
    - ErroneousBosh 1y ago
      > The methods don't mutate the array, they return a new array with the change. But then I need to update a bunch of stuff to point to the new array, and I've still got the old incorrect array hanging around taking up space. This just sounds like a great way to introduce bugs.
      - stickfigure 1y ago
        It ends up being quite the opposite - many, many bugs come from unexpected side effects of mutation. You pass that array to a function and it turns out 10 layers deeper in the call stack, in code written by somebody else, some function decided to mutate the array. Immutability gives you solid contracts. A function takes X as input and returns Y as output. This is predictable, testable, and thread safe by default. If you have a bunch of stuff pointing at an object and all that stuff needs to change when the inner object changes, then you "raise up" the immutability to a higher level. Universe nextStateOfTheUniverse = oldUniverse.modifyItSomehow(); If you keep going with this philosophy you end up with something roughly like "software transactional memory" where the state of the world changes at each step, and you can go back and look at old states of the world if you want. Old states don't hang around if you don't keep references to them. They get garbage collected.
        ErroneousBosh 1y ago
        Okay, so this sounds like it's a method of programming that is entirely incompatible with anything I work on. What sort of thing would it be useful for? The kind of things I do tend to have maybe several hundred thousand floating point values that exist for maybe a couple of hundred thousandths of a second, get processed, get dealt with, and then are immediately overwritten with the next batch. I can't think of any reason why I'd ever need to know what they were a few iterations back. That's gone, maybe as much as a ten-thousandth of a second ago, which may as well be last year.
        stickfigure 1y ago
        It is useful for the vast majority of business processing. And, if John Carmack is to be believed, video game development. Carmamack's post explains it - if you make a series of immutable "variables" instead of reassigning one, it is much easier to debug. This is a microcosm of time travel debugging; it lets you look at the state of those variables several steps back. In don't know anything about your specific field but I am confident that getting to the point where you deeply understand this perspective will improve your programming, even if you don't always use it.
jayd16 1y ago
If you need new values you just make new things. If you want to do an operation on fooA, you don't mutate fooA. You call fooB = MyFunc(fooA) and use fooB. The nice thing here is you can pass around pointers to fooA and never worry that anything is going to change it underneath you. You don't need to protect private variables because your internal workings cannot be mutated. Other code can copy it but not disrupt it.
- MetaWhirledPeas 1y ago
  > If you need new values you just make new things. > If you want to do an operation on fooA, you don't mutate fooA. You call fooB = MyFunc(fooA) and use fooB. The beautiful thing about this is you can stop naming things generically, and can start naming them specifically what they are. Comprehension goes through the roof.
  - ErroneousBosh 1y ago
    Yes, but you can do that without having loads of stale copies of incorrect data lying around, presumably.
    - MetaWhirledPeas 1y ago
      With techniques like method chaining you can avoid using a constant or a variable and just pass return values around.
- ErroneousBosh 1y ago
  > If you want to do an operation on fooA, you don't mutate fooA. You call fooB = MyFunc(fooA) and use fooB. This is the bit I don't get. Why would I do that? I will never want a fooA and a fooB. I can't see any circumstances where having a correct fooB and an incorrect fooA kicking around would be useful.
  - jayd16 1y ago
    As Carmack points out, naming the intermediate values aides in debugging. It also helps you write code as you can give a name to every mutation. But also keep in mind that correct and incorrect is not binary. You might want to pass a fooA to another class that does not want the fooB mutation. If you just have foo, you end up with situations where a copy should have happened but didn't and then you get unwanted changes.
jimbokun 1y ago
The concept is actually pretty simple: instead of changing existing values, you create new values. The classic example is a list or array. You don't add a value to an existing list. You create a new list which consists of the old list plus the new value. [1] This is a subtle but important difference. It means any part of your program with a reference to the original list will not have it change unexpectedly. This eliminates a large class of subtle bugs you no longer have to worry about. [1] Whether the new list has completely new copy of the existing data, or references it from the old list, is an important optimization detail, but either way the guarantee is the same. It's important to get these optimizations right to make the efficiency of the language practical, but while using the data structure you don't have to worry about those details.
- ErroneousBosh 1y ago
  > It means any part of your program with a reference to the original list will not have it change unexpectedly. I don't get why that would be useful. The old array of floats is incorrect. Nothing should be using it. That's the bit I don't really understand. If I have a list and I do something to it that gives me another updated list, why would I ever want anything to have the old incorrect list?
  - b_e_n_t_o_n 1y ago
    State exists in time, a variable is usually valid at the point it's created but it might not be valid in the future. Thus if part of your program accesses a variable expecting it to be from a certain point in time but it's actually from another point in time (was mutated) that can cause issues.
  - jimbokun 1y ago
    You pass in an array to a function meant to perform a transformation on each item of the array and return the result. You pass in an array of 10 values. While the function is executing, some other thread adds two more values to the array. How many values should the result of the function call have? 10 or 12? How do you guarantee that is the case?
deleted 1y ago
[deleted]

I guess I'm not that good a programmer, because I don't really understand why variables that can't be varied are useful, or why you'd use that. How do you write code that actually works?

mleo 1y ago

It forces you to consider when, where and why a change occurs and can help reason later about changes. Thread safety is a big plus.

ErroneousBosh 1y ago
Okay, so for example I might set something like "this bunch of parameters" immutable, but "this 16kB or so of floats" are just ordinary variables which change all the time? Or then would the block of floats be "immutable but not from this bit"? So the code that processes a block of samples can write to it, the code that fills the sample buffer can write to it, but nothing else should?
- stickfigure 1y ago
  Sounds like you have a data structure like `Array<Float>`. The immutable approach has methods on Array like: Array<Float> append(Float value); Array<Float> replace(int index, Float value); The methods don't mutate the array, they return a new array with the change. The trick is: How do you make this fast without copying a whole array? Clojure includes a variety of collection classes that "magically" make these operations fast, for a variety of data types (lists, sets, maps, queues, etc). Also on the JVM there's Vavr; if you dig around you might find equivalents for other platforms. No it won't be quite as fast as mutating a raw buffer, but it's usually plenty fast enough and you can always special-case performance sensitive spots. Even if you never write a line of production Clojure, it's worth experimenting with just to get into the mindset. I don't use it, but I apply the principles I learned from Clojure in all the other languages I do use.
  - ErroneousBosh 1y ago
    > The methods don't mutate the array, they return a new array with the change. But then I need to update a bunch of stuff to point to the new array, and I've still got the old incorrect array hanging around taking up space. This just sounds like a great way to introduce bugs.
    - stickfigure 1y ago
      It ends up being quite the opposite - many, many bugs come from unexpected side effects of mutation. You pass that array to a function and it turns out 10 layers deeper in the call stack, in code written by somebody else, some function decided to mutate the array. Immutability gives you solid contracts. A function takes X as input and returns Y as output. This is predictable, testable, and thread safe by default. If you have a bunch of stuff pointing at an object and all that stuff needs to change when the inner object changes, then you "raise up" the immutability to a higher level. Universe nextStateOfTheUniverse = oldUniverse.modifyItSomehow(); If you keep going with this philosophy you end up with something roughly like "software transactional memory" where the state of the world changes at each step, and you can go back and look at old states of the world if you want. Old states don't hang around if you don't keep references to them. They get garbage collected.
      - ErroneousBosh 1y ago
        Okay, so this sounds like it's a method of programming that is entirely incompatible with anything I work on. What sort of thing would it be useful for? The kind of things I do tend to have maybe several hundred thousand floating point values that exist for maybe a couple of hundred thousandths of a second, get processed, get dealt with, and then are immediately overwritten with the next batch. I can't think of any reason why I'd ever need to know what they were a few iterations back. That's gone, maybe as much as a ten-thousandth of a second ago, which may as well be last year.
        stickfigure 1y ago
        It is useful for the vast majority of business processing. And, if John Carmack is to be believed, video game development. Carmamack's post explains it - if you make a series of immutable "variables" instead of reassigning one, it is much easier to debug. This is a microcosm of time travel debugging; it lets you look at the state of those variables several steps back. In don't know anything about your specific field but I am confident that getting to the point where you deeply understand this perspective will improve your programming, even if you don't always use it.

jayd16 1y ago

If you need new values you just make new things. If you want to do an operation on fooA, you don't mutate fooA. You call fooB = MyFunc(fooA) and use fooB. The nice thing here is you can pass around pointers to fooA and never worry that anything is going to change it underneath you. You don't need to protect private variables because your internal workings cannot be mutated. Other code can copy it but not disrupt it.

MetaWhirledPeas 1y ago
> If you need new values you just make new things. > If you want to do an operation on fooA, you don't mutate fooA. You call fooB = MyFunc(fooA) and use fooB. The beautiful thing about this is you can stop naming things generically, and can start naming them specifically what they are. Comprehension goes through the roof.
- ErroneousBosh 1y ago
  Yes, but you can do that without having loads of stale copies of incorrect data lying around, presumably.
  - MetaWhirledPeas 1y ago
    With techniques like method chaining you can avoid using a constant or a variable and just pass return values around.
ErroneousBosh 1y ago
> If you want to do an operation on fooA, you don't mutate fooA. You call fooB = MyFunc(fooA) and use fooB. This is the bit I don't get. Why would I do that? I will never want a fooA and a fooB. I can't see any circumstances where having a correct fooB and an incorrect fooA kicking around would be useful.
- jayd16 1y ago
  As Carmack points out, naming the intermediate values aides in debugging. It also helps you write code as you can give a name to every mutation. But also keep in mind that correct and incorrect is not binary. You might want to pass a fooA to another class that does not want the fooB mutation. If you just have foo, you end up with situations where a copy should have happened but didn't and then you get unwanted changes.

jimbokun 1y ago

The concept is actually pretty simple: instead of changing existing values, you create new values. The classic example is a list or array. You don't add a value to an existing list. You create a new list which consists of the old list plus the new value. [1] This is a subtle but important difference. It means any part of your program with a reference to the original list will not have it change unexpectedly. This eliminates a large class of subtle bugs you no longer have to worry about. [1] Whether the new list has completely new copy of the existing data, or references it from the old list, is an important optimization detail, but either way the guarantee is the same. It's important to get these optimizations right to make the efficiency of the language practical, but while using the data structure you don't have to worry about those details.

ErroneousBosh 1y ago
> It means any part of your program with a reference to the original list will not have it change unexpectedly. I don't get why that would be useful. The old array of floats is incorrect. Nothing should be using it. That's the bit I don't really understand. If I have a list and I do something to it that gives me another updated list, why would I ever want anything to have the old incorrect list?
- b_e_n_t_o_n 1y ago
  State exists in time, a variable is usually valid at the point it's created but it might not be valid in the future. Thus if part of your program accesses a variable expecting it to be from a certain point in time but it's actually from another point in time (was mutated) that can cause issues.
- jimbokun 1y ago
  You pass in an array to a function meant to perform a transformation on each item of the array and return the result. You pass in an array of 10 values. While the function is executing, some other thread adds two more values to the array. How many values should the result of the function call have? 10 or 12? How do you guarantee that is the case?

deleted 1y ago

[deleted]