John Carmack makes some interesting and relevant comments for this audience in his 2013 quakecon keynote..
My favorite quotes... "multi-paradigm means you can always do the bad thing if you feel you really need to, and programmers are extremely bad at doing the time-scale integration of doing something that they really know is negative." "..it's just amazing how many mistakes and how bad programmers can be, everything that is syntactically legal, that the compiler will accept, will eventually wind up in your codebase. and that's why i think that static typing is so valuable, because it cuts down what can make it past those hurdles." "it's the things that bite you over and over, [when code has] assumptions that are in multiple places in the system. but that's where all the really good high payoff systems optimizations are .... they are also things that are hard to dig out of the codebase later" "garbage collection is a benefit for developers. it has a bad reputation in gaming for intermittent pauses. intermittency is bad. A fixed overhead we can deal with and it makes programming easier." "It's going to take discipline to make sure none of the big things stay in the game-heap." .. "if you isolate out all the constant data and all of the big media, it's not that large. Our real mutable data is counted in megs, not tens of megs, so it's completely credible to walk it every frame.." [though keep in mind that the constant data he's talking about has lots of internal pointers, so to make it typesafe requires either trustable pre-validation or run-time checking] ------------------ http://www.youtube.com/watch?v=93GwwNLEBFg&feature=player_detailpage&t=1425 "It was an amazing learning experience to go through and take our entire multi-million line codebase and get it squeaky clean with code-analysis. That was an experience I wish I could just sort-of download into everybody, because I still run into alot of people that when you talk about things that are unsafe practices or things that will cause problems.. that's such a mushy nebulous term. it's not like I can count the cycles and show you why my way is better than your way. I don't know how to win arguments like that, but there is wisdom to be gained from looking at those experiences, but getting adopting across everything is still very challenging" [he then goes on to talk about an old optimization which is grafted into several places in their code which they'd like to remove because its no longer needed.] "it's the things that bite you over and over, [when code has] assumptions that are in multiple places in the system. but that's where all the really good high payoff systems optimizations are .... but they are also things that are hard to dig out of the codebase later" "accept lenient is just a bad idea ... you really want to be a hard-ass about the assets you take in. you want to say it's either it's right or it's not right. don't fix it up and let it go with a warning because nobody will look at the warnings.. we need to get to get [squeaky clean] with all of our data-assets" "robustness first, then predictability, then performance" http://www.youtube.com/watch?v=1PhArSujR_A&feature=player_detailpage&t=125 "my big software evolution over the last three years .. has been this move towards functional programming style and pure functions. it's been long enough now that I can take some valid data-points from it." [looked back at some pure-functional code that's not in use anymore, and because it's self-contained it seemed like a win] "which can be contrasted with so much other code that has assumptions and interactions and tendrils throughout the system" "I've got enough of these positive cases ... it's usually more of a pain to try and write something in this self-contained functional way, but if you are going to use the code for years, it has large advantages. i'm seeing the payoffs more and more, on a regular basis I see these wins where that's been happy and good because it's written in a pure-form, and that's been a real pain because it wasn't. because it used callbacks and tendrils and flags and settings. i'm more convinced than ever that it's been a big win. I've been applying this ... in c++ in my day-to-day writing language." "in the last year I've set out to ... get my 10,000 lines in real functional languages.. to try and get their merits in a real sense instead of in an abstract sense." ... "what I set out to do was take the original wolfenstein 3d and reimplement it in Haskell." .. "you hear Haskellers and people talk about 1/10th the side of equivalent code, and that's probably an exaggeration, but I believe some of this nicely commented and clean Haskell code can be a factor of a few smaller than the C++ code I was porting [from]" ... "Haskell is probably my functional language of choice. I'm still not completely sold on the value of laziness, but I haven't evaluated [ML] side by side, so there may be something there. " [discussion of reverence of LISP, and exploring LISP] "I think that I sort of get LISP now, and I have a working knowledge of Haskell, and I have a few conclusions coming it." [community discussions about static vs dynamic , strong vs weak typing] "where the majority of programmers are not behind static typing" "I come down really pretty firmly, and all of my experience continues to push me towards this way.. that strong static typing has really significant benefits. Sometimes it's not comfortable. Sometimes you have to build up a type-scaffolding to do something that should be really easy. But there are real strong wins to it. I see this in the code that causes us problems." "In my toy [Haskell] stuff in recent months.." [describes debugging a problem without a debugger since Haskell doesn't have what he would consider real debugger] "the only [bug] that really had me baffled for a little while was a case where proper typing would have removed [the bug]. Conversely in the LISP work, I had a bunch of cases where I was doing something that was just wrong because the types were not there." "..it's just amazing how many mistakes and how bad programmers can be, everything that is syntactically legal, that the compiler will accept, will eventually wind up in your codebase. and that's why i think that static typing is so valuable, because it cuts down what can make it past those hurdles." "...why I went Haskell, rather than some of the more approachable languages. It's the brutal purity of it. languages talk about being multi-paradigm as if it's a good thing, but multi-paradigm means you can always do the bad thing if you feel you really need to. And programmers are extremely bad at doing the time-scale integration of doing something that they really know is negative." [ then he tries to extrapolate his Haskell experience into a research idea for game development ] http://www.youtube.com/watch?v=1PhArSujR_A&feature=player_detailpage&t=1354 "[if you could] do your object from beginning to end, you look at everybody else but you can't touch anybody else..." "you could have straight line pleasant beautiful linear code, not this mess of deferred and handed off to different subsystems. you could make code that would be nice again." "that would be a really powerful thing for game development. " "my scheme was.." "do garbage collection ... garbage collection is a benefit for developers. it has a bad reputation in gaming for intermittent pauses. intermittency is bad. A fixed overhead we can deal with and it makes programming easier.." ... "you set everything up, you garbage collect every frame. It's going to take discipline to make sure none of the big things stay in the game-heap." [describes compacting collector] "The game heap if you isolate out all the constant data and all of the big meda, it's not that large. Our real mutable data is counted in megs, not tens of megs, so it's completely credible to walk it every frame.. "So, you walk through [the game data] every frame, you compact and copy, garbage collection into another frame, BUT you keep the old frame there and you memory protect it." ... "each entity keeps pointers to itself, but any pointer that it has to something else, points to the frame that was just memory protected, that was just garbage collected from." .. "under those conditions, you get garbage collection..., you get the de-threading of all these things.., you allow it to run all of these things in parallel..., and i think it could be a really big win, but it's a research project. it's not something i can sort-of roll into the current codebase. But I look at it and think it's not ridiculous that it could be migrated towards and it would have some large benefits." [going back to lisp]
_______________________________________________ bitc-dev mailing list bitc-dev@coyotos.org http://www.coyotos.org/mailman/listinfo/bitc-dev
