2,593 reputation
21529
bio website
location
age
visits member for 4 years
seen 2 days ago

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.
Jul
16
comment Is it a good idea to “#define me (*this)”?
@BЈовић: How else are you supposed to distinguish between member and local variables? Either you change the naming convention, or you use this->. I don't mean for the compiler's sake, I mean for the sanity of the next poor programmer who has to read your code. If you don't write this-> then you're going to waste the people's valuable time when they go hunting for the scope of the variable. That's at least 5 seconds of thinking that could be turned into 1 second, with 4 more left to spend on more important things. Multiplied by the number of times your code has to be read.
Jul
16
comment Is it a good idea to “#define me (*this)”?
"Using this-> everywhere is just plain stupid" uh, no, it's pretty smart. I could just as well argue not doing so is stupid. It lets you avoid screwing with instance variable names by prefixing them with m_ or _ or whatever just because you're too lazy to type this->, making the code that much more readable.