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

John Carmack on Functional Programming in C++ (2018)

sevangelatos.com

Post reply on HN
Print view View original

121–130 of 179 posts

Re: John Carmack on Functional Programming in C++ (2018)

#121

Post by ghostpepper »

thesz wrote: post #113
the__alchemist wrote: post #94

Earlier quoted context omitted.

ADTs is a concept I've had a tough time understanding; the approximate definition that made the most impact with is considering them as a specific type of enumerations: Ones where each variant holds a value. Is this correct?

It is the other way around: enumerations are special cases of algebraic data types with no values attached. In algebraic data types we have a sum (union) of a labeled cartesian products, and each product may have arbitrary number of values: data MaybeInt = NoInt | AnInt Int data MaybeItsPair = NoIntsPair | AnIntPair Int Int The first constructor in both data types is a labeled (No...) product with empty number of val…

Can you explain the term 'cartesian product' in this context? I'm familiar with the cross product from undergrad linear algebra but I haven't applied algebra to types before, and I don't understand what two sets would produce a single Int as their product.

I haven't studied much theoretical computer science so I'd love to hear some good beginner resources on this stuff.

Re: John Carmack on Functional Programming in C++ (2018)

#122

Post by jlouis »

ChrisMarshallNY wrote: post #76
mightybyte wrote: post #60

Earlier quoted context omitted.

It took me awhile to realize but this is one of the big things that algebraic data types (ADTs) help you to do...design your data types so they have exactly the number of valid states that your domain has. To use another common FP way of saying it...make invalid states unrepresentable.

A classic way to do this, is enumerations.

Enumerations are not ADTs.

Re: John Carmack on Functional Programming in C++ (2018)

#123

Post by ChrisMarshallNY »

jb1991 wrote: post #111
ChrisMarshallNY wrote: post #87

Earlier quoted context omitted.

I use Swift. Swift enums are really nice[0]. [0] https://littlegreenviper.com/miscellany/swiftwater/enums-wit...

I like Swift but the examples on that page are quite over-engineered. Reads like someone was seduced by their own cleverness. There are much simpler ways to achieve what is being done in that example.

If you read that page, you’d understand that it was supposed to be “over-engineered.” I assume that you did read it, and took the least charitable viewpoint. I didn’t post it for peer review. It reflects my enthusiasm, as I was learning the language, and is probably four years old.

I'm a fairly decent chap, and have nothing against you. Not sure why it's so important to you to begin our relationship with an attack. I suspect we have far more in common, than we do, differences.

Re: John Carmack on Functional Programming in C++ (2018)

#124

Post by louthy »

Jensson wrote: post #116
louthy wrote: post #109

Earlier quoted context omitted.

> 3d engine is very structured, it isn't the creative part of game development. I also did lots of the creative bit ;). I just assumed this was going to go down a performance route question, sorry! > Big upfront design as you suggest No, I am not suggesting that at all - I'm saying the opposite of that. You're the third person to think that's what I am saying now, so I assume I didn't explain myself very well. Rather…

Well, you say that works, but basically nobody who programs creatively writes code that way. People who like functional programming mostly writes compilers or similar processing throughput systems, you see it a ton there, but you barely see it on the other side of the programming landscape such as game programming. So, you say it works for you, but basically every example of the things I talked about are done in a ve…

The biggest mistake you make is thinking you do something different to me or any other software engineer. You don't. You do the same thing and the same rules apply. You seem to think you're the only person doing anything creative. Well here's a newsflash: it's the same process in games as it is in all other forms of software development. The end result might look different, but the process is the same. The best devs are the creative ones, but creativity isn't limited to what appears on the screen, it comes from architecting complex solutions to difficult problems, it comes from elegance in code, and it comes from producing something that works for the end-user - whether that's a gamer, a doctor, or someone browsing on their phone.

Games is one of the easiest sectors to be in, the complexity level is low compared to other sectors, especially now all the difficult bits are done for you (off the shelf engines). I assume you're not working on titles that have 15 million lines of code in, like I do every day.

That is possibly why there hasn't been a big push for FP in games yet, because they haven't yet hit the complexity limit of OO like others have. Your argument is "Well we've always done it like this, why change?". Probably for the same reason people don't write games in assembly languages any more: at some point the current tools aren't good enough. Games might not have hit that ceiling yet, but you'll almost certainly be affected by the artefacts of getting close to it.

