Modern Languages Don't Help Solve Hard Problems (Jonathan Blow)
Вставка
- Опубліковано 12 лют 2024
- Snip taken from "The future of software development in video games - Jonathan Blow and Tiago Loureiro"
Original video: • The future of software...
#gamedev #gamedevelopment - Наука та технологія
"we've been stagnated since 1996"
Cobol has entered the chat
Cobol 6 has left the chat.
You leave COBOL out of this. It did what it could for its time.
In business programming - the hardest problem is NOT the programming.
That’s true of *every* kind of programming. Solving the correct problem is the bigger challenge.
@@BalBurghnot sure, there are genuinely hard problems in game programming and data systems or real time systems.
how is business programming different from any other programming?
@@codesquare9131 you think much less about the algorithms, tech and programming in general and more about the business domain and how to retrofit another poorly planned and designed feature 2 days before release.
@@ukrainian_spirit_show
"there are genuinely hard problems in game programming and data systems or real time systems."
Nothing comes to mind.
First hard problem is usually: "What I should do?"
Second, common problem is: "What name I should give this very unique concept/function so everyone understands?"
I actually have glossary in my hands, "global glossary" so anyone can understand, and project based glossary where I wrote new way to express things. Because obvious naming is not clear, I might give name "dingdong" or if it is really temporal name to something that is should removed, I put name like "poo".
That second problem is partially solved by conventions and glossaries, and programming experience helps but it still takes effort every day to think proper names.
Third common problem is that when software is written, how to make it stand the time over 15 years without need to rewrite. Then put it to perspective that people are making buildings that last 50 or 150 years.
There are actually simple ways to make software to stand the time like 50 years but in reality what happens, most of the software are designed to short lived and when the effort is made to write short lived software, it usually rot away prematurely. Fixing that million line of code efficiently can be very hard problem. Usually it causes rewrite.
Developer experience is easy to overlook in business
The project in my company atm has no documentation or tests. Can confirm.
one could argue that's a better developer experience...unless it's poorly written and issue prone, of course@@meltygear5955
The other guy is breathing so hard lmao once you hear it you can't unhear it
was going to make this comment; its so bad i cant focus
i didnt notice it and now I do, why would you curse me like this
I find it comforting, but otherwise it's caused by upper airway respiratory restriction (UARS) which needs medical attention
ARE YOU GONNA FREE THAT MEMORY?!
No. The OS does it for me at the end of my program :D
No, user can just buy more.
Rust: You WILL free that memory or else...
@@meanmole3212 you could always Box::leak()
@@leshommesdupilly lol yesssss... I have over 500k lines of code in my codebase and only just now started unwinding the stack because it didn't matter until recently.
I expected to hear how exactly it sucks and how he proposes to solve it. Every time he stops short without going into details. Of course we know how it sucks for us but I wanted his take on it. Just saying sucks doesn’t move us closer to solving it
@@forest-dweller consistent syntax is good, but it does not help one solve hard problems at all. Look at Lisp family for example, syntax is extremely consistent, does it help?
I agree, this is not a great talk. But I look forward to the day when his new game is done and the programming language can be released, so he can make a much more prepared talk
@@Muskar2 this is not a talk, it's a panel (well, with one panelit:))
@@forest-dweller I have played around with Jai and is good for that specific gaming solution. I think that most of the software problems come from the architecture and monetization or expected monetization instead of the languages themselves. What does Jai give you instead when writing modern C++... What does Rust give you?? There is also modern C... The only thing that I love about Rust/Go/Python and even JS is that you don't have to deal with header files, there are actually modern and good* package managers, and you don't have to deal with impossible to understand legacy code.
@@jacobitosuperstar can agree with this, beginner-ish here, mostly C#, Lua and a lot of shader code experience.
Recently started learning Python and besides the iteration friendliness of it, the big win of that I gotta say has to be ‘the environment’. Everything tends to work no matter where it runs, “import PrettyPrint” will work on a command line script, on Blender’s Python console, Houdini python runtime scripting, standalone isolated virtual environment, etc… it’s truly magic for me.
Some libraries bring it so far, like ‘PyGame’ to make games, that anything that has an embedded Python interpreter and access to the packages will be able to run that.
So, summary, the environmental, packages, libraries ease of use is probably a great thing to be solved. SwiftUI I read a lot about how good is becoming the swift package manager to kickstart anything from a better checkpoint.
I think Jonathan is saying that programming is like art. First it is abstract and it slowly turns into something less abstract. You are working with the nuts and bolts. And i think for most problems he is right. You only see the best solution for a problem if you are looking at the 1st kinda working version of the solution to that problem. In modern languages you dont have or are not allowed to use all the nuts and bolts... I want to work on the problem not fight the programming language or read docs.
Absolutely it’s an Art, but he is conflating learning how to use a paintbrush with creating a painting…
@@71Jay17 This is why i like programming in C, nuts and bolts. I hardly read any docs, ok for memmove() sometimes😀
@@martijnb3381 haha
Problem in development atm is the huge gap in security with the net result being people suffer for it the more critical the application is. I just see it as an area to grow with not a stopper to creation
more like; putting down your first stroke and expecting that to be your final one instead of starting out with sketches
I'm pretty sure Jon would strongly object to at least the second sentence.
It's 2024, not just languages, EVERYTHING sucks!
To the point I wanna build a mechanical computer as a professional software engineer 😞
Building something from scratch in C is still fun to me 🙈
??? that's such a terrible take
@@blackspider4 And that's such a great counterpoint
@@meltygear5955 these people complaining about GC and abstractions in modern languages have never tried building anything of scale. bunch of discord kids that don't have an opinion of their own and have only touched code when following youtube tutorials
Personal experience here as a contractor, ymmv. Nowadays programming sucks to me because there's a legion of people ready to criticize everything I do. From the language you picked to why are you not using framework XYZ or why aren't you writing unit tests (or if you are why aren't you writing mutating tests instead) or not using this or that design pattern or not using this or that development cycle. I can't just pick a problem and solve it, I need to follow a endless list of disparated requirements, some of them perfectly reasonable and making sense, but a lot of them just to satisfact someone's else ego because was their idea. I am just fed up with all this bs.
I've found that the best route is to ignore everyone else and just do it my way. People in different forums keep talking about all the problems with approach x or y, and what you should do instead, yet I'm tugging along just fine. A lot of people are almost religious about the "best" way to program. You HAVE to do it the BEST way! If it works, it works. Nothing else matters to me. The funny thing is that what's considered "best" keeps changing, and there often seems to be no consensus.
People have so many dogmas
I don't understand "programming sucks" at all. Things are now almost every situation better than ever.
The real problem is that we’re inventing languages to make developer skills irrelevant, but we will never get there because unskilled developers will always find ways to f it up. We turned programming into a circus… There are a billion libraries for hundreds of languages written so badly that no skilled developer wants to touch or maintain them… The code quality slowdowns surpasses Moors’s law, storage capacities, and compiler optimizations with geometric progression…
We need to start to differentiate coders, software developers, and software engineers…
Indeed - Tool makers and tool users.
Bingo
He's speaking mainly from a games dev perspective. Security and safety are extremely important for long running backend services.
Agreed but he's also hinting at a draft mode with really quick iterations in code that can be hardened before production, perhaps by having a strict mode. Whether this is a good idea or not is certainly a discussion worth having.
Trying out vague ideas quicky is the very essence of creativity. However it could also postpone a lot of technical debt to be resolved just before the system is made ready for production. Perhaps projects conform to some sort of conservation of fun law overall? The final hardening phase with nervous managers breathing down developers necks and uncertainty about the final release date will certainly be more painful.
@@DeclanMBrennan Wasn’t that Mark Cerny’s proposal decades ago with a pre-production phase before full on production on the game? I haven’t read his stuff since 2005, but I think that’s the jist of it.
I think this idea is flawed, I've made both types of software, games are harder and usually a superset of other types of software
gaming is the reason we have GPUs. So... it is very serious industry.
... As opposed to Javascript's mindset which is that no code is production code.
"Just simplify your code" lol.
yeah, not everyone has the luxury of rewriting everything 3 times until it looks good, and there's not one correct way to do things in a complicated language like c++.
@@duckhuntergaming4713 If you don't rewrite it until it looks good, how do you get your code past the code review? Don't tell me you don't do code reviews?
@@clumsyjester459 what's a code review? (joking) i rewrite it only as much as i have to, i'd rather make progress than write perfect code. also i don't leave memory deallocation for the code review or a later stage, something that jon dismisses as trivial in the video.
@@duckhuntergaming4713 I think he's saying that a "better" language would facilitate simpler code by building the data structures necessary handle the hard stuff for you. Because "looking good" is its own problem when a for-loop is easier to read than a while loop, and yet the 'while' version is faster than the one that looks good.
A while back, ThePrimeTime was doing a livestream about code inter-dependence run amok, referencing a string-trimming function that millions of software builds were borrowing from GitHub, and tons of people's code broke when the repository was moved (or something happened to it, I don't recall). The function that everyone was relying on was a very ugly while-loop that ThePrimeTime was saying should have been written in-house. Except when he did a real-time performance check, the 'while' was orders of magnitude faster. People used it because they didn't understand it, and a code review of that section (if it had been written in-house) might have resulted in a rewrite for comprehension/maintainability that slowed a game down (or a stock trading application, or whatever).
A better language would make the code easier to read without taking the performance hit, and without exposing old problems we've already solved (e.g. memory management, which could be identified via external tools rather than in the language at runtime). Having options in a complicated language in C++ is nice only when you have the luxury of understanding what you just wrote -- it's less-nice when you or other people have to go back and debug it 2 years later, trying to remember the pro/con decision tree that led to that particular snippet of code.
If the language offered fewer options while handling the C-like tradeoffs for you, and it ran just as fast as your preferred option... that would be better for everyone, right? Well, you're probably skeptical that such a thing could ever really exist. And that's kind of Blow's point -- we're settling for what we can get, but not really trying to tackle the harder problems that really lay ahead of us.
The larger systems get the harder it is to just 'simplify' it. It's just a silly statement @@clumsyjester459
Carmack said your brain is a faulty interpreter. Hence rust isn't for geniuses who know in their brain that yes that snippet of code will behave exactly that way. It's for adhd, lazy people like me who don't want to optimize stuff but are forced to due to the rust compiler. It's not for geniuses who can compile the whole program into binary in their brain. It's for silly geese like me who wants to make some app and be able to be relatively assured that I won't get a call from my boss/client that It's memory leaking or the app is doing something undefined.
You're just strawmanning here and ignoring what he is saying.
If Jon can't get productive in Rust, I definitely can't.
Rust doesn’t give a fuck whether you free memory.
Maybe it’s because it was cut from a longer session, but he was talking for over six minutes and said absolutely nothing.
I've listened the whole thing and have no clue what he tries to say
If you don't succeed at first. Try again 🙂
I think the stagnation comes from focus on making programming more accessible, which is a good thing on its own, but it kills great ideas that might have come from wide adoption of heavily math based computer languages. Like imagine C, but in 1996 it didn't evolve into an object oriented language, but it instead all the focus went into building software almost as a series of mathematical statements. Kind of like if formal verification went on steroids in 1996 and it bore into creation widely popular languages focused on mathematics rather than the OO wave we had throughout the end of nineties.
That's like saying "more people reading and writing is a good thing", when it is obviously not.
These things are not goods in and of themselves. They're tools.
Nothing gained from handing every person a powertool, lets say a jackhammer.
We would probably see a lot of road-/ infrastructure-damage from it.
With programming and writing, the barrier to entry being lower does the same. Bad writing does mental and physical damage to our culture. Bad programming can and does take lives, whether through timewaste, resource-waste, or accidents.
@@solarydays
Yes, we're so much better off when a billion more people with access to internet-cafe's can write and run scam-email campaigns and write insecure, unperformant code that somehow makes it into framework #91952 of the day.
Don't you see, quantity >>> quality! Nevermind that it vastly decreases the signal-to-noise ratio!
I like a lot of what JB says but it's really starting to bug me that he has way more gripes than solutions and gets so much more coverage than I would expect from someone that has only released two games in 15 years. Maybe this guy just likes to talk a lot.
Agreed - I also found this to be an incoherent rant. But he does have some wisdom, when he's sufficiently prepared. I must admit I strongly prefer talks by his friend Casey Muratori, because his rants are usually either pretty brief or elaborate enough to really understand his perspective and context.
Yes his comments about freeing memory also for me is very easy, because I have static tool checkers, and runtime checkers, I really have no excuse for having application shipping at all that doesn't free memory properly.
The difference is my apps are connectivity utilities and need to run 24x7
I like programming (I pretty much do all stuff in managed languages). But one hard problem is always managing complexity. And I think this is the issue Jon raises.
For example an RPG can have so many different systems to keep track of, it can be hard to try to keep everything in your head.
And it can be hard to try to prevent the code from becoming one big ball of spaghetti.
So it would be awesome if a language could help out here, in some way.
I find this fascinating. I completely agree with your and Jonathan's analysis that managing complexity is the hardest part of programming, and that when you're iterating on game design you don't want to spend time being confused by spaghetti code... but my conclusion is completely opposite from Jonathan's. I love Rust and for me programming became fun again when I moved *away* from the cowboy C style programming of mallocing everything, passing pointers, implicitly invoking UB everywhere and then when a bug crashes your game you spend hours in valgrind trying to pinpoint where you use a struct after free (or after std::move in C++). The thirty minutes I spend (with pleasure!) on Monday figuring out a nice way to structure my code, I save five times over on Friday when I don't have to fix a race condition that segfaulted the server, don't have to read bug reports from players whose games glitched in ways I cannot reproduce, don't have to stress a month before release because the code is an immense mess and the CPU usages needs to decrease by 50% before we can ship it.
@@SLiV9 Are you writing code using Rust or something similar?
@@TenseiCho I use Rust at work (and Python unfortunately), as well as for all my hobby projects.
@@SLiV9 Gotcha, thank you for answering. I was told the only things I need to learn are C & Python so that's what I've been doing in my freetime. I would imagine having knowledge of a low level and high level language is paramount to any programmers success in the industry.
DO NOT REDEEM MEMORY SIRS
sir do not redeem
Blow seems to have the wrong idea about what Rust's memory management story is. It's not focused on ensuring you free memory (though it does have RAII heap allocation containers). It's focused on preventing shared mutability problems, like iterator invalidation, data races, and use *after* free.
Does this change his criticism that Rust is hard to use when you want to iterate quickly?
@@sabelch nope
@@sabelch But is that really true? I have been using it for 3 years and I feel like I am prototyping new features with Rust with extreme speed. Have I lost the perspective to other languages or did I just learn the language and its ways of doing things with experience to be efficient and fast? One thing is certain though, I have zero interest in changing to any other language at the moment.
@@meanmole3212 I think you might have. It has something to do with rust enforcing incredibly strict rules during compile time as well as taking long to compile. You cannot iterate as quickly. No matter how fast you personally have gotten at it, I promise you people using for example Godot's GDScript or Unreal's Blueprint are gonna be faster by an order of magnitude. Unreal specifically gives people the advice to iterate in Blueprint and then migrate Blueprints to C++ when systems are more set in stone and performance becomes more important, and I think that's exactly the same idea that Blow seems to talk about: Iterate quickly, and once you know what you are doing you can optimise the parts that are struggling.
@@sabelch
No, but it's a pretty shit claim to begin with.
First off, nobody ever delivers proper evidence for these claims. It's always just thrown out there with nothing backing it up. I could probably find a a similar claim for just about every language, about how it delivers significant iteration wins over other languages.
Secondly, the guy never even used the language in the first place, so he can't even provide anecdotal evidence about his experiences with the language.
The problem is that Jon speaks as though there's only 1 problem domain. The performance demands of a game make GC'd languages a non-starter. But PLENTY of applications for code can tolerate 100x the perfomance impact of a GC.
The thing that can be frustrating about Jon is that he regularly demonstrates that he's more than smart enough to understand this. He points out that Rust is too restrictive for the fast iteration that games require. Exactly Jon! And C/C++/Jai has too much friction to development in other problem domains!
We all seem to understand that what's important is the "shape of the problem" (a term Jon himself has used) but we seem to completely forget this when we start complaining about languages.
"can tolerate 100x the performance impact of a GC". Is that your aspiration as a software developer? Have your software be as slow as possible as long as people tolerate it?
If Jon wrote such an app then it would probably be great, and fast as well. Should you not strive to write great software as Jon would?
@@T0m1s You're making such a bad amateur mistake. Speed is not the ultimate measure of a program's quality and it never should be. It is one measure of the final product. If you endlessly pursue speed above all else, you will fail utterly and completely, because (just like the memory leaks Jon is talking about in this video) you will spend countless hours squeezing performance out where it does not matter.
If I click a button and the corresponding command completes in 1ms vs 1us, it is a mark of being a bad programmer to spend hours squeezing more performance out.
This is engineering. You need to think like an engineer.
Yep so tired of people blatantly hating on OOP and GC just because xyz influencer said so.
@@zacharychristy8928 - before you go ranting like a lunatic maybe you could stop to consider that I never said one should pursue speed above all else.
Your idea that many apps can tolerate the impact of GC is sadly very common in the industry, to the point where performance is completely ignored unless the application becomes impossible to use.
However, poor performance impacts your users even if they tolerate it. I'm impacted by it every single day. The excuse is that "oh, we use GC languages because it makes us more productive", when in reality they should say "we're too incompetent to write code without GC".
"it is a mark of being a bad programmer to spend hours squeezing more performance out" - that comment right there is the mark of a bad programmer. By default your program should be fast enough, especially for trivial applications that are 99% of the software. It should not be a matter of "squeezing more performance out"! You should be competent enough and have enough professionalism to write code that is fast enough by default. What reason does your CRUD app have to be slow? What amazing feat of computation does it do that the UI feels sluggish compared to, say, Visual Studio 6 running on 1999 hardware?
@@skulver yeah, and I can agree with that. I think a base knowledge of what's going on under the hood and a healthy skepticism of your higher level language features functioning properly is a very good thing.
Yep! I'm in that subfield.
Memory Leaks are not a problem because you restart the game. Try doing that at a core business service handling a ton of cash. Maybe being a game developer does not grant insights into all areas of programming.
ever heard of k8s? Besides horizontal scale, a great lot of companies use it to restart their services when eventually memory leaks happen (even languages with GC can and will have memory leaks). The atomicity of transactions (as you mentioned cash) is handled outside of runtime in a persistent way, as there is no language/runtime to this day that can guarantee a leak free program.
@@D4no00
["as there is no language/runtime to this day that can guarantee a leak free program."]
But there are language/runtimes that can ensure most of the leaks are not a thing. So it is not a straight thing either.
@@diadetediotedio6918 can you list those languages? and at the same time prove that they are useful in the industry and not just some academic languages that are good on paper.
If you're doing your business software right, it can crash at any time and only cause a processing delay, no wrong processing, because everything is in a database and you work within a transaction.
I find that Rust worries about the annoying, tedious parts for me so I can worry about how the program should work.
3:18, whenever I'm developing alone, I understand every line of it.
5:43, I think using STL is a good strategy: use its containers, make aliases, and later turn them into something you want to deal (for performance, mostly), without lots of refactoring for its communications to outside the container. i.e. use std::vector, to later turn it into a static_vector of your own, for performance - if the compiler already didn't take care of it. The code will change only inside the container. So doesn't it matter how big is the project.
If you want to go fast the default should be an array (std::vector). You don't need the STL. But hash tables... yes, they have page fault per read/write. But trees... stored in an array to eliminate pointer chasing etc. Obviously grossly oversimplified but the perspective can be eye opening.
@@allanwind295 A static_vector is a std::vector-like deployed over an array. So it keeps the same syntax. STL is comfortable to use, leading to more productivity. I think it's good to start having automatic memory management. It makes it easier to understand things, if they are encapsulated, even more for a big project.
I agree with him. I am so frustrated with today's software and most developers and languages! We've go systems that are literally a million times faster (FLOPS) than what we had 30 years ago. And yet software feels just as sluggish but it consumes 100s of MBs for shit we did in 1995 with 4MB! And the features aren't increased either! Writing in Excel or Word feels the same as almost 30 years ago, but we consume 200+ MB and nothing is in the bloody workbook or on the bloody page yet! We didn't get 1000 times more features or 1000 times more speed increase. Hell even my Windows starts only 3 or 4 times faster -- and that's mainly because of my NVme. My Linux starts about the same speed but I am not doing anything more than I did in 1997. That was surfing and coding back then and it is still now.
Can't wait to see all rust fanboys in the comment section explaining how awful people are for not using rust and not thinking it's the best thing ever.
rust is the best thing ever and you are awful for not thinking so.
Rust developers criticize rust all the time lol
@@rayecast Rust is plagued by a very steep learning curve and a complex syntax with many operators. But I really like its premise. Even if it fails at effectively preventing panics which in my opinion is as bad as a crash or undefined behavior.
Just like I can't wait to see someone shitting on Rust without any apparent reasons but to hate in every single video about programming on internet.
@@diadetediotedio6918 I am stealing this comment
What is he trying to say? What's his argument?
What is a hard problem for him?
This dude needs to just shut up and build something like Linus Torvalds. Linus has given us Linux and Git without constant rants.
Linus Torvalds is a human being, he wasn't built, he was a result of two Finns bonking.
Linus is notorious for slamming people down if their opinions or code doesn't suit him. Jon has shipped two bestselling indie games and is now creating a whole programming language with a third game in the works written in said language.
js and shyton are OP, i see... we have REAL problems!
It's all about abstraction and matching it with the maths
I.e The sun ☀️ is a source , of light, illumination
The moon reflects the light of the sun
The moon orbits the earth therefore is prostrating to the earth , the earth orbits the sun therefore prostrating all these are relationships
Rain is droplets of sustenance coming from above, ideas and thoughts that help develop something into practicality is divine rain ( rain upon the conscience )
Abstract is the key
Nim seems to be interesting language with meta programming capabilities.
It's just my perspective but he makes problem solving sound so linear. It's very perpendicular, and above all the largest problem is determining what problems do and don't need to be solved. He's much smarter than me so maybe I'm just creating subjection where there is none. But the idea of modern languages is both intuitive in that we don't have to solve old problems and counterintuitive in that we don't know as much about how to solve new problems.
relax, Jonathan have a take on literally everything that ever existed, so you should take most of his claims with a very generous grain of salt anyway
The problem is that "we don't have to solve old problems" is like using the same tool for every job, which obviously isn't efficient. And then on top you have to make those tools able to handle scenarios that will never occur in your given context - and the more the abstractions are sporadically reused, the more fragile it becomes. I think DRY caused a lot of wasted development time because it destroys readability and maintainability when the layers of abstraction keep increasing. Mind you, it _is_ possible to create a great reusable API but it requires having both convenient, powerful and high automation one-liners and offer gradual tiers until finally giving the caller full control of everything.
@@Muskar2 That doesn't make much sense. I'm not sure how you interpreted what I said as "use the same tool for every job" because what I actually meant was "use the right tool that is proven to work for the job instead of inventing a new tool."
You wouldn't hammer a nail with a wrench, and it's pretty obvious that duct taping a pillow to a hammer would make it worse. If all you need is a single function among a library of hundreds, then the obvious better choice is just to write the function yourself. That doesn't mean you have to solve the problem of writing an entirely new function that does the exact same thing. It just means write it once yourself, abstract it yourself, and then use your own personal abstraction to make your own life easier. Once you personally have solved a problem, you don't have to solve it again. You just need to use the solution.
@@RedBerylFTW I know, and "the right tool that is proven to work for the job" is technically ideal, but I've found that rarely to be an accurate description of what happens when importing external libraries - unless you don't have very strict requirements. Take an ORM for example - some people would argue they're "proven to work for the job" except they're generally terrible and introduce a lot of unnecessary complexity. And that goes for most software tools, in my experience.
It's about realizing that abstractions have a cost, and black box abstractions are the most expensive of them all. That's usually not talked about by advocates of DRY.
Black boxes need to error handle every scenario possible (because they don't have any context) - which is very hard to get right - and even for bug-free black boxes, callers will likely have to fight unexpected side effects, performance penalties and escalating complexity. Many software solutions have deep chains of black boxes and go to great lengths to error handle all kinds of scenarios that would never need to be handled if they had not had black box dependencies.
0:14 I don't think Erlang came as a solution to a "simple problem"
1:18 Rather "it's important not to leak memory" I think the main concern is regarding security: poor memory management results in a lot of issues (ex. CVEs, cheating, etc).
2:04 Sounds like "just don't write bugs"
3:05 100% agree, that's why I think you should use a GC language rather than something with manual memory management
3:44 Agree, but this kind of features (ex. reflection), are better handled in GC'd languages (best example probably Common Lisp)
4:20 Rose tinted glasses. You don't miss the way you wrote code, you miss being 11 yo
I think Jon's main problem in this talk is that he's being secretive about his solutions, and he's clearly not very well prepared for this talk (I'd guess also slightly burned out judging from his prior remarks about not being sufficiently rewarded for his hard work). That defeats the purpose of the discussion
Agreed on the rose tinted glasses. Just like the baby boomers did, gen Xers are hitting their 50s and griping like the boomers did in the 90s except now they have a 24/7 platform to complain to anyone that will listen.
Totally agreed
good
Give me a C with fixed sized integer types and primitive inheritence.
I do not need garbage collection, etc.
For types you can use stdint.h, and typedef them to shorter names if you want. I don't use inheritance, but Google shows a few results, although I'm not sure about how much friction you would get using those techniques. Of course there is always composition-style OOP. Also, you could use a minimal subset of C++.
There are thousands of programming languages out there. I am sure there is one (multiple) which will meet your needs.
Fixed sized integers has been standard this... c89? It's my impression that OOPed for long enough avoid inheritance (and prefer using dependency injection which you can do in C either a compile or run-time).
Have you ever actually written C? Because it has fixed width integers: #include
So fucking true
If you know that hard problem you solve will be rewritten anyway, why not first solve it in a language that is easy to iterate in? Solve it in JavaScript, once you're clear on pitfalls and exceptional cases, properly rewrite it in statically typed, performant and memory safe language.
Rust seems to suck the joy out of programming imho
Same. I wanted to like it because conceptually it's really cool. However, 90% of my development time is spent fighting the compiler. I'm relatively new to it, so perhaps that pain would lessen as time went on.
@@Rambolink94 indeed. It will lessen over time. Fight the compiler now so you don't fight security memory bugs in the future.
i guess thats why js entering every space that shouldn't be in. its just so easy to whiteboard
Muhaha... started programming at age 12, still doing it every day at 50+... me too! 😀 But got to the stage of "programming sucks" ~20 years ago so now I work on hard problems and enjoy it. But if you think wavefront computing is "new", better look up Ivan Sutherland. Start with Alan Kay explaining who he was, _then_ check his "How Quantized Should a Digital System Be?", otherwise you would click away in 30 secs because _he is hard._
UA-cam needs AI so you can block recommendations just based on who is in the thumbnail…
Why not to teach yourself? Ignore and move on.
You are the last part of recomendation algorithm and every action (ignoring is also action) will train the recomender.
And there is those "Not Interest" and "Don't recommend this channel " options. Pretty effective tools, in my experience.
@@InforSpirit because the algorithm is incapable of differentiating between a lack of interest in the subject, or a lack of interest in the presenter. Obviously.
The real trick is learning from people you disagree with.
No general purpose language ever solves hard problems...
I used python to prove P = NP
My point is that the language doesnt do highly abstract things build in. Libraries n frameworks are given that task. @@MonsterManStan
But copilot does. It solves the hardest problem in Computer Science. Naming things. It comes up with really bad names but it is a step forward for humanity though :p.
@@wilfridtaylorbut does it decide when to invalidate caches?
I know let's make another javascript framework!
😂😂
There are some fundamental problems with Jon takes here, so, here I go.
1. On the matter of having "10%" slowdown
For Jon, it appears that something like Rust costing a 10% slowdown would made for him impossible to finish his projects (like he said). While I agree that the time he would take is an important factor and that it is maybe true that could not deliver such a product with a 10%+ slowdown, I don't think a 10% or more friction will equate to 10% of slowdown in the code your write. Your brain can just accomodate with more friction and in this case developing your own mindset about the problems you are writting will integrate with this, so the slowdown can be much, much less invasive.
The other question is about the flat statement on itself. While it can be true that Rust (or any other language that he dislikes on the matter) can "slowdown" him by 10%, he's stating it like that 10% slowdown will not reflect any other benefit with it that could result in a net gain, and this is a statement that he will need to prove (and it is not easy to do that). While it can be true that Rust can result in a net loss because it just "adds friction" and "slowdown development time", this is not an already proven statement and, in fact, Rust is knowed for having programs that generally "just work" when they actually compile because of the additional strictness of the compiler that will prevent a class of bugs and runtime problems (far from being just "memory-leak" things). If you take this in consideration, and the time you will spend debugging your code or trying to trace a bug that the language prevented by having this "10%" more friction/slowdown, then the time you where slowed down can be surpassed by the time you prevented wasting doing these things, so it would be a net gain. I think most of the time this is not a given thing, some programs will benefit from this strictness and it will really result in a cost-benefit situation, but some programs maybe not, but bold claims are almost every single time wrong and unreasonable, and they need to be justified and actually measured instead of speculatively saying "oh I would not be able to do it using X language because of Y".
2. Rust mindset is that "all code is production code"
I don't think he was clear on what he wanted to say here, but I'll assume he's talking about the strictness of the language and type system over defining what is expressable in the language to say that the code that is written in Rust will have a "production aura" kind of thing. If this is the case, then first I want to ask what is the borderline between what is a "development code" and a "production code", I don't think this line is well defined, at maximum it is extremely blurry. I think Jon know the famous """meme""" in the development area that technical debt is normally 'never paid'. Simply because, feature after feature, delivery after delivery, the time to "ensure correctness of the code, fix the messiness and make a good architecture for your 'development code'" can literally never come, and now you are stuck with a shitty code. This was actually one of the problems with the forager (the game) development, it is a problem in many instances and legacy projects as well (I have touched codebases with 10 years or more that are literally a giant mess of "development code" stopped in time). So that line he's trying to draw of "production code" is dubious at best.
For the second part of this, Rust is not so strict that you cannot write a mess with it, no language is strict enought for that. If you want to write shitty and messy code, but shitty and messy code that will still be safer and more foreseable than you would do in something like C++, then just use .unwrap everywhere, use Rc, abuse of constructs that will make the writting of the code so "direct" that you will not feel the friction nearly as much.
And for the "programming being fun" thing, I just think he's taking things so much seriously and thinking so much about the "modern programming problems" that he's removing every joy on his own life, like everyone who tries to compare the present with their idealistic and perfect past generally do. And of course, Jon is a 52 year old man, so... well, take what you want about this. But in the end of the day, just take it easy, programming , that's why I'm a programmer for so long, and that's why I want to be a programmer for the rest of my life if I can.
He's expanded on these points in other videos, but the main thing that applies in this one is that he wants to be able to iterate quickly (among other things) and a language like rust gets in the way of this due to slow compilation and being very restrictive. Rust may solve other problems in the 'among other things' category but it gets in the way of one thing he finds critical. having to abuse the language to make it less restrictive seems like switching a friction source to another; it'd just make it annoying, which comes to the point about programmig being fun: when you spend your time trying to get around issues/quirks with you 'tool' instead of doing the things the tool is supposed to be helping you with, it becomes somewhat of chore and demoralizing.
@@mobugs
Can you send me the link or the name of it? I want to hear how his expanded points go against what I said here, which is very broad.
As for your point on "abuse the language", I don't think at any point I suggested "abusing the language" or "not using it as intended", I think all the suggestions I provided are part of the language expressiveness, and not something like "switching friction" or "getting around". I think the things I said where very clear in general.
@@diadetediotedio6918 i think you can find it by "a programming language for games" my comment about abusing the language was referring to the suggestion of using .unwrap everywhere
@diadetediotedio6918 I don't think you are getting what he says here. He is saying that he will have to iterate over a game several times until he finds that game that is not crappy and that the customers will like. Once he has found that game he can then solidify stuff and fix the bugs. But the primary thing is to iterate until the core business need is met. No point in creating production quality game in the very first iteration that no customer will like. And Rust makes this iterative process very difficult.
game programming may not be the best point of view for a language designer. what is a hard problem ? parallel, concurent,realtime with lots of variables, database, and inputs ?
Every programming talk always say that the industry hasnt really moved forward fundamentally.
However, I don't agree.
Programming in modern times is far more delightful than trying to do it in 2000.
It is different and we have better more refined tools than before.
It's a wonderland of processing power and tools. And it's all so accessible.
Perhaps it's worth simply adding more visualization to the programming process? Programmers manipulate abstractions in their minds to implement code. However, what if the code(environment) itself were to assist in this, facilitating abstraction work?
I recommend watching the talk from Bret Victor called "Inventing on Principle". He tries to showcase your idea.
I've been thinking about this for a long time. Programming in a text editor seems so primitive, especially after I started using Unreal 5 and blueprints. Programming kinda feels like playing old roguelikes. It feels so dated.
Making a 2 dimensional projection instead of a 1 dimensional projection of something that conceptually has a far that exceeding complexity doesn't make much of a difference at all.
What are the specifics? What are the problems you need solved? Ok, you don't care about memory leaks, but what DO you care about? 'I don't understand how my program works' is not a language problem, sorry
to all people criticising jon, have you seen how bad modern programming is?
Its just the result of incentive structures... If there was a clear concept of what the goal is you could specialize tools, languages, patterns and education. Its maximum opportunism which leads to glue languages that commit to nothing and allow you to stick some random stuff you found together and create some MVP.
It’s like blaming the hammer for bad carpentry.
it will likely be equally bad after the release of jai, thats the issue
I criticize him for his abusive personality. His message however is great.
He is an abrasive piece of trash that appeals to an audience which itself has a lack of knowledge and experience but needs to feel elite despite their incompetence. Blaming the tool, just because you can't get shit done in a complex environment, is just sad. Why do you think he is working on his own projects all the time, all by himself?
However severe or not you think memory leaks are it still stands to reason (and data) that the earlier you squash bugs the less they pile up later in development. We see this with the Sea of Thieves devs who, before that point, were responsible for Banjo Kazooie Nuts and Bolts.
They did this through tests, mind - outcomes matter more for a lot of things than the sorts of checks the rust compiler is giving you - but even as a "super genius programmer" you have to pick your balance of performance, scalability and security.
As someone who's debugged memory leaks on SoT and knows how the game is being developed....
Another point he overlooked is that memory leaks and pointer bugs are often 2 sides of the same medal. And a large section of security issues found worldwide are related to pointer stuff and languages like rust try to tackle that exact problem.
@coAdjointTom It is something of an interest of mine so honestly I'd be interested to know more haha
Modern languages:
just = Just();
Just.doIt();
Nicely object oriented and clearly superior to the previously used justDoIt().
The entire point is that rust and other higher level languages makes programs more simple by being able to express things more easily and the compiler helping you. It doesn't seem johny understands this.
Programs certainly don't become simpler in rust. Although the compiler feedback is excellent
@@GepardenK I would certainly say that programs in rust are generally simpler then the same program in C or C++. Especially C programs where complexity quickly spirals out of control because the language has almost no abstraction facilities.But there are edges cases where this is not the case. Self-referential data structure for example are just a complete pain in rust.
I had this compiler written in c++. I never freed anything. Why would I? Such a tool does one job and immediately exits. Memory leaks are only an issue if you risk running out of memory. Typically, when you keep on leaking in a long running program.
Based 🔥🔥💥💥🤣🤣🤣
That's called arena allocation.
@@majorhumbert676Yes, I contemplated that, but I realized an arena for the whole lifecycle of the program would be pointless, so the program itself was my 'arena' :)
It was common, in the past, to just turn off Java's garbage collector in short-running apps. It did nothing but slow things down.
@@llamatronian101so you are saying that by doing more work (collecting the garbage) the program was faster?
Sounds like blow should try Zig instead of working on Jai
I don't think he'd like Zig because of things like being afraid of null pointers and the general safety culture of the language.
No offence but you’ve got no idea what you’re talking about
@@louisgjohnson it aint that deep
@@HairyPixels ?
@@leonss2356 jon has said many times that these memory safety issues are not the problems he has and they are easy to solve. Rust is the worst offender here but ZIg is also oriented around safety. The whole idea of not have hidden behavior is also kind of paranoid and not sure Jon would like that.
„Soooo you are saying we are not supposed to be a geniuses and express your whole program in dependent types and monads with all corner cases and no memory leaks at first try or your program wont compile?? NNNnOooOooooo!!! „ - haskell and rustard fanbois, probably.
I don't get the many complaints about programmers not being productive nowadays when you're doing nothing about it. Provide solutions and stop the constant rants 🙄
Solution is the hard work very few are willing to do anymore. I thought that was obvious.
It sounds to me as if he only cares about how fast the code is written. But don't be surprised if that mentality leads to an insecure, untestable, unmanageable mess that everyone will hate working on & will need to be rewritten completely from scratch in 1-2 years.
He cares about how fast it is to throw things away and rewrite from scratch. The easier it is the faster people can come up with a MVP and more time will be left to write the correct and reliable software. In game, you can build correct software from the beginning but if it is not what people want then you are just like any students with an impressive final year project.
The phrase "If your code is too complicated to understand where you should free the memory just simplify your code" makes no sense. Code that uses smart pointers can be many times simpler than code that doesn't, thanks to the smart pointers. Automatic memory freeing is a powerful tool to write good maintainable code, just like structs, functions, traits, etc. Game development is different than other kinds of developments.
The phrase "Rust's mindset is that all code is production code" makes no sense. Development is greatly simplified and accelerated by compile/write-time validation of the code. All code is intended to be production code. Rust helps you reach production code faster.
"When I was a kid I wrote a game that sucked and I was happy, now I'm a professional programmer and it sucks". I have 17 years of C++ experience. Yeah, it sucks. I have almost two years of Rust experience. Programming doesn't suck anymore.
This comment section makes me fully understand why people like Jon always turn off comments in their videos.
Being honest I wouldn’t find it weird for people to fully disagree on this one. I mean just think if this exact talk was given by a random person everyone would dismiss it. We are just hearing it because we know that this specific person actually knows the technicalities. However in this case it sounds like some who doesn’t. He is just talking that casually
Anyone with a job working on real software brainmogs John into oblivion it’s too funny reading comments worshipping him and his EVERYTHING BAD takes
But many things ARE bad @@usernamesrbacknowthx
Seriously? Some kind of worship without the possibiliity of even question or discussing anything he says is what you would prefer?
Only someone with a narcissism disorder or similar would prefer never to listen to the opinions and experiences of others.
Academic debate is fundamental to progress.
Sure, if there were just hateful comments and trolling it would be bad, but this is not what we see here. I see lots of people with long answers motivating their opinions in a constructive way.
@@TheIllerX, do you always first polarize everything to the extreme?
Rust absolutely sucks for that matter. As powerful as it is, it is time-consuming to write anything, and requires full alertness at any given moment you're typing, thus reducing the barrier of entry both on the population and the times at which you can feel confident taking up your Rust project. Just imagine managing the state of a full game in Rust.
“Just imagine managing the full state of a game in Rust.” Sounds exhausting.
I work in robotics. We use Rust. Do you think a game is more complicated than an autonomous robot?
@@DensityMatrix1yes it may be more complicated, especially with multiplayer involved. What is your experience with Rust? Do you iterate fast?
@@DensityMatrix1 games are way more complex than robots, but state management in games is in another universe of complexity than state management for robots.
@@molewizard okay buddy. I’m not talking about Legobots. I’m talking about fully fledged production autonomous robots. State management for a robot includes: scene parsing, people and object detection on gpu, planning and control. Integrating Optical cameras, depth cameras, lidars, hardware safety systems, telemetry. Extremely tight control loops, RTOS for special devices..
jon is a bit stuck in his own bubble bc there has been many projects, including languages, that try to solve the parallelism issue, and a lot of strategies for green threads. It's just that they are not low level system languages, as automating that while still giving control to the user is very challenging. I guess Rust is the only one that tried stuff for that , like making threading safer, and async features. too bad Rust is garbage
rust garbage why?
@@thedude00because it would require learning something new and that's a lot of effort.
It's easier to just debunk it as garbage.
> a bit stuck in his own bubble
> too bad Rust is garbage (end of message)
Classic.
haha, lots of Rust fans here I see. Yeah, maybe I was too harsh in my comment. But yeah I don't like Rust for a few reasons, including how slow the compilation and the tooling is; and how strict and opinionated it is. But yeah I did learn it. I've used it for years, professionally. Still am. So that was a wrong assumption to make.
It has a lot of good things too, of course. The syntax is great. Sumtypes are great. Lots of good stuff.
Why exactly Rust is "garbage"?
I would love it if a "speaker" like that came with an actual proposition for enhancement of x, y or z language.
Ok, so GC is basically useless but complexity should be resolved : show us one way it could be done, instead of saying it shouldn't be like that.
Because if you don't have a clue about how it could be resolved maybe you are not competent enough to say that this other problem should be ignored in favor of that one.
he is been writing his own programming language from scratch for game devs, I am pretty sure he applied what he said on his own language
@@fornonplayers3668 let's be specific : he started Jai in 2014, it's not released and it's a domain specific language that does not solve general problems like the things he criticize in general purpose programming languages.
If he creates a general purpose language that is just like he says (easier and fun to write, reduces complexity, reduces the amount of code required, etc...) I would gladly applaud.
To me it looks like it's just his ego that is way bigger than his skills.
"domain specific language" is a term that means, like... SQL. Jai is clearly a general purpose language
@@Jack-sy6di oh it's great then! Can you post the link to the docs or the download page?
@@Grouiiiiik There's information online about it if you are curious. What problem with waiting to release it to the general public do you have though?
Jon blow is probably the only human being alive that can bash garbage collectors for impacting performance and in the same breath say that languages need reflections...
Having metadata shipped with your code doesn't do anything to performance
@@saniel2748 Yeah, unless your whole program is filled with and fully depends on that metadata as is the case with dynamically typed language (runtimes), on top of it you can slap on a garbage collector, performance is already bad enough anyways.
C++ 26 reflection is static reflection which means at compile time. We'll be able to generate code based on that reflection allowing us to eliminate code generating macros and achieve better safety. I'm looking forward to it, i love compile time coding. Reflection will make c++ even better and the learning curve even higher hehe.
@@indiesigi7807 static reflection? Now that's what I call pointless. If you can know the type of a thing at compile time, you probably don't need reflections to begin with...
@@CEOofGameDev Yeah, I'm not going to lecture anyone with this amount of ignorance.
Don't expect languages to do too much for you. Expect too much.
There are no hard problems.
"Try to solve the problems that are really hard". That absolute statement makes no sense unless we are talking complexity classes (as in P vs NP). What problems are "hard" in your setting? Making sure the nuke plant behaves correctly and all loops terminate provably? Making communication between software agents manageable? Making the user interface actually usable and discoverable? Generate pixels really fast? But yeah, C++ is the optimally bad language for everything.
I think in terms of games the hard problem is just realtime nature of it
There are many bugs that have no single point of failure you could put breakpoint at and are rather result of system working subtly incorrectly over time
I've seen video from web dev person who tried to make a game and it was something incredibly hard for them. Kinda clicked for me then
Not sure how language could ever help you solve this though.
But then again jon might mean something completely different here and I would've been blocked for saying any of the above on twitter by now
This is the problem generally, there is not a formal definition of "really hard problems" in this setting (unless he is talking about provably hard/impossible problems, like P=NP or the halting problem, but in this case nothing will help you).
Hard is the opposite of easy
A better approach to what C++ attempted to do are actually layering a scripting language on top. (Pick your favorite: Tcl. Perl, Python, Lua). And oddly enough Tcl, Perl, and Python were all in common use by 1996. For that matter, BASIC is also an interpreted language. And BASIC is older than C. We need a toy/DSL language that frees us from the petty details, and a deep wizard compiled language that lets us write optimized routines and low-level device drivers. Any language that tries to do both has been failsauce.
I'd like it if they talked about the real problems and didn't dismiss all language developent in the last 20 years.
He’s 100% correct.
Memory leaks are fine! We'll fix the problems later! I don't need to write clean code! Code faster! ...wait, why can't I understand my code? That doesn't come across well.
It sounds to me, not a game programmer, that games need better frameworks, and domain-specific languages, rather than borrowing C, C++, C#, Rust, Python, or anything else from the developers that know you can't fix memory leaks and race conditions later.
Elegant objects and the true encapsulation the answer
A damn fine book. Actually mind opening.
So Smalltalk?
@@GamersUniverseOE definitely yes
Rust is a joke!
It's like a "Peanuts" strip, where the deluded cultists are Charlie Brown, the cult leader is Lucy, and the language definition is the football. Here's this feature (e.g., typestates) that one obscure research language used 30-40 years ago and nobody has touched since. I think it's a good feature, so I'm putting it into Rust. Oops, turns out there's a reason nobody else copied that feature, so I've removed it and any code that used it won't compile now. So re-write your debugged code and then get to work fixing any bugs that got introduced in the process of re-writing it. Feel free to use this other feature I've just added, I promise I'm not going to pull it away from you a couple of years down the road.
At the same time games are not important for humanity, in fact they are irrelevant, in fact if they disappeared we would be better off doing things that are useful. So no, problems in games are not hard. The reality of the world is hard.
Christ he got it very wrong.
Creating bad code first results in bad code out the door thats a fact. The reality is when the budget and time pressures hits guess what gets chopped? thats right, that last tasks of the security & code rewrite.
If you’re wrapped over the knuckles every time you create bad code: you get good. Your patterns change and your performance increases naturally with experience! It’s not a sustained problem contrary to his preference of constantly creating garbage.
@@solarydays
So you missed the point entirely. Whats sad is you think there is a difference. “real” hahahaha
@@solarydays “so strategic hes on a different planet”
hahahaha
@@solarydays hahahaha
I like this guy, seems to have a common sense attitute to programming.
But I don't really understand his objections to moden C++. Sure, multiple inheritance often result a mess, but STL?
That is the complete opposite. That heavily reduces the mess, by not forcing everyone to invent the wheel over and over again and waste time implementing sorting algorithms for the millionth time.
Individual element thinking vs. group-based thinking. Atomized black boxes with overreaching error handling vs. context-aware lifecycles that solves the exact problems at hand.
Excuse-me. Memory leaks are super bad, super critical. Yeah, Johny 15 years old playing CyberPunk, will reboot his computer if he has too... but... When you're coding for a bank, server applications that run 24/7, repeat what you said about memory leaks plz.
Jblow is again right.
Modern software is just an organizational tool to scale up the software industry. Politics, essentially, but for people that are specially bad at politics and socializing. (Programmers)
Dennis Ritchie made C after making B and UNIX.
Chris Lattner made Mojo after making LLVM, MLIR and Swift. Blow even has the audacity to make fun of him...
Jon Blow makes Jai after making Braid and The Witness claims it's gonna be better than anything out there, he also mentions many times he'd make a better OS than Windows (because the bozzo thinks Windows is better than Linux) but he doesn't have time LOL!
Who's BSing you? If you've played Braid and The Witness you should realize who's trying to scam you, or who's playing a character since the Indie Game documentary, is kinda sad he has legit people who thinks he's capable of pulling this off. Odin and Zig have better origin stories and teams with people way more capable than Jon and his team. But you do you homies, my guess is that you're probably too young to detect this grift.
Serious question, will you recant this statement if JAI releases and manages to become a real contender in the low-level language space ?
Yeah of course, random internet person? That would be awesome@@KennethBoneth more languages the better.
I don't like the fact that's not Open Source either, it makes it even impossible to benchmark or audit, and I think Jon has a rather bleak view of Open Source. So likely I wouldn't use it, there's not that many closed source languages out there that do or have done well either way.
@@IgorGuerrero Jon has said that the language will be open sourced once it releases.
@@imranzero Good to know.
To be fair, The Witness was developed using an in house developed engine, and Thekla is making supposedly 3 games using Jai. Dude can develop tech, we just need to see if it is actually going to be that good.
I wouldn’t go as far as to say he is full of shit or scamming people, as nothing was asked of anyone at any point AFAIK
He makes points that are very tunnel visioned but make sense in some ways, we just have to wait and see if he’s right.
I love the authority Jon Blow speaks, one, if not educated, would think he designed many languages... But honestly, he just doesn't have the credentials for this nor the knowledge, and makes PS2 looking games in 2024, you don't need a new programming language to solve that, just use UE5.
Did Dennis Ritchie design languages before C?
He stated multiple times that he designed multiple languages over the years. He just didn't publish them
Just use UE5 and force users to play your game in 480p and DLSS.
the stagnation he speaks of is not in graphics accellerators.
To make PS2 games... My point is, he doesn't need any of the tools he claims he needs to make @@CringeBruhovski
Boring and generic talk
The problems he's describing aren't language problems, it's architecture design and process problems.