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

51–60 of 179 posts

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

#51

Post by zabzonk »

jb1991 wrote: post #40
jb1991 wrote: post #38

Earlier quoted context omitted.

If you read the article and see what pure functions are, you will understand. The length function has no parameters, by definition it must access data outside of the function if it’s going to do anything. This means it is not pure. Can you take that length function outside of the class and run it and have it do something? No, it is tightly coupled to the class that it is attached to.

Incidentally if this has whetted your appetite for functional programming, I encourage you to read a lot more about it and study languages that are truly functional. It could be quite liberating to see this approach to software development. It is not a panacea but it is a very useful perspective to acquire on software engineering, regardless of language, which is what this article discusses.

i find this slightly patronising - i have studied languages such as scheme and haskell. and i don't see how writing a function such as length(string) could be pure if the member function length() was not, as you would pass a copy of the string (ok, pure) and then call a member function (impure, according to you) on it to actually get the length.

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

#52

Post by simplotek »

bmitc wrote: post #20
forrestthewoods wrote: post #16

Earlier quoted context omitted.

> There's also almost nothing pragmatic about C++. Huh? We’re talking about game dev. C or C++ is the primary language for just about every game engine ever. Even Unity is written C++. I can’t say functional languages haven’t ever shipped a game. I’m sure there’s an example or three. But yeah when it comes to shipping games C++ is the definition of pragmatic.

The word game appears twice in all the articles, so I took this writing as a broad outlook. And C++ is not C. Just because C++ ships games doesn't make it pragmatic. Aren't many game codebases considered to be absolute hell? And none of that says anything about the pragmatism of functional-first languages.

> The word game appears twice in all the articles, so I took this writing as a broad outlook. And C++ is not C.

C++ is indeed not C. C++ is a considerable improvement over C. You can stick with your C-style code and get the same result you'd get if you had used C, but you still have access to features that simplify a great deal your life and don't have a performance impact, like templates. With C++ you can have your C cake and eat the C++ cake too. The only drawback is compilation times, but any caching system takes care of that.

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

#53

Post by jmrobles »

seanalltogether wrote: post #24

> A large fraction of the flaws in software development are due to programmers not fully understanding all the possible states their code may execute in. I think this probably the most important concept for programmers to keep at the front of their minds when working day to day. So many of the problems I see come from developers (myself included) adding new business logic to a process, or fixing a bug and not thinkin…

The problem is even bigger when you are reviewing PRs, the lack of context is the big problem,imo.

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

#54

Post by HybridCurve »

seanalltogether wrote: post #24

> A large fraction of the flaws in software development are due to programmers not fully understanding all the possible states their code may execute in. I think this probably the most important concept for programmers to keep at the front of their minds when working day to day. So many of the problems I see come from developers (myself included) adding new business logic to a process, or fixing a bug and not thinkin…

I actually just started to refactor some of my code earlier this week to deal with this very problem.

It was related to deserialized data being transposed from one complex digraph to another. The reason I did not catch it as being problematic sooner was precisely because the state management was loosely distributed within the transposing functions' call hierarchy. The code which was trying to manage the states had emerged from fixes for a series of different problems related to edge cases, and once the new problems started relating to fixes for the others, I had that "Ahhh, well sh*t.." moment you get when finding you were missing something important.

> I think this probably the most important concept for programmers to keep at the front of their minds when working day to day.

The lesson I had learned was to be more mindful when synthesizing a solution and there might be more state interdependence than we expect. Centralizing state management has helped me solve it in this case.

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

#55

Post by jb1991 »

zabzonk wrote: post #51
jb1991 wrote: post #40

Earlier quoted context omitted.

Incidentally if this has whetted your appetite for functional programming, I encourage you to read a lot more about it and study languages that are truly functional. It could be quite liberating to see this approach to software development. It is not a panacea but it is a very useful perspective to acquire on software engineering, regardless of language, which is what this article discusses.

