1. Understand the problem 2. Do the simplest thing that could possibly work. (which often means to not write any code at all, or better, delete a bunch of code) 3. Kent Beck's three rules: - Make it work - Make it right - Make it fast 4. Iterate. (cycle
While this works for small projects, wouldn't it be better to be somehow future proof by building a system/structure /framework, even though they're less straight forward and more complex? I mean this improves efficiency in future projects and makes things much more organized, especially if others are joining in your projects. Furthermore, the programming things you get taught at good schools will help you improve your way of thinking. One thing that comes to mind are algorithms courses; they're usually not that straight forward, but they help improve efficiency like crazy... I might have missed the main idea behind this video to tell you the truth...
@@efraimdeluxe lmao I think people know why they're using asynchronous routing. Try to setup an http router that can only serve one response at a time.
@Abigail Jones I agree with lots of what he says. But as someone inside the companies he likes to shit on, he completely misses why things are the way they are at these companies. The reason why companies in the web world use over-engineered solutions is because those solutions aren't over engineered if you're working at a Google or Facebook, and you can make boatloads of money working for those companies. So people working for these companies use them as skill and resume builders. A negative term for this is "resume driven development".
“Programming culture is broken” This deserves a book, because it will resonate a lot. It's one of those things everybody at some level feel but don't say.
i remember going on nights telling myself why everyone tries to hide it. it felt so wrong to my core and i could never accept it. i still can't understand today why no one talks about it. when i complain i almost always got complaints because i told exactly what the situation is. people have problems with the truth lmao
“We’re not allergic to complexity as programmers” Apparently one of the few advantages to my scatterbrain, poor focus and poor working memory is I am totally allergic to making things more complicated than they need to be.
Jonathan explains why I still love coding for my old Commodore 64. The machine and everything is much simpler and there are no mess of libraries and stuff. As a fulltime web developer, I think that is what has kept me sane over all these years as I still get some outlet and feeling of achievement on that old computer. :)
“The current aesthetics of programming is mostly Rube Goldberg machines”-the reason for that is we are desperately looking for an optimal abstraction to make our lives easier, to make programming very ergonomic and pleasant to build tools with. We want “the machine” out of the way so we can create freely, and we think the right abstraction would save us. But every time we try to do that, to create a better abstraction, even if it becomes hugely popular and takes over the world, some years later we look at it and see we didn't actually make programming better, and often we just made it more complicated.
Yep. This doesn't really come from programmers, but from management's impulse that bigger more "powerful" solutions that enforce certain "rules" will give them more control over the final product. Which is certainly true. Management just doesn't have the humility to admit that this is almost always a bad idea. It's the classical failure of the central planning paradigm, which fails at almost everything except corruption.
I like your comment and relate to your thinking, I have always thought as programming as follows; either something works well and is efficient or it is 'easy and fun with a small learning curve' never both.
In my universtity we started with C++ as first language and our teacher forbidden strings, he wants us to understand char arrays first and then using this neat string abstraction only. This is neat imo
That's how programming should be taught, IMO. Start with assembly language, then gradually build up abstractions moving to higher level languages like C++, then learn data structures and design patterns. Only then will people understand how things work and why they are useful, and not fall into this cargo cult programming.
then why isnt he teaching you C instead? i dont think arbitrarly limiting the featureset of a language is a good way to teach programming (ok technically std::basic_string is part of the STL, and not the core language, but I think you get what I mean) genereally speaking C++ is probably the worst language to teach programming in, already just because there are x possible way to initialize, constructors/destructors, reference, value and move semantics, templates (and related compile error messages), operator overloading etc. i could go on forever. saying this as a professional C++ dev. imo the best way to teach programming in is C & asm for teaching how the code ends up being executed on the machine and python or lisp for teaching algorithms.
Thats the thing. If you start programming at university you already lost in the game. Should be on the school board for every 12 year old who is interested in it (not a common course, as im in favor deletion of all common courses after elementary school).
I paid to learn to code on Codecademy and I was disappointed at how much of it was only focused on frameworks. Eventually it will reach a point where the majority of people teaching only know the frameworks and know nothing about what is taking place underneath. I come from a maths background and have no issue with the underlying logic of programming. I picked up coding in a basic IDE quickly but was flummoxed when my friend introduced me to Unity. I can see that in the long-run learning Unity would make games dev and design in particular much easier but as an intermediate programmer I need to learn more about the underlying computing principles before I start taking shortcuts. I am now learning assembly language and the fundamentals of how CPUs work and interact with the rest of the hardware. I know I'll be a better programmer because of this.
I won't call myself a very experienced programmer, so don't take my response as "it's bad/wrong" (i'm not trying to anyway) But I find it really funny that you went straight up to ASM because of Unity, that's smtg i never saw with my programmers acquaintances or even on the web. I wish you all the best of luck on it, would be really cool if you find rare game engine/ASM tips and share them on yt or even hacker news. anw lmao my response isn't really adding anything to your comment but i find it very cool that you took that path
@@Spriters400 Ha ha it must sound like I tried unity and thought eff it - binary all the way! Right from print "hello world" in Java I had a problem with languages and IDEs. Programs exist now which allow a person to do much more at the just the single press of a virtual button. Learning how to do a lot of higher level stuff (not all of it) is so simplified it is pointless to learn - ANYBODY can do it. It tells me nothing about how it works and that almost put me off to begin with. All the time I'm thinking but how...? Unity is an extreme example of this. The how is taken care of by someone else and I intuitively knew this must be wasteful. Perhaps this doesn't matter today because hardware is so powerful but I'd still rather make a more efficient program. Understand I'm not planning on building a game in ASM. If I did use ASM it would be inline or something of the sort. Also since ASM is not a single language I'm more interested in learning the general underlying principles but practising ASM will help me with this. Probably misleading to say I'm learning assembly language, as though it's that straight-forward. The important point is this: Making an engine/framwork/language _more_ human-optimised seems to often lead to _less_ hardware-optimised implementation that is deliberately hidden from the user. I've written code that I thought was concise and therefore efficient but actually was less memory intensive if it contained more lines/instructions because I wasn't aware of some things taking place under the hood. When I eventually come to making some serious programs, I am not going to waste my time coding everything down to the bit but I would consider it an equal waste of time to never code in detail and produce something that in the end is of a lower quality than it could have been. At the very least, if I understand how lower level stuff works, I will better understand how higher level stuff works so use it more effectively. EDIT: I watched this the other day. I loved crash as a kid and this is a shining example of what I mean. It was one of the best PS1 games because of low level knowledge. czcams.com/video/izxXGuVL21o/video.html
@@martincattell6820 I saw this vid the other day too and found it very interesting !! Actually you could code in ASM but it'd be for security, and even it'd be better in a C language with inlines but anyways, I totally get your point of view and pretty much agree with you, the most important thing is understanding, knowing how it works in our reality with hardware/software etc... You told so much things that I don't have much to add :^p
I couldn't agree more about the way we teach programming and the ways in which we model the "ideal" programming interfaces. Today's programming interfaces are convoluted and we're basically learning entire frameworks just to avoid having to know too much about computers. But that in and of itself separates us, programmers, from our craft. Having to adopt a whole new framework every single year is not making us better at programming, it's making us better as following instructions and/or rules. It's inevitably a bunch of individuals who are excited that they built something huge, and the rest of us using this tool to do all of the thinking for us. That's not going to make us solve problems better nor is it even the optimal way to approach problems in most cases. I understand there are levels of abstraction that can be helpful but, in my experience, using functional languages is just better sometimes than using class-based approaches because you don't always need that level of abstraction to design a system. Sometimes extra levels of abstraction take us further away from the problem... in fact, I would argue that's what happens MOST of the time. I cannot tell you how many times my tutoring sessions were me trying to help people stay on track with the goal because they were "lost in the code" so to speak. And I've always felt like being lost in the code is because of the several layers of abstraction that have to be managed and understood on top of the core goals of actually solving the individual problems. In a way it's like Mathematics. We don't tell math students to create entirely new systems of using numbers just to solve most problems. Even complicated problems, we simply tell them to take it one step at a time and keep each step separated from each other so you know what each step is doing. Perhaps taking a step back in the programming world would be better. Can completely agree with the learning being somewhat terrible as well. In our courses we don't learn much about the computer. We learn it on theoretical level, but with no practice nor any idea of how to control things. There is one class about assembly language but no classes that taught how to take those ideas and expand on them into modern languages like C++, Java, etc. Very little is taught to force us to understand the machine we are working with.
Functional programming is a bad example IMO, bit I totally agree overall. Why is it a bad example? Functional programming is not made for your average programmer, but for academics by academics. Its about research in CS, which is very important, but most programmers dismiss it as "useless". We wouldn't have computers at all if it were not for Turing, Church, Curry, Knuth, Von Neumann, etc. All of them were/are mathematicians/hard core CS researchers. Example. Knuth created Tex to typeset his book. Yeah, he created the legendary Tex just for that. Tex is sth your average programmer would never be able to create, because it is very mathematicial, I mean it uses graph theory for example. It is not sth you can sit dawn, draw three pictures, open up your emacs, and just start coding random things. Thats not how it works. Finally, why are functional programming languages not too abstract or forced too much? They have sth no other language has, and that is purity. The idea is that you have purity of functions, no side effects, or at least no unpredictable side effects. Why is this useful? Because it is one of the rare ways to prove an algorithm. For your average programmer that might be useless, but again, someone has to push the cutting edge and the people pushing the cutting edge have to deal with this stuff and they love doing it. If you go study CS, you are expected to deal with these things, because that is what CS is all about. You can do ALL of undergrad CS without touching a computer or learning a real world language, because purely CS has nothing to do with programming as engineering. That would be highly unpractical and unecessary difficult, not to mention that learning CS through actual computers and programming languages also gets you experience to do actual programming in the industry. But people never do their research and always go into CS thinking they will be making games all undergrad....
Most great programmers in my experience don't really know a lot of frameworks, and just have a good logic in programming. Ironically most of them are in Consultant jobs, instead of actual developer jobs, where they are most needed.
Man you went to a terrible school :( maybe try computer engineering, since you actually learn about low level concepts? One of my profs wrote the original TCP paper...
Keep in mind that the mathematical theories have been digested for a long time. The common abstraction we learn are really useful and fit perfectly with the problem we want to solve (metric spaces -> limits -> derivatives). But these abstractions are not hardware friendly because of how computers work (limited memory, fixed instruction set). Programmers have the power to build functioning things by only writing words, in a sense like mathematicians. But those abstractions are so juicy (I personally fall for this, being trained as a mathematician). A solution: we focus all of our energy into compilers, so that we can build languages that express the potential of math (you mentioned functional languages). Or we abandon those "academic" ideas and remove these biases, start writing good documentation about what we are doing and start introducing good industry developers into higher level education.
I've been feeling this sht about Unity and Unreal for 2 years. I'm finally tackling c++ so I could write Cuda and get into the real time Ray tracing pipeline. I just discovered this dude today. And I am LOVING his pov.
@@PTv1deos Roger wants you to write a user guide, you're talking about a reference manual. If forced to choose, I'd rather have the latter. It's reliably organised and vital for maintenance work as opposed to green field development
Such amazing piece of words :( I admire those type of advocacy, which gives great great feedback, which is not only good for programming stuff, but also for life.
I remember a small team and I made something (that blew up in the good way) in less than four months by throwing many abstraction practices out the window. Various other projects that are nowhere near the same output or quality that took YEARS. It’s amazing how well most projects can run without 78 complicated layers of abstraction/encapsulation, if you just try it. And here we were, thinking the project wouldn’t even run, or our team wouldn’t be able to follow the code logic…how wrong we were…
I get weird dopamine spike when removing code that's no longer needed. It works especially well when things are well decoupled so removing files or methods is just a breeze without breaking anything.
Beautiful talk. ❤ I'm adding some thoughts on two of the topics Jon talks about, namely simplicity and pressure, only because I feel I have a slightly different perspective that might be useful in this conversation. So here are my thoughts: **1. on simplicity** : to me, simple means an efficient, non-wasteful, and effective way of doing something. It's something you aim for when you are trying to solve something, not when deciding what to solve. In other words, choose what projects to work on based on what's important to you, what you want to see in the world. Once the project is chosen, only then think about simplicity. In my case, once I choose a project (i.e. a problem I want to solve), I generally go through a several step process: - I start by reducing the problem to a clear question I want to answer - I list what's given or what I know - I draft a strategy (this is where simplicity is the main goal: what's the simplest way to find the answer to my question) - I build my solution - I test (plus re-iterate, if necessary) and deliver my solution **2. on pressure** : I would like to see more people become aware that the only truly useful and truly non-fragile form of pressure is the one that comes from expecting the best of yourself. It doesn't matter what the industry expects or what the world expects. If each one of us aimed to bring out the best in ourselves, the industry and the rest of the world would inevitably get better. ❤
It's funny I just read some of the works by Sir Francis Bacon and he was saying the same thing about people in his time believing what they want or what they are told instead of using their sense experience and testing their ideas against nature - essentially what's going on in programming right now. We need to test our ideas against the environment they are in and learn from that experience instead of just believing what we are told is "good" or what sounds nice to us.
I think that's a universal problem with humans. Our brains don't want to put more work than necessary, so they will make us take shortcuts, binge watch netflix instead of challenging ourselves with exercise and so on. Really, testing our ideas is not something deeply engraved in us, it's something we learn.
There is both a lot of externally-imposed complexity in the development world and a lot of "package deals" when making decisions about a project, which I think contribute to this problem. To give some examples. A web page may not be as simple as just banging out some HTML+CSS if different browsers behave differently. Or maybe you want to make your C code more typesafe and enforce unit boundaries, so you turn to C++, but now you've opened the door for template metaprogramming. And unit interfaces are good, but the generally accepted paradigm for them is OO. Which comes with inheritance, which is ill-conceived and complex (see Effective C++ or Effective Java). Incrementalism and backward compatibility also keep us piling onto the status quo instead of tearing out the complexity and leaving only the useful parts.
The programming culture of not utilizing a computers full potential, and hiring tons of developers to maintain old codebases is due to the current business culture of fast-to minimal-viable-product and the focus on maintaining VC funding. Hiring inexperienced programmers is cheaper and gets the job done, so it will always be preferred by businesses, and by extension stackoverflow questions, and by extension programming rit large. In this TED talk I will...
This is straw man BS, most companies I worked have their shit together. If you want to work for a shitty company then don't complain when you get shit conditions.
Every complexity you build now is one you'll have to live with and be constrained by in the future. So choose them wisely, and don't be too sentimental to dispose of them if they prove unworthy down the line.
One big problem with the whole world is that people are desperate to be seen as smart. This is a primary source of exploding complexity. Another big source, is having to constantly build up on someone else's foundation which has turned into layers and layers of complexity that is not even understood. Things need to be made as simple as possible to do the job at hand. Sometimes things need to be scraped straight to the ground and built again to have a solid foundation.
Game programmers aren't magically superior to enterprise programmers. There are a lot of unskilled, dogmatic, unorganized, etc programmers in both. It's mostly a difference of motivation on the job. If people are not motivated, they will accomplish much much less. It's very hard to find real motivation in enterprise software, what little you can find, politics often funnels it away. EDIT: Enterprise software has unskilled programmers pooling in full stack and web dev. In game programming they pool around hyped systems, recently Unity. In response people try to avoid these areas. But also using C++ or ECS doesn't make you a better programmer, it's a trap mentality people get into, you might actually be worse than the people using Unity, because you're obsessed with tooling for shallow reasons or reasons that are not your own. (I think this last part is largely JBlow's point).
Just listen to every Rich Hickey video you can find and what this guy is talking about will come into sharp focus. Hickey lays out the issues with complexity and bad design issues very clearly. He created Clojure, but what he says applies in any language.
That was great. "Complexity kills." "Trying to learn to program today really sucks." YES. I really feel like an old fart saying these things, but that doesn't make them less true.
Trying to learn to program today is great. You have all the free compilers and documentation you need. It depends on where you were born, but it was a pain being a child in the 90's just trying to even understand where to start (might have been different had there been a software developer in my family, edit: or if we had classes in school).
@@gracefool i don't think there is anything wrong with learning HTML, CSS and JavaScript. But when learning it you have to know that it is sort of a method of using programming techniques (Think this is the case with most languages). It is not the true startingpoint of a program and there is always something you don't know and are simplifying too much. (not long since i started learning so any critique on this view is welcome)
Saying that learning to program today sucks is just a complete lack of perspective. When I was a kid, you had to buy books to learn this stuff. You know, those big heavy things made of lots of stacked sheets of paper? And your books had to be specific to the tool you were using, because standardization was inconsistently applied if at all (fond memories of including conio.h), so whether C code written for some other tool would compile/work on yours was a crapshoot. Also have fun manually managing segments and offsets in your 16 bit operating system. Graphics? Lol :) Today documentation is everywhere, tools are amazing and consistent, compilers provide excellent diagnostic messages, and computer architecture as whole became saner. JBlow is just a FUD artist with a terminally short memory.
@@alwin-1335 So, you don't have experience, but you _think_ there's nothing wrong? Honestly, we need more (or at least some) research on this topic. From experience I can tell you that the things you know affect your thinking. Your first programming language will dictate how you think, look at problems, etc. It'll change when you learn new stuff of course. But are you sure you want to condemn yourself to knowing JavaScript as the first language? JavaScript is only suitable for small projects, preferably only for write-execute-discard scripts. I really liked JS in the past, but experience told me there's nothing to like about the language.
Not enough programmers understand the value of "floor" programming. You need to look up before you make the first rungs of the ladder. There's a lot to be gained from making frameworks before using frameworks--discovering problems, creating solutions, and seeing what's bloat and what isn't. I spent far too much time creating code that I barely understood in frameworks that require an eagle's eye to grasp. Programming isn't difficult. What's difficult is knowing what to write and when to write it, when to break your code and when to leave it alone, when to optimize and when to not.
There's never enough talent, no matter how much of it there is. And while I agree that quality programming requires understanding the fundamentals, I don't think this concept is what's missing for this perspective to spread. Education has its limits. In my experience, the problem is that low-level programming is widely seen as a niche that powerful hardware has graduated the masses from. And that in order to do low-level programming, you have to have extreme domain-specific knowledge (expensive), extremely talented (expensive^2) and spend orders of magnitude more development time that you can't afford to (bankrupting expensive). The promise of higher-level languages is not just to anthropomorphize programming, but also to speed-up productivity (by reusing modules created before). And if you can find a way to make DoD fast and accessible, like bloated OOP, _then_ I think the industry will change dramatically. Then it'll be obvious that it's not a hobby akin to steam engines today, like many developers I know believe (including myself not too long ago).
I hate frameworks and bloated dependencies (like Qt, I would rather write my own user interface system then use that garbage) that themselves need 6 other dependencies that all require to be built from source. Excessive abstraction is also something I hate. Instead of just writing something straightforward they hide everything from you with shiny design patterns. Good if you're the end user but not if you're trying to understand how it works.
Working at a company doing things always take longer and Jonathan is correct that there is a lot of time wasted. But the main reason is not from developers doing things in a overly complicated way, it is from a lack of requirements. As a tech lead I have all of the responsibility of a project manager but none of the mandate. I also feel like programming games is a lot different because you don’t have to add features ten years don the line so readability is not as important there. Having said all this, do we over engineer the web? Hell yes.
Commodore Vic20...I remember that! My buddy wrote a random number generating program and we had a lottery...lol. BTW...he is right...learning to code in today's environment is pretty crappy....lol. Thanks
Something Jonathan does not talk about in the "Wasting 99.99% of your computer power is not a huge deal because it is so fast" is that it is actually the same argument as when we first started destroying the planet in the first place. "It does not matter that we cut that much trees, there are so many!", well look where we're at now... shouldn't we be respectful of the energy we are spending doing useless work with our machines?
Computers get faster and more power efficient so it isn't really a problem nowadays. And if it's price to pay for easily understandable and debuggable code I think it's worth it
Yeah it's along the lines of the "cloud" abstraction. Makes people forget that we're literally cooking the fucking atmosphere to deliver Facebook to people.
@@Sahilbc-wj8qk I heard a good comment somewhere, "Machines are 40% faster so my code can be 40% slower". No, wrong, bad. Don't be needlessly slow. It hurts my programming heart and it should hurt yours, too, dear reader. You pay for it in wasted time waiting for things to happen.
An analogy I us for complexity. If you want to hang a shelf. Just drill the 6 holes yourself. There is no point leasing a CNC drill rig, set it up, program it to drill just 6 holes. Proponents for "code reuse" and "using fully tested third party code rather than you own" will of course say the CNC drill rig is proven technology, and it enforces x, y, and z OOP design patterns and type hierarchies. "Just drill the god damn 6 holes. The project is done in 1 hour. It will take a day just to get the CNC machine, a day learning how to set it up, a day testing the project setup and another 3 days at least fixing bugs caused by other devs still angry that we needed a CNC machine in the first place. Then 3 weeks later when you have just managed to forget all about the project, a Severity 1 security vun is found in your version and you have to go and upgrade the whole application, which is code breaking. It is certainly aimed far more squarely at Java programmers as a Java programmer these days couldn't reverse a string without using the apache commons string utils + deps. I recently had to include 5 spring framework jar files in my project because some idiot supplying a static util class in a common library thought it was a bright idea to include an Assert statement in a library. NO! THOUGH SHALT NOT CONTROL MY RUNTIME FROM YOUR LIBRARY! ARRRRR! But... the most annoying thing was that they used Spring's Assert class. For 2 Assert statements they could have written faster in plain old java than it took them to add the Spring dep to the pom.xml. Then you get death star ass hats who try to over engineer everything from the get go. Often with commercial implications of course. If you are a software consultancy, the more software you need to write and hte longer it takes the better. Just as long as you can preach from your OOP sermon book about why all that complexity was needed.
You can learn now but think like the old days, you can buy the old books from that era. Ultimately what he is saying is, understand the fundamentals, not what someone else tells you the fundamentals are and do. He's also saying having something or anything between you and the machine has the negative potential to obscure, ruin or destroy good code. So be pragmatic. There are good current examples but they are more likely found in youtube videos specific to your need as you build your own understanding youll see this. They are less likely to be found in the latest books on your language of choice selling in high number in Amazon. Mr Blow is recommending you know why you are doing something not just how you do something. I hope this helps to clarify for someone.
Mathematica is nice, but proprietary. Matlab is ass. Python is ass too but less so than Matlab. Something like Julia would probably be better (only wish they hadn't gotten array indexing wrong).
Sometimes the problem that you have is communicating the way you want code to look with other programmers. Sometimes the problem that you have is documenting those patterns. These packages (hopefully) can solve these problems essentially allowing you to outsource the work on the pattern and the documentation of those patterns. Not saying it's necessarily the right way to go, but to say that it's not solving a problem is not correct. The problem of communication is not a hard engineering problem, but it is a collaborative problem.
This video is very accurate but I feel like it doesn't actually help solve the problem. Like how would you like to see the learning process structured in order to teach beginners the skills they actually need to be successful in this field? I originally went to college intended to get a degree in computer science but switched majors after a few years because I felt very frustrated in my classes for many of the reasons you seem to be frustrated with the programming community. I still have the desire to program and fortunately the one thing I retained from these classes was my knowledge of C++, but I don't feel like I have the skills necessary to actually program something functional. I've started many projects, like games and apps, but I quickly become confused and overwhelmed. What are the actual skills I need to turn my ideas into fully functional programs?
I'm by no means an expert, so If anyone here is please jump in and correct me, but the most crucial thing for me was starting and *finishing* small projects. It's easy to get overambitious and think you're ready to move on to something larger, when in actuality you still need to strengthen the basics. It's never too late to learn something new, but lots of people think they need to come out of the womb knowing linear regression and machine learning and all types of shit. Think of something small and doable, like a calculator. Then don't stop until it's done. Look shit up, watch tutorials, pull out your hair, and when it's finally done and working you can close all of those tabs and feel like you accomplished something. Then do it *again*, this time without looking anything up. If you get stuck, you know you need to go back and study up a bit on what's causing you trouble, if you succeed, it's time to make something new, and slightly more complex. I hope this helps in some way, and please don't give up. Anyone can learn this shit, it's not rocket science. Just hard work, like anything else.
I am not an expert on programming but I think I understand what is required, and his to get what I want by now. - You need to know how to learn, and you need to know how to do it fast, you will never be in a situation where you only write what you know, if you did you already have the program in your head and can get it done in hours of days. - You need a mental toolbox, a bunch of tricks and concepts you can use as a foundation on the way to writing a new program, it will make things easier, be and this toolbox needs constant TLC, when you make a solution remember the concept. - You need to understand the limitations of your brain and knowledge and correct for it, is you're stuck on a problem for 3 days or more you have to do and reconsider if your approach is right, and to think about that you need sleep and a clear head. - Just do it, you can't build up any of these things without just writing programs, even if they suck, if you think your programs such, refactor your projects, refractor your mental toolbox. there is no other way...
People often ignore or overshoot the domain knowledge required to model their problems. What he is trying to not overspeak on at 04:44 is that you can overcomplicate things by not knowing what you are trying to accomplish and also undermodel things and thus not achieve the desired result. That is what killed Novus Aeterno MMORTS's kickstarter effort.
I like Bevy, but he's right that I would see benefit from not having its expectations imposed in my ability to 100% shape the things that I build. I think there's a tradeoff with where the effort comes from, since buying into the Bevy way of doing it comes with a huge benefit from other people
There's a lot of the DoD community that resonates with me - and definitely that a lot of education could be more competent, learning-oriented and scientific (albeit I think that's virtually impossible because there's not enough talented and passionate teachers in the world, and without AI-support, I doubt there can ever be). But I think these old-school programmers are really missing what's possible in a world with 25M+ programmers. Social norms is one thing. But I think most developers think skill floor / barrier of entry, and productivity requirements are the bottleneck for DoD being widely adopted. I found DoD through a very indirect route, and I previously thought C++ and DoD was a tiny niche and way above my potential skill level. I was lucky to find some down-to-earth resources I resonated with and I'm now learning that C++ (without most OOP-features) is actually sometimes easier than OOP. So there's *CLEARLY* a communication problem going on. Once I understand DoD well enough, I intend to take a stab at clearing up this communication error, and not preach to the choir (or get on their high horse) like I feel like many DoD people do. Similar to science communication, providing falsifiable evidence in a very accessible and intriguing format is something that will spread very fast on SoMe's. I have a handful of ideas of how to achieve this, and if nobody else does it, I intend to. That is, if it turns out that DoD isn't just marginal improvements on average, and has huge downsides for the vast majority of the developer industry.
Computer education and those structures. They are designed in academia to solve theoretical problems. Sure they apply to certain real world problems, but I find more often than not they get used to account for "what if" scenarios. Its like programmers who work this way just try and shape the problem to fit a solution. They construct a much bigger web than they needed to solve the problem. The web they build will solve the problem and the a dozen other problems you don't yet have and might never have. I tend to find however that their "what if" scenarios never seem to actually cover where the play moves next. A little bit of "what if" is brilliant, it tends towards defensive programming and really makes you understand the problem. But if you do it at too high a level, you start inventing requirements, designing for them and implementing them, when there was absolutely no need to do so. And lets be honest, these patterns and abstractions don't actually come for free. I have seen Java engineers argue that a double nested visitor pattern was simplier because it produced methods with only 1 line of code, compared to my 3 method solution where the average was 12 lines of code. I had to sigh and draw their attention to the "True" complexity of what they wrote and how, unless you completely digest and understand the pattern it is just gobble-de-gook. Not least because when these people get down into the dirty they stop naming types specific things and start giving them academia taxonmy names, like "Visitor", "Observer", "MutexGateway", one minute it's Orders, LineItems and Taxes, the next it's Visitor and Deligates and the business logic extends deep down into the sea of academic bullshit. I my 20 year career I have had to take apart, rewrite and throw away at least 3 death star projects that got out of hand and when the OOP priest left to spoil a startup's life, we binned all his projects at cost of millions because nobody wanted to work in that code base.
I find the same people stare at you confused when you say something like "Throw them through a set or dictionary, do some venn/Set analysis and then you can sort, pair and return them." They stare at you like it's the first time they have seen Set analysis in code....
it's a sliding scale, you can get a feel for something's complexity by how you feel when trying to with or on the system, also arguably complexity is relative, no point my system being deemed simple of you can't even begin to fathom it
To me it means having more moving parts than required (functions, variables, interfaces, libraries etc). Bringing it down to the bare minimum moving parts to make it work requires skill, knowledge and restraint
The problem is we keep finding ways to add code, but there's a dearth of tools and techniques for removing unneeded code. So we just keep piling on layers. We aren't going to get simplicity until we have tools that can tell us what can be taken away or simplified.
If you can add it with tool assistance you can also remove it without tool assistance. Because "I guess I'll have to wait 'til someone writes a tool" is textbook deferred responsibility.
The tool that can tell you what to take away or simplify, and stop piling on layers, is called your brain. That's the part (well, one of the parts) that all the people hyping AI as something that will take all software engineers' jobs don't get. Being a good software engineer is about understanding what requirements really are, building the thing that's actually needed, simplifying things and making them maintainable, etc. Having a bunch of fools ask an AI to write code for them doesn't solve that problem, in fact it makes it worse. But you're right that there aren't a lot of refactoring tools that can analyse a codebase and help to cut it down and simplify it, in the case where the software engineers involved know the importance of that. And despite what I just said about AI, that's probably something that AI tools will help with a lot. But actually being a human being that understands that simplicity is important, that maintainability is important, and that cutting down the size of a codebase and refactoring it is important, that isn't something that having a tool is going to magically fix. So I take a bit of issue with you seeming to blame the lack of tools as the cause of the piles of garbage code problem.
The problem is not the lack of skills in programming in the industry, it is the lack of skills of building and programming systems than can evolve and change overtime. Difficult to compare the video game industry and the line of the business industry as the horizon for a program/system is not the same Probably anyone can program even the most complex program, this is the easy part. But thinking, designing, making the right design choice so this program can evolve overtime following the business changes is the shit.
this is not the sht it's actually quite trivial, just dont try to cast the entire program into some huge inflexible structure, keep things open ended, dont try and hide everything into a class hierarchy. people think this is hard because they keep trying to predict the future to find a class hierarchy that's just right instead of admitting they dont know what's gonna happen and keeping the program "raw" to increase flexibility.
If you want to make a game, I'd get the basics of c++ or c# for about say 6 months, then find a pre-made game template and work with that. (Granted you're a solo developer)
People don't understand that programming is at the core all about algorithms and data structures. You can add a thounsand layers of bullshit around it, but it wont make your problem any easier.
Agree with him 100%, however important to limit this in the context of Jonathan Blow's fantastic work: Game programming. Once a game is shipped is it done. So the dev lifetime is 5 years max. Corporate have systems that have to stay up, evolve and be maintained for decades. I completely agree that web programming is broken. I hope project such as Blazor start to kill this monster which is the Javascript ecosystem.
> Corporate have systems that have to stay up, evolve and be maintained for decades. Yes, but for systems of any relevant complexity it is really hard to surmise the changes required within the next years, let alone decades.
When there's a bug in a game it's funny or you just patch it and nobody cares. When there's a bug in corporate software people lose money and you get fired lol. Programming on your pet project is fun, you get to do everything you want your way, make tradeoffs as you see fit and the whole codebase is in your head. When you program on a project with 100s of other people, it's hard. You feel unproductive. You can't ship code without conforming and it's never gonna be quite your ideal, you'll never know the whole code bases anf you've got complex problems that come from not stepping on each other's toes. It is what it is. Big companies can afford to be inefficient because each tiny brick a programmer adds to the system translates to a lot of value across all customers. Even if it's slow, and resource hungry, and hard. Making your own everything for yourself is fun, but doesn't have the economy of scale, generally speaking. Unless you make the number 1 app on a store or something.
> Once a game is shipped is it done. This isn't true ever since Steam became a thing. Even Jonathan is working on a new edition of his first game right now.
hot take. programming culture is broken because consumers dont know how good products could be so they buy cheap crap. imagine if you are a shitty javascript developer and you listened to jon and became an amazing native programmer who knows all the amazing algorithms. lets think for a second about what would acutally happen. would he get anymore money from his job? no the company knows what product they are making and they arent going to change it because someone is suddenly more professional on the team. so what would happen? the new omega brogrammer would look for a job where he can get payed what his skills are worth and would leave the java script job. would that change the company now that the java script position was vacant? no it would not, they would just put up a job listing to replace him. and a young aspiring developer would see the job listing and get those skills to get the job. therefore the cheap java script culture would be perpetuated as such. so what would change the culture? consumers wanting a better product that would cause the company to put out job listings for higher tier products.
I've been trying to get into programming for years but I just can't stand it, there's so much wrong with the field itself and the way it is taught that you need an insane level of dedication to persist.
@@christopherwillson That’s alright; I’m in a similar situation. I’m intrigued but intimidated by code, and I don’t exactly jump at opportunities to learn it. Still, I’m not ready to abandon it just yet. I keep thinking about it for a reason, and I’ll know if it’s good for me in time.
Yeah alot of rabbit holes out there. They spend so much time coding but so little time with good documentation and assumptions and design goals. So people can know if this is right for them.coding can be an excuse to do what you think is hard for you too do. So people just do it because they feel comfortable there. . In my small xp. Agree that cs is not really a science since it really hasn't progressed. It's nice that there is easier entry level and more choices. The only hope is that cs is the last hope of helping medical science since it can leverage The hardware. Things will get better
There is some truth to what he is saying but he is going way over the top into "you darn kids get off my lawn" kind of deal. Jonathan, there are other people in the world who can program, besides you. You are not the only competent programmer in the world. Jesus christ. Jonathan really has a hard time with understanding the problem. It is collaboration that is the problem. And he escapes it by never working with more than a handful of people he employed. As good of a programmer Jonathan is, he is unemployable.
Most of the developers (I don’t call them programmers) do nothing but copy/move some code from here to somewhere else, especially the Python and JavaScript guys writing trivial things out of zero creativity. They have zero idea how even memory and CPU work and the worst part is that they even don’t care lol
They want everyone to be a programmer, but they have to make 4 levels of tools and abstraction for most people to be interested at even trying. You can't just make people want to learn how. I never learned to program because it's a never-ending moving target, and no entry point seemed to be a good one. I refuse to be a cog in a social machine that does nothing valuable.
I love how Jonathan Blow go for a rant about the modern programmers while underestimating his own skill and assuming everyone has the same knowledge, skill and values. Programming games is completely different thing than doing web applications or desktop applications even. You need to deal with high level abstractions because you need work with the system below and don't invent circle over and over again. It is good engineer who will not be slowed down with low level stuff if somebody else actually solved it out and reuse the solution. Of course it has some limits but reusing and abstraction is something that made us create applications which are more accessible for users. Regarding even the gaming industry, while I don't like Unity, I can easily see that its availability enabled to boost creativity of small studios and explore game genres more. Regarding the number of developers working on projects... well Jon is probably just better at programming than everyone else. Good for you. But not noticing it will make you old guy ranting about new generations.
Learning to program with python reduces programming to a set of trivial non-transferrable skills, like memorising names of libraries and function calls, as well as their quirks.
Careful. Simple *programming* is amazing for the gamer. If your game runs at 120 stable with the same features because of great programming as opposed to just piling on those features and never optimising anything as is the current state.
I feel like Jon, & Casey are doing God's work. We need someone saying these things. Aside from them it seems like the only ones trying to affect "programming culture" are crazy sjw's who put social concerns, over technical.
Good examples can be found. I find C examples from 100-year-olds with beards, and they are pretty fun + (empirically, verifiably) useful. Edit: here's one from _this year_ that isn't bad: czcams.com/video/URrzmoIyqLw/video.html Outspoken leaders in these "successful game programmer" circles like to shit all over everyone who doesn't acknowledge their superior superiority, but the picture certainly isn't as bleak as they lead us to believe.
I really hate these kinds of rambling videos that pretend to have meaning. Like wtf is he getting at? What does he take issue with in "programming culture", which he leaves utterly undefined and unexplained? That there are bad programmers out there? Well no shit. Being bad at something is the first step to being good at something, isn't it? What does he mean programmers try to do things in a complex way? Is he criticising that programmers choose the wrong way to go about solving a problem? Isn't that just a restatement of there being bad programmers? What is he talking about virtue? Why isn't computer science scientific? Please explain what scientific science is to you then? Why isn't programming based on evidence? I don't know what CS is like in the USA, but here in Germany we do learn about the way a turing machine and the computer itself works, so I don't know what he's talking about. What science isn't "ideas that were communicated to them by other dudes" in the first place? If people aren't designing the thing that would solve their problem then what the fuck are they doing? Just so much nonsensical rambling. I mean, maybe some amount of "programmers" don't know how a computer works on the inside, but then they're not really programmers imo. If they don't have at least some understanding of what their computer does with their program they're just users of programming but not programmers, obviously. Being attached to some complex way of doing things just sounds like noob stuff to me, isn't it? What do you mean no selection pressure? If you can't program well you won't find a good job. That's as much pressure as can be, really. Either that or you don't make a product people want to use, or make a product that can easily be replaced by another programmer doing the same thing better. Or is this about programming and computer architecture having become so complex, that it's extremely opaque for newcomers? If so, then this is something I agree with him about. But that's also something that comes out of the pressure of optimisation. People with years and years of experience and the newest tech at their disposal keep optimising things to a point where it's hard to understand. That's something that happens in literally any field whatsoever though so it's a difficult topic, and not as simple as programming culture being broken. I think everyone that acts like they know well, what he means just want to feel smart and superior..
No, I think some people genuinely get or at least sympathize with what he means. I'm relatively inexperienced in programming but even I've noticed that not all of the impenetrable aspects of programming are solely born from optimization (and I don't think that's necessarily all bad). A lot of this discussion is about methods/philosophy of abstraction and frameworks for instance. Though I agree any persistent issues born from this can at least in some part be attributed to inexperience or complacency on the programmers side. And I also think some of the more level headed comments following up on what he's said were more insightful than the overly cynical rant of the video itself. I think he over blows it.
@@IronicHavoc But my point is that he never clearly states *what* he means. If they empathise with the feeling of "programming being headed in the wrong direction" then that's just really really vague. That's my whole point. I agree on the second paragraph aswell.
Thank you. I guess his way of making abstract claims about things being "bad" and "complex" resonates with people because everybody has experienced these frustrations but in different ways, and they can all fill in the gaps he leaves with whatever particular issues they have. I think if he would make his arguments more concrete they would fall apart and people would realize they're all thinking about different things. For example, his complaint about the multithreaded entity system is so ignorant it pisses me off. His claim that all time is spent on rendering is just false for many games. Maybe somebody wrote three games and discovered "I always have problems with too much time being spent in the entity simulation and end up making it multithreaded for performance which introduces tons of bugs. I should make something reusable from it so I can save time in the future and only have to fix bugs once." And hey, he made it accessible for other programmers too so now they can just plug it in and increase performance for free, with the added bonus that the introduced code has a lot of mileage so it will likely handle many unforeseen issues for us. Reusable components are a way of _reducing_ complexity and that is at the core of this library's value offering, because now we don't have to keep that implementation in our working memory any more. Someone else took care of it and we can reason about things at a higher, simpler level. Sure, I bet the library author could have made it simpler, but making things simple is hard and requires many iterations and experience. It's a failing of human capacity, not of attitude.
Just to be fair to the guy, it's important to put things in context: he was saying those things during a live stream, to people who probably already knew him and could make more sense of the stuff he was saying. This video is just a clip from that live stream, and Jonathan Blow isn't the one who posted it.
Interesting to think about this now after Elon Musk took over Twitter. I feel this is one aspect he saw and took on when he first came in. Twitter was unnecessarily complex and he took the first steps to dismantling all of this cruft.
I don't agree with this at all, ECS is *objectively* superior to any other entity handling concept. There are benchmarks I could send him but it wouldn't change his mind because it doesn't matter to him. How good your entity system and your game engine is directly affects the produced game quality. Vulkan is also vastly superior to modern OpenGL and probably DirectX 12 from what I saw as well.
If it works for you and allows you to do more things - great. Just be open to the idea that everything has its downsides and be honest to yourself by asking what downsides of ECS you see, and if these downsides take time from you or other people or not. Everything requires maintenance, and Jon and his team probably have enough code to maintain to ignore other technologies that won't address their needs. Shipping something to the world usually means losing many battles, and if they will lose performance battle it'll probably be caused by some other factors, not because they couldn't compute positions or attributes of tens of thousands of objects on CPU. :)
He's arguing that the performance gained by ECS is trivial compared to the bottleneck that rendering is (Vulcan's gains are mostly on rendering too). He's also arguing against designing a solution before defining the problem. These are both valid criticisms. I personally develop in Unity which is ECS oriented and I use components only sparingly when needed (right now im using them on my UI for example). For instance Unity would like me to make a HasHealth component and add it to both destructible objs and characters, yet I find it more easy to use an interface with one method that gets called within Unity's event system and then calls a static method on my RPG class that calculates dmg. If I want to change the rules of my game I dont edit multiple classes, I just go to the relevant methods on my RPG class.
@@arbolarbol7876 What he's saying is basically immediate gains. I am proposing that instead of focusing on immediate gain, maybe that is 5 years or 10 years we focus on making something which will last until we die and after. I don't care about shipping games especially if they are built lazily. ECS doesn't have to mean you need a crazy elaborate system using templates and inheritance. It could be as simple as having a structure of arrays where each array is statically defined for a specific component. Then a way to get an entities components from these arrays where the entity is simply an ID. That in itself can drastically improve speed due to caching and also it's efficient in fetching a small related data member to an entity. You don't need to find a whole entity object or whatever. It helps with memory segmentation and efficiency as well. So overall it is better than simply having a struct or class which holds every possibly used member an entity can have. It makes multi-threading really easy to do. It helps even for structure and debugging, as you can easily list the components an entity has, disable or enable systems at runtime, etc...
Vulkan is also the lowest level and lightest graphics API we have which actually jon and casey were asking for prior to 2016. When it was released though all they can tell us is that "It's not low level enough, I need GPU bytecode" when that wasn't the original request. Jon actually instead said that "I just want to draw triangles I don't want to learn a whole ecosystem.". It is a contradiction. If you want a low level graphics API you will need to learn how the video chip and video driver works. Vulkan does just that which was your original request, to have a new lightweight video driver that replaces OpenGL as it is bloated and has a flawed design. OpenGL was designed for single-threaded usage and it uses a state machine. The command buffers are handled by the driver and IT decides when your draw call will be actually executed on the graphics card. Also the GLSL language is implemented differently on so many drivers which is a result of a faulty specification. Vulkan has SPIR-V to remedy that. Vulkan also allows for GPU memory management and you can define passes and subpasses before doing any drawing. So all I can say as a conclusion is the problem isn't with Vulkan nor C nor ECS, the problem is the lack of perseverance, effort and forward thinking from the person behind the keyboard.
@@SaidMetiche-qy9hb I agree with you on Vulcan and you make me wanna dive into it and also I disagree with everything else, tools and ecosystems wont outlive you, games will. Developers should focus on releasing great games, how they are written is only relevant insofar as it makes them easy to patch, update, etc.
JBlow makes two games over twenty years and becomes the authority on computer science. Guy acts like he publishes papers on algorithms instead of just using a graphics API to make entertainment.
@@iamvfx You're missing the point. Grand claims should be backed up by grand credentials. Two games on Steam does not make you an authority on software engineering.
@@AirmanAJK By you I didn't mean you specifically, but most of us, he did better than most of us. Most games are low effort, not thought out noise, unless you have interesting counter examples.
@@iamvfx But he's only done work in this very narrow slice of software, yet he'll disparage concepts like JIT and cross-platform abstractions generally. Like sit down dude. Some of us are processing massive amounts of data from real-time systems across networks. Sorry your pixel shaders don't take advantage of tools we use.
Advice on learning to program, assuming you're not just a dabbler and want to make a serious career out of it: 1) DO NOT USE IDEs 2) PICK ONE LANGUAGE, IT DOESN'T MATTER WHICH 3) DO NOT USE LIBRARIES OR FRAMEWORKS 4) GET FAMILIAR WITH THE COMMAND LINE 5) WRITE SIMPLE PROGRAMS THAT DO SIMPLE STUFF 6) WRITE MORE COMPLICATED PROGRAMS DOING MORE COMPLICATED STUFF, IDEALLY REUSING THE SIMPLE PROGRAMS YOU'VE ALREADY WRITTEN DO THIS FOR AT LEAST 6 MONTHS BEFORE YOU EVEN THINK ABOUT DOING SOMETHING DIFFERENT
@Jason Holtkamp You shouldn't be learning new tools until you have a firm understanding of the problems those tools are helping you solve. It's only then that you also understand the stuff that those tools are abstracting away from your awareness. That's how we end up with "programmers" building complex software with absolutely no understanding of what's really going on. My advice is to write your own libraries at first, ie create you're own little utility programs that you can re-use. Granted, in any modern language you're going to get a lot of built-ins in the core language, but that's okay.
Just bullshit, does he actually know the curriculum today? Here in Germany you learn at most University either Scheme or Haskell and Python at the beginning from professors who know their shit. Outside the university you have tons of choices today and I'm talking about online courses and not some random post and tutorials on some random sites. As always Blow creates a strawman to argue against for the purpose of ranting.
Do you know the curriculum today? Here in Poland none of those is true, we had only C/C++/C# and few mobile technologies. We had python but only because we happened to choose one optional subject that had it. Online courses tend to do the same thing too, they teach you overcomplicated stuff because that's what gives you a job, but at the same time doesn't teach you the most important part.
1. Understand the problem
2. Do the simplest thing that could possibly work. (which often means to not write any code at all, or better, delete a bunch of code)
3. Kent Beck's three rules:
- Make it work
- Make it right
- Make it fast
4. Iterate. (cycle
6. Learn how to count
@@dandymcgee Hahaha! I blame lack of sleep. :)
@@ddanielsandberg It was a good list either way. Glad you saw the light humor in my comment.
@@ddanielsandberg So due to lack of sleep you messed up that point which made a point about lack of sleep? I see.
While this works for small projects, wouldn't it be better to be somehow future proof by building a system/structure /framework, even though they're less straight forward and more complex? I mean this improves efficiency in future projects and makes things much more organized, especially if others are joining in your projects.
Furthermore, the programming things you get taught at good schools will help you improve your way of thinking. One thing that comes to mind are algorithms courses; they're usually not that straight forward, but they help improve efficiency like crazy...
I might have missed the main idea behind this video to tell you the truth...
13:48 - "Programming culture is broken on a global scale"
FINALLY. Someone I respect said it.
could you possibly elaborate on what he means? I don't really understand how it is broken.
@@tarekali7064 Just look at the async hype in python for example ... everone is doing it, nobody really knows why ..
@@efraimdeluxe lmao I think people know why they're using asynchronous routing. Try to setup an http router that can only serve one response at a time.
@Simon Farre Indeed; he's unintentionally preaching to the uneducated masses.
@Abigail Jones I agree with lots of what he says. But as someone inside the companies he likes to shit on, he completely misses why things are the way they are at these companies. The reason why companies in the web world use over-engineered solutions is because those solutions aren't over engineered if you're working at a Google or Facebook, and you can make boatloads of money working for those companies. So people working for these companies use them as skill and resume builders. A negative term for this is "resume driven development".
“Programming culture is broken” This deserves a book, because it will resonate a lot. It's one of those things everybody at some level feel but don't say.
i remember going on nights telling myself why everyone tries to hide it. it felt so wrong to my core and i could never accept it. i still can't understand today why no one talks about it.
when i complain i almost always got complaints because i told exactly what the situation is.
people have problems with the truth lmao
“We’re not allergic to complexity as programmers”
Apparently one of the few advantages to my scatterbrain, poor focus and poor working memory is I am totally allergic to making things more complicated than they need to be.
I'm using this excuse now. Thanks!
Jonathan explains why I still love coding for my old Commodore 64. The machine and everything is much simpler and there are no mess of libraries and stuff. As a fulltime web developer, I think that is what has kept me sane over all these years as I still get some outlet and feeling of achievement on that old computer. :)
You are not alone brother!
You would like fantasy consoles like tic-80 and pico8.
“The current aesthetics of programming is mostly Rube Goldberg machines”-the reason for that is we are desperately looking for an optimal abstraction to make our lives easier, to make programming very ergonomic and pleasant to build tools with. We want “the machine” out of the way so we can create freely, and we think the right abstraction would save us. But every time we try to do that, to create a better abstraction, even if it becomes hugely popular and takes over the world, some years later we look at it and see we didn't actually make programming better, and often we just made it more complicated.
that is so on point!
Yep. This doesn't really come from programmers, but from management's impulse that bigger more "powerful" solutions that enforce certain "rules" will give them more control over the final product. Which is certainly true. Management just doesn't have the humility to admit that this is almost always a bad idea. It's the classical failure of the central planning paradigm, which fails at almost everything except corruption.
I call this "runaway abstraction".. Not only does it decrease code quality, it can also be problematic when writing secure code.
To put it simply: programmers try to find the computational equivalent to the philosophers stone, but they get excited when it makes fools gold.
I like your comment and relate to your thinking, I have always thought as programming as follows; either something works well and is efficient or it is 'easy and fun with a small learning curve' never both.
In my universtity we started with C++ as first language and our teacher forbidden strings, he wants us to understand char arrays first and then using this neat string abstraction only. This is neat imo
Actually good professor, pog
That's how programming should be taught, IMO. Start with assembly language, then gradually build up abstractions moving to higher level languages like C++, then learn data structures and design patterns. Only then will people understand how things work and why they are useful, and not fall into this cargo cult programming.
IMO its not true, I learned C++ for years and use higher level languages now, everything I learnt is completely useless now
then why isnt he teaching you C instead?
i dont think arbitrarly limiting the featureset of a language is a good way to teach programming (ok technically std::basic_string is part of the STL, and not the core language, but I think you get what I mean)
genereally speaking C++ is probably the worst language to teach programming in, already just because there are x possible way to initialize, constructors/destructors, reference, value and move semantics, templates (and related compile error messages), operator overloading etc. i could go on forever. saying this as a professional C++ dev.
imo the best way to teach programming in is C & asm for teaching how the code ends up being executed on the machine and python or lisp for teaching algorithms.
Thats the thing. If you start programming at university you already lost in the game. Should be on the school board for every 12 year old who is interested in it (not a common course, as im in favor deletion of all common courses after elementary school).
I paid to learn to code on Codecademy and I was disappointed at how much of it was only focused on frameworks. Eventually it will reach a point where the majority of people teaching only know the frameworks and know nothing about what is taking place underneath.
I come from a maths background and have no issue with the underlying logic of programming. I picked up coding in a basic IDE quickly but was flummoxed when my friend introduced me to Unity. I can see that in the long-run learning Unity would make games dev and design in particular much easier but as an intermediate programmer I need to learn more about the underlying computing principles before I start taking shortcuts.
I am now learning assembly language and the fundamentals of how CPUs work and interact with the rest of the hardware. I know I'll be a better programmer because of this.
I won't call myself a very experienced programmer, so don't take my response as "it's bad/wrong" (i'm not trying to anyway)
But I find it really funny that you went straight up to ASM because of Unity, that's smtg i never saw with my programmers acquaintances or even on the web.
I wish you all the best of luck on it, would be really cool if you find rare game engine/ASM tips and share them on yt or even hacker news.
anw lmao my response isn't really adding anything to your comment but i find it very cool that you took that path
@@Spriters400
Ha ha it must sound like I tried unity and thought eff it - binary all the way!
Right from print "hello world" in Java I had a problem with languages and IDEs. Programs exist now which allow a person to do much more at the just the single press of a virtual button. Learning how to do a lot of higher level stuff (not all of it) is so simplified it is pointless to learn - ANYBODY can do it. It tells me nothing about how it works and that almost put me off to begin with. All the time I'm thinking but how...?
Unity is an extreme example of this. The how is taken care of by someone else and I intuitively knew this must be wasteful. Perhaps this doesn't matter today because hardware is so powerful but I'd still rather make a more efficient program.
Understand I'm not planning on building a game in ASM. If I did use ASM it would be inline or something of the sort. Also since ASM is not a single language I'm more interested in learning the general underlying principles but practising ASM will help me with this. Probably misleading to say I'm learning assembly language, as though it's that straight-forward.
The important point is this:
Making an engine/framwork/language _more_ human-optimised seems to often lead to _less_ hardware-optimised implementation that is deliberately hidden from the user.
I've written code that I thought was concise and therefore efficient but actually was less memory intensive if it contained more lines/instructions because I wasn't aware of some things taking place under the hood.
When I eventually come to making some serious programs, I am not going to waste my time coding everything down to the bit but I would consider it an equal waste of time to never code in detail and produce something that in the end is of a lower quality than it could have been. At the very least, if I understand how lower level stuff works, I will better understand how higher level stuff works so use it more effectively.
EDIT: I watched this the other day. I loved crash as a kid and this is a shining example of what I mean. It was one of the best PS1 games because of low level knowledge.
czcams.com/video/izxXGuVL21o/video.html
@@martincattell6820 I saw this vid the other day too and found it very interesting !!
Actually you could code in ASM but it'd be for security, and even it'd be better in a C language with inlines but anyways, I totally get your point of view and pretty much agree with you, the most important thing is understanding, knowing how it works in our reality with hardware/software etc...
You told so much things that I don't have much to add :^p
@@Spriters400 Yeah sorry. Long comment.
@@martincattell6820 No problem, quality comment :p
I couldn't agree more about the way we teach programming and the ways in which we model the "ideal" programming interfaces. Today's programming interfaces are convoluted and we're basically learning entire frameworks just to avoid having to know too much about computers. But that in and of itself separates us, programmers, from our craft. Having to adopt a whole new framework every single year is not making us better at programming, it's making us better as following instructions and/or rules. It's inevitably a bunch of individuals who are excited that they built something huge, and the rest of us using this tool to do all of the thinking for us. That's not going to make us solve problems better nor is it even the optimal way to approach problems in most cases. I understand there are levels of abstraction that can be helpful but, in my experience, using functional languages is just better sometimes than using class-based approaches because you don't always need that level of abstraction to design a system.
Sometimes extra levels of abstraction take us further away from the problem... in fact, I would argue that's what happens MOST of the time. I cannot tell you how many times my tutoring sessions were me trying to help people stay on track with the goal because they were "lost in the code" so to speak. And I've always felt like being lost in the code is because of the several layers of abstraction that have to be managed and understood on top of the core goals of actually solving the individual problems. In a way it's like Mathematics. We don't tell math students to create entirely new systems of using numbers just to solve most problems. Even complicated problems, we simply tell them to take it one step at a time and keep each step separated from each other so you know what each step is doing. Perhaps taking a step back in the programming world would be better.
Can completely agree with the learning being somewhat terrible as well. In our courses we don't learn much about the computer. We learn it on theoretical level, but with no practice nor any idea of how to control things. There is one class about assembly language but no classes that taught how to take those ideas and expand on them into modern languages like C++, Java, etc. Very little is taught to force us to understand the machine we are working with.
Functional programming is a bad example IMO, bit I totally agree overall.
Why is it a bad example? Functional programming is not made for your average programmer, but for academics by academics. Its about research in CS, which is very important, but most programmers dismiss it as "useless". We wouldn't have computers at all if it were not for Turing, Church, Curry, Knuth, Von Neumann, etc. All of them were/are mathematicians/hard core CS researchers.
Example. Knuth created Tex to typeset his book. Yeah, he created the legendary Tex just for that. Tex is sth your average programmer would never be able to create, because it is very mathematicial, I mean it uses graph theory for example. It is not sth you can sit dawn, draw three pictures, open up your emacs, and just start coding random things. Thats not how it works.
Finally, why are functional programming languages not too abstract or forced too much? They have sth no other language has, and that is purity. The idea is that you have purity of functions, no side effects, or at least no unpredictable side effects. Why is this useful? Because it is one of the rare ways to prove an algorithm. For your average programmer that might be useless, but again, someone has to push the cutting edge and the people pushing the cutting edge have to deal with this stuff and they love doing it. If you go study CS, you are expected to deal with these things, because that is what CS is all about. You can do ALL of undergrad CS without touching a computer or learning a real world language, because purely CS has nothing to do with programming as engineering. That would be highly unpractical and unecessary difficult, not to mention that learning CS through actual computers and programming languages also gets you experience to do actual programming in the industry. But people never do their research and always go into CS thinking they will be making games all undergrad....
Most great programmers in my experience don't really know a lot of frameworks, and just have a good logic in programming. Ironically most of them are in Consultant jobs, instead of actual developer jobs, where they are most needed.
Man you went to a terrible school :( maybe try computer engineering, since you actually learn about low level concepts? One of my profs wrote the original TCP paper...
Keep in mind that the mathematical theories have been digested for a long time. The common abstraction we learn are really useful and fit perfectly with the problem we want to solve (metric spaces -> limits -> derivatives). But these abstractions are not hardware friendly because of how computers work (limited memory, fixed instruction set).
Programmers have the power to build functioning things by only writing words, in a sense like mathematicians. But those abstractions are so juicy (I personally fall for this, being trained as a mathematician).
A solution: we focus all of our energy into compilers, so that we can build languages that express the potential of math (you mentioned functional languages). Or we abandon those "academic" ideas and remove these biases, start writing good documentation about what we are doing and start introducing good industry developers into higher level education.
@@mattewlefty991 LISP folks may argue that we're all writing compilers anyway :)
When I was in 7th grade (1995) I got my step dads “oh! Pascal” book, and I still program in it today. :)
I've been feeling this sht about Unity and Unreal for 2 years. I'm finally tackling c++ so I could write Cuda and get into the real time Ray tracing pipeline. I just discovered this dude today. And I am LOVING his pov.
20:37
-Here's a command
-Here's what it does
-Example of how it can be used
I will structure my game engine documentation like this.
Exactly Backwards.
@@RogerBarraud What do you mean by "Exactly backwards" in regard to structuring documentation in that particular way?
@@PTv1deos Roger wants you to write a user guide, you're talking about a reference manual. If forced to choose, I'd rather have the latter. It's reliably organised and vital for maintenance work as opposed to green field development
"What problem does this solve" is what I often ask when discussing the addition of a new feature/operation.
this guy is a machine
Such amazing piece of words :( I admire those type of advocacy, which gives great great feedback, which is not only good for programming stuff, but also for life.
I remember a small team and I made something (that blew up in the good way) in less than four months by throwing many abstraction practices out the window. Various other projects that are nowhere near the same output or quality that took YEARS. It’s amazing how well most projects can run without 78 complicated layers of abstraction/encapsulation, if you just try it. And here we were, thinking the project wouldn’t even run, or our team wouldn’t be able to follow the code logic…how wrong we were…
The best thing in programming is to remove code. The second best thing in programming is to rewrite code.
I wrote a entity component system for my game engine, got it working and I hated it so I just deleted it haha.
Is this a quote? Sounds familiar, like something Ken Thompson would say.
@@stumbling Uh I think one of the original Unix guys said it yeah
I get weird dopamine spike when removing code that's no longer needed. It works especially well when things are well decoupled so removing files or methods is just a breeze without breaking anything.
Beautiful talk. ❤
I'm adding some thoughts on two of the topics Jon talks about, namely simplicity and pressure, only because I feel I have a slightly different perspective that might be useful in this conversation. So here are my thoughts:
**1. on simplicity** : to me, simple means an efficient, non-wasteful, and effective way of doing something. It's something you aim for when you are trying to solve something, not when deciding what to solve. In other words, choose what projects to work on based on what's important to you, what you want to see in the world. Once the project is chosen, only then think about simplicity.
In my case, once I choose a project (i.e. a problem I want to solve), I generally go through a several step process:
- I start by reducing the problem to a clear question I want to answer
- I list what's given or what I know
- I draft a strategy (this is where simplicity is the main goal: what's the simplest way to find the answer to my question)
- I build my solution
- I test (plus re-iterate, if necessary) and deliver my solution
**2. on pressure** : I would like to see more people become aware that the only truly useful and truly non-fragile form of pressure is the one that comes from expecting the best of yourself. It doesn't matter what the industry expects or what the world expects. If each one of us aimed to bring out the best in ourselves, the industry and the rest of the world would inevitably get better. ❤
It's funny I just read some of the works by Sir Francis Bacon and he was saying the same thing about people in his time believing what they want or what they are told instead of using their sense experience and testing their ideas against nature - essentially what's going on in programming right now. We need to test our ideas against the environment they are in and learn from that experience instead of just believing what we are told is "good" or what sounds nice to us.
I think that's a universal problem with humans. Our brains don't want to put more work than necessary, so they will make us take shortcuts, binge watch netflix instead of challenging ourselves with exercise and so on.
Really, testing our ideas is not something deeply engraved in us, it's something we learn.
18:30 how he learned to program
There is both a lot of externally-imposed complexity in the development world and a lot of "package deals" when making decisions about a project, which I think contribute to this problem. To give some examples. A web page may not be as simple as just banging out some HTML+CSS if different browsers behave differently. Or maybe you want to make your C code more typesafe and enforce unit boundaries, so you turn to C++, but now you've opened the door for template metaprogramming. And unit interfaces are good, but the generally accepted paradigm for them is OO. Which comes with inheritance, which is ill-conceived and complex (see Effective C++ or Effective Java). Incrementalism and backward compatibility also keep us piling onto the status quo instead of tearing out the complexity and leaving only the useful parts.
I dont know any framework that fixes that, I still need to add specific css for safari, so frameworks make no difference for that
The programming culture of not utilizing a computers full potential, and hiring tons of developers to maintain old codebases is due to the current business culture of fast-to minimal-viable-product and the focus on maintaining VC funding. Hiring inexperienced programmers is cheaper and gets the job done, so it will always be preferred by businesses, and by extension stackoverflow questions, and by extension programming rit large. In this TED talk I will...
This is straw man BS, most companies I worked have their shit together. If you want to work for a shitty company then don't complain when you get shit conditions.
@@teckyify your experience is just as anecdotal
@lagooned There's probably more options in between/aside from low standards corporations and big tech firms.
You'll know what you need, when you do what you want.
"If you're an independent developer, and you know what game you're going to make...just type the code".
thank you for ranting mr. blow, very cool!
Every complexity you build now is one you'll have to live with and be constrained by in the future. So choose them wisely, and don't be too sentimental to dispose of them if they prove unworthy down the line.
One big problem with the whole world is that people are desperate to be seen as smart. This is a primary source of exploding complexity. Another big source, is having to constantly build up on someone else's foundation which has turned into layers and layers of complexity that is not even understood. Things need to be made as simple as possible to do the job at hand. Sometimes things need to be scraped straight to the ground and built again to have a solid foundation.
Game programmers aren't magically superior to enterprise programmers. There are a lot of unskilled, dogmatic, unorganized, etc programmers in both.
It's mostly a difference of motivation on the job. If people are not motivated, they will accomplish much much less. It's very hard to find real motivation in enterprise software, what little you can find, politics often funnels it away.
EDIT:
Enterprise software has unskilled programmers pooling in full stack and web dev. In game programming they pool around hyped systems, recently Unity. In response people try to avoid these areas. But also using C++ or ECS doesn't make you a better programmer, it's a trap mentality people get into, you might actually be worse than the people using Unity, because you're obsessed with tooling for shallow reasons or reasons that are not your own. (I think this last part is largely JBlow's point).
Just listen to every Rich Hickey video you can find and what this guy is talking about will come into sharp focus. Hickey lays out the issues with complexity and bad design issues very clearly. He created Clojure, but what he says applies in any language.
I agree. Rich and John are working in very different problem spaces and so their solutions are different, but their core philosophy is pretty similar.
yet somehow he created an extremely complex and not very cache friendly system of data structures to achieve immutability, how's that not dogmatic?
That was great. "Complexity kills." "Trying to learn to program today really sucks." YES. I really feel like an old fart saying these things, but that doesn't make them less true.
Trying to learn to program today is great. You have all the free compilers and documentation you need. It depends on where you were born, but it was a pain being a child in the 90's just trying to even understand where to start (might have been different had there been a software developer in my family, edit: or if we had classes in school).
I was lucky, I learnt BASIC as a kid. I can't believe how nowadays people teach JavaScript/HTML/CSS as a first language.
@@gracefool i don't think there is anything wrong with learning HTML, CSS and JavaScript. But when learning it you have to know that it is sort of a method of using programming techniques (Think this is the case with most languages). It is not the true startingpoint of a program and there is always something you don't know and are simplifying too much. (not long since i started learning so any critique on this view is welcome)
Saying that learning to program today sucks is just a complete lack of perspective. When I was a kid, you had to buy books to learn this stuff. You know, those big heavy things made of lots of stacked sheets of paper? And your books had to be specific to the tool you were using, because standardization was inconsistently applied if at all (fond memories of including conio.h), so whether C code written for some other tool would compile/work on yours was a crapshoot. Also have fun manually managing segments and offsets in your 16 bit operating system. Graphics? Lol :)
Today documentation is everywhere, tools are amazing and consistent, compilers provide excellent diagnostic messages, and computer architecture as whole became saner. JBlow is just a FUD artist with a terminally short memory.
@@alwin-1335 So, you don't have experience, but you _think_ there's nothing wrong? Honestly, we need more (or at least some) research on this topic.
From experience I can tell you that the things you know affect your thinking. Your first programming language will dictate how you think, look at problems, etc. It'll change when you learn new stuff of course. But are you sure you want to condemn yourself to knowing JavaScript as the first language?
JavaScript is only suitable for small projects, preferably only for write-execute-discard scripts. I really liked JS in the past, but experience told me there's nothing to like about the language.
It’s surreal to hear your twitch username quoted in a video.
Not enough programmers understand the value of "floor" programming. You need to look up before you make the first rungs of the ladder. There's a lot to be gained from making frameworks before using frameworks--discovering problems, creating solutions, and seeing what's bloat and what isn't. I spent far too much time creating code that I barely understood in frameworks that require an eagle's eye to grasp. Programming isn't difficult. What's difficult is knowing what to write and when to write it, when to break your code and when to leave it alone, when to optimize and when to not.
There's never enough talent, no matter how much of it there is. And while I agree that quality programming requires understanding the fundamentals, I don't think this concept is what's missing for this perspective to spread. Education has its limits. In my experience, the problem is that low-level programming is widely seen as a niche that powerful hardware has graduated the masses from. And that in order to do low-level programming, you have to have extreme domain-specific knowledge (expensive), extremely talented (expensive^2) and spend orders of magnitude more development time that you can't afford to (bankrupting expensive). The promise of higher-level languages is not just to anthropomorphize programming, but also to speed-up productivity (by reusing modules created before). And if you can find a way to make DoD fast and accessible, like bloated OOP, _then_ I think the industry will change dramatically. Then it'll be obvious that it's not a hobby akin to steam engines today, like many developers I know believe (including myself not too long ago).
This should be the main page of the internet
There's no such thing as 10x programmers. Only 1/10 programmers.
Looking forward to sending my kids to the college of Eater, Hotz & Blow
I hate frameworks and bloated dependencies (like Qt, I would rather write my own user interface system then use that garbage) that themselves need 6 other dependencies that all require to be built from source.
Excessive abstraction is also something I hate. Instead of just writing something straightforward they hide everything from you with shiny design patterns. Good if you're the end user but not if you're trying to understand how it works.
Working at a company doing things always take longer and Jonathan is correct that there is a lot of time wasted. But the main reason is not from developers doing things in a overly complicated way, it is from a lack of requirements.
As a tech lead I have all of the responsibility of a project manager but none of the mandate. I also feel like programming games is a lot different because you don’t have to add features ten years don the line so readability is not as important there.
Having said all this, do we over engineer the web? Hell yes.
Thanks!
Commodore Vic20...I remember that! My buddy wrote a random number generating program and we had a lottery...lol. BTW...he is right...learning to code in today's environment is pretty crappy....lol.
Thanks
Something Jonathan does not talk about in the "Wasting 99.99% of your computer power is not a huge deal because it is so fast" is that it is actually the same argument as when we first started destroying the planet in the first place. "It does not matter that we cut that much trees, there are so many!", well look where we're at now... shouldn't we be respectful of the energy we are spending doing useless work with our machines?
We shouldn't even need that justification. Inefficient code should hurt the programmer on a spiritual level.
Computers get faster and more power efficient so it isn't really a problem nowadays. And if it's price to pay for easily understandable and debuggable code I think it's worth it
Yeah it's along the lines of the "cloud" abstraction. Makes people forget that we're literally cooking the fucking atmosphere to deliver Facebook to people.
@@MB-up3mh Hell abstraction of wrapper classes .
@@Sahilbc-wj8qk I heard a good comment somewhere, "Machines are 40% faster so my code can be 40% slower". No, wrong, bad. Don't be needlessly slow. It hurts my programming heart and it should hurt yours, too, dear reader. You pay for it in wasted time waiting for things to happen.
quote of the day : complexity lovers the threshold of what can even be acomplished.. you made my day
An analogy I us for complexity. If you want to hang a shelf. Just drill the 6 holes yourself. There is no point leasing a CNC drill rig, set it up, program it to drill just 6 holes. Proponents for "code reuse" and "using fully tested third party code rather than you own" will of course say the CNC drill rig is proven technology, and it enforces x, y, and z OOP design patterns and type hierarchies.
"Just drill the god damn 6 holes. The project is done in 1 hour. It will take a day just to get the CNC machine, a day learning how to set it up, a day testing the project setup and another 3 days at least fixing bugs caused by other devs still angry that we needed a CNC machine in the first place.
Then 3 weeks later when you have just managed to forget all about the project, a Severity 1 security vun is found in your version and you have to go and upgrade the whole application, which is code breaking.
It is certainly aimed far more squarely at Java programmers as a Java programmer these days couldn't reverse a string without using the apache commons string utils + deps.
I recently had to include 5 spring framework jar files in my project because some idiot supplying a static util class in a common library thought it was a bright idea to include an Assert statement in a library. NO! THOUGH SHALT NOT CONTROL MY RUNTIME FROM YOUR LIBRARY! ARRRRR! But... the most annoying thing was that they used Spring's Assert class. For 2 Assert statements they could have written faster in plain old java than it took them to add the Spring dep to the pom.xml.
Then you get death star ass hats who try to over engineer everything from the get go. Often with commercial implications of course. If you are a software consultancy, the more software you need to write and hte longer it takes the better. Just as long as you can preach from your OOP sermon book about why all that complexity was needed.
as a java dev, i can only tell you, learn to say no, make them remove the deps, make them learn how to reverse strings, so on
preach Jon!!
You can learn now but think like the old days, you can buy the old books from that era. Ultimately what he is saying is, understand the fundamentals, not what someone else tells you the fundamentals are and do. He's also saying having something or anything between you and the machine has the negative potential to obscure, ruin or destroy good code. So be pragmatic. There are good current examples but they are more likely found in youtube videos specific to your need as you build your own understanding youll see this. They are less likely to be found in the latest books on your language of choice selling in high number in Amazon. Mr Blow is recommending you know why you are doing something not just how you do something. I hope this helps to clarify for someone.
I think that matlab, mathematica or scilab would be better for math than python. But it's only my opinion, great video, glad I'm here.
Mathematica is nice, but proprietary. Matlab is ass. Python is ass too but less so than Matlab. Something like Julia would probably be better (only wish they hadn't gotten array indexing wrong).
Mathematica is super nice if you're into algebra, but most applied mathematicians I've met use c++, python or Julia (increasingly Julia nowadays).
jon is anxious, just relax
Sometimes the problem that you have is communicating the way you want code to look with other programmers. Sometimes the problem that you have is documenting those patterns. These packages (hopefully) can solve these problems essentially allowing you to outsource the work on the pattern and the documentation of those patterns.
Not saying it's necessarily the right way to go, but to say that it's not solving a problem is not correct. The problem of communication is not a hard engineering problem, but it is a collaborative problem.
This video is very accurate but I feel like it doesn't actually help solve the problem. Like how would you like to see the learning process structured in order to teach beginners the skills they actually need to be successful in this field?
I originally went to college intended to get a degree in computer science but switched majors after a few years because I felt very frustrated in my classes for many of the reasons you seem to be frustrated with the programming community. I still have the desire to program and fortunately the one thing I retained from these classes was my knowledge of C++, but I don't feel like I have the skills necessary to actually program something functional. I've started many projects, like games and apps, but I quickly become confused and overwhelmed. What are the actual skills I need to turn my ideas into fully functional programs?
I'm by no means an expert, so If anyone here is please jump in and correct me, but the most crucial thing for me was starting and *finishing* small projects. It's easy to get overambitious and think you're ready to move on to something larger, when in actuality you still need to strengthen the basics. It's never too late to learn something new, but lots of people think they need to come out of the womb knowing linear regression and machine learning and all types of shit.
Think of something small and doable, like a calculator. Then don't stop until it's done. Look shit up, watch tutorials, pull out your hair, and when it's finally done and working you can close all of those tabs and feel like you accomplished something. Then do it *again*, this time without looking anything up. If you get stuck, you know you need to go back and study up a bit on what's causing you trouble, if you succeed, it's time to make something new, and slightly more complex.
I hope this helps in some way, and please don't give up. Anyone can learn this shit, it's not rocket science. Just hard work, like anything else.
I am not an expert on programming but I think I understand what is required, and his to get what I want by now.
- You need to know how to learn, and you need to know how to do it fast, you will never be in a situation where you only write what you know, if you did you already have the program in your head and can get it done in hours of days.
- You need a mental toolbox, a bunch of tricks and concepts you can use as a foundation on the way to writing a new program, it will make things easier, be and this toolbox needs constant TLC, when you make a solution remember the concept.
- You need to understand the limitations of your brain and knowledge and correct for it, is you're stuck on a problem for 3 days or more you have to do and reconsider if your approach is right, and to think about that you need sleep and a clear head.
- Just do it, you can't build up any of these things without just writing programs, even if they suck, if you think your programs such, refactor your projects, refractor your mental toolbox. there is no other way...
- Frederic Chopin
“Nature is pleased with simplicity. And nature is no dummy.”
People often ignore or overshoot the domain knowledge required to model their problems. What he is trying to not overspeak on at 04:44 is that you can overcomplicate things by not knowing what you are trying to accomplish and also undermodel things and thus not achieve the desired result. That is what killed Novus Aeterno MMORTS's kickstarter effort.
I like Bevy, but he's right that I would see benefit from not having its expectations imposed in my ability to 100% shape the things that I build. I think there's a tradeoff with where the effort comes from, since buying into the Bevy way of doing it comes with a huge benefit from other people
ecs is not bad on its own, it's bad that it's over advertised and some programmers try to use it in cases that shouldn't be used
Yeah, I think it makes perfect sense for Dwarf Fortress for example.
Same thing with most of the popular technologies really. Or methodologies or really anything.
There's a lot of the DoD community that resonates with me - and definitely that a lot of education could be more competent, learning-oriented and scientific (albeit I think that's virtually impossible because there's not enough talented and passionate teachers in the world, and without AI-support, I doubt there can ever be). But I think these old-school programmers are really missing what's possible in a world with 25M+ programmers. Social norms is one thing. But I think most developers think skill floor / barrier of entry, and productivity requirements are the bottleneck for DoD being widely adopted. I found DoD through a very indirect route, and I previously thought C++ and DoD was a tiny niche and way above my potential skill level. I was lucky to find some down-to-earth resources I resonated with and I'm now learning that C++ (without most OOP-features) is actually sometimes easier than OOP. So there's *CLEARLY* a communication problem going on. Once I understand DoD well enough, I intend to take a stab at clearing up this communication error, and not preach to the choir (or get on their high horse) like I feel like many DoD people do. Similar to science communication, providing falsifiable evidence in a very accessible and intriguing format is something that will spread very fast on SoMe's. I have a handful of ideas of how to achieve this, and if nobody else does it, I intend to. That is, if it turns out that DoD isn't just marginal improvements on average, and has huge downsides for the vast majority of the developer industry.
1 test is can you introduce a data type or class or component without screwwing up the rest of the code.
Computer education and those structures. They are designed in academia to solve theoretical problems. Sure they apply to certain real world problems, but I find more often than not they get used to account for "what if" scenarios. Its like programmers who work this way just try and shape the problem to fit a solution. They construct a much bigger web than they needed to solve the problem. The web they build will solve the problem and the a dozen other problems you don't yet have and might never have. I tend to find however that their "what if" scenarios never seem to actually cover where the play moves next. A little bit of "what if" is brilliant, it tends towards defensive programming and really makes you understand the problem. But if you do it at too high a level, you start inventing requirements, designing for them and implementing them, when there was absolutely no need to do so.
And lets be honest, these patterns and abstractions don't actually come for free. I have seen Java engineers argue that a double nested visitor pattern was simplier because it produced methods with only 1 line of code, compared to my 3 method solution where the average was 12 lines of code.
I had to sigh and draw their attention to the "True" complexity of what they wrote and how, unless you completely digest and understand the pattern it is just gobble-de-gook. Not least because when these people get down into the dirty they stop naming types specific things and start giving them academia taxonmy names, like "Visitor", "Observer", "MutexGateway", one minute it's Orders, LineItems and Taxes, the next it's Visitor and Deligates and the business logic extends deep down into the sea of academic bullshit.
I my 20 year career I have had to take apart, rewrite and throw away at least 3 death star projects that got out of hand and when the OOP priest left to spoil a startup's life, we binned all his projects at cost of millions because nobody wanted to work in that code base.
I find the same people stare at you confused when you say something like "Throw them through a set or dictionary, do some venn/Set analysis and then you can sort, pair and return them."
They stare at you like it's the first time they have seen Set analysis in code....
How do you know if a route you're going down is going to be complicated or not?
Is there a heuristic for determining such a thing?
it's a sliding scale, you can get a feel for something's complexity by how you feel when trying to with or on the system, also arguably complexity is relative, no point my system being deemed simple of you can't even begin to fathom it
To me it means having more moving parts than required (functions, variables, interfaces, libraries etc). Bringing it down to the bare minimum moving parts to make it work requires skill, knowledge and restraint
"früher war früher auch schon alles besser"
The problem is we keep finding ways to add code, but there's a dearth of tools and techniques for removing unneeded code. So we just keep piling on layers. We aren't going to get simplicity until we have tools that can tell us what can be taken away or simplified.
If you can add it with tool assistance you can also remove it without tool assistance. Because "I guess I'll have to wait 'til someone writes a tool" is textbook deferred responsibility.
@@alexbuhl1316 It's formal term is "cargo cult"
We need objective metrics to tell us whatever a given abstraction is "paying its rent" so to speak, or if it's more trouble than it's worth
The solution is a language that encourages short and direct expression of the solution. See apl or k programming languages
The tool that can tell you what to take away or simplify, and stop piling on layers, is called your brain.
That's the part (well, one of the parts) that all the people hyping AI as something that will take all software engineers' jobs don't get. Being a good software engineer is about understanding what requirements really are, building the thing that's actually needed, simplifying things and making them maintainable, etc. Having a bunch of fools ask an AI to write code for them doesn't solve that problem, in fact it makes it worse.
But you're right that there aren't a lot of refactoring tools that can analyse a codebase and help to cut it down and simplify it, in the case where the software engineers involved know the importance of that. And despite what I just said about AI, that's probably something that AI tools will help with a lot.
But actually being a human being that understands that simplicity is important, that maintainability is important, and that cutting down the size of a codebase and refactoring it is important, that isn't something that having a tool is going to magically fix. So I take a bit of issue with you seeming to blame the lack of tools as the cause of the piles of garbage code problem.
More editing required lol. For anyone reading I highly recommend skipping silence using a different media player
"values that can be empirically verified"
Please elaborate. Seems like an important statement.
The problem is not the lack of skills in programming in the industry, it is the lack of skills of building and programming systems than can evolve and change overtime.
Difficult to compare the video game industry and the line of the business industry as the horizon for a program/system is not the same
Probably anyone can program even the most complex program, this is the easy part. But thinking, designing, making the right design choice so this program can evolve overtime following the business changes is the shit.
this is not the sht it's actually quite trivial, just dont try to cast the entire program into some huge inflexible structure, keep things open ended, dont try and hide everything into a class hierarchy. people think this is hard because they keep trying to predict the future to find a class hierarchy that's just right instead of admitting they dont know what's gonna happen and keeping the program "raw" to increase flexibility.
If you want to make a game, I'd get the basics of c++ or c# for about say 6 months, then find a pre-made game template and work with that. (Granted you're a solo developer)
Why does it not have subtitles?
experienced programmers in the comments: What decent learning recources would you recommend for a beginner-medium programmer ? :D
It depends, what are you learning?
@@TropicalMelonMan C++ programming for computer Graphics :)
@@animaux1999 Then learning OpenGL would be a good place to start. For that, I recommend learnopengl.com
Look up "Handmade Hero" on youtube. It's a series by one of Jon's friends, Casey Muratori, and it is very good.
Also, Casey is working on a programming course he calls Star Code Galaxy. I'm really curious about it myself.
there are plenty of mit licensed renderers though
All of the old good books are still here. SICP, C Programming, etc.
It's less popular than CZcams videos and medium articles though.
People don't understand that programming is at the core all about algorithms and data structures.
You can add a thounsand layers of bullshit around it, but it wont make your problem any easier.
Agree with him 100%, however important to limit this in the context of Jonathan Blow's fantastic work: Game programming. Once a game is shipped is it done. So the dev lifetime is 5 years max. Corporate have systems that have to stay up, evolve and be maintained for decades. I completely agree that web programming is broken. I hope project such as Blazor start to kill this monster which is the Javascript ecosystem.
> Corporate have systems that have to stay up, evolve and be maintained for decades.
Yes, but for systems of any relevant complexity it is really hard to surmise the changes required within the next years, let alone decades.
When there's a bug in a game it's funny or you just patch it and nobody cares. When there's a bug in corporate software people lose money and you get fired lol.
Programming on your pet project is fun, you get to do everything you want your way, make tradeoffs as you see fit and the whole codebase is in your head. When you program on a project with 100s of other people, it's hard. You feel unproductive. You can't ship code without conforming and it's never gonna be quite your ideal, you'll never know the whole code bases anf you've got complex problems that come from not stepping on each other's toes.
It is what it is. Big companies can afford to be inefficient because each tiny brick a programmer adds to the system translates to a lot of value across all customers. Even if it's slow, and resource hungry, and hard. Making your own everything for yourself is fun, but doesn't have the economy of scale, generally speaking. Unless you make the number 1 app on a store or something.
We have online games that here for decades.
> Once a game is shipped is it done.
This isn't true ever since Steam became a thing.
Even Jonathan is working on a new edition of his first game right now.
Also, Elm is a really nice replacement for JavaScript's React, Angular and alike.
Really complex way of explaining why people should have a mindset of reducing complexity
With the painting, and the stuff on the sofa, you look a Comanche! Do you identify with temple OS? The old times...
hot take. programming culture is broken because consumers dont know how good products could be so they buy cheap crap. imagine if you are a shitty javascript developer and you listened to jon and became an amazing native programmer who knows all the amazing algorithms. lets think for a second about what would acutally happen. would he get anymore money from his job? no the company knows what product they are making and they arent going to change it because someone is suddenly more professional on the team. so what would happen? the new omega brogrammer would look for a job where he can get payed what his skills are worth and would leave the java script job. would that change the company now that the java script position was vacant? no it would not, they would just put up a job listing to replace him. and a young aspiring developer would see the job listing and get those skills to get the job. therefore the cheap java script culture would be perpetuated as such. so what would change the culture? consumers wanting a better product that would cause the company to put out job listings for higher tier products.
goddamn clickbait title
i agree about the web programming stuff, websites making is just a big stupid grunt work hamster wheel.
13:40 Social ideas a generally bad ideas
we are not averse to complexity... well, heck, you gotta start somewhere in order to understand much more complicated things.
11:06 - what he is saying is not true for Dwarf Fortress, for example.
You must have a special.
14:30 #Te anti #Fe
17:17 #Te
I've been trying to get into programming for years but I just can't stand it, there's so much wrong with the field itself and the way it is taught that you need an insane level of dedication to persist.
Lol
@@BNNNB ?
@@christopherwillson They probably think programming isn’t for you. Where are you now with programming?
@@thewiseowl8804 No further. With AI and no-code getting better and better it's not looking like I'll ever get completely into it.
@@christopherwillson That’s alright; I’m in a similar situation. I’m intrigued but intimidated by code, and I don’t exactly jump at opportunities to learn it. Still, I’m not ready to abandon it just yet. I keep thinking about it for a reason, and I’ll know if it’s good for me in time.
Yeah alot of rabbit holes out there. They spend so much time coding but so little time with good documentation and assumptions and design goals. So people can know if this is right for them.coding can be an excuse to do what you think is hard for you too do. So people just do it because they feel comfortable there. . In my small xp. Agree that cs is not really a science since it really hasn't progressed. It's nice that there is easier entry level and more choices. The only hope is that cs is the last hope of helping medical science since it can leverage The hardware. Things will get better
There is some truth to what he is saying but he is going way over the top into "you darn kids get off my lawn" kind of deal.
Jonathan, there are other people in the world who can program, besides you.
You are not the only competent programmer in the world.
Jesus christ. Jonathan really has a hard time with understanding the problem.
It is collaboration that is the problem. And he escapes it by never working with more than a handful of people he employed.
As good of a programmer Jonathan is, he is unemployable.
I'm not sure what's he saying.
15:38
16:15
Most of the developers (I don’t call them programmers) do nothing but copy/move some code from here to somewhere else, especially the Python and JavaScript guys writing trivial things out of zero creativity. They have zero idea how even memory and CPU work and the worst part is that they even don’t care lol
more chicks in the vidz plz
They want everyone to be a programmer, but they have to make 4 levels of tools and abstraction for most people to be interested at even trying. You can't just make people want to learn how. I never learned to program because it's a never-ending moving target, and no entry point seemed to be a good one. I refuse to be a cog in a social machine that does nothing valuable.
Even he's not saying it does "nothing valuable"
I just stopped reading about how to program and just tried programming.
Who is this guy?
a game dev
I love how Jonathan Blow go for a rant about the modern programmers while underestimating his own skill and assuming everyone has the same knowledge, skill and values. Programming games is completely different thing than doing web applications or desktop applications even. You need to deal with high level abstractions because you need work with the system below and don't invent circle over and over again. It is good engineer who will not be slowed down with low level stuff if somebody else actually solved it out and reuse the solution. Of course it has some limits but reusing and abstraction is something that made us create applications which are more accessible for users. Regarding even the gaming industry, while I don't like Unity, I can easily see that its availability enabled to boost creativity of small studios and explore game genres more.
Regarding the number of developers working on projects... well Jon is probably just better at programming than everyone else. Good for you. But not noticing it will make you old guy ranting about new generations.
Learning to program with python reduces programming to a set of trivial non-transferrable skills, like memorising names of libraries and function calls, as well as their quirks.
Simple seems good for engineering but not necessarilyy for a good game experience for the gamer.
Careful. Simple *programming* is amazing for the gamer. If your game runs at 120 stable with the same features because of great programming as opposed to just piling on those features and never optimising anything as is the current state.
I feel like Jon, & Casey are doing God's work. We need someone saying these things. Aside from them it seems like the only ones trying to affect "programming culture" are crazy sjw's who put social concerns, over technical.
we live in a society dot txt
Good examples can be found. I find C examples from 100-year-olds with beards, and they are pretty fun + (empirically, verifiably) useful.
Edit: here's one from _this year_ that isn't bad: czcams.com/video/URrzmoIyqLw/video.html
Outspoken leaders in these "successful game programmer" circles like to shit all over everyone who doesn't acknowledge their superior superiority, but the picture certainly isn't as bleak as they lead us to believe.
I really hate these kinds of rambling videos that pretend to have meaning. Like wtf is he getting at? What does he take issue with in "programming culture", which he leaves utterly undefined and unexplained? That there are bad programmers out there? Well no shit. Being bad at something is the first step to being good at something, isn't it? What does he mean programmers try to do things in a complex way? Is he criticising that programmers choose the wrong way to go about solving a problem? Isn't that just a restatement of there being bad programmers? What is he talking about virtue? Why isn't computer science scientific? Please explain what scientific science is to you then? Why isn't programming based on evidence? I don't know what CS is like in the USA, but here in Germany we do learn about the way a turing machine and the computer itself works, so I don't know what he's talking about. What science isn't "ideas that were communicated to them by other dudes" in the first place? If people aren't designing the thing that would solve their problem then what the fuck are they doing? Just so much nonsensical rambling. I mean, maybe some amount of "programmers" don't know how a computer works on the inside, but then they're not really programmers imo. If they don't have at least some understanding of what their computer does with their program they're just users of programming but not programmers, obviously. Being attached to some complex way of doing things just sounds like noob stuff to me, isn't it? What do you mean no selection pressure? If you can't program well you won't find a good job. That's as much pressure as can be, really. Either that or you don't make a product people want to use, or make a product that can easily be replaced by another programmer doing the same thing better. Or is this about programming and computer architecture having become so complex, that it's extremely opaque for newcomers? If so, then this is something I agree with him about. But that's also something that comes out of the pressure of optimisation. People with years and years of experience and the newest tech at their disposal keep optimising things to a point where it's hard to understand. That's something that happens in literally any field whatsoever though so it's a difficult topic, and not as simple as programming culture being broken. I think everyone that acts like they know well, what he means just want to feel smart and superior..
No, I think some people genuinely get or at least sympathize with what he means. I'm relatively inexperienced in programming but even I've noticed that not all of the impenetrable aspects of programming are solely born from optimization (and I don't think that's necessarily all bad). A lot of this discussion is about methods/philosophy of abstraction and frameworks for instance.
Though I agree any persistent issues born from this can at least in some part be attributed to inexperience or complacency on the programmers side. And I also think some of the more level headed comments following up on what he's said were more insightful than the overly cynical rant of the video itself. I think he over blows it.
@@IronicHavoc But my point is that he never clearly states *what* he means. If they empathise with the feeling of "programming being headed in the wrong direction" then that's just really really vague. That's my whole point.
I agree on the second paragraph aswell.
Thank you. I guess his way of making abstract claims about things being "bad" and "complex" resonates with people because everybody has experienced these frustrations but in different ways, and they can all fill in the gaps he leaves with whatever particular issues they have. I think if he would make his arguments more concrete they would fall apart and people would realize they're all thinking about different things.
For example, his complaint about the multithreaded entity system is so ignorant it pisses me off. His claim that all time is spent on rendering is just false for many games. Maybe somebody wrote three games and discovered "I always have problems with too much time being spent in the entity simulation and end up making it multithreaded for performance which introduces tons of bugs. I should make something reusable from it so I can save time in the future and only have to fix bugs once." And hey, he made it accessible for other programmers too so now they can just plug it in and increase performance for free, with the added bonus that the introduced code has a lot of mileage so it will likely handle many unforeseen issues for us. Reusable components are a way of _reducing_ complexity and that is at the core of this library's value offering, because now we don't have to keep that implementation in our working memory any more. Someone else took care of it and we can reason about things at a higher, simpler level. Sure, I bet the library author could have made it simpler, but making things simple is hard and requires many iterations and experience. It's a failing of human capacity, not of attitude.
@@MattiasFlodin EXACTLY dude. That's exactly what I was trying to say. Very well put.
Just to be fair to the guy, it's important to put things in context: he was saying those things during a live stream, to people who probably already knew him and could make more sense of the stuff he was saying. This video is just a clip from that live stream, and Jonathan Blow isn't the one who posted it.
The most opinionated developer on youtube?
Interesting to think about this now after Elon Musk took over Twitter.
I feel this is one aspect he saw and took on when he first came in.
Twitter was unnecessarily complex and he took the first steps to dismantling all of this cruft.
I don't agree with this at all, ECS is *objectively* superior to any other entity handling concept. There are benchmarks I could send him but it wouldn't change his mind because it doesn't matter to him. How good your entity system and your game engine is directly affects the produced game quality.
Vulkan is also vastly superior to modern OpenGL and probably DirectX 12 from what I saw as well.
If it works for you and allows you to do more things - great. Just be open to the idea that everything has its downsides and be honest to yourself by asking what downsides of ECS you see, and if these downsides take time from you or other people or not. Everything requires maintenance, and Jon and his team probably have enough code to maintain to ignore other technologies that won't address their needs. Shipping something to the world usually means losing many battles, and if they will lose performance battle it'll probably be caused by some other factors, not because they couldn't compute positions or attributes of tens of thousands of objects on CPU. :)
He's arguing that the performance gained by ECS is trivial compared to the bottleneck that rendering is (Vulcan's gains are mostly on rendering too). He's also arguing against designing a solution before defining the problem. These are both valid criticisms.
I personally develop in Unity which is ECS oriented and I use components only sparingly when needed (right now im using them on my UI for example). For instance Unity would like me to make a HasHealth component and add it to both destructible objs and characters, yet I find it more easy to use an interface with one method that gets called within Unity's event system and then calls a static method on my RPG class that calculates dmg. If I want to change the rules of my game I dont edit multiple classes, I just go to the relevant methods on my RPG class.
@@arbolarbol7876 What he's saying is basically immediate gains. I am proposing that instead of focusing on immediate gain, maybe that is 5 years or 10 years we focus on making something which will last until we die and after. I don't care about shipping games especially if they are built lazily. ECS doesn't have to mean you need a crazy elaborate system using templates and inheritance. It could be as simple as having a structure of arrays where each array is statically defined for a specific component. Then a way to get an entities components from these arrays where the entity is simply an ID. That in itself can drastically improve speed due to caching and also it's efficient in fetching a small related data member to an entity. You don't need to find a whole entity object or whatever. It helps with memory segmentation and efficiency as well. So overall it is better than simply having a struct or class which holds every possibly used member an entity can have. It makes multi-threading really easy to do. It helps even for structure and debugging, as you can easily list the components an entity has, disable or enable systems at runtime, etc...
Vulkan is also the lowest level and lightest graphics API we have which actually jon and casey were asking for prior to 2016. When it was released though all they can tell us is that "It's not low level enough, I need GPU bytecode" when that wasn't the original request. Jon actually instead said that "I just want to draw triangles I don't want to learn a whole ecosystem.". It is a contradiction. If you want a low level graphics API you will need to learn how the video chip and video driver works. Vulkan does just that which was your original request, to have a new lightweight video driver that replaces OpenGL as it is bloated and has a flawed design. OpenGL was designed for single-threaded usage and it uses a state machine. The command buffers are handled by the driver and IT decides when your draw call will be actually executed on the graphics card. Also the GLSL language is implemented differently on so many drivers which is a result of a faulty specification. Vulkan has SPIR-V to remedy that. Vulkan also allows for GPU memory management and you can define passes and subpasses before doing any drawing. So all I can say as a conclusion is the problem isn't with Vulkan nor C nor ECS, the problem is the lack of perseverance, effort and forward thinking from the person behind the keyboard.
@@SaidMetiche-qy9hb I agree with you on Vulcan and you make me wanna dive into it and also I disagree with everything else, tools and ecosystems wont outlive you, games will. Developers should focus on releasing great games, how they are written is only relevant insofar as it makes them easy to patch, update, etc.
JBlow makes two games over twenty years and becomes the authority on computer science. Guy acts like he publishes papers on algorithms instead of just using a graphics API to make entertainment.
He did better than you.
@@iamvfx You're missing the point. Grand claims should be backed up by grand credentials. Two games on Steam does not make you an authority on software engineering.
@@AirmanAJK By you I didn't mean you specifically, but most of us, he did better than most of us. Most games are low effort, not thought out noise, unless you have interesting counter examples.
@@iamvfx But he's only done work in this very narrow slice of software, yet he'll disparage concepts like JIT and cross-platform abstractions generally. Like sit down dude. Some of us are processing massive amounts of data from real-time systems across networks. Sorry your pixel shaders don't take advantage of tools we use.
Advice on learning to program, assuming you're not just a dabbler and want to make a serious career out of it:
1) DO NOT USE IDEs
2) PICK ONE LANGUAGE, IT DOESN'T MATTER WHICH
3) DO NOT USE LIBRARIES OR FRAMEWORKS
4) GET FAMILIAR WITH THE COMMAND LINE
5) WRITE SIMPLE PROGRAMS THAT DO SIMPLE STUFF
6) WRITE MORE COMPLICATED PROGRAMS DOING MORE COMPLICATED STUFF, IDEALLY REUSING THE SIMPLE PROGRAMS YOU'VE ALREADY WRITTEN
DO THIS FOR AT LEAST 6 MONTHS BEFORE YOU EVEN THINK ABOUT DOING SOMETHING DIFFERENT
@Jason Holtkamp You shouldn't be learning new tools until you have a firm understanding of the problems those tools are helping you solve. It's only then that you also understand the stuff that those tools are abstracting away from your awareness. That's how we end up with "programmers" building complex software with absolutely no understanding of what's really going on. My advice is to write your own libraries at first, ie create you're own little utility programs that you can re-use. Granted, in any modern language you're going to get a lot of built-ins in the core language, but that's okay.
and remember to turn your caps lock off
CAPS LOCK IS CRUISE CONTROL FOR COOL
@Abigail Jones 7. USE VIM FOR EVERYTHING. :)
What is wrong with IDEs?
Just bullshit, does he actually know the curriculum today? Here in Germany you learn at most University either Scheme or Haskell and Python at the beginning from professors who know their shit. Outside the university you have tons of choices today and I'm talking about online courses and not some random post and tutorials on some random sites. As always Blow creates a strawman to argue against for the purpose of ranting.
Do you know the curriculum today? Here in Poland none of those is true, we had only C/C++/C# and few mobile technologies. We had python but only because we happened to choose one optional subject that had it.
Online courses tend to do the same thing too, they teach you overcomplicated stuff because that's what gives you a job, but at the same time doesn't teach you the most important part.