6 ms·
His overall solution highlighted in the intro is that he's moved on from inlining and now does pure functional programming. Inlining is only relevant for him du
by ninetyninenine 2y ago
His overall solution highlighted in the intro is that he's moved on from inlining and now does pure functional programming. Inlining is only relevant for him during IO or state changes which he does as minimally as possible and segregates this from his core logic.
Pure functional programming is the bigger insight here that most programmers will just never understand why there's a benefit there. In fact most programmers don't even completely understand what FP is. To most people FP is just a bunch of functional patterns like map, reduce, filter, etc. They never grasp the true nature of "purity" in functional programming.
You see this lack of insight in this thread. Most responders literally ignore the fact that Carmack called his email completely outdated and that he mostly does pure FP now.
- deleted 2y ago[deleted]
- wruza 2y agoSome grasp it but see its trade-off contract, which is demanding.
- ninetyninenine 2y agoWith practice it just becomes another paradigm of programming. The trade off is really a skill issue from this perspective. The larger issue is performance which is a legitimate reason for not using fp in many cases. But additionally in many cases there is no performance trade off.
- nuancebydefault 2y agoI've never seen pure FP...
- nuancebydefault 2y agoI might add Carmack's take on functional programming https://web.archive.org/web/20120501221535/http://gamasutra.com/view/news/169296/Indepth_Functional_programming_in_C.php https://web.archive.org/web/20120501221535/http://gamasutra....
- sdeframond 2y agoI would recommend you take a look at Haskell or Elm. John Karmack did and talked about it https://m.youtube.com/watch?v=1PhArSujR_A https://m.youtube.com/watch?v=1PhArSujR_A
- eyelidlessness 2y agoSurely if you’ve seen any non-trivial amount of code, you have seen pure FP applied piecemeal even if not broadly. A single referentially transparent function is pure FP, even if it’s ultimately called by the most grotesque stateful madness.
- int_19h 2y agohttps://pandoc.org/ https://pandoc.org/
- wmanley 2y agoHere's the link where he discusses functional programming style: https://web.archive.org/web/20170116040923/http://gamasutra.com/view/news/169296/Indepth_Functional_programming_in_C.php https://web.archive.org/web/20170116040923/http://gamasutra.... He does not say that that his email is completely outdated - he just says that calling pure functions is exempt from the inlining rule. He's not off writing pure FP now. His approach is still deeply pragmatic. In the link above he discusses degrees of function purity. "Pure FP" has a whole different connotation - where whole programs are written in that constrained style.
- ninetyninenine 2y agoHe literally said he’s bullish on pure fp. Which means he is off writing pure fp. His own article about it never explicitly or implicitly implies a “pragmatic approach”. I never said he said his email was completely outdated. He for sure implies it’s outdated and updates us on his views of inlining which I also mentioned.
- coob 2y ago> I never said he said his email was completely outdated. From your prior message: > Carmack called his email completely outdated
- ninetyninenine 2y agoOk my bad but I did mention what he’s doing with inlining. So I contradicted myself in the original message which you didn’t identify. He still does inlining.
- deleted 2y ago[deleted]
- solomonb 2y agoThe original article literally starts with this: > In the years since I wrote this, I have gotten much more bullish about pure functional programming, even in C/C++ where reasonable: (link) > >The real enemy addressed by inlining is unexpected dependency and mutation of state, which functional programming solves more directly and completely. However, if you are going to make a lot of state changes, having them all happen inline does have advantages; you should be made constantly aware of the full horror of what you are doing. He explicitly says that functional programming solves the same issue as inlining but more directly and completely.
- Hendrikto 2y ago> he's moved on from inlining and now does pure functional programming Neither of those are true. He does more FP ”where reasonable“, and that decreases the need for inlining. He does not do pure FP, and he still inlines.
- ninetyninenine 2y agoHe literally says he’s more bullish on pure fp. Read it. And I also wrote about where he still inlines.
- Hendrikto 2y agoExactly. More bullish means he uses and advocates for functional more than before. It by no means implies having ”moved on“ from inlining.
- ninetyninenine 2y agoHe has Moved on in general and his intro comments on how he still uses inlining for special cases.
- solomonb 2y ago"pure FP" does not mean only writing in a functional style. Purity refers to referential transparency, ie., functions do not depend on or modify some global state.
- zelphirkalt 2y agoActually even further: They also don't modify/mutate any arguments. If they did, then that could raise problems with concurrency.
- Hendrikto 2y agoI know what purity is. It is a core principle of functional programing. So ”functional“ already implies purity, and ”pure functional“ implies exclusively functional (e.g. Haskell).
- eyelidlessness 2y agoI think more people grasp functional programming all the time, or at least the most salient detail: referential transparency. It’s easy to show the benefits in the small, without getting heavy on academics: pure functions are easier to test, understand, and change with confidence. All three of these reinforce each other, but they’re each independently beneficial as well. There are tons of benefits to get from learning this lesson in a more intentional way—I know that I changed my entire outlook on programming after some time working in Clojure!—but I’ve seen other devs take the same lessons in multi-paradigm contexts as well.
- ninetyninenine 2y agoNot just this. Modularity is the main insight as well. The reason why oop doesn’t work is because methods can’t be broken down. Your atom is oop is literally a collection of methods tied to mutating state. You cannot break down that collection further. In pure fp. You can break your function down into the smallest computational unit possible. This is what prevents technical debt of the architectural nature as you can rewrite your code as simply recomposing your modular logic.
- zelphirkalt 2y agoThat most wont get it is due to the fact that most are kind of "industrial programmers", who only learn and use mainstream OOP languages amd as such never actually use a mainly FP language a lot. Maybe on HN the ratio is better than on the whole market though.
- jmorenoamor 2y agoAt least for me, it's hard to get that insight, I tried to read articles and watch videos, and none of them gave me say: "oh! now I get it"
- ninetyninenine 2y agoYou need to learn Haskell in a non trivial way. Code in it. And then you need to completely internalize why the IO monad exists and why it encourages the programmer to code in ways that stay away from using it. I had a friend (who’s in general a good programmer) learn Haskell and then get completely annoyed by the IO monad so that he quit learning Haskell. So yeah, it’s not easy to “get it” You only get it with reading and practice. Really you just need to completely internalize and grasp the purpose of the IO monad in Haskell.
- dkarl 2y ago> To most people FP is just a bunch of functional patterns like map, reduce, filter, etc. For me, these were the gateway drugs to FP, because they weren't available in the languages I was used to, namely C++ and Java. I encountered map and filter in Python in the 1990s, immediately realized a ton of Java and C++ code I wrote would be simpler with them, and dove into Lisp when I found out that's where Python got them. They have nothing to do with pure functional programming, of course; they're just nice idioms that came from functional languages. That led to a long slippery slope of ideas that upgraded my non-FP programming at every step, long before I got into anything that could be described as pure FP. I don't know if it helps to draw a strict line between "pure" and "impure" FP. I mostly code in Scala, which is an imperative, side-effecting language. Scala gives you exactly the same power as Java to read and mutate global state. However, by design, Scala provides extremely good support for functional idioms, and you can use an effects system (such as Cats Effect or ZIO) to write in a pure FP style. But is it "pure FP" if you can read and mutate global state, and if you have to rely on libraries that are written in Java? Maybe, maybe not, but I don't think trying to answer that question yields much insight.
- ninetyninenine 2y agoYou do want to draw a strict line. When I say most programmers don’t get it… I’m talking about you. You don’t get why carmack is bullish about pure fp. You think it’s just map, reduce and filter and you don’t get why those functions are irrelevant. To you you’re just fulfilling an ocd need to simplify your code and make it more pretty. There is deeper insight here that you missed and even when you read what carmack wrote about pure fp I doubt you’ll internalize the point. Lisp is not pure. That’s why you don’t have the insight. For the true insight you need to learn about Haskell in a non trivial way. Not just youtube videos, but books that teach you the language from first principles. You need to understand the IO monad. And why it makes Haskell pure and how it forces you to organize your code in a completely different way. This is not an easy thing to understand. The IO monad, when it appears, infects your code with the IO type and makes it extremely annoying to get rid of. I had a friend who learned Haskell and hated Haskell because of the IO monad. He stopped learning haskell to early and he never "got it". If you reach this point you have to keep learning about Haskell until you understand why things are the way they are with haskell. Just remember this: the annoyance of the IO monad is designed like that so that you write your logic in a way that doesn’t allow the monad to pollute most of your code.
- aithrowawaycomm 2y agoOver the last few decades there has been quite the rug-pull in "functional programming"! 1) programming which is based on "functions" (procedures) as values, including anonymous lambdas (hence map/fold/etc paradigms), which is only really possible in languages that intentionally support it 2) programming where every procedure (except some boundary code for IO/etc) is truly is a well-defined mathematical function, which is possible in almost any programming language 1) describes any language you would call a "functional programming language," whereas 2) involves well-understood concepts around mutability and determinism that a minority (correctly) describe as "pure functional programming." So I think it's a bit judgmental to say "lack of insight" when it's more about shifting terminology. A very high-reliability C program might be "purely functional" (inside of an IO/memory boundary) and built by engineers with the precise insight you're discussing, but in most contexts it would be odd to say "purely functional," especially if the code eschews C mechanics around function pointers. In most imperative contexts it is clearer to describe purely functional ideas in terms of imperative programming (which are equally clear, if less philosophically interesting).
- _proofs 2y agowhere does the condescension come from? the loftiness/lording over people who "just don't get it", that clearly comes across in your communication? this is a really non-productive comment. you have an opportunity to teach and share knowledge but instead you hoard and condescend, and rant about your implied superiority. if so many programmers don't understand -- what's more productive: this comment, or helping "most programmers" to get it, and understand?
- ninetyninenine 2y agoIt’s communication to programmers who do get it. I love to teach and explain but this is one of those things that can’t be conveyed. You have to do it yourself. If you want an explanation though, use Google. But I don’t think explanations actually help you grok what’s really happening. You really have to come to catharsis yourself. Learn Haskell. Learn it to the point where you completely understand the purpose of the IO monad and why it exists and helps a program organize better. Then you will understand. When you do get it. You’ll be among a small few who have obtained something that’s almost like forbidden knowledge. No one will “get” you.