i find this slightly patronising - i have studied languages such as scheme and haskell. and i don't see how writing a function such as length(string) could be pure if the member function length() was not, as you would pass a copy of the string (ok, pure) and then call a member function (impure, according to you) on it to actually get the length.

No, you would not typically call a member function on anything in a pure language. Instead, you would pass a sequence of characters and the function would return the length, by counting them.

I didn’t mean to sound patronizing, I apologize for that. Your question suggested that you aren’t that familiar with functional programming, so I was just trying to steer you in the right direction. A function that takes no parameters is not a pure function in general, unless all it does is return a constant value, which wouldn’t make much sense. length() does not make sense in a functional programming style.

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

#56

Post by rhn_mk1 »

jb1991 wrote: post #38
zabzonk wrote: post #37

Earlier quoted context omitted.

why do you think the length member function is not pure?

If you read the article and see what pure functions are, you will understand. The length function has no parameters, by definition it must access data outside of the function if it’s going to do anything. This means it is not pure. Can you take that length function outside of the class and run it and have it do something? No, it is tightly coupled to the class that it is attached to.

A member function must have at least one parameter. Here it's "parameter0":

parameter0.membfun()

It doesn't really matter whether the parameter name is separated from the function name by a dot, or a bracket. In a different syntax, it might have been written as "membfun(parameter0)" without any practical difference.

This means that Foo::length() can be pure no problem, because Foo is its parameter, and, as such, in its scope.

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

#57

Post by jb1991 »

rhn_mk1 wrote: post #56
jb1991 wrote: post #38

Earlier quoted context omitted.

If you read the article and see what pure functions are, you will understand. The length function has no parameters, by definition it must access data outside of the function if it’s going to do anything. This means it is not pure. Can you take that length function outside of the class and run it and have it do something? No, it is tightly coupled to the class that it is attached to.

A member function must have at least one parameter. Here it's "parameter0": parameter0.membfun() It doesn't really matter whether the parameter name is separated from the function name by a dot, or a bracket. In a different syntax, it might have been written as "membfun(parameter0)" without any practical difference. This means that Foo::length() can be pure no problem, because Foo is its parameter, and, as such, in i…

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 this is definitely not what purity and functional programming is about.

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

#58

Post by mejutoco »

Tanjreeve wrote: post #49
jillesvangurp wrote: post #19

Earlier quoted context omitted.

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…

>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. Until it does matter. Then it *really* matters at which point you're normally looking at a bottom up rewrite and likely retooling and rehiring for new skills. Ive been bitten by "oh it's just a prototype" a few too many times n…

One could always create a native python module in Rust/other and call it from Python. It might not work for videogames, for instance, but ML seems to do fine with this approach, and they require a lot of performance from the GPU.

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

#59

Post by mejutoco »

noduerme wrote: post #36

As a 25+ years coder who's very accustomed to thinking in my own ways, I have a problem with functional-purism similar to the problem I had with globals and factory functions. The fact is that most programs have a lot of states and these states have to be represented somehow. Allowing the objects to contain functions that act on those states is a perfectly good analogy for most business logic or game logic you're mod…

> these states have to be represented somehow

In data types!

> But so many functions are more comprehensible when they take place bound to the scope of what it is they're acting upon

To me, the most understandable function (lowest context needed, lowest cognitive overhead) is a black box that takes type x as input and produces type y as output, without side-effects

> I don't think that thinking in terms of objects or even global states should be considered a code smell

Classes can mix state and behaviour. I prefer when state is encoded in types and behaviour in functions, instead of having implicit state changes in a class, because it is more difficult to track, and constraint.

Of course, in the real world, if a library or platforms uses OOP, so be it. I am not dogmatic. But ideally, I avoid OOP because of this implicit mixing of state and behaviour.

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

#60

Post by mightybyte »

seanalltogether wrote: post #24

> A large fraction of the flaws in software development are due to programmers not fully understanding all the possible states their code may execute in. I think this probably the most important concept for programmers to keep at the front of their minds when working day to day. So many of the problems I see come from developers (myself included) adding new business logic to a process, or fixing a bug and not thinkin…

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.
Post reply on HN