3 ms·

"...until the requirements change..." - nothing to do with Erlang per se. Let's move on.

• rdtsc 12y ago
  It has to do with Erlang. Because the original discussion point to 2 things in Erlang that make it easier -- immutability of data structures and the functional aspect. Testing a function that idempotent means that when it is tested it will be solid the only work you'd have to do is if requirement changes. In OO programming having large objects with mutable state + threads, it is very hard to reason how a particular (failure) state was arrived it. So besides requirements change another thing that changes is the state in the objects (in an unpredictable and untraceable). You end up with engineers saying things like "Yeah I see this bad data in this property, but how the hell did it get this, I don't know".
  • CmonDev 12y ago
    Ok, maybe the problem is that I am already avoiding the large objects, mutable state and threads in my mainstream OOP language code. I am also applying the idempotence where applicable.