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

John Carmack's comment on Doom 3's code style

kotaku.com

Post reply on HN
Print view View original

141–150 of 210 posts

Re: John Carmack's comment on Doom 3's code style

#141

Post by jblow »

dchichkov wrote: post #136
jblow wrote: post #128

Earlier quoted context omitted.

I think we have different ideas about what constitutes optimization. Sure, putting const in parameter declarations is easy to do. It may even buy you a little bit of speed because the compiler is a little bit clearer about pointer aliasing and whatever. But it's not going to make a difference in the equivalence classes of slow code / fast code / Really Fast Code. Serious hardcore optimization usually involves changin…

Thanks. I've really enjoyed that discussion with you. And by the way, your comment mentioning several decades of experience was certainly appropriate.

Yeah, this discussion went a lot better than the other one! Certainly more enjoyable, anyway.

Re: John Carmack's comment on Doom 3's code style

#142

Post by dpark »

nitrogen wrote: post #138
dpark wrote: post #89

Earlier quoted context omitted.

I have a few objections: 1. It wastes my time. Sure, I could probably set up my editor to fix this, but I shouldn't have to do so to satisfy someone else's pointless indentation fetish. I've personally never worked on a team where this was an accepted, general guideline. It was always just one guy who wanted this, and did it to every function he touched, adding maintenance headaches for everyone else (until/unless ot…

I bet that some programmers' brains need those orderly columns in order to be able to parse the code effectively, overwhelmed by the chaos of rivers of whitespace otherwise. In that case, it sounds like an editor that displays in columns but stores in compact form would be helpful.

That's certainly possible, and I agree with your idea that those devs should use the custom editor setup they need instead of expecting everyone else to accommodate them.

Re: John Carmack's comment on Doom 3's code style

#143

Post by neumann_alfred »

georgeorwell wrote: post #107
jblow wrote: post #96

Earlier quoted context omitted.

No, you clearly didn't understand my point. I am talking about maximizing the rate of successful features implemented. Programming things in assembly language is obviously not going to do that. I don't know, man. I have 31 years of programming experience. I am not detecting from your argument that you have anywhere near this level of experience, so I am inclined not to get into this discussion. But I will say that yo…

I'm not even clear that it's clear I didn't understand your point. I guess I have trouble communicating effectively. I thought your point was that flexible control flow structures like if-else allow you to change code quickly and more easily in the future. Wasn't that the point? Assuming I have understood your preference for flexible code, I am simply stating my belief that it is useful to balance this with rigid cod…

It depends on what you are trying to do.

Which you can't know in advance, which is the point. Since you don't know what you might want to do with stuff down the road, you end up writing code in a style that is less concise but more "putty-like". I am an amateur programmer with derpy years of experience, but I found myself often taking "shortcuts" out after a while, because they made working with the code harder.. just like the poster said, I realize that trying to be super clever all the time isn't that helpful. I guess you could say in places that are subject to constant change or lots of copy and paste, I trade screen space for putty-ness, and when something turns out to not really change anymore, or generally gets in they way of more interesting things, I compact it a bit.

Re: John Carmack's comment on Doom 3's code style

#144

Post by stch »

jblow wrote: post #96
georgeorwell wrote: post #87

Earlier quoted context omitted.

