When I'm bouncing ideas with a coworker, after a long unfruitful conversation he'd often propose "here's a dumb idea", and I would reply "that's perfect, and exactly what we're going to do".
To me personally simplicity comes from data oriented design. I usually figure out the minimal amount of data that represents my problem, then I imagine the necessary transformations that data has to go through towards the solution. While coding I try to design functionality from both the "perspective" of the current data as well as my "top-down" requirements. I don't really think about programming patterns then or anything like that, because every problem is different. Programming patterns to me are like music theory is to music, a tool to analyze or describe what code does, but not really a tool to create new code. If you focus on them too much, it creates a temptation to create unnecessary complexity within your solution. ECS is one of those patterns, there are very few game genres (or systems within games), in which that kind of scalability (and interdependance of a large group of entitites) is actually needed. I think that might have to do with our human perception, which cannot precisely keep track of that many things anyways (It can feel more like merely a visual effect). Tree or graph based algorithms might be more suited to create something meaningful to our perception and at which point the at least the cache friendliness of ECS would fall apart.
Can you elaborate on this? As someone who's gotten comfortable with OOP and ECS frameworks, while I'm open to the idea that these things are unnecessary, it's hard to switch over to something else as I don't see many examples of alternatives.
@@11sveden12 I would not buy in too heavily into either the comment that the above person or what mr. blow said. Their opinions are dictated by their context. Much of Blow's opinions are shaped by the small size of his projects and the smaller size of the teams he works on and the length of time he spends on his projects. (edit: also staff turnover) If I were you the most important take away from this video is to solve your tangible problems rather then building a piece of technology that also solves the problem.
Thinking of problems as a series of data transformations really has benfitted me greatly too. It's so much more composable since data is just data and transformation can be isolated, ommitted, repeated etc. It makes it easier to reason about, easier to reproduce and test, easier to extend and maintain.
@@rafethearchitect A fair point, but I guess my point is that without any concrete examples to look at, experiment with, or translate to, it's difficult to get a feel for which tool is the right one for a particular problem.
@@11sveden12 there is nothing wrong with OOP or ECS frameworks. I just wanted to describe, how starting from the problem in a data oriented view helps you figure out how much of these two you might use in the actual code/how you would mix them. Something like a general purpose ECS like Jonathan mentioned in the clip or starting with a specific programming pattern in mind, before analyzing the problem, will usually lead to a more complicated solution, that is harder to expand or refactor. Like one would not use deep neural net machine learning for problems that are 100% solved with simple mathematical models already, etc.
Man I’ve stumbled upon Jons videos and Prime reactions to Jon from time to time but it’s the first time I hear that he made The Witness and it’s definitely in my top 5 puzzle games. Damn.
Really? I heard his name back in ZP review of Braid where the joke was "Jonathan Blow? More like Jonathan Suck!" Then I just assumed that Braid dev's name is well known.
I think the problem is simplicity in programming is not how we humans think about it. we think imperatively do this then search here and do this here and this here, meanwhile math is usually a reductionist exercise. Sometimes an algorithm can be reduced to a mathematical expression, its simpler, but how do you get to simpler? It takes years, decades, even hundreds of years on some solutions. Freakonomics made a podcast on richard feynman, they gave an anecdote of him working with a coworker, they were doing a competition, the resulting paper was 50 from the other guy, while richard had solved it on the first day, and spent the last 2 months simplfying the paper to 2 pages. Je n'ai fait celle-ci plus longue que parce que je n'ai pas eu le loisir de la faire plus courte. I made this one [letter] longer only because I have not had the leisure to make it shorter. Provincial Letters: Letter XVI (4 December 1656) -- Blaise Pascal
Einstein said “Make things as simple as possible, but no simpler” which I think is spot on. If you look at a problem at a specific level of abstraction, it should be as simple as possible, and when you go up or down a level the problem changes, but the goal is the same: as simple as possible, but no simpler
Easy to say. Hard to achieve. How can you know when it's as simple as it can be without iterating over the problem domain. Now you've introduced the optimal stopping problem into you process. Probably in software if the code works, meets performance and other behavioral expectations then you're done, whether or not the solution is "simple." The concept of "simple" isn't simple either. Check Rich Hickey's talk called something like "keep it simple"
@@mesaber86 no. Look up the word abstraction, it’s a way of looking at things at different levels of complexity. Imagine it like a ladder you can walk up and down: at some levels you might have everything figured out as simple as they can be, but if you move up or down it might be more complex than it has to be.
Reminds me of what some computer science articles back from the 1960s and 1970s said... the question of what's the point of trying to solve problems with tools that themselves are more complicated than the problem itself and which in fact become the greater problem while trying to do that. Many programming languages and frameworks being prime examples of that. I'm also thinking of Robert Martin's talk about how web frameworks force web developers to write their code on the terms of the framework with most of the names in the system then ending up reflecting the framework instead of talking about the actual problem being solved.
I feel similarly about this deep learning hype right. I love deep learning, it's my passion and main focus in research. But people just want to get attached to this system of ideas because others have convinced them they are cool and effective rather than arriving at a deep learning method as the appropriate solution to a problem.
Saw a funny video where a person tries to teach a ML program how to add 2 numbers together. And some 500 data points later the program does it with 99.5% accuracy.
The even larger problem when it comes to simplicity is that there isn't even a widespread understanding of what differentiates simplicity from ease of use. People see giant bloated messes of software (e.g. Visual Studio, Web-UI for desktop-apps) and think to themselves how great it is because it is easy. They may even call it simple because to them those two words mean the same thing to them when they are vastly different things. And then they mistakenly tolerate all restrictions, annoyances, bugs and peformance hits that result from that needless complexity. A while ago I made a concious effort to simplify my workflow and the tools that I use and it's been a giant boon for my productivity and piece of mind. It is so much more rewarding and powerful and often easier to add functionality that is missing than remove/configure functionality that was already present.
I'm new to programming, somehow stumbled on this channel and everything you say is incredibly useful. I saw you on the Indie Game movie years ago and it's cool to get a deeper insight into how you think. I don't want to be the kind of programmer that spend years making simple web pages, would be cool to reach a level of mastery one day (used to be an artist). Anyways appreciate the content, subscribed.
When I find a useful library that does something that is relevant to what I am doing but has too many or too few features I often copy it into my project and remove the stuff I don't need if that is quicker than writing it myself. The ownership is also important, if it is some code that will be responsible for any kind of core functionality in the program I don't want it to be an external dependency because that limits which changes I can make to it quick and easy. For the same reason I typically avoid integrating any third party library into any of the core flows of my code if I am not prepared to fork and maintain my own version of that library if I need to at any point.
Same bro, that's the rational thing to do, but people are afraid of doing that, because by copy pasting the code, you are now responsible for it, and people are pussies lol, they don't want to have responsibility
I would argue that the idea spread of microservices rather than the real idea. The real idea sounds good but hard to impl in most companies. Probably 98% of them
Microservices actually often solves every about every problem where software architecture design choice affect, except for performance may suffer of overhead caused by that when services are distributed. So it is not always good architecture choice. NoSQL type of databases usually helps for scaling databases horizontally and focusing availability, so they are solving real problems.
I'd argue there is selection pressure in software, but it's actually *toward* increasing complexity. There is pressure to get shit out the door as fast and as minimally correct as you can. If the code makes money in the immediate term it's the right code. This naturally coincides with increased complexity, since it takes time and effort to make things simple, and that time could be spent making more code that makes more immediate-term money. TBC it's not just that: it's also that a lot of developers are bored and don't take what they're doing seriously, and so tend to get drawn to "fun" solutions, where they play dress up that they are at google solving google-scale problems, leading to a tendency to over complicate solutions as a form of entertainment.
I have multiple Playlists, for game dev and more for physics / science / philosophy related stuff. I wondered where I put this video in. It would be in the "coding" playlist, then on the other hand in the "game dev insights" playlist, but also it's philosophical about coding so it should be in that playlist? Instead of creating a new "coding philosophy" playlist, I just put it in the different playlists that already exit for simplicity's sake.
A lot of words were spoken and written about simplicity in programming, but the only talk that actually gives any actionable definition of simplicity is "Simple made easy" by Rich Hickey. Another good thing about that talk and Clojure in general is that it shows how "more simplifying" (in Rich's sense) is not always a good thing.
Uh.. Redux is simple solution to managing global state. I used that everywhere before React got reducer, so I can use same pattern with less dependencies.
As I watch I sit here shaking my head like “yeah right exactly” and I’m one of the biggest offenders in what he discusses in most of these type of talks 😂
It's an interesting one. I've been using Unity's ECS and DOTS paradigms for the past year. Largely because I felt I needed to for the kind of game I'm making - hundreds of thousands of active entities, all persistent in an open world, and I don't want to try building my own engines again (been there, done that, failed due to inexperience). It's pretty performance intensive stuff. And ECS/DOTS have helped made it achievable, at least in comparison to the prior GameObject paradigm. But sometimes I wonder, if I just opened a new C++ project and made the game's actors flat objects, no components, no fancy systems... could I not get 90% of the same performance, with half the complexity?
I've had very similar experiences. Years ago I even wrote my own ECS system and it was an interesting exercise in learning how to do things a different way. An ECS system does have some clear performance benefits if performance is the actual problem you're trying to solve. If not it's probably just making your life harder. But at the end of the day if your goal is to make an actual game I agree with Blow that you should just do the simplest thing that actually solves the problem. For me right now even though I have experience building game engines from scratch, nowadays I just use Unity. And even within Unity there's a time and a place for ECS/DOTS. For example, cloth, hair and fluid simulation. My experience building game engines from scratch still helps though. I have a better understanding of what's actually going on under the hood and it makes it easier to make these decisions. Sometimes I feel regret wasting so much time building my own game engines but then I remember it really did make me a better programmer overall so in that sense it's not really wasted time.
You can definitely get far with a dumb/raw version of Unity's DOTS ECS. Just have static lists/dictionaries with data, then functions that iterate through them. An event is a list is cleared at the end of every frame.
Working as a programmer is like running in an infinite tunnel and you can see only a single point of light at end , you can run towards the light but you never know when you'll reach the end.
I agree that programming culture is broken. I often feel like the crazy person in the room because I'm advocating for simplicity and everyone looks at me like, "Why?"
If not much is going to happen on the screen it’d be better to get a different screen where the camera is larger. On mobile this video is terrible but the audio is great.
For me, simplicity in programming means, pretty much, S.O.L.I.D. Small pieces of code, each concerned with single responsibility, doing one job in the simplest way then feeding the result to another simple piece of code. Minimal dependencies / coupling. Easy to unit test. Minimal state. If it can be divided into smaller isolated pieces, it almost always should.
I really like programming in C because its simple and just solves the problem. You need to type more code then in C++ or Python. But i know what my code is doing and im not dependent of external frameworks or tools, other then memcpy(), memcmp(), memmove()... If i work in C im directly working on the problem and not looking at the docs of some framework. Sorry, i work as a Magento dev and i really like C programming😅
C is great but it has it's flaws. If c was const by default, if it had a distinction between pointer to a single object and pointer to an array of objects with an additional length field, and the pointers were not nullable by default it would be almost a perfect language. There are also some quality of life features c is missing. I like zig for those reason. I think it is a promising language which aims to be like c, but with better defaults.
Is it really simple when you have to dodge footguns for the simplest of tasks? Idk I think people just call the thing that they know really well "simple" because to them it is. That's fine but it's not really a useful category by itself but just another way of saying "if you do what you are competent at then it usually works out".
I like when C segfaults and takes a massive core dump on me, it really enhances the experience and brings me joy. In all seriousness, we should move on, it’s been like 50 years, John.
@@maksymiliank5135arrays are a pain in C, yes. Also the east const west const, IMHO. Ffs just make it either const int const *a or int const *const a, not some weird mix.
@@cas1652 I'm learning in my free time and so far C was the language I made the most progress in. Made it all the way to a moving spinning cube with opengl. Making custom math types is ugly tho. C++'s operator overloading is a great feature for vectors and matrices.
He speaks well and his perspective is appealing to me, however i still don't understand how he wants software to be written. You can't just "write the game", i imagine you need a framework (framework as in some minor dogmatic paradigm such as ECS) to write in, and it can be any kind of framework. It can be a custom one that you winged just to match your requirements, but you do need a framework. What do you think? I genuinely have a hard to time understanding what kind of simplicity he is after, and how you can make something "simple" without spaghetti code
He's basically just saying to put more emphasis on justifying the tools/frameworks you're using and not to be tricked by READMEs/blogs/articles/videos. Ask yourself if it's actually solving YOUR problem or if it's just very good at making you THINK it is. You'll be adding complexity if it fooled you. I spent ages refactoring some old C++ code by modernizing it. The code was a lot more readable and even more performant after lots of measuring. What was my original problem? Actually just build the damn program and get it working properly. Did refactoring the code help me solve that problem? No. It was still not working properly but now it was just not working properly a little faster. I wasted my time and actually made it more complex for I found debugging the modernized version was hiding things behind a lot of clean and 'simple' abstractions, whereas the old version was far more explicit about what it was actually doing and easier to step through. The old version in my case is probably something Jon would consider more 'simple', even though it looked messy.
You really don't need any framework of any kind: Put the rules of the games on paper, what the player can do, what are the effects that should trigger, what the "world simulation" does, and implement that any way you want in any language you want: Could just be a giant "while" loop full of "if" in a single "main" function, could be made with objects and methods, could be done using some finite state machine, could be done "functional style" where you return the next status of the "game world" based on the previous state and the inputs from the player. Basically: Make it work as simple as you can, no abstraction, no design, just use globals, locals, whatever you feel comfortable with to understand how to solve the problem, then after a while you will see patterns, refactor things so they work better together, etc... at that point you basically have a game engine, made for this one specific game, but that's a start. There's nothing wrong with spaghetti code if it works, and if it works you can still detangle things and sort the spaghetis by size, color or taste :D
@@amber1862 thank you for clarifying and for the nice story. I think you explained it simply and well. I imagine this is what he is really talking about
@@DbugII thank you for your elaborate response, it's interesting to see that your response is different than that of the other person that responded to me. I disagree with you, I don't think it's a good idea to just write spaghetti code. It becomes unmaintainable very quickly, and you do want to add more features. I imagine spaghetti code is much harder to debug than some kind of minor framework that you made yourself to fit the requirements, considering the fact that you also wrote it yourself so you also know the framework/engine very well
I misspoke: What I mean is that it's not important to respect any structure while you are exploring: Copy-paste, add globals, whatever, until you get something that work. At that point, now that you have something that work, you can see how to move things around in a way that makes sense. The tldr is that you can't structure something properly until you know how it's supposed to work in first place. Think in term of "throw away prototype": There's no point wasting time in trying to design something properly until you actually have identified all the important parts of the problem, and it's much easier to modify/improve something with loose couplings than something structurally advanced.
Every technology / form factor carries real trade-offs. ECS's tradeoffs are significant, but often too subtle for people to see until it's too late and they're overcommitted. Choosing the right system / approach for your project is about choosing the right trade-offs for it. But if there's no comprehensively informed / honest discussion of trade-offs, you can't take any of it at face value. I get a little tired watching people spring the ECS trap on junior programmers by hiding the truth about its trade-offs or not even themselves knowing what they are. It's a problem because people end up wasting YEARS because someone wants to sell them on something they don't really understand very well themselves in the wider context of shipping real products. Meme-oriented programming is a problem, and I'm tired of pretending it isn't. This is the perspective of people who ship real commercial game software, not just tech demos and toy projects.
Did he start writing a programming language to make a game or did he make a game to test the needs of his programming language. From what I've seen the answer is the latter one.
Science used to be defined, before modern age, as a body of knowledge about entities, causes and effects. Understanding was defined as the ability to classify these entities, causes and effects. Wisdom was defined as the ability to apply understanding to achieve a valuable end. Computer science is not a science because it creates its own entities as it goes. It's more like a body of abstractions. Math on the other hand is a science, because it discovers its rules and entities. Also, it could be said that math is about things, computer science is about actions done to abstractions, and therefore it is as much a science by nature as "the science of taking a walk" or "the science of playing tennis". Greater complexity does not change the nature of a thing.
The part about social decisions in a corporate context is painfully true. I've had to ignore basic technical facts just to support some whiteboard architect's favorite pet idea because there was no convincing them otherwise. It's gross.
I think what our friend Jonathan here misses is people learn software for the money, not for the craft. The real issue is our institutions (both Academia and Industry) fail to gatekeep incompetent people. This is what #learn2code for a decade does.
Jon comes from a background where you write once and don't need to maintain it for decades. Web companies are the opposite of that. With maintenance comes the burden of tech debt and constant stream of reqiests from clients and other teams. You simply cannot fo that in a week in basic because the requirements just keep coming.
Entity Component Systems aren't just a way to organize your entities though, Proper ECS implementations have components laid out in memory together, such that you can take advantage of CPU cache; in games with tens of thousands of entities this is a huge performance benefit
@@PaddyLamont where does he address this exact point? I was going to bring out my pitchfork too, but actually Jon seems to have a warped idea of what an ECS. 1) Said "entities is just calling some functions that do some code that's been the same since like 1950" ... really? I'm not completely entrenched in this topic but that doesn't sounds right at all 2) He didn't read the thing he mentioned @7:20 but then makes a bunch of claims about it ECS 3) It seems like he thinks an entity is just an object... I find it hard he could make that mistake but by the way he's talking about them it really seems that way
I'm pretty confident Jon knows all about ECS, to the point where he used it as an example of a complex system that might not fit the particular use case of an indie game developer making a game. The whole point is that complex systems may solve many problems as advertised, but you should strive to solve the real and specific problem that's right in front of you, instead of relying on complexity that speculatively may solve a problem you don't have.
I agree with you here. I am in no position to critique Jon. But I do see a conversation in web dev that I wonder if it’s similar. Some people will bristle at using web frameworks because they are too complicated. But in my opinion frameworks (like Laravel and rails) compress complexity by solving important problems. The alternative is to solve all those problems from scratch. I do think Jon had a good point that if a tool is dictating how you write your code and it’s not even solving your main problem then that’s bad.
I work in enterprise... and all of this is painful to hear, because it's true. Aspect driven development and other crap in jvm based langs is a bloat and there is hate in my bald head
Well known game developer who made Braid and The Witness. Currently working on a new programming language, jai, which he's using to work on his new upcoming game, among other projects. He streams working on both the game and the language a lot, and he's fairly critical and outspoken about his views, so that's why there's so much footage of him out there. A lot of the stuff clipped tends to be the just the spicy takes, but there's great game design and programming recordings too.
You may have clicked a single video about him and now are in the "JBlow CZcams bubble" To get out, go to your YT History and search for "JBlow" and/or "Jonathan Blow" and remove any and all watched videos. Once they are removed from your view history you're more likely to not be recommended the same kind of videos :) Also works for any and all grifters that just produce shitty clickbait, etc.
"Simply solving the problem" is fine in a world of 1 person writing the OS to the GUI, but when working with other devs and eventual customers with different problems and desired solutions most stuff becomes a strange comprise. I do think people should really measure instead of premature optimizing.
As someone who works in consulting, this just sounds like a marketing trick more than anything, to me. They let you get more done by less experienced developers in the short term, which saves you money and produces some basic deliverables early, but in the long term it's a financially ruinous decision. Half my projects are coming in and fixing the seemingly endless problems caused by cheap teams of poor developers using one software package or another designed to give you workable abstractions and make development more accessible. There are still times when this is useful (and there would be more of those times if clients were less strict about implementing every little 'essential' requirement) but it seems to me like premature optimisations primarily exist as a way to convince yourself or a client that you're doing more work, when in reality you're just offloading work to some future developer (or worse, developing software that will never get shipped).
The 'premature optimization' is so overused I drives me nuts. If a senior developers writes better code then a junior one, did he 'prematurely optimized' it? If I decide to write a program in Go rather then javascript, did I 'prematurely optimized' it? If I just write good and efficient code (because I have internalized how computers really work and it just comes naturally to me), did I prematurely optimized it? But I agree with you on one thing: the more you have to interact with rest of the world, the harder it is to keeping it simple. Which isn't to say it's impossible, but the scenario of writing an engine from scratch and not having to deal with others people existing projects, does sound at least slightly idealistic
@@xeamek99 when I say premature optimize I mean "you aren't going to need it" messy class hierarchy and design patterns to just submit a simple webform to the db. Meanwhile random business people have "requirements" to customize every little thing in some menu no customer ever asked for. I'm not talking about just choosing a bad algorithm or language. If you are a business with 10 javascript devs and 1 go dev. They will not choose to train everyone in go. There's silly inertia to "what is popular" and also silly rewrites into "what is new" where no one measured if it solved a real problem.
@@DevanConrad Premature Generalisation is the term you want to use here. As for the business people requirements - those tend to disappear very quickly when you can point out that you can complete the "80%" solution in 20% of the time. The issue at the moment is that the Pareto principle isn't visible, because although they're only implemented 20% of the feature requests, which should cover 80% of the usecases, they're not actually doing 20% of the work. Why? Because their 'generic', future-coding approach is trying to build a solution not just to cover the 20% features committed to, or even the remaining 80% that the buisness people would also like, but also all the other possible things the developers predict the business users might want in future! So they usually end up doing 200% of the work! Except, to make it even more depressing - it isn't 200% of the work. It's 20,000% of the work. 99% of business software developed by teams can be done by a single developer if they'd just focus on solving the actual problem that needed solving.
Easy for a guy that works on one product every 10 years to say programmers at big companies create overly conplex software. I work on a team that os responisble for shipping software that generates billiones in quarterly revenue globally. The problem space and requirements are extremely complex from the start. There is no amount of wishful thinking or ideology that is going to make the complexity go away. It would take multiple trillions dollars to fix that, or entirely new base of technoloy to build upon. The best thing that can be done is to manage complexity. Make the software as simple as possible but not any simpler. Thats where the real challenge is. Usually in my space (packaging and release) its cross cutting configuration.
Why not just make a good fun game that people love to play? Whats all this "change the world" stuff? The world is as it is and wont change from a computer game... Lol Ego blown out or what?
This has nothing to do with a game. But with promoting a mindset where people actually try to do a good job, instead of mindlessly following the flow. It's fucking miserable when you're surrounded by people who act like this is all how it's supposed to be. It's like for someone who's lived their whole life in a self-sufficient village to move to a city, it's just depressing as shit, going from something wholesome to a place where there's no honesty and nothing makes sense.
Yeah, unfortunately he is 150/100 on ego, it is easy to observe that on how he talks and laughs on some stuff. Classic dunning-kruger effect, know a thing or two in a field, thinks he knows every other field.
If you take simplicity to it's extremes you have to remove ABSTRACTION LAYERS as they add complexity by adding redirection and they obfuscate things. No libraries, no functions even. Just start typing at the top until the end. John is a smart hard working programmer, but he doesn't seem to have an idea about software architecture or even structure outside of what fits into cache. This really makes me wonder about the ergonomics of his JAI programming language. Either it has everything build in like Python or only basic functionality.
I think that ECS and game's success are orthogonal. I'm sure there are lots of successful games that have doors as characters or characters moving their mouth to play sounds that are supposed to come from a terminal on the wall because of some horrible class hierarchy that doesn't allow non-npcs to be animated or produce sound or something like that.
He doesn't practice what he preaches here though. He writes his own engines for his games, but there really isn't a functional need for reinventing the wheel like that for his type of games. Could have saved a lot of time and money using Unity or Unreal. His current game and engine he has been complaining how his budget is over 20 million, how devs aren't coding right in his engine. Huh wonder why. Feel bad for anyone working under someone like this.
As a programmer you get paid far too much, a lot of what you do can be simplified and/or automated and I look forward to the day you lose your priest caste status
"An idiot admires complexity, a genius admires simplicity"
Terry Devis 💯🫡🔥
When I'm bouncing ideas with a coworker, after a long unfruitful conversation he'd often propose "here's a dumb idea", and I would reply "that's perfect, and exactly what we're going to do".
To me personally simplicity comes from data oriented design. I usually figure out the minimal amount of data that represents my problem, then I imagine the necessary transformations that data has to go through towards the solution. While coding I try to design functionality from both the "perspective" of the current data as well as my "top-down" requirements. I don't really think about programming patterns then or anything like that, because every problem is different. Programming patterns to me are like music theory is to music, a tool to analyze or describe what code does, but not really a tool to create new code. If you focus on them too much, it creates a temptation to create unnecessary complexity within your solution. ECS is one of those patterns, there are very few game genres (or systems within games), in which that kind of scalability (and interdependance of a large group of entitites) is actually needed. I think that might have to do with our human perception, which cannot precisely keep track of that many things anyways (It can feel more like merely a visual effect). Tree or graph based algorithms might be more suited to create something meaningful to our perception and at which point the at least the cache friendliness of ECS would fall apart.
Can you elaborate on this? As someone who's gotten comfortable with OOP and ECS frameworks, while I'm open to the idea that these things are unnecessary, it's hard to switch over to something else as I don't see many examples of alternatives.
@@11sveden12 I would not buy in too heavily into either the comment that the above person or what mr. blow said. Their opinions are dictated by their context. Much of Blow's opinions are shaped by the small size of his projects and the smaller size of the teams he works on and the length of time he spends on his projects.
(edit: also staff turnover)
If I were you the most important take away from this video is to solve your tangible problems rather then building a piece of technology that also solves the problem.
Thinking of problems as a series of data transformations really has benfitted me greatly too.
It's so much more composable since data is just data and transformation can be isolated, ommitted, repeated etc.
It makes it easier to reason about, easier to reproduce and test, easier to extend and maintain.
@@rafethearchitect A fair point, but I guess my point is that without any concrete examples to look at, experiment with, or translate to, it's difficult to get a feel for which tool is the right one for a particular problem.
@@11sveden12 there is nothing wrong with OOP or ECS frameworks. I just wanted to describe, how starting from the problem in a data oriented view helps you figure out how much of these two you might use in the actual code/how you would mix them. Something like a general purpose ECS like Jonathan mentioned in the clip or starting with a specific programming pattern in mind, before analyzing the problem, will usually lead to a more complicated solution, that is harder to expand or refactor. Like one would not use deep neural net machine learning for problems that are 100% solved with simple mathematical models already, etc.
Man I’ve stumbled upon Jons videos and Prime reactions to Jon from time to time but it’s the first time I hear that he made The Witness and it’s definitely in my top 5 puzzle games. Damn.
Which are the other 4? :D
Really? I heard his name back in ZP review of Braid where the joke was "Jonathan Blow? More like Jonathan Suck!"
Then I just assumed that Braid dev's name is well known.
"Jonathan Blow on Simplicity"
> 16 minutes
lmao
I think the problem is simplicity in programming is not how we humans think about it. we think imperatively do this then search here and do this here and this here, meanwhile math is usually a reductionist exercise. Sometimes an algorithm can be reduced to a mathematical expression, its simpler, but how do you get to simpler? It takes years, decades, even hundreds of years on some solutions.
Freakonomics made a podcast on richard feynman, they gave an anecdote of him working with a coworker, they were doing a competition, the resulting paper was 50 from the other guy, while richard had solved it on the first day, and spent the last 2 months simplfying the paper to 2 pages.
Je n'ai fait celle-ci plus longue que parce que je n'ai pas eu le loisir de la faire plus courte.
I made this one [letter] longer only because I have not had the leisure to make it shorter.
Provincial Letters: Letter XVI (4 December 1656) -- Blaise Pascal
Einstein said “Make things as simple as possible, but no simpler” which I think is spot on. If you look at a problem at a specific level of abstraction, it should be as simple as possible, and when you go up or down a level the problem changes, but the goal is the same: as simple as possible, but no simpler
Easy to say. Hard to achieve. How can you know when it's as simple as it can be without iterating over the problem domain. Now you've introduced the optimal stopping problem into you process. Probably in software if the code works, meets performance and other behavioral expectations then you're done, whether or not the solution is "simple." The concept of "simple" isn't simple either. Check Rich Hickey's talk called something like "keep it simple"
Doesnt that contradict itself. If there is something simpler you havent achieved as simple as possible.
@@mesaber86 no. Look up the word abstraction, it’s a way of looking at things at different levels of complexity. Imagine it like a ladder you can walk up and down: at some levels you might have everything figured out as simple as they can be, but if you move up or down it might be more complex than it has to be.
> level of abstraction
Alfred Korzybski wants to speak with you. Future student.
@@rabbitcreative he seems like an interesting character. He would’ve made a good computer scientist
i watch this at least once per week, thanks
Reminds me of what some computer science articles back from the 1960s and 1970s said... the question of what's the point of trying to solve problems with tools that themselves are more complicated than the problem itself and which in fact become the greater problem while trying to do that. Many programming languages and frameworks being prime examples of that. I'm also thinking of Robert Martin's talk about how web frameworks force web developers to write their code on the terms of the framework with most of the names in the system then ending up reflecting the framework instead of talking about the actual problem being solved.
I feel similarly about this deep learning hype right. I love deep learning, it's my passion and main focus in research. But people just want to get attached to this system of ideas because others have convinced them they are cool and effective rather than arriving at a deep learning method as the appropriate solution to a problem.
Saw a funny video where a person tries to teach a ML program how to add 2 numbers together. And some 500 data points later the program does it with 99.5% accuracy.
The even larger problem when it comes to simplicity is that there isn't even a widespread understanding of what differentiates simplicity from ease of use.
People see giant bloated messes of software (e.g. Visual Studio, Web-UI for desktop-apps) and think to themselves how great it is because it is easy. They may even call it simple because to them those two words mean the same thing to them when they are vastly different things. And then they mistakenly tolerate all restrictions, annoyances, bugs and peformance hits that result from that needless complexity.
A while ago I made a concious effort to simplify my workflow and the tools that I use and it's been a giant boon for my productivity and piece of mind.
It is so much more rewarding and powerful and often easier to add functionality that is missing than remove/configure functionality that was already present.
I'm new to programming, somehow stumbled on this channel and everything you say is incredibly useful. I saw you on the Indie Game movie years ago and it's cool to get a deeper insight into how you think. I don't want to be the kind of programmer that spend years making simple web pages, would be cool to reach a level of mastery one day (used to be an artist).
Anyways appreciate the content, subscribed.
When I find a useful library that does something that is relevant to what I am doing but has too many or too few features I often copy it into my project and remove the stuff I don't need if that is quicker than writing it myself.
The ownership is also important, if it is some code that will be responsible for any kind of core functionality in the program I don't want it to be an external dependency because that limits which changes I can make to it quick and easy.
For the same reason I typically avoid integrating any third party library into any of the core flows of my code if I am not prepared to fork and maintain my own version of that library if I need to at any point.
Same bro, that's the rational thing to do, but people are afraid of doing that, because by copy pasting the code, you are now responsible for it, and people are pussies lol, they don't want to have responsibility
Microservices and NoSQL are the perfect examples of overcomplicating things without solving the actual problem.
I would argue that the idea spread of microservices rather than the real idea. The real idea sounds good but hard to impl in most companies. Probably 98% of them
Because people don't understand that they should use a microservice to solve a problem, instead, use a microservice to manage a single table.
Microservices actually often solves every about every problem where software architecture design choice affect, except for performance may suffer of overhead caused by that when services are distributed. So it is not always good architecture choice.
NoSQL type of databases usually helps for scaling databases horizontally and focusing availability, so they are solving real problems.
Solution in search of a problem
I'd argue there is selection pressure in software, but it's actually *toward* increasing complexity. There is pressure to get shit out the door as fast and as minimally correct as you can. If the code makes money in the immediate term it's the right code. This naturally coincides with increased complexity, since it takes time and effort to make things simple, and that time could be spent making more code that makes more immediate-term money.
TBC it's not just that: it's also that a lot of developers are bored and don't take what they're doing seriously, and so tend to get drawn to "fun" solutions, where they play dress up that they are at google solving google-scale problems, leading to a tendency to over complicate solutions as a form of entertainment.
I have multiple Playlists, for game dev and more for physics / science / philosophy related stuff. I wondered where I put this video in. It would be in the "coding" playlist, then on the other hand in the "game dev insights" playlist, but also it's philosophical about coding so it should be in that playlist? Instead of creating a new "coding philosophy" playlist, I just put it in the different playlists that already exit for simplicity's sake.
A lot of words were spoken and written about simplicity in programming, but the only talk that actually gives any actionable definition of simplicity is "Simple made easy" by Rich Hickey. Another good thing about that talk and Clojure in general is that it shows how "more simplifying" (in Rich's sense) is not always a good thing.
Amen
Redux for me was one of those 'simple' solutions that are actually way more complicated than dealing with the problem it claims to solve.
true for all frameworks
Uh.. Redux is simple solution to managing global state. I used that everywhere before React got reducer, so I can use same pattern with less dependencies.
I agree with a lot of what he says and I love this kind of discussion, even if I think of some buts and ifs, his voice is really needed today.
As I watch I sit here shaking my head like “yeah right exactly” and I’m one of the biggest offenders in what he discusses in most of these type of talks 😂
Everyone got opinions till things start breaking
You dont think things are broken now?
Good take. I agree
12:00 that understanding was probably more interesting then the all the opinion about coding
It's an interesting one. I've been using Unity's ECS and DOTS paradigms for the past year. Largely because I felt I needed to for the kind of game I'm making - hundreds of thousands of active entities, all persistent in an open world, and I don't want to try building my own engines again (been there, done that, failed due to inexperience). It's pretty performance intensive stuff. And ECS/DOTS have helped made it achievable, at least in comparison to the prior GameObject paradigm. But sometimes I wonder, if I just opened a new C++ project and made the game's actors flat objects, no components, no fancy systems... could I not get 90% of the same performance, with half the complexity?
Probably…
I've had very similar experiences. Years ago I even wrote my own ECS system and it was an interesting exercise in learning how to do things a different way. An ECS system does have some clear performance benefits if performance is the actual problem you're trying to solve. If not it's probably just making your life harder.
But at the end of the day if your goal is to make an actual game I agree with Blow that you should just do the simplest thing that actually solves the problem. For me right now even though I have experience building game engines from scratch, nowadays I just use Unity. And even within Unity there's a time and a place for ECS/DOTS. For example, cloth, hair and fluid simulation.
My experience building game engines from scratch still helps though. I have a better understanding of what's actually going on under the hood and it makes it easier to make these decisions. Sometimes I feel regret wasting so much time building my own game engines but then I remember it really did make me a better programmer overall so in that sense it's not really wasted time.
You can definitely get far with a dumb/raw version of Unity's DOTS ECS. Just have static lists/dictionaries with data, then functions that iterate through them. An event is a list is cleared at the end of every frame.
Abstraction is evil
Don't write code like an academic writing his paper.
*There is a conflict of interests:* _simplicity does not lead to job security._
Jonathan Blow is the current Steve jobs of programming minus the immaturity
Working as a programmer is like running in an infinite tunnel and you can see only a single point of light at end , you can run towards the light but you never know when you'll reach the end.
sheeeesh
I agree that programming culture is broken. I often feel like the crazy person in the room because I'm advocating for simplicity and everyone looks at me like, "Why?"
didnt do the appropriate labour reduction during the game initial design phase. didnt get it done.
Braid 2! Do want!
The anniversary edition coming soon has new levels. :)
@@KuroOnehalf I'd prefer Braid 2 :(
Casey? Spaghetti code Casey?
Such a long winded way to just say YAGNI
much more to it than that
If not much is going to happen on the screen it’d be better to get a different screen where the camera is larger. On mobile this video is terrible but the audio is great.
I sometimes write my code so to the point, i feel insecure about it being way too simple lol I do cover all requirements and tests
For me, simplicity in programming means, pretty much, S.O.L.I.D. Small pieces of code, each concerned with single responsibility, doing one job in the simplest way then feeding the result to another simple piece of code. Minimal dependencies / coupling. Easy to unit test. Minimal state. If it can be divided into smaller isolated pieces, it almost always should.
Please link the source next time.
Wtf jonathan blow has a clips channel
I really like programming in C because its simple and just solves the problem. You need to type more code then in C++ or Python. But i know what my code is doing and im not dependent of external frameworks or tools, other then memcpy(), memcmp(), memmove()... If i work in C im directly working on the problem and not looking at the docs of some framework. Sorry, i work as a Magento dev and i really like C programming😅
C is great but it has it's flaws. If c was const by default, if it had a distinction between pointer to a single object and pointer to an array of objects with an additional length field, and the pointers were not nullable by default it would be almost a perfect language. There are also some quality of life features c is missing. I like zig for those reason. I think it is a promising language which aims to be like c, but with better defaults.
Is it really simple when you have to dodge footguns for the simplest of tasks? Idk I think people just call the thing that they know really well "simple" because to them it is. That's fine but it's not really a useful category by itself but just another way of saying "if you do what you are competent at then it usually works out".
I like when C segfaults and takes a massive core dump on me, it really enhances the experience and brings me joy. In all seriousness, we should move on, it’s been like 50 years, John.
@@maksymiliank5135arrays are a pain in C, yes.
Also the east const west const, IMHO. Ffs just make it either const int const *a or int const *const a, not some weird mix.
@@cas1652 I'm learning in my free time and so far C was the language I made the most progress in. Made it all the way to a moving spinning cube with opengl.
Making custom math types is ugly tho. C++'s operator overloading is a great feature for vectors and matrices.
He speaks well and his perspective is appealing to me, however i still don't understand how he wants software to be written. You can't just "write the game", i imagine you need a framework (framework as in some minor dogmatic paradigm such as ECS) to write in, and it can be any kind of framework. It can be a custom one that you winged just to match your requirements, but you do need a framework.
What do you think? I genuinely have a hard to time understanding what kind of simplicity he is after, and how you can make something "simple" without spaghetti code
He's basically just saying to put more emphasis on justifying the tools/frameworks you're using and not to be tricked by READMEs/blogs/articles/videos. Ask yourself if it's actually solving YOUR problem or if it's just very good at making you THINK it is. You'll be adding complexity if it fooled you.
I spent ages refactoring some old C++ code by modernizing it. The code was a lot more readable and even more performant after lots of measuring. What was my original problem? Actually just build the damn program and get it working properly. Did refactoring the code help me solve that problem? No. It was still not working properly but now it was just not working properly a little faster. I wasted my time and actually made it more complex for I found debugging the modernized version was hiding things behind a lot of clean and 'simple' abstractions, whereas the old version was far more explicit about what it was actually doing and easier to step through. The old version in my case is probably something Jon would consider more 'simple', even though it looked messy.
You really don't need any framework of any kind: Put the rules of the games on paper, what the player can do, what are the effects that should trigger, what the "world simulation" does, and implement that any way you want in any language you want: Could just be a giant "while" loop full of "if" in a single "main" function, could be made with objects and methods, could be done using some finite state machine, could be done "functional style" where you return the next status of the "game world" based on the previous state and the inputs from the player.
Basically: Make it work as simple as you can, no abstraction, no design, just use globals, locals, whatever you feel comfortable with to understand how to solve the problem, then after a while you will see patterns, refactor things so they work better together, etc... at that point you basically have a game engine, made for this one specific game, but that's a start.
There's nothing wrong with spaghetti code if it works, and if it works you can still detangle things and sort the spaghetis by size, color or taste :D
@@amber1862 thank you for clarifying and for the nice story. I think you explained it simply and well. I imagine this is what he is really talking about
@@DbugII thank you for your elaborate response, it's interesting to see that your response is different than that of the other person that responded to me.
I disagree with you, I don't think it's a good idea to just write spaghetti code. It becomes unmaintainable very quickly, and you do want to add more features. I imagine spaghetti code is much harder to debug than some kind of minor framework that you made yourself to fit the requirements, considering the fact that you also wrote it yourself so you also know the framework/engine very well
I misspoke: What I mean is that it's not important to respect any structure while you are exploring: Copy-paste, add globals, whatever, until you get something that work.
At that point, now that you have something that work, you can see how to move things around in a way that makes sense.
The tldr is that you can't structure something properly until you know how it's supposed to work in first place.
Think in term of "throw away prototype": There's no point wasting time in trying to design something properly until you actually have identified all the important parts of the problem, and it's much easier to modify/improve something with loose couplings than something structurally advanced.
Reminder. It takes a genius to make complexity simple. It takes an idiot to make simplicity simple.
Every technology / form factor carries real trade-offs. ECS's tradeoffs are significant, but often too subtle for people to see until it's too late and they're overcommitted. Choosing the right system / approach for your project is about choosing the right trade-offs for it. But if there's no comprehensively informed / honest discussion of trade-offs, you can't take any of it at face value.
I get a little tired watching people spring the ECS trap on junior programmers by hiding the truth about its trade-offs or not even themselves knowing what they are. It's a problem because people end up wasting YEARS because someone wants to sell them on something they don't really understand very well themselves in the wider context of shipping real products.
Meme-oriented programming is a problem, and I'm tired of pretending it isn't. This is the perspective of people who ship real commercial game software, not just tech demos and toy projects.
Keep it simple, says the dude who decided to start writing programming language as a step to make his next game.
🤣
Did he start writing a programming language to make a game or did he make a game to test the needs of his programming language. From what I've seen the answer is the latter one.
Computer science is not scientific? I think he meant coding 😂😂😂
Science used to be defined, before modern age, as a body of knowledge about entities, causes and effects. Understanding was defined as the ability to classify these entities, causes and effects. Wisdom was defined as the ability to apply understanding to achieve a valuable end. Computer science is not a science because it creates its own entities as it goes. It's more like a body of abstractions. Math on the other hand is a science, because it discovers its rules and entities. Also, it could be said that math is about things, computer science is about actions done to abstractions, and therefore it is as much a science by nature as "the science of taking a walk" or "the science of playing tennis". Greater complexity does not change the nature of a thing.
The part about social decisions in a corporate context is painfully true. I've had to ignore basic technical facts just to support some whiteboard architect's favorite pet idea because there was no convincing them otherwise. It's gross.
I think what our friend Jonathan here misses is people learn software for the money, not for the craft.
The real issue is our institutions (both Academia and Industry) fail to gatekeep incompetent people.
This is what #learn2code for a decade does.
I think he realizes that and assumes most people deep enough to find him/watch his streams genuinely want to know for the craft
Jon comes from a background where you write once and don't need to maintain it for decades. Web companies are the opposite of that. With maintenance comes the burden of tech debt and constant stream of reqiests from clients and other teams. You simply cannot fo that in a week in basic because the requirements just keep coming.
I think this is a simple diy - boilerplate and architecture - library complexity tradeoff. So depends on your game.
Entity Component Systems aren't just a way to organize your entities though, Proper ECS implementations have components laid out in memory together, such that you can take advantage of CPU cache; in games with tens of thousands of entities this is a huge performance benefit
Did you not listen to him talk? He literally addresses this exact point.
proper ecs implementations have components as structs in arrays (AoS). aos is what makes ecs fast, people just miss the details
@@PaddyLamont where does he address this exact point?
I was going to bring out my pitchfork too, but actually Jon seems to have a warped idea of what an ECS.
1) Said "entities is just calling some functions that do some code that's been the same since like 1950" ... really? I'm not completely entrenched in this topic but that doesn't sounds right at all
2) He didn't read the thing he mentioned @7:20 but then makes a bunch of claims about it ECS
3) It seems like he thinks an entity is just an object... I find it hard he could make that mistake but by the way he's talking about them it really seems that way
I'm pretty confident Jon knows all about ECS, to the point where he used it as an example of a complex system that might not fit the particular use case of an indie game developer making a game. The whole point is that complex systems may solve many problems as advertised, but you should strive to solve the real and specific problem that's right in front of you, instead of relying on complexity that speculatively may solve a problem you don't have.
What @@DS-rd8ud said
Don’t know if making custom game engines and even programming languages is something to be considered “keeping it simple “
I agree with you here. I am in no position to critique Jon. But I do see a conversation in web dev that I wonder if it’s similar.
Some people will bristle at using web frameworks because they are too complicated. But in my opinion frameworks (like Laravel and rails) compress complexity by solving important problems. The alternative is to solve all those problems from scratch.
I do think Jon had a good point that if a tool is dictating how you write your code and it’s not even solving your main problem then that’s bad.
@@davidharting3119well I'm not sure the people who bash frameworks have exactly laravel in their minds
I work in enterprise... and all of this is painful to hear, because it's true. Aspect driven development and other crap in jvm based langs is a bloat and there is hate in my bald head
Isn't Jon making his own programming language? What's he talking about.
who tf is jonathan blow and why do i keep getting clips of him reccomended i don't even watch them
Jonathan Blow is an independent video game programmer.
You're getting the recommendations because you need them.
I hope that helped.
Well known game developer who made Braid and The Witness. Currently working on a new programming language, jai, which he's using to work on his new upcoming game, among other projects. He streams working on both the game and the language a lot, and he's fairly critical and outspoken about his views, so that's why there's so much footage of him out there. A lot of the stuff clipped tends to be the just the spicy takes, but there's great game design and programming recordings too.
You may have clicked a single video about him and now are in the "JBlow CZcams bubble"
To get out, go to your YT History and search for "JBlow" and/or "Jonathan Blow" and remove any and all watched videos.
Once they are removed from your view history you're more likely to not be recommended the same kind of videos :)
Also works for any and all grifters that just produce shitty clickbait, etc.
"Simply solving the problem" is fine in a world of 1 person writing the OS to the GUI, but when working with other devs and eventual customers with different problems and desired solutions most stuff becomes a strange comprise. I do think people should really measure instead of premature optimizing.
As someone who works in consulting, this just sounds like a marketing trick more than anything, to me. They let you get more done by less experienced developers in the short term, which saves you money and produces some basic deliverables early, but in the long term it's a financially ruinous decision. Half my projects are coming in and fixing the seemingly endless problems caused by cheap teams of poor developers using one software package or another designed to give you workable abstractions and make development more accessible.
There are still times when this is useful (and there would be more of those times if clients were less strict about implementing every little 'essential' requirement) but it seems to me like premature optimisations primarily exist as a way to convince yourself or a client that you're doing more work, when in reality you're just offloading work to some future developer (or worse, developing software that will never get shipped).
The 'premature optimization' is so overused I drives me nuts.
If a senior developers writes better code then a junior one, did he 'prematurely optimized' it?
If I decide to write a program in Go rather then javascript, did I 'prematurely optimized' it?
If I just write good and efficient code (because I have internalized how computers really work and it just comes naturally to me), did I prematurely optimized it?
But I agree with you on one thing: the more you have to interact with rest of the world, the harder it is to keeping it simple. Which isn't to say it's impossible, but the scenario of writing an engine from scratch and not having to deal with others people existing projects, does sound at least slightly idealistic
@@xeamek99 when I say premature optimize I mean "you aren't going to need it" messy class hierarchy and design patterns to just submit a simple webform to the db.
Meanwhile random business people have "requirements" to customize every little thing in some menu no customer ever asked for.
I'm not talking about just choosing a bad algorithm or language.
If you are a business with 10 javascript devs and 1 go dev. They will not choose to train everyone in go. There's silly inertia to "what is popular" and also silly rewrites into "what is new" where no one measured if it solved a real problem.
@@DevanConrad Premature Generalisation is the term you want to use here.
As for the business people requirements - those tend to disappear very quickly when you can point out that you can complete the "80%" solution in 20% of the time.
The issue at the moment is that the Pareto principle isn't visible, because although they're only implemented 20% of the feature requests, which should cover 80% of the usecases, they're not actually doing 20% of the work.
Why? Because their 'generic', future-coding approach is trying to build a solution not just to cover the 20% features committed to, or even the remaining 80% that the buisness people would also like, but also all the other possible things the developers predict the business users might want in future! So they usually end up doing 200% of the work!
Except, to make it even more depressing - it isn't 200% of the work. It's 20,000% of the work. 99% of business software developed by teams can be done by a single developer if they'd just focus on solving the actual problem that needed solving.
Easy for a guy that works on one product every 10 years to say programmers at big companies create overly conplex software. I work on a team that os responisble for shipping software that generates billiones in quarterly revenue globally. The problem space and requirements are extremely complex from the start. There is no amount of wishful thinking or ideology that is going to make the complexity go away. It would take multiple trillions dollars to fix that, or entirely new base of technoloy to build upon. The best thing that can be done is to manage complexity. Make the software as simple as possible but not any simpler. Thats where the real challenge is. Usually in my space (packaging and release) its cross cutting configuration.
Why not just make a good fun game that people love to play? Whats all this "change the world" stuff?
The world is as it is and wont change from a computer game... Lol
Ego blown out or what?
he is talking about programming culture. if you are not a software developer, it's not for you.
This has nothing to do with a game.
But with promoting a mindset where people actually try to do a good job, instead of mindlessly following the flow.
It's fucking miserable when you're surrounded by people who act like this is all how it's supposed to be.
It's like for someone who's lived their whole life in a self-sufficient village to move to a city, it's just depressing as shit, going from something wholesome to a place where there's no honesty and nothing makes sense.
Yeah, unfortunately he is 150/100 on ego, it is easy to observe that on how he talks and laughs on some stuff. Classic dunning-kruger effect, know a thing or two in a field, thinks he knows every other field.
If you take simplicity to it's extremes you have to remove ABSTRACTION LAYERS as they add complexity by adding redirection and they obfuscate things. No libraries, no functions even. Just start typing at the top until the end.
John is a smart hard working programmer, but he doesn't seem to have an idea about software architecture or even structure outside of what fits into cache. This really makes me wonder about the ergonomics of his JAI programming language. Either it has everything build in like Python or only basic functionality.
Volume is way too low
Wasn't Overwatch done mostly in ECS? In the first years, OW was a success as a class-based FPS.
That by itself put Blow's argument in deconstruction.
I think that ECS and game's success are orthogonal.
I'm sure there are lots of successful games that have doors as characters or characters moving their mouth to play sounds that are supposed to come from a terminal on the wall because of some horrible class hierarchy that doesn't allow non-npcs to be animated or produce sound or something like that.
I need more details. This monologue was too abstract, and therefore useless.
I don't know what proverbs Jon has been reading, but simplicity is not a virtue in the Bible.
There are proverbs that exist outside of the Bible like, “A penny saved is a penny earned,” or “a broken clock is right twice a day.”
@@dboydomr neither of those is about the virtue of simplicity. Do you have any relevant examples?
@@peripheralarbor sure mate. “Nature is pleased with simplicity.” -Newton
He's not talking about the book in the Bible but proverbs as in the short sayings
He doesn't practice what he preaches here though. He writes his own engines for his games, but there really isn't a functional need for reinventing the wheel like that for his type of games. Could have saved a lot of time and money using Unity or Unreal. His current game and engine he has been complaining how his budget is over 20 million, how devs aren't coding right in his engine. Huh wonder why. Feel bad for anyone working under someone like this.
I don't like Jon Blow cause he is not a true MAGA patriot
lmao
Maga Patriot is an oxymoron but go off king
Trump 2024!
That’s right, Patriots don’t want to make America great again!
As a programmer you get paid far too much, a lot of what you do can be simplified and/or automated and I look forward to the day you lose your priest caste status