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

161–170 of 210 posts

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

#161

Post by gnuvince »

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…

Rust is pretty much exactly what a lot of people want and need; a high level language with a strong focus on safety and concurrency, while still allowing you to control the lower level details such as memory layout for good performance.

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

#162

Post by neutronicus »

nirvdrum wrote: post #43
scanr wrote: post #35

Earlier quoted context omitted.

> Clarity can usually be addressed with longer variable or method names, but there's a strong culture against that in nearly ever programming community. It would be interesting to see a list of those that discourage long method and variable names. I haven't seen anything that suggests that Java, Ruby, Python, Haskell, Kotlin, Scala, PHP, Groovy etc. discourage long variable and method names.

IntelliJ has inspections for long class and method names. A lot of Java devs run that. Long names are frequently derided in the Ruby community as being Java-like. I can't speak to Haskell at all. But generally whenever something needs to be typed frequently, it tends to be shortened. My favorite is when vowels are deemed too onerous.

The Haskell community certainly love their infix non-alphanumeric functions.

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

#163

Post by gsg »

dchichkov wrote: post #120
jblow wrote: post #106

Earlier quoted context omitted.

This is true (especially: breaking vectorization). But premature optimization is not a good idea, and if you are doing real optimization, you are going to rewrite that piece of code 10 times anyway, so it is in a different class of problem and the putty stuff I was saying before does not apply (i.e. this code is in the 1% or so of the codebase that is highly performance-sensitive). Optimized code is just a different…

And again it depends. I would return to a simple example of passing a parameter by a const reference. When you are writing this const in the "const std::string &name" you are 1) constraining developers from breaking things 2) making the code more efficient 3) providing clues to other developers 4) providing clues to optimizer. All of these points are important to some degree. And it is just the same, when you are wri…

Constness of parameters has zero effect on optimisation. Const declarations may provide a small benefit.

Go ahead and apply const as you see fit, but don't expect better code out of it.

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

#164

Post by evincarofautumn »

dysoco wrote: post #75

So he discourages Getters/Setters and instead says that declaring the variable as Public is better? I mean, isn't that like not giving a sh-- about encapsulation principles ?

For immutable objects, “setFoo()” makes no sense, and “getFoo()” is redundant. For encapsulated objects, “foo” doesn’t need to be exposed at all, not even through getters and setters. A group of fields with no behaviour is not an object—it’s data.

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

#165

Post by Luyt »

ufo wrote: post #123
zanny wrote: post #121

Earlier quoted context omitted.

The argument from the Java camp is that if you always use the getters and setters, you leave the access and modification open to extension, say, by adding a callback listener for changes to a variable. I then just say, change it when you need it, and use that fancy "find usages" thing most IDEs and vim have.

Precisely. The real reason Python gets this right is that it the properties feature lets you write `obj.foo` but still call a `getFoo` method behind the scenes.

C++Builder and Delphi offer this too, with the '__property' declarator.

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

#166

Post by dan00 »

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…

...

    sides[i] = dot  LIGHT_CLIP_EPSILON   
                       ? SIDE_FRONT 
                       : SIDE_ON;
...

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

#167

Post by dchichkov »

gsg wrote: post #163
dchichkov wrote: post #120

Earlier quoted context omitted.

And again it depends. I would return to a simple example of passing a parameter by a const reference. When you are writing this const in the "const std::string &name" you are 1) constraining developers from breaking things 2) making the code more efficient 3) providing clues to other developers 4) providing clues to optimizer. All of these points are important to some degree. And it is just the same, when you are wri…

Constness of parameters has zero effect on optimisation. Const declarations may provide a small benefit. Go ahead and apply const as you see fit, but don't expect better code out of it.

Would you guarantee that for every implementation of every C++ compiler ever? Especially considering that constexpr is already there?

So, I'd rather leave these clues to the compiler/optimizer.

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

#168

Post by cbsmith »

Jare wrote: post #100
cbsmith wrote: post #42

Earlier quoted context omitted.

Considering how many languages these days completely eschew the header/body paradigm, I'm not sure that "head-only" programming is such an obvious mistake.

Such languages tend to be reasonably smart about what changes trigger large recompiles, and about not re-parsing the same lines of header-only code over for every compilation unit. In C++ the best you can hope is to set up precompiled headers and live with the artificial dependencies.

If the only problem you have with header-only programming is compile times, might I humbly suggest that the problem you are actually concerned about is entirely somewhere else (hint: most language compilers are terribly unsmart about what changes trigger recompiles, as the cost of compiling the entire source tree isn't too terrible).

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

#169

Post by zerooneinfinity »

sgift wrote: post #90
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…

Well, let me state this: John's version is not to my preference 'cause it has { in the same line as if, but I can live with that. But YOUR version uses not only the ? operator, which should be burned with fire but it NESTS two of them together. Please, I want to die now. :( Conclusion: We have different preferences.

How would you initialize a variable that depends on the truthfulness of another without the ternary operator. You should be careful when using extremes in programming.

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

#170

Post by georgeorwell »

dchichkov wrote: post #167
gsg wrote: post #163

Earlier quoted context omitted.

Constness of parameters has zero effect on optimisation. Const declarations may provide a small benefit. Go ahead and apply const as you see fit, but don't expect better code out of it.

Would you guarantee that for every implementation of every C++ compiler ever? Especially considering that constexpr is already there? So, I'd rather leave these clues to the compiler/optimizer.

http://www.gotw.ca/gotw/081.htm
Post reply on HN