3. Aside from the fact that his wording is backwards from his meaning, I agree that it should be possible to write code that doesn't ever garbage collect.
4. Ok
5. Does this guy know the function of a linker?
6. Again, he asserts something you are to avoid, when really he should be emphasizing what you need to support: code without runtime checks.
7. Wrong. This is one of the few opportunities you have to beat C at its own game. C hardcodes assumptions about the stack that prevent certain low level optimizations.
His #8 is then a summary of the entire article, and really is the only valid point he's made. C is close to a sweet spot for wrapping low level code in somewhat higher level clothing. You can't beat it at the same level of simplicity (not if you count the cost of any potential switch anyway). The way to beat C is to naturally support the high level / low level hybrid that he's doing with python+C in a single language.
> C hardcodes assumptions about the stack that prevent certain low level optimizations.
Would you please expand on this? I can't think of any assumptions C makes about the stack that C++ wouldn't make; neither can I think of low-level optimizations that said assumptions prohibit. I'm curious about what you have in mind.
I just meant that the role of the stack is hardcoded. In most assemblys you can write to the stack pointer and presto, you're working with a new stack. This is a capability of assembly that C doesn't expose.
It raises a valid issue though: The article's author is operating under the assumption that any replacement language must be totally interoperable with C -- both calling and being called. If you have some crazy stack-reassignment logic in a new language, it will break a native C function's ability to longjmp out of a calling function written in the new language.
2. Hahahahahaha
3. Aside from the fact that his wording is backwards from his meaning, I agree that it should be possible to write code that doesn't ever garbage collect.
4. Ok
5. Does this guy know the function of a linker?
6. Again, he asserts something you are to avoid, when really he should be emphasizing what you need to support: code without runtime checks.
7. Wrong. This is one of the few opportunities you have to beat C at its own game. C hardcodes assumptions about the stack that prevent certain low level optimizations.
His #8 is then a summary of the entire article, and really is the only valid point he's made. C is close to a sweet spot for wrapping low level code in somewhat higher level clothing. You can't beat it at the same level of simplicity (not if you count the cost of any potential switch anyway). The way to beat C is to naturally support the high level / low level hybrid that he's doing with python+C in a single language.