This is the same guy that created this https://handmade.network/forums/t/1662
He gave a talk on c and how he uses it, I think it will resonate with a lot of people here.
https://www.youtube.com/watch?v=443UNeGrFoM&feature=youtu.be
He gave a talk on c and how he uses it, I think it will resonate with a lot of people here.
https://www.youtube.com/watch?v=443UNeGrFoM&feature=youtu.be
With regards to the following "slide":
:+1:
EDIT: I use C89 for these reasons, as well as his points on the issues of operator and function overloading with C++. However I don't think C99 "is broken" (I avoid language like that anyway). To avoid incoming questions of why he thinks it's broken, he clarifies elsewhere that C99 lets you place dynamic arrays on the stack. Compiler optimization becomes hard given that you don't know the offsets at the compilation stage.
:+1:
EDIT: I use C89 for these reasons, as well as his points on the issues of operator and function overloading with C++. However I don't think C99 "is broken" (I avoid language like that anyway). To avoid incoming questions of why he thinks it's broken, he clarifies elsewhere that C99 lets you place dynamic arrays on the stack. Compiler optimization becomes hard given that you don't know the offsets at the compilation stage.
Edited by Abner Coimbre
on
Reason: Clarification on ANSI C vs C99
First off, C and C++ are both a horrible languages.
But - lets be clear - C++ is not a horrible language because it has operator and function overloading.
Neither is C++ horrible because it has "a lot of features".
C++ is bad because it's built on top of C and is one layer of bad design on top of another layer of even more eye-wateringly bad design.
1. He makes two weak arguments against operator and function overloading - both of which boil down to - some fool might abuse them.
Idiot-proofing is not a good language design strategy.
It's worth having operator overloading just for being able to write vector math using infix notation.
2. He makes the argument that "typing" or lack of expressivity is not a problem.
But typing IS a problem in C.
Because C has NOTHING.
C has no arrays or strings.
C has no data structures or modules or compile-time reflection.
There is nothing wrong with having raw-pointers in a language, but when ALL you have is pointers -
typing does become a problem.
When are no ways to automate anything*, when there are no ways to make ADTs (abstract data types),
when everything you do can and will blow-up unexpectedly at any time in future due to stack or heap corruption,
typing does become a problem.
And make no mistake - to make a game of decent scale in C - requires large amount of error-prone busy-work typing.
* Unless text-manipulation preprocessor counts as an "automation tools".
But - lets be clear - C++ is not a horrible language because it has operator and function overloading.
Neither is C++ horrible because it has "a lot of features".
C++ is bad because it's built on top of C and is one layer of bad design on top of another layer of even more eye-wateringly bad design.
1. He makes two weak arguments against operator and function overloading - both of which boil down to - some fool might abuse them.
Idiot-proofing is not a good language design strategy.
It's worth having operator overloading just for being able to write vector math using infix notation.
2. He makes the argument that "typing" or lack of expressivity is not a problem.
But typing IS a problem in C.
Because C has NOTHING.
C has no arrays or strings.
C has no data structures or modules or compile-time reflection.
There is nothing wrong with having raw-pointers in a language, but when ALL you have is pointers -
typing does become a problem.
When are no ways to automate anything*, when there are no ways to make ADTs (abstract data types),
when everything you do can and will blow-up unexpectedly at any time in future due to stack or heap corruption,
typing does become a problem.
And make no mistake - to make a game of decent scale in C - requires large amount of error-prone busy-work typing.
* Unless text-manipulation preprocessor counts as an "automation tools".
In most of the parts I share the same opinion as the OP video. But, it is ironically when it it saying that typing is not a problem. From my point of view is a big problem, in the HandmadeDev talk he told that he saw thousands of line of code that don't do nothing (I suppose OOP), so how can you say that is not a problem when it does nothing? Another thing is when it says a language is to new, who cares how old/new is as long as it has a good purpose and works how it should. At the end is the same as when people are saying this year C++ dies or this is the year of Linux, many many years same story.
@pragmatic_hero You could make abstract types using void pointer and cast them to what you need. Look at C++ it using templates everywhere and for operation like shorting, searching, compare, etc. it forces we to implement some functions. You could easily take same approach. About the error-prone stuff, I still prefer C over languages like JavaScript where you almost never have errors (and then you ask yourself why is not working).
@pragmatic_hero You could make abstract types using void pointer and cast them to what you need. Look at C++ it using templates everywhere and for operation like shorting, searching, compare, etc. it forces we to implement some functions. You could easily take same approach. About the error-prone stuff, I still prefer C over languages like JavaScript where you almost never have errors (and then you ask yourself why is not working).
Yes, ADTs in C can be made in two ways - where first uses `void *` for the "generic type".
Then using macro or function array_at(array,index,element_size) to do the pointer arithmetic.
The second way to do ADTs is ginormous macros - one for the structure definition and one for implementation code. And everytime you'd need a new data struct you would just expand the macros with the necessary types inserted.
The giant macros one is the only one which can be optimized by the compiler - but is a giant pain in the ass to debug and work with.
Sean Barrett's stretchy_buffer approach is a nice macro/pointer hack which works surprisingly nicely for "dynamic arrays".
It still doesn't do range-checks (and has some drawbacks), but is it VERY, VERY useful!
While the talk was discussing both meanings of the word "typing" (as in strong typing), the part of the talk I was referencing was the one where he was telling how "typing in code" or having to type large amounts of code to do simple things is not a problem in C.
I totally don't agree that C lack of expressibility - or having 100 lines to do simple things (where it could have been 10-30 lines) - is not a problem. Having loads of code is always a problem.
Large parts of game code are not actually complicated and are straight forward busywork coding.
Since all of it is prone to blowing up randomly (yay stack and heap corruption), it's not fun at.
Making games in C is just giant pain in the ass - for all the wrong reasons.
1 | struct array {u32 count; void * items;};
|
Then using macro or function array_at(array,index,element_size) to do the pointer arithmetic.
The second way to do ADTs is ginormous macros - one for the structure definition and one for implementation code. And everytime you'd need a new data struct you would just expand the macros with the necessary types inserted.
The giant macros one is the only one which can be optimized by the compiler - but is a giant pain in the ass to debug and work with.
Sean Barrett's stretchy_buffer approach is a nice macro/pointer hack which works surprisingly nicely for "dynamic arrays".
It still doesn't do range-checks (and has some drawbacks), but is it VERY, VERY useful!
While the talk was discussing both meanings of the word "typing" (as in strong typing), the part of the talk I was referencing was the one where he was telling how "typing in code" or having to type large amounts of code to do simple things is not a problem in C.
I totally don't agree that C lack of expressibility - or having 100 lines to do simple things (where it could have been 10-30 lines) - is not a problem. Having loads of code is always a problem.
Large parts of game code are not actually complicated and are straight forward busywork coding.
Since all of it is prone to blowing up randomly (yay stack and heap corruption), it's not fun at.
Making games in C is just giant pain in the ass - for all the wrong reasons.
Edited by pragmatic_hero
on
It is (theoretically) possible for the compiler to go ahead and do partial specializations for the void* + element_size style. With a specialization per element size.
Though partial specializations is a pretty tricky problem when picking optimizations. It's much simpler to just inline the array functions and optimize that, especially when the function is on the order of a few lines like they would be for variable sized array functions.
Though partial specializations is a pretty tricky problem when picking optimizations. It's much simpler to just inline the array functions and optimize that, especially when the function is on the order of a few lines like they would be for variable sized array functions.
Meh. I was going to comment, but see Casey's rants on Handmade Hero for my feelings, pretty much sums that up.
He had some interesting points but after about 45 minutes he started to sound whiny and I couldn't watch anymore. Never had that problem on Handmade Hero, despite Caseys awesome rants.
He had some interesting points but after about 45 minutes he started to sound whiny and I couldn't watch anymore. Never had that problem on Handmade Hero, despite Caseys awesome rants.
Edited by Todd
on
@steve Thanks for sharing the video!
Nice trick at 1:51:00 - generalization of the "buffer pitch" technique.
Nice trick at 1:51:00 - generalization of the "buffer pitch" technique.