Jonathan Blow's speech at the UC Berkeley's Computer Science Undergraduate Association, in the same school he himself went, on April 1, 2011. the-witness.net/news/ check it out if you're interested.
I will just write notes here for my future self: - Avoid optimization (and wasting time thinking about it). You don't usually need it in most cases. - Use Arrays for everything. Data structures are about optimization. - Don't build generalized systems. They are worse than hard-coded ones. - Deleting code is better than adding code. - Prefer big top-to-bottom straightforward functions, instead of function calls
Function calls are clearer than giant functions in my opinion, they make it easier to read blocks of work, without requiring comments. They just need to be scoped, so they aren't accidentally reused or shared between different contexts...
@17:50 _"If I think somethings wrong with that they did, but what they did is kind of beyond my capability, maybe I just don't understand why they did what they did."_
This guy is solid, and has a finger on the pulse of every shiny-eyed fresh CS grad ready to build their first big new better-then-ever program... with the latest algorithmic arcana and the cleverest metal-tight optimizations... and an array of other ill-prepared habits our academia and early instincts seems to foster. He accurately and logically tears those self-destructive attitudes down in pursuit of a better paradigm he defines fairly well considering time constraints. I have seen suffering over these issues in every programming organization or group I have worked with since becoming a programmer.
@@tech6hutch because The Witness is a unique game, with unic ideas, art style, level design and puzzles. Blow's games is not a conveyor of shit as most games now
I agree with everything he's said here - All of the mistakes he mentioned exactly describe the mind-set of a new programmer. I'm in the business/ERP space but even there (where the computer science and optimisation elements are less important than functional correctness), these rules absolutely apply. These are lessons that are only learnt with experience.
+Nameguy He's talked about that before. At that time (2011-ish) the game was basically done. It was all in crappy programmer art, but the game was there. So all he had to do was hire someone to do the visuals and tweak a few things as needed. There was a point when they decided to seriously upgrade the visuals, which meant hiring more people and pushed the release date back significantly.
+Jeffery Wells I was thinking about that as he mentioned his "cost of life" metric for efficiency: another side effect of moving slow is that the state of the art keeps progressing, meaning by the time you make something perfect, it seems out-of-date. Witness has an interesting polished-but-classic quality to it for that reason, I imagine.
"I prefer it to be a thousand lines long doing one linear sequence of events. I don't want to hide that fact!" This made me laugh a lot. Blow is making an important point I think. I used to take pride in shrinking all my functions by making lots of little functions, but you have to recognize when that's unnecessary.
@@PauloConstantino167not only that. Reading a function that calls 100 other functions is hard because you have to scroll the file up and down all the time and sometimes even switch between the files to figure out what is going on. It's effectively a function call overhead multiplied by the fact that your brain doesn't run at 3,5GHz and doesn't have 16 gibs of ram.
I like a lot of this advice because I basically love contrarian advice. There is so much group / herd "thinking" and mindless adherence to certain dogmas that it is almost an ethical duty to go against some of that. That being said, most of this advice is well-known from decades back ("Premature Optimization is the root of all evil" D. Knuth) but it is worthwhile to repeat again and again. One of my faves is actually removing code or accomplishing some functionality without introducing a lot of extraneous staff (libraries, frameworks, etc), much satisfying that adding complexity for the sake of very small efficiencies (the "very marginal benefits" mentioned in the video), or sometimes for the sake of using some design pattern that ultimately changes nothing other than complicate the code. This is something that happen with what I call "junior-seniors" and is a frequent nerd temptation to all of us, including me, of course. And one of everyone's favorites: generic systems, when a "Generalized system is usually worse than a specific one", which somehow seems to be counter-intuitive. There is something deeply human in this however, the desire to feel smart, to somehow come on top of our insecurities and of our peers.
I wish people would advise others to think for themselves, instead of promoting generalizations. It's not "your mileage may vary", it's "your mileage WILL vary" (usually, hopefully)
Actually, you're misusing Knuth's quote. He was talking about low-level optimization, which is rarely done nowadays. What Jonathan is talking about is quite different.
What a refreshing talk...This is the way to program that I also have found being most effective.... It's a bit like a the commersial I once read for matlab, "if you save 2 days of programming, then it doesn't matter that the calculation takes 10 minutes longer"
I love this talk. It's interesting that the first point is about how you need to optimize your time coding and to do that you need to not waste time optimizing code. It's sort of an ironic way to make the point that human time is way more important than computer time.
30:43 _"If there is some code that is like a 1000 lines long and only does one linear sequence of events, I actually prefer to be a 1000 lines long doing one linear sequence of events."_
The readability is the key problem of generic systems, OOP and all kinds of frameworks. The more layers of generic nonsense that a system has, and the more "magic symbols" it needs the programmer to learn in order to actually understand the code, the worse it is. We are now living through a period of new frameworks popping up every month that is supposed to make your life easier, but its essentially a waste of time. Spend your time learning the core language and how to do things without a single library, that makes you a good programmer.
@@obiwanus Hello from the further, further future! Getting ready and excited for the public beta release of his language Jai while having VERY high expectations for it considering Rust going full speed converting pissed off C++ programmers on their side.
@@meanmole3212 Hello from the even further future. Still no public beta, but the language is looking very good. The future me has tried Rust and ditched it after one year, because of the friction involved and the fear that it's going to become another C++ eventually.
Huh... did not expect that The Witness only has a few thousands LOC more than Braid. While I realize that the amount of content is mostly just assets, I figured that all the complexities of dealing with a 3D environment would require many more LOC than a 2D game.
So I should be looking for CS papers that tell me how to simplify things in order to get them done faster in development. And to concentrate on using the kind of data structures which help me get things done fast and not add complexity costs down the line. Which sounds kind of like some of the agile ideas, YAGNI, etc. where you postpone optimization and other decisions for until you need them while keeping the code simple enough so that it's flexible and cheap to rewrite if necessary.
24:00 Blow is basically saying, a swiss army knife will never be as good at cutting bread as a bread knife, or as adept for uncorking a wine bottle as a corkscrew.
I think you missed the point. Also, with just a bread knife or with only a corkscrew you`re limited to opening wines or cutting bread, instead eating a half good cutted bread with a not-so-good-opened whine.
Because you can just read a big straightforward function from top to bottom. But with many small functions, you have to jump around in the code to read them, and the worst of all, you have to remember what they do.
Calls to other functions inside a function turn it into "choose your own adventure book". A straightforward function reads like a normal book. Of course nobody says you must never split a function into subfunctions. It's just that when you have one function that does one thing and no parts of it are needed anywhere else - you should probably just put some comments in there and leave it like that. You typically extract something you copy paste for 3rd-5th time in several different functions.
It's interesting to take all this talk about optimization and put it in the context of his presentation where he demonstrates how slow Photoshop is. Well what now? He says here that optimization is (often) bad but now he is pissed that it takes too long for Photoshop to open because it has not been optimized very well.
Had that same thought. However, what he advocates for is a simple code. I'm like 99% sure that photoshop isn't it. His main point is that simple actually is fast. I also like "pessimization" where your architecture choices are slow, you (should) know that and you use them extensively anyways.
23:51 research papers. Can't agree more. I'm not an idiot (I like to think) and was recently reading some graph layout papers. Indecipherable. Pseudo code v.bad. Missing chunks of information needed in order to actually get any benefit. basically, most of the time you need to do it yourself, through trial and error.
He wrote 75 000 lines in 3 years of making Braid (aside from design, marketing, QA etc.) :) The 3200 are probably a figure like the one from Mythical Man Month. As he said - the average includes a lot of "bureaucratic" roles and projects. And cases like cleaning legacy code, where you actually have a "negative" contribution to lines count.
It all depends on what you are writing. In some cases you are choked by the complexity of what you are trying to make and other times you are choked by the speed of your fingers.
This is the kind of practical knowledge and wisdom you gain when you make your game from scratch and not use Unity or Unreal. It's your choice. You want to become like him or you just want to sell game.
That's probably a bad thing, as that code needs to be run, and people need to read it. You should produce fewer lines of code (with more or less the same functionality).
1:03:00 he talks about failing certification on xbox 360 if the framerate is dropping. was it like for xbox live arcade only? cus lots of games are and were dropping frames on consoles so how does it gets certified lol pubg is literary payed for by microsoft and runs and looks and plays like shit
I would have to disagree with what Blow said at 33:10, that not admitting personal mistakes is human nature. I'd say that is prevalently cultural garbage dragged from certain tribes back in yesteryear an individual convincing the tribe about an accorded action(hunting a specific gazelle), then being wrong(choosing the fast one) and being punished(as it was the cultural habit in such tribe.) Today, western cultures unfortunately tend to demean mistakes as well, rather than create testbeds so that people can sand-box ideas into potentially great products, but risking also failure and certain level of harm. Hopefully that is changing.
I disagree on using arrays instead of other data structures. Using arrays is an optimization(memory). So if you don't care about any optimization a use a linked list or something which has more memory usage etc.
Ok but he's not saying don't optimize, he's saying optimize for years of life required, first. And in his case, because of how he thinks, using arrays broadly is an optimization towards that end and is therefore beneficial.
But most of the stuff he says about optimizations is true. " optimize code is harder to read , harder to maintain .... has more assumptions". In the same vain arrays make assumptions about the data type, number of elements. On the other hand a Python List( because I can't think of one in C++) doesn't make those assumptions. You can just use it without first finding about the number of elements. You can reuse it easily. It's easy to change.
Ah yea I get what you're saying I suppose. Still I don't think he's suggesting that we do that, only saying thats his system. He probably has a mental/library work around for those problems. Arrays do have some issues, but for many the performance benefits far out weigh those negatives.
No doubt this is more important in games where generally you code around a minimum memory requirement. So there is no need for lists and growing heaps, due to the fact that you know what the maximum length an array should become, and you need to be sure there is in fact memory to allocate this array before actually starting it. Imagine playing a game halfway through and then allocation fails and the game crashes and dies. Accessing an array is also very fast and easy so the code generally is very readable and easy to debug. In JIT type languages a lot of the performance is lost due to a garbage collection going crazy from having to collect all kinds of objects, so if you know how the maximum number of objects you need of a type before hand and just pre-allocate the memory, your code will run way faster and the GC can go to sleep.
I wonder, if he wants to optimize years of his life per program implementation, why he started on Jai? Isn't this new language of his (an attempt at optimizing C++) taking him too much time already and will take even more than it has already taken? He could probably write a game or two in this timeframe, or just enjoy life, not write anything for a while (there's plenty of other things to do without getting bored). IDK, Jai just sounds like a contradiction to me to what he is saying here. I have to say, I've done a lot of native and web development, just not C++, don't know how bad it is, so maybe I'm wrong and Jonathan will have more life left and games written after having finished Jai, but I'm skeptical.
No doubt making a language that better than C/C++ must also be a fun project on its own. The fact that he is also using it for the next game he is developing, makes it all the better - not only does he make a game, but also the language he wants to write it in.
Actually, he said quality of life was one of his core reasons for making Jai. He gets to spend the rest of his life not stressing over the things in C++ that make him want to tear his hair out. He said when he first got Jai working to a point he could actually use and play with it, he basically breathed a sigh of relief and decided he would never use C++ again for any game after the Witness shipped. Indeed, in his mission statement for Jai, he said that "the joy of programming" was a critical concern in the design of the language.
You don't consider that he may wants to improve the productivity of other game developers in general, so a more altruistic angle, by sacrificing his own time
@4:40 Was Jonathan Blow really this stupid back in 2011? Is he still? Any programmer who is tasked with writing an entire green tech project is going to write tens to hundreds of thousands of lines of code in a year. That doesn't mean you're "more productive", it just means you're doing a different kind of production: green tech. Green tech is when you spew out thousands of lines of shitty code that everyone else gets to maintain in the years to come. The reason the industry average is ~3000 is because people don't work on green tech: they spend most of their time maintaining mature software products, where your time is spent deleting bad code and replacing it with shorter, more concise and more maintainable code (a net negative in "lines written"), or investigating bugs in mature products where you can spend 90% of the time figuring out what is going wrong and end up simply editing a few lines (no new lines written) to fix it.
@@chyza2012 I finished the entire engine in under a week. I got bored with making the story and doing game design so I went and worked on something else.
@@yellow6297 Denial like this is where your data intellectually goes very off. You are not able to make braid in 22 12 hour days in no reality, because it will in no reality take just 22 12 hour days due to the hundreds of things you have no experience and discipline to overcome.
