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

181–190 of 210 posts

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

#181

Post by crntaylor »

dchichkov wrote: post #41

I've loved John's code since I saw it first time when the original Quake was leaked from their FTP site through IP spoofing. I was just a kid at that time, and it was an amazing experience to hack it. Yet now, the first example that I saw in this article hurts my eyes. Compare: for ( i = 0; i numVerts ; i++ ) { dot = plane.Distance( in->verts[i] ); dists[i] = dot; if ( dot LIGHT_CLIP_EPSILON ) { sides[i] = SIDE_FRONT…

Perhaps it's because I come from a functional programming background, but I find your re-written version using the ternary operator is much easier to understand, and prettier to boot. Well done!

This is a great example of "factoring out" that satisfies both the computer science and the mathematical definitions of the term. The assignment "sides[i] = " is repeated inside the if block, and it can be "factored out" using the ternary operator, just like in math:

    (a * x + a * y + a * z) = a * (x + y + z)
I'm even tempted to say that "assignment distributes over if", but that might be pushing the analogy too far. Any further and I might start thinking about monads, so I'll stop here.

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

#182

Post by gsg »

dchichkov wrote: post #178
gsg wrote: post #171

Earlier quoted context omitted.

Constness of pointer or reference parameters has no optimisation effect because it doesn't convey any reliable information. It doesn't indicate whether the thing is written to in the body of the function (the compiler already has that information). It doesn't indicate whether the thing can be written to through another pointer (const parameters may be aliased). And it doesn't indicate whether the thing is written to…

Would you guarantee that optimizers wouldn't use heuristics at IPO stage? Either way, you are right, and my comment should have been: 1) constraint 2) providing clues to developers 3) providing clues to optimizer.

Without yielding useful information, const annotations can't hope to have any positive effect on compiler optimisations, fancy or not.

I agree that const is useful for the other reasons you mention.

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

#183

Post by eru »

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…

John Hughes makes a good argument in favour of rigidity in "Why Functional Programming matter" (e.g. http://www.cs.kent.ac.uk/people/staff/dat/miranda/whyfp90.pd...)

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

#184

Post by MortenK »

stinos wrote: post #46
ExpiredLink wrote: post #12

> C++ code can quickly get unruly and ugly without diligence on the part of the programmers. To see how bad things can get, check out the STL source code. Microsoft's and GCC's[5] STL implementations are probably the ugliest source code I've ever seen. Even when programmers take extreme care to make their template code as readable as possible it's still a complete mess. Take a look at Andrei Alexandrescu's Loki libra…

when do you consider someone a guru?

When a person has done enough self promotion to persuade a lot of people to uncritically accept whatever mantra they spout.

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

#185

Post by alanctgardner2 »

lttlrck wrote: post #160
swift wrote: post #58

Earlier quoted context omitted.

You should be using const variables as much as possible (and in general preferring immutable data). In that case assignment and declaration _must_ take place at the same location.

this

There's an upvote button to agree with a comment, no need to post a single word. Generally, terse answers aren't really appreciated here (unless they're very good).

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

#186

Post by jaegerpicker »

dpark wrote: post #25
nitrogen wrote: post #14

Earlier quoted context omitted.

What do you find so disagreeable about collecting variables at the top of a function? For the most part, I like having all the variable declarations at the top, so it's easy to see what names are in what scope.

void up_front_decls() { float some_var; int another_var; some_var = get_some_var(); do_some_calculations(some_var); maybe_something_else(&some_var); some_var = get_another_var(); do_some_other_calculations(another_var); blah_blah_already_broken(); } void as_needed_decls() { float some_var = get_some_var(); do_some_calculations(some_var); maybe_something_else(&some_var); int some_var = get_another_var(); // compile-ti…

Your up fornt example isn't a result of poor style it's the result of a bad programmer. Assigning the right values to the right variables is the most basic of programming concepts. Sure typo's and bugs happen, I've done it too but it's still a programmer error not style error.

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

#187

Post by npsimons »

daemin wrote: post #131
npsimons wrote: post #98

Earlier quoted context omitted.

I'm kind of the same opinion as Carmack re: getters/setters. My feeling is, if all you're going to do is allow clients to read and write the variable, why not just expose it? Sure, you can argue encapsulation and even justify it by saying that later down the road you may want to change the implementation, but far too often I've seen C++ classes with a setter and getter for every variable, for no good reason (eg, they…

Some arguments in favour of getters and setters are; that using a function allows for the addition of caching, addition of thread safety checks, changing to compute the variable rather than store it, addition of logging, mapping it to be generated from another variable, etc.

I understand all of those justifications. When I mentioned changing implementation in my post, I was thinking of exactly those sorts of things. But none of them seem to be applied in the general case of "make a pass-through getter and setter for every member variable". My biggest question to the answer of universal getter/setters is "what is being abstracted?" Classes (and objects) are meant to abstract things like an "engine" so that you don't have to twiddle fuel_injector_rate, spark_plug_timing, etc, but rather just call engine.startIgnition().

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

#188

Post by ansible »

graue wrote: post #118
Cowen wrote: post #20

Earlier quoted context omitted.

He's mentioned before that he's toyed with the idea of switching to Haskell. That wasn't for functional programming though. It was instead for the built-in static code analysis the Haskell type system and compiler provides.

Do you have a link to the source for that? I'm curious to read. If your description is accurate, Rust[1] is exactly what he wants. I've been learning Rust recently (with a little help from [2]) and it does a ton of static code analysis, is safe by default (no dangling or null pointers, no shared mutable state), uses Hindley-Milner type interface just like Haskell, and generally is what you would expect if Haskell and…

I'll say this for them, they know how to write an introductory home page.

All too often, I've heard about some language, and then spent minutes trying to figure out what it is all about.

Rust is definitely worth a longer look by me.

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

#189

Post by gtani »

graue wrote: post #118
Cowen wrote: post #20

Earlier quoted context omitted.

He's mentioned before that he's toyed with the idea of switching to Haskell. That wasn't for functional programming though. It was instead for the built-in static code analysis the Haskell type system and compiler provides.

Do you have a link to the source for that? I'm curious to read. If your description is accurate, Rust[1] is exactly what he wants. I've been learning Rust recently (with a little help from [2]) and it does a ton of static code analysis, is safe by default (no dangling or null pointers, no shared mutable state), uses Hindley-Milner type interface just like Haskell, and generally is what you would expect if Haskell and…

He sort of alluded to it, but there's the usual perceived tooling/ retraining/hiring / performance ceiling issues for shops with > N devs, N somewhere between 5 and 25 (I don't agree with his arguments, just repeating them)

http://gamasutra.com/view/news/169296/Indepth_Functional_pro...

http://www.reddit.com/r/haskell/comments/jap3x/im_very_tempt...

http://blogs.uw.edu/ajko/2012/08/22/john-carmack-discusses-t...

Post reply on HN