Support me on Ko-fi: ko-fi.com/jona... Jonathan Blow on C++ Clip from Jonathan Blow Twitch: / j_blow UA-cam: / @jblow888 #jonathanblow #gamedev #webdevelopment #programming #cplusplusprogramming
Blow brings critical thinking to software development. Which frankly is severely lacking in the industry. People are more concerned with copying others and calling it best practice, without thinking about whether it actually is best for what they are programming right now in front of them. And this is because too many things have become high level, granted to save time, but at the expense of using your head. Software today are more like bloatware.
This viewpoint makes no sense to me. Is the argument that garbage collection and the like directly causes bugs, or is it that lowering the barrier to entry causes bugs? I don't see a sensible way to interpret it as the former, so I'll just have to interpret it as the latter, or as something else that he failed to explain. Lowering the barrier to entry is naturally going to result in less skilled individuals making buggy programs, but to lie the blame at the feet of higher level languages is absurd and unnecessarily exclusionary. The bugs and poor performance come from poor programming, not from streamlined language design.
The argument is *not* that lowering the barrier to entry causes bugs. The argument is that the philosophy of trying to abstract away and hide as much of the actual code that's running, especially in the context of RAII constructors and destructors, lulls people into a false sense of simplicity that causes bugs and performance issues. There's a reason Go, which is considered by many to be a very low-barrier-to-entry language, does not have RAII-style behavior, and instead you see explicit functions that have side effects and then return a struct, and then you often immediately defer a function call that cleans up the side effects of that first function. The amount of code with that approach is barely any more, just a simple `defer` call often one line immediately after "construction", but it *very clearly* expresses what has side effects, what doesn't, and keeps you more in tune with what your program's *actually* doing. In C++ it's just so hard to tell what's going on because a literal universe of activity can be *implicitly* happening where all you have in your code is an ending curly brace, and between two constructors `Foo()` and `Bar()` with very similar signatures, one just allocated a bit of memory on the stack, and the other went off and did 300ms of brittle object-specific work. Another example would be calling functions that can throw exceptions; where C++ just has everything implicit, something like Rust has you explicitly use '?' to very simply return errors up the call stack. I'd hardly say implicit throws are "lower barrier to entry" than just putting a ? on an error-able function; the barrier to entry is actually *higher* IMO if you want to get things right because you have to be extremely eagle-eyed as to what can throw and what can't, and keeping consistent on where and how you're dealing with exceptions.
@@Aurora12488 At best, I can see a point to be made there, but Jonathan has done a hideously bad job of making it. If the argument is that C++'s RAII behaviour directly leads to bugs, then I don't believe I'm qualified enough to argue otherwise, but my interpretation from this video is that abstraction as a whole, with regards to memory/handle cleanup, is inherently a bad thing because it can cause bugs.
@@tovc I mean, this is a 3rd-party clip channel that made a 1-minute out-of-context clip from a larger stream. I assume JBlow probably brought this up relatively absent-mindedly because it's something that bothers him in general, but then didn't go into detail because something else caught his attention. It's more-so a bad *clip* than a bad *viewpoint* . So I'm not really going to criticize how good a job he did explaining it, but rather I'm interested in explaining myself the meaning behind his statement because it's something that has been a pretty big driving force in new language design. A lot of 2010s languages like Rust and Go seem to basically say "we like what C++ is trying to do, but we just think it does a pretty terrible job at actually doing those things". I just don't want people to see this clip and judge the validity of the *viewpoint* based on the contents of the *clip* .
what's wrong with objects knowing how to clean themselves up? Before OOP we wrote flat procedurals APIs and had to make "something_free" functions that you had to call too. C++ just formalized this into a syntax and helped automate it. I fail to see the problem.
because although the idea of auto-managed memory is fine and actually good especially for protyping. There's this slight issue with programming culture where things like auto-managed memory lulls people into a mindset of non-caring and carelessness because "xyz doesn't matter anymore.". Which becomes a _huge_ problem when soembody actually needs to come along and deal with these manually managed problems. I mean just look at how many people who went to school, or did a course, and learnt C++, but are still struggling with basic file management, null pointers and c-strings. its insanity.
@@sososo3906 std::pmr::polymorphic_allocator allow you to use a memory pool, you can use any container template that allow to pass a allocator all the stl is designed this way to allow you to use any strategy you want.
idk how it works in C++, but in BeefLang you just make a tiny field destructor, like "Dictionary = new .() ~ DeleteContainerAndItems!(_);", and when scope-allocated object with this field leaves scope, everything is "cleaned up by itself". Don't see anything wrong with that.
These accounts never do and likely never will, because then people would just see one clip and watch the whole source video, rather than return for more clips.
This is nonsense. How often are we supposed to reinvent the wheel? In the pursuit of improving our processes to create we can create better and more complex things, and one element for that is to simplify processes that are commonly used. Of course it requires these processes to work properly, otherwise we are dealing with blackboxes throwing unknown errors. But these "bugs" he is referring to are not due to the disadvantages of higher level functions, but due to bugs made by programmers - or rather sloppy work. If he believes the skill of programmers is decreasing, well, maybe. But maybe we shouldn't have 1000 wheel inventors and 10 bridge builders, but 10 wheel inventors and 1000 bridge builders by now? As of large companies, only the devil knows at this point what they think the limit is for how many cooks it takes to craft a meal - apparently armies of cooks. You should focus the problem to what it actually is. That's like saying "sometimes there is war, therefore humanity is to blame" - no, that's too vague.
That's a good point. People forget the most important thing - do the things, not thinking about patterns, languages and design philosophy. You can write code with really terrible style and design, but if it implements the algorithm correctly, with no obvious bugs, and the algorithm is correct - it will work fine, because it will just be good at what it does.
@dootie8285 Different wheels for different roads. Also how many different types of wheels are there. Also different wheels for different cars. Really this tiring analogy is boring and trope. Does not reflect the reality in any way. Same for bridge builder and engineering analogy. Makes no sense for programming. Its only partially relative to what the problems are in this field. When it comes to games that needed to support new hardware every five years you absolutely could not rely on CPP to do it for you.
@@sumofat4994 The analogy makes sense. Why would I, to this day, still want to struggle with file management across every single platform I want my program to be built on? And we *already have all that*, we don't need people who are specialized in doing that, but people who can utilize that to build more complex things. This already happened btw, how many people can code in Assembly, and how big is the demand for that? If you can code in C# for example, it means you can develop things much better and faster. Maybe performance would be better if it were done in C or C++, but it would take 2-5 times as much time. The time and effort we can invest into programs is limited, and if we'd have to do every lowlevel thing from scratch, we'd lose out too much time on actual development. Worse even: It's possible that doing that can cause additional complexity, making development more difficult much earlier. We may have to deal with more bad programmers, but that needs to be solved not by making programming more tedious, but otherwise.
@@sumofat4994to take this further, I think it's insane to say we've invented a wheel in the first place. Even if we have, this discipline is too young to label something as ubiquitous, timeless, and impactful as the wheel. Software is still constantly evolving and I'm not sure how far into the future we'll have to be in order to look back and confidently say "this was our wheel"
@@avertver yeah but the whole point is that "most of the time" you would never get it "fully correct", so you have to write your code and associated utilities to be able to accommodate the changes you want to materialise, the easier you can materialise your change in thought the more this speaks of your ability to design and write "good" programs yes it might vary in some preferences from person to person to his ability, but in the matter of logical structure there has to be a way to design good programs and another where it is bad in that it is awful to understand or reliably modify
It's funny that the biggest problem of c++ is also its biggest strength - not willing to break existing code. Not sure how it'd go with both carbon and cppfront, but there's hope that at least one of them willl simplify the language while keeping it backwards compatible.
carbon is a non-starter if you are happy with the "C++ way of things" (not talking about all the awful stuff involved to ensure its completely defined behavior) but I'm betting on cppfront as its approach is "just right" on a lot of stuff as it only normalises existing idioms, not create new ones that serve its goals like carbon
@@itsmeagain1415 idk, having compatibility is a great promise, as long as they can deliver. It's still a "beta" language, so the syntax might change. I'm actually tempted to go the zig route if nothing changes because of the trivial way of writing constexpr, but rewriting all of the cpp codebase is a non-starter
I was in the dark for so long. Finally I will know Jon's opinion on C++
Blow brings critical thinking to software development. Which frankly is severely lacking in the industry. People are more concerned with copying others and calling it best practice, without thinking about whether it actually is best for what they are programming right now in front of them. And this is because too many things have become high level, granted to save time, but at the expense of using your head. Software today are more like bloatware.
This viewpoint makes no sense to me. Is the argument that garbage collection and the like directly causes bugs, or is it that lowering the barrier to entry causes bugs? I don't see a sensible way to interpret it as the former, so I'll just have to interpret it as the latter, or as something else that he failed to explain.
Lowering the barrier to entry is naturally going to result in less skilled individuals making buggy programs, but to lie the blame at the feet of higher level languages is absurd and unnecessarily exclusionary. The bugs and poor performance come from poor programming, not from streamlined language design.
What if the method of streamlining is poor?
The argument is *not* that lowering the barrier to entry causes bugs. The argument is that the philosophy of trying to abstract away and hide as much of the actual code that's running, especially in the context of RAII constructors and destructors, lulls people into a false sense of simplicity that causes bugs and performance issues. There's a reason Go, which is considered by many to be a very low-barrier-to-entry language, does not have RAII-style behavior, and instead you see explicit functions that have side effects and then return a struct, and then you often immediately defer a function call that cleans up the side effects of that first function. The amount of code with that approach is barely any more, just a simple `defer` call often one line immediately after "construction", but it *very clearly* expresses what has side effects, what doesn't, and keeps you more in tune with what your program's *actually* doing. In C++ it's just so hard to tell what's going on because a literal universe of activity can be *implicitly* happening where all you have in your code is an ending curly brace, and between two constructors `Foo()` and `Bar()` with very similar signatures, one just allocated a bit of memory on the stack, and the other went off and did 300ms of brittle object-specific work. Another example would be calling functions that can throw exceptions; where C++ just has everything implicit, something like Rust has you explicitly use '?' to very simply return errors up the call stack. I'd hardly say implicit throws are "lower barrier to entry" than just putting a ? on an error-able function; the barrier to entry is actually *higher* IMO if you want to get things right because you have to be extremely eagle-eyed as to what can throw and what can't, and keeping consistent on where and how you're dealing with exceptions.
Language dictates the mindset though. And mindset dictates quality.
@@Aurora12488 At best, I can see a point to be made there, but Jonathan has done a hideously bad job of making it. If the argument is that C++'s RAII behaviour directly leads to bugs, then I don't believe I'm qualified enough to argue otherwise, but my interpretation from this video is that abstraction as a whole, with regards to memory/handle cleanup, is inherently a bad thing because it can cause bugs.
@@tovc I mean, this is a 3rd-party clip channel that made a 1-minute out-of-context clip from a larger stream. I assume JBlow probably brought this up relatively absent-mindedly because it's something that bothers him in general, but then didn't go into detail because something else caught his attention. It's more-so a bad *clip* than a bad *viewpoint* . So I'm not really going to criticize how good a job he did explaining it, but rather I'm interested in explaining myself the meaning behind his statement because it's something that has been a pretty big driving force in new language design. A lot of 2010s languages like Rust and Go seem to basically say "we like what C++ is trying to do, but we just think it does a pretty terrible job at actually doing those things". I just don't want people to see this clip and judge the validity of the *viewpoint* based on the contents of the *clip* .
what's wrong with objects knowing how to clean themselves up? Before OOP we wrote flat procedurals APIs and had to make "something_free" functions that you had to call too. C++ just formalized this into a syntax and helped automate it. I fail to see the problem.
because although the idea of auto-managed memory is fine and actually good especially for protyping. There's this slight issue with programming culture where things like auto-managed memory lulls people into a mindset of non-caring and carelessness because "xyz doesn't matter anymore.". Which becomes a _huge_ problem when soembody actually needs to come along and deal with these manually managed problems.
I mean just look at how many people who went to school, or did a course, and learnt C++, but are still struggling with basic file management, null pointers and c-strings. its insanity.
You will miss the chance to use a memory pool
@@sososo3906 std::pmr::polymorphic_allocator allow you to use a memory pool, you can use any container template that allow to pass a allocator all the stl is designed this way to allow you to use any strategy you want.
@@sososo3906 There is placement new and operator delete for that purpose
idk how it works in C++, but in BeefLang you just make a tiny field destructor, like "Dictionary = new .() ~ DeleteContainerAndItems!(_);", and when scope-allocated object with this field leaves scope, everything is "cleaned up by itself". Don't see anything wrong with that.
Hi, thanks for putting up these clips. In the future, could you please link to the specific streams/videos where they are sourced from?
These accounts never do and likely never will, because then people would just see one clip and watch the whole source video, rather than return for more clips.
Using C++ like that is like using C#, you're using it as a "managed language".
using modern c++ is so fucked up you might as well just use c#. it's easier, prettier, and probably even faster than idiomatic c++ no cap on god frfr
@@loli42 Yo, didn't expect to see you here.
@@tiranito2834 i'm officially an internet microcelebrity
Jonathan Blow on how to blow a take, and sound pretentious and "knowledgeable" at the same time.
While being completely wrong most of the time.
This is nonsense. How often are we supposed to reinvent the wheel? In the pursuit of improving our processes to create we can create better and more complex things, and one element for that is to simplify processes that are commonly used. Of course it requires these processes to work properly, otherwise we are dealing with blackboxes throwing unknown errors. But these "bugs" he is referring to are not due to the disadvantages of higher level functions, but due to bugs made by programmers - or rather sloppy work.
If he believes the skill of programmers is decreasing, well, maybe. But maybe we shouldn't have 1000 wheel inventors and 10 bridge builders, but 10 wheel inventors and 1000 bridge builders by now? As of large companies, only the devil knows at this point what they think the limit is for how many cooks it takes to craft a meal - apparently armies of cooks.
You should focus the problem to what it actually is. That's like saying "sometimes there is war, therefore humanity is to blame" - no, that's too vague.
That's a good point. People forget the most important thing - do the things, not thinking about patterns, languages and design philosophy. You can write code with really terrible style and design, but if it implements the algorithm correctly, with no obvious bugs, and the algorithm is correct - it will work fine, because it will just be good at what it does.
@dootie8285 Different wheels for different roads. Also how many different types of wheels are there. Also different wheels for different cars.
Really this tiring analogy is boring and trope. Does not reflect the reality in any way.
Same for bridge builder and engineering analogy. Makes no sense for programming. Its only partially relative to what the problems are in this field.
When it comes to games that needed to support new hardware every five years you absolutely could not rely on CPP to do it for you.
@@sumofat4994 The analogy makes sense. Why would I, to this day, still want to struggle with file management across every single platform I want my program to be built on?
And we *already have all that*, we don't need people who are specialized in doing that, but people who can utilize that to build more complex things. This already happened btw, how many people can code in Assembly, and how big is the demand for that? If you can code in C# for example, it means you can develop things much better and faster. Maybe performance would be better if it were done in C or C++, but it would take 2-5 times as much time.
The time and effort we can invest into programs is limited, and if we'd have to do every lowlevel thing from scratch, we'd lose out too much time on actual development. Worse even: It's possible that doing that can cause additional complexity, making development more difficult much earlier.
We may have to deal with more bad programmers, but that needs to be solved not by making programming more tedious, but otherwise.
@@sumofat4994to take this further, I think it's insane to say we've invented a wheel in the first place. Even if we have, this discipline is too young to label something as ubiquitous, timeless, and impactful as the wheel. Software is still constantly evolving and I'm not sure how far into the future we'll have to be in order to look back and confidently say "this was our wheel"
@@avertver yeah but the whole point is that "most of the time" you would never get it "fully correct", so you have to write your code and associated utilities to be able to accommodate the changes you want to materialise, the easier you can materialise your change in thought the more this speaks of your ability to design and write "good" programs
yes it might vary in some preferences from person to person to his ability, but in the matter of logical structure there has to be a way to design good programs and another where it is bad in that it is awful to understand or reliably modify
It's funny that the biggest problem of c++ is also its biggest strength - not willing to break existing code. Not sure how it'd go with both carbon and cppfront, but there's hope that at least one of them willl simplify the language while keeping it backwards compatible.
carbon is a non-starter if you are happy with the "C++ way of things" (not talking about all the awful stuff involved to ensure its completely defined behavior)
but I'm betting on cppfront as its approach is "just right" on a lot of stuff as it only normalises existing idioms, not create new ones that serve its goals like carbon
@@itsmeagain1415 idk, having compatibility is a great promise, as long as they can deliver. It's still a "beta" language, so the syntax might change. I'm actually tempted to go the zig route if nothing changes because of the trivial way of writing constexpr, but rewriting all of the cpp codebase is a non-starter