3 ms·
I don't think I understand the relationship between inlined functions and functional programming established in the article. As I see it, whether you inline or
by arcturus17 6y ago
I don't think I understand the relationship between inlined functions and functional programming established in the article.
As I see it, whether you inline or split into functions or subroutines, you can have functions be pure, in the sense that they don't mutate state. In my experience with functional programming, splitting code into smaller functions is not a problem but rather encouraged too, for the sake of readability (so no different than other paradigms).
There must be something that escapes me, possibly at the systems level. Can someone please explain?
- srtjstjsj 6y agoCarmack agrees with you. He wrote that functional functions are the ideal, but often not possible, and non-functional functions are bad and should be inlined. This is the "functional core, imperative shell" pattern where you have as many small neat functional functions as possible, and one big nasty non-functional main loop for only your mutating state, where every line must be studied carefully in relation to all other lines.
- ZephyrBlu 6y agoThe "functional core, imperative shell" pattern is how I naturally gravitate to writing code. It helps so much with readability and understanding what the code does. Trying to read other peoples code that jumps around between many functions with side effects, often being nested 3-4 levels deep, hurts my soul.