I see you're even questioning my history in games. Below [1][2][3][4][5][6][7][8] are some of the titles I worked on (or my code is in). But to be clear, we didn't use these techniques back then either, because it was too soon to be doing it (or we weren't enlightened then). You should consider being a little more open minded about how you could, possibly, write software more effectively. Especially when you have someone who's been on both sides of the fence advocating it. Just writing it off because you think people who do FP just write "compilers or similar processing throughput systems" is shooting yourself in the foot more than anything.

[1] Battalion Wars: https://en.wikipedia.org/wiki/Battalion_Wars

[2] Fire Blade: https://en.wikipedia.org/wiki/Fire_Blade_(video_game)

[3] Warmhammer 40,000 Fire Warrior: https://en.wikipedia.org/wiki/Warhammer_40%2C000%3A_Fire_War...

[4] Call of Duty - Finest Hour: https://en.wikipedia.org/wiki/Call_of_Duty:_Finest_Hour

[5] The Regiment: https://en.wikipedia.org/wiki/The_Regiment_(video_game)

[6] Reign of Fire: https://en.wikipedia.org/wiki/Reign_of_Fire_(video_game)

[7] Attack of the Saucerman: https://en.wikipedia.org/wiki/Attack_of_the_Saucerman

[8] Lunatik [canned]: https://www.unseen64.net/2020/11/16/lunatik-pure-entertainme...

Re: John Carmack on Functional Programming in C++ (2018)

#125

Post by thuuuomas »

noduerme wrote: post #47
thom wrote: post #39

Earlier quoted context omitted.

The argument isn’t that state is bad or doesn’t need to be managed. It’s more that spreading that state over a large number of areas leads to a lot of complexity and cognitive overhead in terms of expected behaviour at any given point of execution. Functional programming gives you ways to be much more explicit about the transformation being performed and the before/after states (except arguably when you start getting…

Isn't encapsulating state - and functions that act on states - within the smallest-possible class ancestor a pretty reasonable way of handling that? I'm not suggesting spaghetti or`GOTO 10400` or `GlobalCatBehaviorFactory.StartMeowing(cat)` or something. I mean we have a paradigm, and it's basically OOP with a dash of functional programming at the functional level. Maybe what I'm trying to say is that a lot of functi…

> absolute purity doesn't leave a route for daily coders writing regular programs to do their jobs

This speaks to the muscle memory of daily coders way more than to the details of FP/OO.

You could easily make the same argument about “absolute encapsulation”.

Re: John Carmack on Functional Programming in C++ (2018)

#126

Post by jasmer »

The psychological aspect of 'purity' in this concept is as interesting as anything.

I think that devs are naturally prone to be obsessive compulsive about such things.

We can see 'defeating the borrow checker' as a 1st order objective.

I think devs fee that 'defeating the borrow checker' gives us much more satisfactiong than 'fulfilling the customers needs'.

There's something a big 'chinse finger trap' about FP that consumes our attention on an impusleve level that is not necessarily consistent with what it actually means to be a good engineer.

This, along with our will to abstract and to want to use 'shiny new things' etc..

Re: John Carmack on Functional Programming in C++ (2018)

#127

Post by [deleted] »

jillesvangurp wrote: post #19
baby wrote: post #8

He talked about it a bit during his lex friedman interview. He said he spent some time there, IIRC, and found it somewhat intriguing, perhaps interesting, but needed to get shit done eventually and so stopped his investigation. Very pragmatic. From what I can see in this article he mostly seemed to like the purity aspect of FP. It seems to me like a number of FP concepts aren’t really “FP things”, as Carmack points o…

In the same interview he also mentions using python a lot lately and making the point that for the vast majority of code, performance really doesn't matter and productivity is more important. Reading this article, he's making a great argument for Rust. I assume the article predates rust by quite a bit. But basically Rust is not a pure functional language but still has a lot of elements in the language that add purity…

[deleted]

Re: John Carmack on Functional Programming in C++ (2018)

#128

Post by jb1991 »

ChrisMarshallNY wrote: post #123
jb1991 wrote: post #111

Earlier quoted context omitted.

I like Swift but the examples on that page are quite over-engineered. Reads like someone was seduced by their own cleverness. There are much simpler ways to achieve what is being done in that example.

If you read that page, you’d understand that it was supposed to be “over-engineered.” I assume that you did read it, and took the least charitable viewpoint. I didn’t post it for peer review. It reflects my enthusiasm, as I was learning the language, and is probably four years old. I'm a fairly decent chap, and have nothing against you. Not sure why it's so important to you to begin our relationship with an attack. I…

My apologies, I didn’t realize you were posting a link to your own site! I would have phrased my comment differently, although probably that should not have made a difference and I should’ve phrased it differently anyway.

Re: John Carmack on Functional Programming in C++ (2018)

#129

Post by jb1991 »

FpUser wrote: post #117
jb1991 wrote: post #57

Earlier quoted context omitted.

I see your point, but you are still passing the entire state of the entire object to your function if you want to follow that line of thought. This is also discussed in the article, and it’s not really what functional programming is about. What other state is in there that the function has access to? Maybe on a case-by-case basis you can say that particular object only has one piece of data, but in the general case t…

Splitting hairs

It’s not really splitting hairs — you lose the primary benefits of functional programming if you disregard these things.

Re: John Carmack on Functional Programming in C++ (2018)

#130

Post by thesz »

ghostpepper wrote: post #121
thesz wrote: post #113

Earlier quoted context omitted.

It is the other way around: enumerations are special cases of algebraic data types with no values attached. In algebraic data types we have a sum (union) of a labeled cartesian products, and each product may have arbitrary number of values: data MaybeInt = NoInt | AnInt Int data MaybeItsPair = NoIntsPair | AnIntPair Int Int The first constructor in both data types is a labeled (No...) product with empty number of val…

Can you explain the term 'cartesian product' in this context? I'm familiar with the cross product from undergrad linear algebra but I haven't applied algebra to types before, and I don't understand what two sets would produce a single Int as their product. I haven't studied much theoretical computer science so I'd love to hear some good beginner resources on this stuff.

Cartesian product: https://en.wikipedia.org/wiki/Cartesian_product

The number of variants of the AnIntPair construction is the number of distinct elements in the Int type, squared.

I used definition of algebraic data type in Haskell: http://wiki.haskell.org/Algebraic_data_type

Post reply on HN