Software Engineering principles to make teams better

Post by amw-zero » Fri, Jul 02, 2021, 1:25 PM UTC

valenterry wrote: post #90

chrisdirkis wrote: post #87

Earlier quoted context omitted.

An example might be a function that takes a vector3, adds 5 to the x value, then returns the vector's length. You could model that as "make a second vector v_2 {x = v.x + 5, y = v.y, z = v.z}; return v_2.length", but if you have struct semantics, you can just do "v.x += 5; return v.length", and be confident that you're not modifying the vector that the caller has.

I see - but then you would still not have guaranteed local reasoning within the part of the code that modifies the vector. Is that really worth it? Also, creating the second vector should really look like "v2 = v.copy(x = x + 5); return v2.length". Or even just "return v.copy(x = x + 5).length".

Post by dexterous » Fri, Jul 02, 2021, 4:15 PM UTC

ketozhang wrote: post #85

macintux wrote: post #18

Earlier quoted context omitted.

> Use immutability by default, even in languages that make that harder than it should be That and referential transparency are huge wins. It is a shame languages like Python make it such a challenge.

Immutability isn't so difficult to do with Python language itself for any object. The push back is culture and practice of "we are all adults here" and that influences the language to make it forcing immutability awkward. For example, let's assign a constant variable to a sequence; should you do use list or tuple (FOO = [1,2,3] or FOO = (1,2,3) )? It doesn't matter, the constant capitalization discourages you to muta…

Post by amw-zero » Sun, Jul 04, 2021, 12:16 PM UTC

valenterry wrote: post #104

amw-zero wrote: post #101

Earlier quoted context omitted.

You showed why it is worth it - it also avoids copying. Mutation is more efficient in every way, except cognitive overhead. So by preventing _sharing_ of mutable values, you get the best of both worlds. This is the same model that Rust takes too. It doesn't eliminate mutability, only controls it. The argument that "performance doesn't matter anymore because computers are so fast" is a bad one. Efficiency is efficienc…

It's certainly fair to balance/decide between performance and local reasoning. But one should be clear then that they give up one for the other and not claim that both is possible. Because from my understanding from what you said, local reasoning isn't possible anymore, even though reasoning is still easier compared to when you don't have struct semantics. But that's still two different things.

  func newStructValue(s: Struct) -> Struct {
    s.value = 5

    return s
  }