2,375 reputation
11428
bio website
location
age
visits member for 3 years, 7 months
seen yesterday

Jul
25
comment Is immutability very worthwhile when there is no concurrency?
@KChaloux: Your first point is just a language limitation, not a conceptual one. I'm not going to continue farther.
Jul
25
comment Is immutability very worthwhile when there is no concurrency?
@itsbruce: (I'll only respond since this is a clarification rather than a continuation of the debate, so let's leave it at that.) I guess what I've been trying to say is that the type shouldn't be immutable in the first place, unless it's a violation of the type's correctness rather than a maintainability issue. The user should be able to choose to make individual variables mutable or immutable depending on the situation, and if you make your type immutable, then you take that choice away and force the user to pay an unnecessary performance penalty even when it matters. That's all.
Jul
24
comment Is immutability very worthwhile when there is no concurrency?
My last comment for now, for future readers (and perhaps for @Doval): Looking over the discussion again, I think there is a confusion I need to clear up. The original question was about making types immutable, not about making individual variables immutable. My argument has been that that making types immutable by default is not a good idea because it prevents you from making mutable variables of that type whenever that's necessary (for performance or other reasons). I'm not claiming, however, that making variables mutable by default is a good idea. So don't confuse the two.
Jul
24
comment Is immutability very worthwhile when there is no concurrency?
@Doval: Yeah, well what about when you do have a performance problem?! The fact that your best rebuttal is "well, if it's not a problem then I'll just ignore it" is my entire point here. Parallelism isn't a magic bullet. One machine only contains so many CPUs (say, 8), so it's not like you actually will necessarily have the parallelism you need. But parallelizing beyond that is freaking hard. And potentially expensive. Functional programming just spits in the face of Computer Science, whose goal is to worry about efficiency. But if you don't want to reply then don't.
Jul
24
comment Is immutability very worthwhile when there is no concurrency?
@Doval: So, any thoughts on the log N factor?
Jul
24
comment Is immutability very worthwhile when there is no concurrency?
@Giorgio: Thanks, 3x is pretty impressive. Not convinced it's close to the same ballpark though. If I had to switch from C++ to assembly, I think it would take me at least an order of magnitude or even two orders more time, not just twice or three times as long.
Jul
24
comment Is immutability very worthwhile when there is no concurrency?
@Doval: It doesn't disprove that, but it does prove what (doesn't) works in practice doesn't necessarily match what you expect to (not) work in theory.
Jul
24
comment Is immutability very worthwhile when there is no concurrency?
@Giorgio: Could you give me a ballpark number then? How many times faster were you? 10x?
Jul
24
comment Is immutability very worthwhile when there is no concurrency?
@Doval: In theory yeah, but I'm saying in practice much of the code you're using directly or indirectly every day is mutable and it's already scaled, so that argument isn't so convincing.
Jul
24
comment Is immutability very worthwhile when there is no concurrency?
@Doval: I love that you actually tried asymptotic time complexity analysis. Your analysis is wrong though. An O(N) algorithm can (must?) easily become O(N log N) with immutability. It is no longer O(N) like you claim, and a log N factor is not something that you can gloss over like that. (Think of an algorithm like BWT; how can you possibly claim it will stay efficient with immutable arrays?)
Jul
24
comment Is immutability very worthwhile when there is no concurrency?
@Giorgio: Er, I didn't ask if it was "noticeable", I asked if it was "even remotely in the same ballpark". A 20% increase is "noticeable" but not even remotely in the same ballpark.
Jul
24
comment Is immutability very worthwhile when there is no concurrency?
@KChaloux: Use const in C++ and you'll realize the same thing: most variables can be const.
Jul
24
comment Is immutability very worthwhile when there is no concurrency?
@itsbruce: I don't see how it can "not scale"? Like I said, people have been doing this for decades, so obviously, this does scale. It might be a bit more work sometimes, but it's not like people can't do it. And mutability brings about efficiency too.
Jul
24
comment Is immutability very worthwhile when there is no concurrency?
@Doval: Yeah, that's my point. I would turn down a 20% improvement. Why? Because immutability doesn't come for free -- there's a price tag: it makes the code more inefficient. So there has to be a justification for you to pay that cost, and a 20% productivity improvement isn't a justification for me to make my code slower.
Jul
24
comment Is immutability very worthwhile when there is no concurrency?
@Doval: I don't really feel like the kind of productivity gained by moving from assembly to C or C++ is even remotely in the same ballpark as the kind gained from going from mutable to immutable types; do you?
Jul
24
comment Is immutability very worthwhile when there is no concurrency?
@Den: I don't see why you can't have your cake and eat it too. Why not just take C++'s approach? The types are mutable, but you can receive parameters of those types by copy or by a read-only reference. That gives you immutability of the caller's variables without tying your hand behind your back for all instances of that type.
Jul
24
comment Is immutability very worthwhile when there is no concurrency?
"it's very hard to know"... is it really that hard? People have managed to do this for decades now.
Jul
22
comment When I test out the difference in time between shifting and multiplying in C, there is no difference. Why?
@quickly_now: They can be converted into combinations of shifts and additions/subtractions.
Jul
16
comment Is it a good idea to “#define me (*this)”?
@BЈовић: Pages? It's not a question of thinking "long", it's a question of not having to think at all. When this-> is there--and you have a habit of putting it in there whenever it's possible--then you are immediately 100% certain the variable is an instance field. It requires no thinking whatsoever, so it's not distracting. But when that's not the case, then you have to think. Whether that's 5 seconds or 30 seconds is a different issue, the point is it still takes up unnecessary mental resources regardless, without any benefit in terms of development speed either as I mentioned earlier.
Jul
16
comment Is it a good idea to “#define me (*this)”?
Not to mention that using this actually helps you write your code faster because the IDE can display a drop-down listing all the member variables, from which you can easily select a member without typing most of its name at all. So it's not even good from a coding efficiency standpoint.