4 ms·
To me, this reads like someone who used C to add a large list of numbers recursively and concluded C was trash because they ran out of stack. There's no denyin
by fpgeek 15y ago
To me, this reads like someone who used C to add a large list of numbers recursively and concluded C was trash because they ran out of stack.
There's no denying there is a specific problem. People are certainly entitled to decide that solving that problem is too much hassle for them. But how seriously should we take their opinions when they do that?
I'd say it depends on the quality of the effort they did invest. In this case, the OP admits that they used the wrong data structure in Clojure and the right one in Lush, which makes the entire exercise meaningless.
- anonymous 15y agohttp://pastebin.com/2fGefex4 http://pastebin.com/2fGefex4 $ gcc -o addalot --std=c99 -Os addalot.c $ ./addalot [1500117.315354] 0.000032 per iteration on average. Works fine for me.
- dchest 15y agoThis is not the correct C program, this is a C program for the compiler with tail call optimization (or with the stack large enough for it to work). There's no TCO in the C standard.
- yvdriess 15y ago> There's no TCO in the C standard. That doesn't make tail-recursive C programs any less correct.
- _delirium 15y agoThey're not incorrect, but that's mostly because the C standard also allows you to assume an infinite stack, so recursive programs that ask for absurd stack depths don't violate the standard with or without TCO. But if in practice the program only runs successfully when compiled on a compiler with TCO, it's not very portable, in that it relies on non-guaranteed compiler features for it to actually work.
- stonemetal 15y agoThere is no restriction against TCO in the C standard either. TCO is a valid optimization for a compiler to apply. So what is incorrect about it?
- dchest 15y agoBecause it relies on the particular implementation of C compiler, not on the C standard. Take -Os flag away or use a compiler that doesn't have TCO, and the program has a bug. See also: * using memcpy() for overlapping regions (relies on the particular implementation of memcpy(); was exposed by a change in glibc - http://lwn.net/Articles/414467/ http://lwn.net/Articles/414467/); * memory aliasing assumptions; * passing NULL, 0 to memcpy() (http://code.google.com/p/spiped/source/detail?r=8 http://code.google.com/p/spiped/source/detail?r=8); etc.
- stonemetal 15y agoIt is ansi C standard code. There is an implementation limitation (stack size) that this program runs into. However that doesn't violate the C standard in any way, because the standard doesn't specify available stack space. So the program is compatible with certain C implementations in certain configurations. Given the C standard allows a C implementation to pick any stack size they like (including zero) we could claim that about all valid C programs that make any use of the stack.
- michaelcampbell 15y ago> In this case, the OP admits that they used the wrong data structure in Clojure and the right one in Lush, which makes the entire exercise meaningless. This right here is the crux of the flawed hypothesis of the entire article.