It strikes me that your argument taken to the extreme is that everybody should program in assembly language because you can do anything, anytime, anywhere. Well, at least as far as control flow structures are concerned. Certainly C is preferable to C++ if you want simple and malleable code. Do you also prefer if-else to switch statements? (I'm not sure.) Do you like to use goto? (I doubt it.) Do you eschew the use of…

No, you clearly didn't understand my point. I am talking about maximizing the rate of successful features implemented. Programming things in assembly language is obviously not going to do that. I don't know, man. I have 31 years of programming experience. I am not detecting from your argument that you have anywhere near this level of experience, so I am inclined not to get into this discussion. But I will say that yo…

What a big baby reply. "i'm really smart and you sound really dumb, so I'm gonna take the high road and not argue with you".

Re: John Carmack's comment on Doom 3's code style

#145

Post by gits1225 »

zaphoyd wrote: post #3
jlongster wrote: post #2

My heart grew a little warm with the last paragraph of John Carmack's comment: "The major evolution that is still going on for me is towards a more functional programming style, which involves unlearning a lot of old habits, and backing away from some OOP directions."

Has anyone here come across any particularly good books or other resources on functional style programming in C++? Especially ones that have been updated for C++11s new functional features.

Bartosz Milewski's blog: http://bartoszmilewski.com/

Re: John Carmack's comment on Doom 3's code style

#146

Post by georgeorwell »

jblow wrote: post #139
georgeorwell wrote: post #137

Earlier quoted context omitted.

I used the word extreme in the assembly language argument to indicate that I understood you weren't actually advocating people program in assembly. So I don't consider it a straw man. Rather, it was an example of extremely flexible control flow. Sometimes this is what you need. Sometimes you need to modify the stack so that a function is called in a different way. Sometimes gotos can provide significantly more effici…

Creepy reply is creepy. About this: "Plus, I mean, what if I revealed myself to you, and then you were like, oh shit, I better take what he says a little bit more seriously, wouldn't that just be embarrassing? I don't want to do that to you." No, by all means, go ahead. I am interested in having a productive discussion about programming, so if you can share your experience in a way that convinces me, I am totally ope…

I cut out the creepy parts, I agree that they were. I can't reveal my experience without breaking anonymity. If you need to know about my experience for my examples and arguments to hold water, then my points aren't very good anyway, which is why I prefer to stay anonymous. Good luck with The Witness and I'm sorry that this was painful. Symbolism and meaning in games are important and I appreciate what you are doing.

Re: John Carmack's comment on Doom 3's code style

#147

Post by mattdw »

worldsayshi wrote: post #103
quux wrote: post #7

Earlier quoted context omitted.

John Carmack wrote a nice article about experiences writing functional code in C++ here: http://www.altdevblogaday.com/2012/04/26/functional-programm...

"a function can still be pure even if it calls impure functions, as long as the side effects don’t escape the outer function" This is a very good point that probably could be systematically exploited. Does anyone know examples of this?

Clojure has "transient" (mutable) forms of its immutable datastructures, which can be bashed in place, but they're not allowed beyond function boundaries in either direction (I think). So you convert (copy?) to transient, mutate it in-place, then convert back to "persistent" before returning it.

Re: John Carmack's comment on Doom 3's code style

#148

Post by neumann_alfred »

dchichkov wrote: post #70
Garoof wrote: post #63

Earlier quoted context omitted.

I like the last one better. I think it reads more like "assign one of these values to sides[i]" and less like "do one of these three things". "By this latter I mean, if you change the code a little bit, you don't have to rewrite it; it looks basically the same." I'd say that's kind of the point though. The first one would look "basically the same" if in the last else it assigned to sides[j] instead of sides[i]. In th…

Precisely. And there is even a little bit more to it. 1. it reads "assign one of these values to sides[i]". 2. it would not allow some other peoples spurious code into the assignment. which is a good thing. 3. space is used to convey meaning; note how sides[i] stands next to dists[i]; ternary operation is formatted as a table, etc.

If you have people adding "spurious" stuff to your code, you have a bigger problem than coding style. Why would you need locks on your door if you live on a planet with only friends on it? If you don't; why don't you?

Re: John Carmack's comment on Doom 3's code style

#149

Post by to3m »

georgeorwell wrote: post #104
to3m wrote: post #99

Earlier quoted context omitted.

Well, I might be unusual, but I don't object to goto, I don't uses classes and inheritance much - and I like code that's all in one file, too. (Means I can keep an eye on it.) So it might not surprise you to hear that I'd vote for the code that uses the if statement :) - in fact, I don't really understand why the second would ever be preferable, outside some unlikely case specially engineered to prove me wrong. I can…

All you need to do is hoist the conditionals out of the ?: if you have a bug and you want to inspect them, either with printf or a debugger. Everything else is available before the statement. Personally I don't use debuggers except to get a backtrace from a core dump once in a while. I use various forms of automated testing and logging to stderr/stdout. They just aren't very useful with concurrency bugs.

The "all you need to do" bit is exactly the way this has wasted my time. I'm not saying that doing it is particularly complicated, nor that any individual occurrence is especially onerous, and in fact it usually isn't (though you do lose your state, and that's annoying) - but the time taken mounts up!

Ah well. I've said my piece. If your experience hasn't convinced you, like mine convinced me, then I imagine yours was a lot more fun ;)

Re: John Carmack's comment on Doom 3's code style

#150

Post by [deleted] »

eliasmacpherson wrote: post #27

I've always been told that the get, set() idiom is to allow the author to change the implementation at a later date. I always resent doing it but I can see how if the body of the function is not declared in the header file, but instead the associated .cpp file, that an author can change it, without introducing a whole recompile overhead. Writing code that may not be needed is bad, but it's a trade off vs. preventing…

[deleted]
Post reply on HN