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

131–140 of 179 posts

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

#131

Post by ledauphin »

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…

just because a pattern can be used alongside a different paradigm doesn't make it "not an FP thing."

Referential transparency and immutability are fundamental to FP, therefore they are meaningfully described as FP things regardless of who is using them or where.

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

#132

Post by mejutoco »

gnuvince wrote: post #110
mejutoco wrote: post #59

Earlier quoted context omitted.

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

> 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 True, however we must be careful not to go completely bananas either; it's really hard for a reader to piece back together a full mental picture if the functionality is spread into dozens even hundreds of general-purpose 3-line funct…

Agree. This is why starting with the data structures makes the code clearer.

Of course the functions can be grouped in modules. It is the same problem as having god objects, having lots of methods or many classes in OOP (it is orthogonal to OOP or functional programming).

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

#133

Post by ChrisMarshallNY »

jb1991 wrote: post #128
ChrisMarshallNY wrote: post #123

Earlier quoted context omitted.

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.

And mine. I just get tired of the "Attack first" approach that everyone takes, these days.

I know that I sound like a demented old man, when I say that I miss the old days, when we all shared passions for the tech, and, even when we were in competition with each other, we tended to have respect for one another.

But those were also the days of the UseNet flamewars, so it wasn't all flowers and bunnies (and I was definitely a flame warrior).

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

#134

Post by justinpombrio »

ChrisMarshallNY wrote: post #87
KMag wrote: post #83

Earlier quoted context omitted.

The nice thing about ADTs is that you can couple the state variables with the enum, so that the representable state is better tied to the enum value. (Yes, you can kind of do this in C with a discriminated union of a struct holding an enum and a union, but the type system doesn't stop you form grabbing a union member that doesn't match up with the current enum value.)

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

To clarify: Swift enums are ADTs, because they can hold data for each case. Same as Rust enums. This contrasts to C enums which are not ADTs because they cannot store additional data.

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

#135

Post by baby »

sidlls wrote: post #112
baby wrote: post #78

Earlier quoted context omitted.

No modern language seems to have oop tho (golang, rust)

Rust supports object oriented programming, and so does golang. In the case of the latter, it’s a fertile ground for all manner of bugs, performance issues, and weird behaviors thanks to the duck typing approach they chose.

How do you do OOP with rust?

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

#136

Post by justinpombrio »

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" is a fancy word for "pair". Or more generally "tuple".

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

#137

Post by zactato »

optbuild wrote: post #91

Why aren't more universities teaching functional programming first to form good mental models for the students and then show them when to use state and when to not. Why is everyone teaching Python?

Hasn’t Lisp been the language of choice for CS 101 for several decade at MIT and other universities?

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

#138

Post by sidlls »

baby wrote: post #135
sidlls wrote: post #112

Earlier quoted context omitted.

Rust supports object oriented programming, and so does golang. In the case of the latter, it’s a fertile ground for all manner of bugs, performance issues, and weird behaviors thanks to the duck typing approach they chose.

How do you do OOP with rust?

https://doc.rust-lang.org/stable/book/ch17-00-oop.html

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

#139

Post by naasking »

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…

> If games were so much easier to write that way we would see tons of them, especially among the better games, but we don't.

Functional programming only started going mainstream a few years ago. Give it time, it will make an impact. You can already see the influence of functional reactive programming in UI frameworks like React, where the screen state is a pure function of the program state. That's exactly what games have been doing for years, ie. rendering every from based on program state, only now we have a purely functional model of how this works.

Some of the "purely functional" aspects will be optimized/compiled away at various layers, but the programmer would still be able to work with the high-level model without attending to those details.

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

#140

Post by boppo1 »

makeitdouble wrote: post #97
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 am always wondering how much are we expected to understand the code we’re working on. It is very easy to just say people should know everything, but in practice people don‘t review every single library, nor defend against every single possible case, and surely don’t keep everything in memory while working on any single problem. I really can’t imagine someone “fully understanding” how the linux kernel works for inst…

Total newb here, but according to Stroustrup, the whole point of programming is so you don't have to know everything. You're responsible for:

A. Understanding relevant computing fundamentals

B. Understanding the interfaces to code you use

C. Writing reliable implementations and documenting them well

D. Writing useful and appropriate interfaces for your implementations

In a perfect world, this creates a nice chain where every programmer only needs to look after these four points and then everything will work seamlessly.

Too bad we don't live there.

Post reply on HN