Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

John Carmack on inlined code (2014)

number-none.com

Post reply on HN
Print view View original

381–390 of 402 posts

Re: John Carmack on inlined code (2014)

#381

Post by ninetyninenine »

gpderetta wrote: post #367
ninetyninenine wrote: post #334

Earlier quoted context omitted.

>For-loops do exist, they just need to not have side effects, No they don't. For loops and loops in general are procedural actions. You are jumping from directive to directive, command to command. Loops are NOT functional at all. loops are an artifact of the computational machine, jumping to different instructions. Functional programs like functions in mathematics DO not contain for loops. > which in practice means t…

Python: def range_mul(n, mul): for i in range(n): yield i*mul x = list(range_mul(10, 20)) range_mul is a pure function, yet it is implemented with a for loop. Once you have first class continuations or the equivalent, the differences between imperative and pure blur (cf. Haskell do-notation, is it imperative?). In any case I think you are missing int_19h point, the it doesn't matter if a function is implemented using…

> Haskell do-notation, is it imperative?

No it’s not. It only works in context of a monad and it achieves what looks like imperative code by utilizing closures.

I think it’s quite obvious imperative code with mutations but a deterministic end result can be hidden behind a function and treated as pure. I don’t think anyone misses this point so it’s likely redundant to bring that up. Either way it’s not the point of the conversation.

Re: John Carmack on inlined code (2014)

#382

Post by whstl »

reshlo wrote: post #357
whstl wrote: post #314

Earlier quoted context omitted.

Both React and Vue are older than 10 years old at this point. Both are older than jQuery was when they were released, and both have a better backward compatibility story. The only two real competitors not that far behind. It's about time for this crappy frontend meme to die. Even SOAP didn't really live that long before it started getting abandoned en masse for REST. As someone who was there in the "last 12 months" J…

> Some of this technology has a completely different level of complexity that to this day I am not able to grasp Enterprise JavaBeans mentioned?

That's another great example!

Re: John Carmack on inlined code (2014)

#383

Post by gpderetta »

ninetyninenine wrote: post #379
gpderetta wrote: post #367

Earlier quoted context omitted.

Python: def range_mul(n, mul): for i in range(n): yield i*mul x = list(range_mul(10, 20)) range_mul is a pure function, yet it is implemented with a for loop. Once you have first class continuations or the equivalent, the differences between imperative and pure blur (cf. Haskell do-notation, is it imperative?). In any case I think you are missing int_19h point, the it doesn't matter if a function is implemented using…

range_mul is not pure. Don’t believe me? Ask ChatGPT: “”” No, a Python function that contains the yield keyword is not a pure function. A pure function is defined as a function where the output is solely determined by its input values, with no observable side effects. This means it should: • Always return the same result when given the same input. • Have no side effects (like modifying global state, reading from or w…

Well, technically a call to range_mul() is still pure and it matches the definition: it has no side effects, and it returns a new instance of the same object (the generator); the generator itself is inpure of course, so I concede the point. But that's a limitation of python generators being one-shot; with proper delimited continuations you can snapshot the state at any point and replay it at leisure, not differently than a lazy stream.

Regarding the rest, I was referring to this comment from int_19h re encapsulation:

"In general, so long as mutation can be encapsulated in modules that only expose pure functional interfaces, I think it should still count as FP for practical purposes."

Re: John Carmack on inlined code (2014)

#384

Post by ninetyninenine »

dkarl wrote: post #374
ninetyninenine wrote: post #33

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 programme…

> 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.…

You 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.

Re: John Carmack on inlined code (2014)

#385

Post by ninetyninenine »

Hendrikto wrote: post #355
ninetyninenine wrote: post #195

Earlier quoted context omitted.

He literally says he’s more bullish on pure fp. Read it. And I also wrote about where he still inlines.

Exactly. More bullish means he uses and advocates for functional more than before. It by no means implies having ”moved on“ from inlining.

He has Moved on in general and his intro comments on how he still uses inlining for special cases.

Re: John Carmack on inlined code (2014)

#386

Post by ninetyninenine »

jmorenoamor wrote: post #373
ninetyninenine wrote: post #33

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 programme…

At 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"

You 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.

Re: John Carmack on inlined code (2014)

#387

Post by dkarl »

ninetyninenine wrote: post #384
dkarl wrote: post #374

Earlier quoted context omitted.

> 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.…

You 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 w…

Cats Effect manages effects using an IO monad. Most of the projects I currently work with use it.

This is why I say it's not useful to try to draw a strict line. I'm not going to argue with you on whether using an IO monad in an impure language is "pure FP" or not, but some Scala devs would. That argument in itself is not nearly as illuminating as knowing all the tools and concepts.

Re: John Carmack on inlined code (2014)

#388

Post by smrq »

JadeNB wrote: post #306
ragnese wrote: post #128

Earlier quoted context omitted.

> My goal in most cases now is to optimize code for the limits of the human mind (my own in low-effort mode) and like to be able to treat rules as guidelines. The trouble is how can you scale this to millions of developers, and what are those limits of the human mind when more and more AI-generated code will be used? I think the truth is that we just CAN'T scale that way with the current programming languages/models/…

> macOS is produced by the richest company on Earth and a few years ago the CALCULATOR app had a bug that made it give the wrong answers... This is stated as if surprising, presumably because we think of a calculator app as a simple thing, but it probably shouldn't be that surprising--surely the calculator app isn't used that often, and so doesn't get much in-the-field testing. Maybe you've occasionally used the calc…

Constantly, to keep the results of a calculation on screen. It's fallacious to assume that your own usage patterns are common. Hell, with as much evidence as you (none), I would venture that more people use the Calculator app than know that you can type calculations in Spotlight at all.

Re: John Carmack on inlined code (2014)

#389

Post by [deleted] »

rcv wrote: post #335

> The fly-by-wire flight software for the Saab Gripen (a lightweight fighter) went a step further... I would love to hear some war stories about the development of flight software. A lot of it is surely classified, but I'm fascinated by how those systems are put together.

[deleted]

Re: John Carmack on inlined code (2014)

#390

Post by cellularmitosis »

solomonb wrote: post #235
wmanley wrote: post #79

Earlier quoted context omitted.

Here's the link where he discusses functional programming style: 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…

The 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 ha…

Maybe this is just a subtle semantic thing, but what I took from this is that he is factoring out pure functions where ever possible, within a procedural context. In my mind, that’s not the same thing as “functional programming”.
Post reply on HN