3 ms·

I think there's a big point that's being missed here. Carmack is conflating inlining code with writing functional code. These are different things. I'd agree t

by apeace 10y ago

I think there's a big point that's being missed here. Carmack is conflating inlining code with writing functional code. These are different things. I'd agree that if the majority of your code is mutating state, it makes sense to mash all that together in one place. You want to keep an eye on the dirty stuff. But on the other hand, inlining pure functions that don't use or mutate any global state doesn't make sense to me. Why is making it "not possible to call the function from other places" a benefit? How about calling that code from a unit test!

phkahler 10y ago
>> Why is making it "not possible to call the function from other places" a benefit? When it's a pure function that's not a problem. When it changes state then you lose track of ordering and such. That's his point, state changes need to be kept in the one big function so you can keep track of them easily. And of course, almost all interesting software has mutable state. Otherwise you're just doing a computation and looking for a single output.
- apeace 10y ago
  >> When it's a pure function that's not a problem. That was my point. He's conflating two different things. I understand why inlining mutation has benefits. Just not inlining functional code. >> And of course, almost all interesting software has mutable state. Of course, but I think most programmers overestimate how prevalent state needs to be throughout a program. I once wrote an RSS aggregator as an eight-stage pipeline. It checked about 40k feeds, each every 60 seconds. Every stage had a 'main' file where the vast majority of state was kept. The rest was functional libraries. I suppose that would be a demonstration of what Carmack is proposing, with the difference being that my pure functions (the majority of the code) had clear names and were unit-tested. It worked so well that almost every large program I've written since has been designed the same way!
MyNameIsFred 10y ago
Carmack addressed this, at least as I read it. One of his concluding guidelines was that it purely functional methods are a virtue and should be made purely functional wherever possible (he phrases it in terms of "const"). He did also day, however, that in his domain non-trivial pure-functional methods rarely apply.

by apeace 10y ago

phkahler 10y ago

>> Why is making it "not possible to call the function from other places" a benefit? When it's a pure function that's not a problem. When it changes state then you lose track of ordering and such. That's his point, state changes need to be kept in the one big function so you can keep track of them easily. And of course, almost all interesting software has mutable state. Otherwise you're just doing a computation and looking for a single output.

apeace 10y ago
>> When it's a pure function that's not a problem. That was my point. He's conflating two different things. I understand why inlining mutation has benefits. Just not inlining functional code. >> And of course, almost all interesting software has mutable state. Of course, but I think most programmers overestimate how prevalent state needs to be throughout a program. I once wrote an RSS aggregator as an eight-stage pipeline. It checked about 40k feeds, each every 60 seconds. Every stage had a 'main' file where the vast majority of state was kept. The rest was functional libraries. I suppose that would be a demonstration of what Carmack is proposing, with the difference being that my pure functions (the majority of the code) had clear names and were unit-tested. It worked so well that almost every large program I've written since has been designed the same way!

MyNameIsFred 10y ago

Carmack addressed this, at least as I read it. One of his concluding guidelines was that it purely functional methods are a virtue and should be made purely functional wherever possible (he phrases it in terms of "const"). He did also day, however, that in his domain non-trivial pure-functional methods rarely apply.