The point he tries to make is that, in order to design "good" programs that run "efficiently", you need to understand how a computer works. Languages and tools that abstract away the nature of the underlying hardware lead you away from this. In the long run, complexity and abstraction provides convenience, but it comes at a price. The language itself or IDE are interchangeable in this argument. He just uses C++ to underpin his case, because C++ allows you to go all the way from C-simplicity to VM-memory-managed-complexity.
The point he tries to make is "people writing dev tools have historically done a terrible job and nobody seems to care. Things can be much, much better"
I think a more accurate description is that language designers, in general, have been solving the wrong problems for a *long* time. And, then, these things get adopted dogmatically whether or not you can prove their usefulness in an empirical way... Like outside of a silly, trivial example that would fit nicely in a book. You can apply that to any "high level" language.
God, I hate this quote. It takes a long time to make a good language. People complain about C++ because all other languages bought into a bunch of really bad ideas. So we're stuck with C++. Personally, I moved on to vanilla C. People that give this quote to every critique of C++ are the crabs in the bucket, that keeps pulling the escaping ones back in.
@@tah3460 Cope all you want. Say all you want. The language speaks for itself. And if you knew how to actually use the language you would not be in Vanilla C in 2024... Good luck with your coping
@@tah3460 C++ is not perfect. It has to deal with imperfections and could be better. That's not what I am denying. But improving an efficient multipurpose language that is applied on a massive scale is far from trivial. And Jon just doesn't have the answer to that. He also lacks the formal theory required to advance the language space. He is just a low level dude who thinks to understand high level stuff.
The fact that you and Bjarne think this quote is a good counter argument is really telling of the programming culture. There are good things about C++, the fact that it's stable, the fact that it has many good compilers, the fact that it interacts well with C and system apis. There are so many good things about c++, popularity is a by product not an argument for anything. But this is truly emblematic, programmers don't care about quality, they care about it in so far as it brings popularity. Popularity is first, not thought of as by product of good quality but as the main target. Whats even scarier is that programmers then use this same metric to choose tech. This is the reason why the web programming is like it is. Its the same logic but from customer side (who are also programmers).
I've seen a number of projects where they have to simply shrug their shoulders and start working around poorly understood behaviors that seem to be emergent properties of the specific mix of proprietary black boxes which nobody is willing to own or investigate. Whether that's "bad" or not is left as an exercise for the reader.
As someone who is still learning to code I found that learning to code unreal engine is not learning to code. It's learning to use their ecosystem which has some c++ structure, so I understand what he means.
Yes. You should learn C++ by itself. Everything else is bs. Learn pure c++ specially pointers, references, dereferences and memory adress. Then the heap and stack shenanigans. I recommend the coredumped channel here on youtube.
@@ytdlgandalf It is. However it is built around using the editor. Most of what I've learned starting out is how to expose classes and their variables to the editor to then use them there. Can you 100% write into c++ classes Or write game level logic in the level file? Yes. But that's not very practical. Especially in a team setting. I tend to learn more by looking at a blueprint and then reverse engineering it into c++. If you are learning, then it's a good way to understand dependencies and how inheritances works. I guess. But it has a lot of its own APIs, which means learning ITS systems rather than c++ utilities. I'm feeling like I'm learning more 'coding' writing a program that's going to parse a csv file and output values from a specific column. Keep in mind I'm a beginner at both c++ and unreal. These are just my initial impressions.
he says in the end that C++ is okay even though it's getting crazier everyday. Instead of the title, what he's actually talking about in this video is that languages that don't allow you to do memory management yourself are bad
I agree with most, but not all, of this. One thing he's forgetting is that all of the standard container types in C++ allow you to supply whatever allocator you want and default to the implementation's version. You could, for instance, make an allocator that only uses the stack or the implementation you're using could do the same, or even just use the stack for small allocations which makes sense anyway. However, not everything should be allocated via the stack, nor for that matter should everything be on the heap. As far as RAII abstracting away implementation details such as when a file gets closed, I don't see that as a problem. For most files you need to open it's better to load the whole file at once and then close the file handle. For files that you need to stay open for longer, then presumably you would open them in a higher level function like main() and just not close them until the main loop has exited. The only thing I would ask Jon Blow is when is Jai being released? Hopefully he releases it before I release my own language, but I'm nearly done and just kind of monkeying about by implementing code generators for every target I want.
I don't understand his criticism of Vulkan. The whole point of Vulkan is to provide the lowest level API for graphics programming. You manually allocate GPU memory, you manually create textures and assign buffers to them, you manually create dozens of command buffers so that they stay on GPU instead of having to send thousands of commands through a driver every frame. Somebody who cares about performance, like Jonathan Blow, would absolutely love Vulkan as it offers unparalleled performance gains. And you can't learn Vulkan without learning how the rendering pipeline works on the lowest level. You can't draw anything on the screen if you don't create vertex buffers and execute a command buffer to draw them using specific shader program to some framebuffer. There's a bajillion of boxes connected to one another because that's how graphics card works, it's really complicated. There's a reason we mostly abandoned higher level APIs, like OpenGL, they're fine until you come across CPU-GPU bottleneck. So him criticizing Vulkan's "ecosystem" seems very backwards to me.
My interpretation of his view on Vulkan based on hearing him talk about it a number of times is, even though you can call Vulkan relatively low level in terms of what is available now, it's not low level in the way you program a CPU. When you use Vulkan, you are still just making an API call into a black box. The black box may have more knobs and simpler primitives than the other black boxes, but at the end of the day, it is still the one making decisions about things like instructions and memory layout, not you. He is saying that you should be able to program the GPU without having to go through anything like Vulkan in the first place, the same way you can with a CPU, it's not that Vulkan is worse than the alternatives.
@@everalert To put it concisely: "Let us bit-bang our graphics cards like it's 1994 again!" A sentiment I can get behind. Hardware is interesting. Libraries and APIs, not so much.
@@Roxor128 As someone who dabbled with VGA Mode 13h I can't really agree. It's fun to be able to draw pixels directly to the framebuffer, but at some point it's no longer fun to optimize it in ways that actually make sense from the hardware's perspective. Back in MS DOS times everybody had to invent their own graphics engine and that was fine because almost nobody needed to hyper-optimize their 2D games. But when 2.5D and 3D games started to appear, it became clear that we need hardware accelerators, otherwise we can't keep up with increasing resolution and player demands for better graphics just using CPU writing pixels to screen. And that's what happened, we got first accelerated graphics cards that had 3D acceleration and it became very obvious we can't talk directly to hardware anymore as the API for graphics card was incomprehensible. It's not as simple as writing pixels to mapped buffers, you have to talk in the language the graphics card understands. There's no way to go around Vulkan API unless you want to reinvent the entire graphics driver with its proprietary interface.
pure C is best imo, but it's a lot easier to hire a c++ than a c programmer. also, writing state machines(which is probably the majority of gameplay code) is just too cumbersome in c. one last thing, as much as c programmers don't like templates and overloading, they are surely a better solution to code duplication than the horrible macros c uses.
C is not a better language than C++. It is simpler sure but C++ actually allows you to do great things. To me the confusion is that C++ had multiple languages in one. C++ can be used in a very java type of programming with high level stuff everywhere, exceptions as your main type of error handling and meant towards building your standard app. You can also build your c++ in a style where every object has its own static memory pool and your program will never have use more memory than what was present at startup. You can also create programs to build express and handle pure logic language with operators and everything. You can also just do C+ which is C but we a little more convenient stuff by having templates, better cast, implementing a defer statement for resource handling etc. C++ is very versatile and way more powerfull than C, but it is difficult because you need to understand what you want to build with it and what subset of the language will help you with that. I still love C but arguing C is just better is not true at all.
I write my (mobile) indy games in C, but that's as a hobby. I don't like the long compilation times of C++ and I also _like_ to reimplement everything (data structures, algorithms etc). But I understand that for actual professional production C++ is used. Even when using plain C, I end up reimplementing a lot of object orientation that would come for free with the language with C++. The best for me would be a C++--, with all the features they piled on top of C++ in the last 20 years removed, and going back to being C with (simple) classes, nothing else, and I would use C++ then (and it would be probably way faster to compile)
@@YellowCable you can choose to do that, using c++ with only a subset of the language. I would say it is the only way to do c++, choose the subset you want to use.
You do know you can embed the C language into Lisp sexps and then use quasiquoting macros(compilers) to generate C-code and exponential more power than just writing C directly.
Manual memory management is really easy. Passing blocks of memory to functions that need it really clarifies what is going on in your program. The worst thing you can do is call malloc or other such allocator within a function. Because you're gonna forget that you called it. And by the time you remember, there's a thousand memory leaks in your program.
I’m not sure I completely buy into the argument for a few reasons. First, it’s completely legitimate to run your business off of Excel, rather than use an off the shelf or customised solution. Whats that got to do with programming? We program to facilitate real world goals… as long as we can achieve those goals, we win. Second, a language is an abstraction over an instruction set, intact, often it’s a few layers above that. But an instruction set is an abstraction on top of hardware. That hardware itself has layers of abstractions below the instruction set. Just because you use a low level language, doesn’t mean you are free from all the levels of abstraction. Third, just because you use a low level language, doesn’t mean you’re using it effectively, and it doesn’t remove the need to use third-party libraries, which provide layers of abstraction that indirectly control.
"... as long as we can achieve those goals, we win." Isn't that like saying as long as the code runs who cares if it's implemented following SOLID principles and design patterns?
@@ifstatementifstatement2704 I’m highlighting that there is nuance in the real world, and highly optimised code doesn’t alway/often have a majority impact on real world success. Another analogy is biology… evolved… all life has to continue with legacy genetics from the past that may not be useful or efficient, and maybe even detrimental, yet life… ah… finds a way. lol. So to with programs and the people/companies using them.
@@br3nto I think you are missing his point, and maybe it's because the video is cut short. He is talking about performance critical scenarios, where the code has to run things as efficient as possible. Yes, you can run your business off of Excel, you can even program very small games in Excel, but you won't be able to render a 3d graphics in Excel.
@@narekmusic no I’m not missing the point, and I’ve seen his other vids talking about the same thing (and also Casey’s vids). I just think they are off the mark. They’re right for a small subset of why we program.
Yep, this is not the first video where I see the concept of abstractions in programming being criticized. For example I have also seen criticism on the entire concept Object Oriented programming for example. Abstractions can make things harder to maintain and harder to understand. Both by adding more complexity and by increasing the distance between the programmer and the hardware. Although I generally still believe that higher level languages and especially GC languages have valid use cases, because they simply make development faster in many cases. But I do really love and very much believe in Rust, even though it has some serious challenges too, such as not yet having a stable ABI, longer compile times and a significant learning curve. One of the biggest challenges to improving things is dealing with all the existing architecture. You cannot simply put C and C++ away. Everything still depends on it. And not to mention how strong the world wide web hangs on JS. That's a lot.
I don't think RAII is bad. I think destructors and deterministic memory management is one of C++'s strengths.... but maybe that's just me. I am interested in what other people think of this.
How is it deterministic if you don't know when the memory management happens? If you have a shared pointer to something, refcount goes to 0, the destructor is called. There's really no way for you to know when this happens exactly. Automating the memroy management != making it deterministic. Deterministic means you know the exact point at which your objects are removed from memory. RAII is very close to GC, except it's a lot more effort.
@@filipg4 Deterministic just means not random. A refcount going to zero and immediately getting deallocated is not random behaviour is it? No, but GC is non deterministic since you have no idea when it will happen. You don't have to know beforehand when exactly an object will be deallocated for every single possible input, you just have to know that it is deallocated when there are no references remaining. That is what makes it deterministic. There is an exact point in time where it happens. If you ran a single-threaded program with no random-pauses an arbitrarily large number of times with RAII memory management, you would observe objects being deallocated at the exaxt same in terms of instructions every single run. That is what makes it deterministic. What about with multiple threads and random pauses? Then all forms of memory management are non deterministic. Just imagine deallocators as the free function being put at the end of each scope, sometimes with an if statement.
@@filipg4 RAII is deterministic since it is (1) not random, and (2) always happens in a predictable pattern/order after a set of conditions have been met. Garbage collection is on the other hand, not deterministic since there are no guarantees or knowledge about when a collection cycle will occur and an object will be freed from memory. If you introduce multiple threads and random pauses then you could say it's non deterministic, but then all forms of memory management would be non deterministic, even if you did it in C, you wouldn't know when or what order something might be free'd. So you can't make the argument that RAII itself is non deterministic unless you want to argue that all memory management is non deterministic (which it isn't). The basic idea being you know when something will be deallocated given the set of inputs and system configuration, the set of instructions will always appear in the same order. The same cannot be said for garbage collection.
@@filipg4 The thing is, you DO know exactly when it gets deallocated. It is exactly the same as explicit memory management in C, but it is automated for you in C++ so you don't have to think about it. There is no difference, it is just hidden from you. You said it yourself. The objects get deallocated when the counter goes to zero. That is deterministic. It happens there and then. It's not like the counter goes to zero and then some non deterministic amount of time later a collector comes along and frees that memory (that would be non deterministic), it happens as soon as the counter goes to zero (excluding compiler magic optimizations). That is deterministic. You know exactly when and where the deallocation happens, it's not hidden away from you in some mystical garbage collector runtime.
@@filipg4 The benefits of RAII is the fact that you get determinism and you don't unecessarily waste memory footprint. GC managed languages need a large amount of additional memory and resources to compete with non GC languages. RAII simplifies the manual memory management of C into a somewhat automatic management of memory, without sacrificing performance or memory footprint (a zero cost abstraction). If RAII is so bad then you would see people flock to the hundereds of garbage collected languages we have around, but they don't because there is an inherent trade off of automating memory management and application performance. For games in particular, every ns of performance counts, and the cost of non-deterministic memory management using a garbage collector is far too large to justify.
I think abstraction is good and necessary. Imagine if instead of using something like a std::vector or an std::map you would write a hand tuned version, every time you needed such a data structure you wrote it from scratch tuned to your specific use case, because maybe, there is a particular hash function better suited to your keys or you can extra clever about when and by how much to grow the vector and if you are at it, why not write a custom memory allocator? No you use abstractions and only replace them when profiling reveals them to be a problem. Good languages support this, e.g. by giving you stuff like generic data types.
As a non-programmer who works with other non-programmes who exclusively use managed / interpreted languages, I don't really have a choice. If the job is to write some Python code that calls some API in the cloud, there's no chance anyone will accept functionality written in some high performance, low level language, even if that functionality is correct and outperforms the Python version. Why? Because it would force the people I work with to learn this low-level language they currently don't know. This is a cost most companies, depts, teams, w/e will not bear.
I haven't looked at Python since... Well since it came out but if I remember right wasn't one of its big selling points the fact that it could interface with libraries from other languages really easily? I dunno, I've been avoiding it ever since I had to debug someone's code and found out that it was failing because of some missing whitespace. But his point is more that you don't have a choice of what level of depth you're allowed to use. in C++ a string is just a char array with extra functionality baked in. But nothing is stopping you from making a char array. The important features that really make c++ strong for low-level programing is pointers/move instructions that reduce copying variables, bitwise commands so you can store stuff in an int32 instead of an array of something, ability to specify if you want a linked list array or a vector. If a person isn't asking those kinds of questions then it won't matter what language they're using.
most companies are married to design and language decisions they made decades ago, sure. But if you look at it like that, ANY change in programming language would be a nonstarter, sometimes even things like migrating from python 2 to 3
This is a poor example, however low level languages still have advantages with type safety, performance, reliability and readability on large code bases. I'm mostly a rust programmer but also write python, JavaScript daily. If one of my json fields comes back with a null value or some other unexpected value the compiler will soon yell at me. Rust can also run python or JavaScript fairly easily I can also make python or JavaScript modules as native or wasm modules.
Isn't there a tension between: 1. "Climbing to Heaven", the idea that layers of abstraction is bad, 2. the best system to used is the simplest one that allows you to do a job (and that Vulkan is not this)?
How so? Are you saying the best system is one that adds layers of abstraction? If so, then you're right, but I think his point is more about the degree or scale of abstraction than abstraction itself - for example, functions are a good abstraction. Files are probably a good abstraction. If you need to draw colored triangles, a function called `render_colored_triangle(x, y, z, color)` that does what you need it to do is probably a good abstraction. Bad abstractions might be something like almost anything defined in the PDF spec, which rarely do what you want them to do by default, and are huge and hard to understand. Or the C++ STL 'Path' class which I believe overloads "operator/" (yes, forward slash) to do string concatenation. This is not helpful. EDIT: I don't think I made the point very well. I just named things I think are bad vs. good. I think his point is just 'more' abstraction is not better by default. Any abstraction layer removes capabilities from the layer below it - you can't do everything you can do in assembly in C, you can't do everything you can do in C in Python. You can't do everything your graphics API can do with your 'render_colored_triangle' function.
What he basically said during that section is that you should just be able to make 3D graphics happen without much difficulty. His total view is that GPUs need something similar to x86 where every command does the same thing no matter which card you're talking about, instead of seperate APIs that have to talk to drivers
Point about IDE’s - idk I miss having one now that I’m the monolith project that’s on a Linux box with multiple C, C++ and ADA files. I really miss the help of “find all references” and “go to definition” as well as some general error / syntax checking that comes from something like VS.
All of those features exist in text editors like NeoVim and Vs Code with the caveat being you have to do a little bit of manual setup with a compile_commands JSON file
from what I seen Jai seem to be an improved C like if objective-c was designed by someone sensible 🤔 it didn't exactly convince me that it will be something useful for making games though maybe if it was a lua replacement but in it's current form it's just yet another language 🤔
c++ and javascript are the most popular languages in programming and also have the most footguns c++ is powerful at least, but still it gets pretty confusing especially after c++ 11/14ish. Modern languages like rust and zig seem to handle things much better. personally I think moving away from macros was a mistake, as confusing and obscure as they can be.
I am quickly becoming a Zig-evangelist, after over-coming by initial doubts about it and giving it an honest try. I have yet to encounter a problem that I could solve with macros that I cannot solve with comptime. While I understand that "macros are bad" is popular sentiment and not without truth, I never actually had much of an issue with them, at least when I was the one writing them. It is *other people's* macros that I think are bad...
This was a strange op-ed decrying many things - abstraction layers, knowledge of implementation details, using black boxes, IDEs, programming paradigm tradeoffs, etc - but it has nothing to do with C++ being good or bad for _any task at all_ let alone for games...
7:10 Well, I program my website with nothing more than Linux Mint's default text editor (which has syntax highlighting and a plugin for word completion, which isn't aware of the programming language) over FTP. That's it. I write all the JS, CSS and HTML as well as some PHP in a text editor. But for my Python programming I use a full-fledged IDE, PyCharm.
Kids nowadays will never know the days back when syntax-highlighting was the best we could get, and raw-dogging HTML was common practice, your editor wouldn't even close a tag for you. That said, I do enjoy and have become accustomed to (perhaps even a bit reliant upon...?) modern LSP features. such as auto-complete, go-to-definition. etc.
@@ForeverZer0 Nowadays most people who create their own website probably don't even know what HTML looks like. THey just book a managed server with Wordpress or some other tool and then write the content on there in WYSIWYG editors and have never seen a single HTML tag.
I've never done anything more than trivial programs in C++ but from what I can tell people really love that language so I think he may be overstating its terribleness. How disliked really is C++ then I wonder?
C++ has an amalgamation of weird features that nobody asked for that everyone seems to either love or hate, added over a long time, which results in codebases that look like they have been written in totally different and bizarre languages. If you want to have a good time with C++, you write everything from scratch, not even touching the standard template library.
because it has all the problems of c and even more. header files, UB, no introspection, no serialization, the STL, many templates make compilation slow, bad error messages, etc. i still use it because it’s low level and standard. i would use jai or another mature alternative though.
There's dozens of standards and conventions and every code base looks like it could be several languages instead of all CPP. Plus compiler magic. CPP is powerful, but honestly some of the new players are doing it better for my use cases, be it rust, or Zig, or NIM.
People love to hate things. I actually enjoy a lot writing C++ code. You may just need to get proficient with it to see its true value. I also like Rust.
Like bro, there are TONS of new languages solving the problems he describes, but it’s still only his solution that’s right… and we also can’t use it because it’s too special.
@@UliTroyo I'm too non-committal to say that for sure but I was also thinking along such lines, to a large extent. Thing is though, it takes such foolishness & hubris to imagine Sisyphus teaching his rock to roll itself up hill. History will be the judge & has yet to come to pass. Everybody has to be their own hyperbolic door salesman these days, doesn't matter if he's wrong if he ends up influencing enough people to invest enough time & effort into his methodologies & frameworks. All models are wrong but some are useful; "I'm the best & everything sucks" is a valid axiomatic assertion that can get sht done from time to time, even if inter-subjectively false.
IDE: I mostly need some tool that: #1 gives quick access to the sourcefiles (list/tree), #2 is a proper text editor, #3 highlights the language syntax, #4 can find references of an object, #5 can show a list of appropriate methods/objects/parameters (IntelliJ idea), #6 can help with auto-formatting code, #7 at least marks the codelines that the compiler dislikes (even better at edit time) Thats about it. The rest are usually tools I dont 100% need. Im sure visual Studio could be just 10% of its size to do those tasks instead of being so bloated.
Aside from the title, he doesn't say c++ is bad, he says it is getting worse (I agree with that), and he seems to imply that there isn't a better alternative.
@@sonicewave I don't think there's "pre-template" c++… templates were there even in c++ 98. Even the STL, which is part of the standard, is based on templates
@@HolografixFinn C++11 was the end of the road for me, the language started dying off, not too many jobs. At that time web was exploding. I pivoted to web, for me it was a way to stay relavent and not be at the mercy of far and few crappy C++ jobs. Unless you wanted to grind it out on Wall St. doing low-latency trading. I did that for 1 year and it was not something I enjoyed. I definitely did not want to write code for micro devices, I saw this as a career ending move. C++ was to me like writting too much code to do simple things and it felt like you were always reinventing the wheel for something at each company you worked at.
I'm sure Jonathan is aware of all the nuance underneath each of his statements, but I think he likes to be a tad reductive because it's what gets people's attention. Perhaps todays garbage collected languages are generally going to produce poorly optimized programs, sure. That doesn't mean abstracting away memory will always be a bad idea. We just haven't stumbled upon the right paradigm to do it perfectly. In the same fashion, most developers should not need to care about assembly. When some kid wants to make their first video game, they shouldn't have to be writing assembly across multiple instruction sets to target different architectures. The same kid probably shouldn't need to think about memory management either, at least at first. Look, we'll always need developers proficient in individual areas across the entire stack of computers. But, we need good abstractions, and memory management can and will be mostly abstracted away at some point in the future.
You don't need to abstract away memory when you understand how to use it. And if you program in C++ or Rust or other modern languages, you will never understand it because you aren't given the tools to manipulate the memory. Even the basic dialect of C that most people learn is too loosey goosey with the memory.
2:25 it's funny how he describes "climbing to heaven" as an impractical view of the world, where you program with daydreams, when, for example, the number 1 principle of Python is practicality. Python is probably the second largest and most successful completely open source project after Linux. It supported more than a decade of AI already, which delivered the value embedded in GPUs and other specialized hardware. It is hard to dismiss the _practicality_ of Python, yet Jonathan does exactly that.
no every program needs to be super optmised. There scratch games out there that are really good. Take the software engineering adage: 1. make it work 2. make it right 3. if necessary, make it fast
Nonsense , sometimes you just want to deliver some slow crappy program ASAP, since delivery time pays a bigger role than "code quality" or runtime performance, that's where those "high level" programming languages and frameworks shine. this video is just a rant to get attention, nothing smart being said.
@@marcsfeh Rust is the only language on your list that is actually production ready, but it is not great for gamedev. Zig is getting there and it's usable for the most part but you will end up bumping into a lot of compiler bugs and breaking changes. Odin is a very low quality toy compiler, anyone mentioning it as a real option has absolutely no idea what's going on.
@@marcsfeh tell me you jerk it to every primeagen videos dreaming of the day you'll become a jr dev with out telling me you jerk it to primeagen videos
It became very clear very quickly that this guy's just rambling from some self-prescribed sense of knowing better than everyone. "C++ is terrible"? "VS is a big complicted ecosystem"? And his conclusion: C++ is actually the best for it. Bizarre.
Your comprehension is very bad. His point is the reason C++ is dominant is because at the time this talk was given there was no real competition in the low level language space.
@@filipg4 That 'point' is completely obvious to anyone with half a prefrontal cortex. It's also *utterly useless*. Where is his suggestion for an alternative? Where are the numbers on potential performance benefits? All this self-aggrandasing manchild did was complain for over 10 minutes about a vast range of tools and systems developed and used by people other than himself. The narcissism is glaring from miles away. Again, "C++ is terrible"? Does he really believe himself to have the authority to make such a statement? I feel sorry for anyone who's deluded themselves into believing that this presentation actually contains actionable information. "Go make a better programming language than C++, it's terrible. Oh, and all the modern ones too because they're worse than C++."
@@filipg4 That 'point' is completely obvious to anyone with half a prefrontal cortex. It's also *utterly useless*. Where is his suggestion for an alternative? Where are the numbers on potential performance benefits? All this self-aggrandasing manchild did was complain for over 10 minutes about a vast range of tools and systems developed and used by people other than himself. The narcissism is glaring from miles away. Again, "C++ is terrible"? Does he really believe himself to have the authority to make such a statement? I feel sorry for anyone who's deluded themselves into believing that this presentation actually contains actionable information. "Go make a better programming language than C++, it's terrible. Oh, and all the modern ones too because they're worse than C++."
@@filipg4 That 'point' is completely obvious to anyone with half a prefrontal cortex. It's also *utterly useless*. Where is his suggestion for an alternative? Where are the numbers on potential performance benefits? All this self-aggrandasing manchild did was complain for over 10 minutes about a vast range of tools and systems developed and used by people other than himself. The narcissism is glaring from miles away. Again, "C++ is terrible"? Does he really believe himself to have the authority to make such a statement? I feel sorry for anyone who's deluded themselves into believing that this presentation actually contains actionable information. "Go make a better programming language than C++, it's terrible. Oh, and all the modern ones too because they're worse than C++."
^ That 'point' is completely obvious to anyone with half a prefrontal cortex. It's also *utterly useless*. Where is his suggestion for an alternative? Where are the numbers on potential performance benefits? All this self-aggrandasing manchild did was complain for over 10 minutes about a vast range of tools and systems developed and used by people other than himself. The narcissism is glaring from miles away. Again, "C++ is terrible"? Does he really believe himself to have the authority to make such a statement? I feel sorry for anyone who's deluded themselves into believing that this presentation actually contains actionable information. "Go make a better programming language than C++, it's terrible. Oh, and all the modern ones too because they're worse than C++."
"Hiding things is bad for software quality" Amen...but as usual, there's a caveat. "Hiding things" is relative. Someone from the 80's vs someone from the 90's is gonna have completely different idea of what is unreasonably hidden.
A lot of data people code in Python because it's easier to learn and I dunno, just stuck as the norm? Just about every book or training that I see is about using Python to do your work. Personally I've always liked the idea of C++. Took a break from being a beginner at coding (2006) and now coming back to it seeing all the features the library supports I'm having a great time. I don't need to write the code to concatinate two strings? Fantastic. But I don't have to use string if I don't want to, I could still totally make a char array if in my very specific scenario it would be better. Meanwhile you have javascript where types are so loose that you have to memorize a flow chart of how it decides what type your variable is. And at the same time we see articles from big companies who are nixxing their codebases to finally be more responsive and efficient because (surprise surprise) people actually notice that and prefer it.
All I hear is "No one should ever have an easy entry to programming. Suffer until you know every little detail of CPU architecture and reach my skill level or you are not worthy" Also the last bit about C++ "getting crazier but still okay" is hilarious in light of how the steering council manages to introduce multiple new foot-guns with every new version of C++. As if there weren't enough of them already.
He's been on record saying that if all you know is X language or Y engine, then you should use that to make games. His points are not for begginers, but for people that write custom engines for their games.
@@anthonyewell3470 If that is the case I believe he could have phrased it slightly better than "Here is every **wrong** decision in programming since 1991"
I started programming mostly in Z80 assembly on my calculator and until this day I still think that's the best and easiest intro to programming. But I respect that there's probably different types of people and my journey maybe isn't for everyone.
