2,477 reputation
21529
bio website
location
age
visits member for 3 years, 10 months
seen yesterday

Oct
25
answered Code that converts a value into a different representation, then converts it back to where it started is bad, but how?
Oct
12
awarded  Popular Question
Sep
19
awarded  Notable Question
Sep
13
awarded  Famous Question
Aug
22
comment Interface design where functions need to be called in a specific sequence
+1 this is the most flexible way to do it.
Aug
18
comment In the days of modern computing, in 'typical business apps' - why does performance matter?
@JanHudec: I don't quite see how you can really say that with a straight face when the very website you're currently on (our dear Stack Exchange) serves 560M page views a month across the world runs on just 25 servers.
Aug
16
comment What does “context-free” mean in the term “context-free grammar”?
Kind of a tangent, bhat happens if you give a PDA one or two extra stacks? Can it recognize an interesting, broader class of languages in that case?
Aug
14
comment Why do people nowadays use factory classes so often?
One thing that never made sense to me is, if you use factories to make new objects then you have to make the factory in the first place. So what exactly does that get you? Is it assumed that someone else will give you the factory instead of you instantiating it on your own, or something else? This should be mentioned in the answer, otherwise it's unclear how factories actually solve any problem.
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.