Jump to content

  • Log In with Google      Sign In   
  • Create Account


#Actualscarypajamas

Posted 16 August 2013 - 11:40 PM

The following is going to be a bit of a rant.  Before I start, my intention is not to offend anyone, everyone is entitled to their own opinion.  With that out of the way, here is my story:
 
I used to do all my game/engine development in C++, but switched over to C about 1.5 years ago.  I can say with great certainty I will never go back to C++ (for indie work).
 
My reasons for choosing C have nothing to do with performance, dislike for OOP, or the need for a standard ABI.  My reasons are purely social and empirical.    Here are some of them:
 
The C++ Community:
I find the C++ community to be ridiculously divided on what is "proper" C++.  I can't tell you how many times I've read posts criticizing the subset of C++ chosen for a project.  "Oh, that's not C++, that's C with Class!", "Why aren't you using templates?", "Manual memory management is for grandpas, hipsters like me are using smart pointers!", and it goes on and on...  Is proper C++ boost style with template meta-programming everywhere, IsItJustLikeJavaWith = new UsedEverywhere?, is it c_with_classes_style, etc...  I think the chaos among the C++ community is merely a reflection of how large, divided, and diverse the design of the C++ language is.
 
Let me end this argument once and for all: If the code compiles with a standards compliant C++ compiler, then it is C++.  Period.  End of story.  Just because you don't like the subset chosen, does not mean the code is not C++.  There is no such thing as "Modern C++" or "Modern Java", "modern" is just a buzzword used to sell you on said individuals favorite subset.
 
C++ Design:
One of the philosophies of C is to trust the programmer.  This rule is broken numerous times in C++.  The fact you have to cast between pointer types just creates unnecessary noise in the code, nothing more.  The fact you have to prefix the implementation of a class's method with MyClass:: is dumb.  Objective-C got this right by allowing you to wrap your class method implementations in a @ClassName { } block.  Seriously, prefixing the class on a method is data redundancy.  It is not simple, it is not minimal, it is not DRY.  I'm sure some developers think that because their typing more code their solution is better.  This is not true and C's idioms encourage the complete opposite of this.
 
C++ requires lots of boilerplate.  When I write C++, I end up spending about 40% of my time in the header file and/or writing boilerplate.  With C its about 5%.  Because of this, I do find myself developing faster in C than I do C++.  If you find C slow to develop with, it could be because your using C for a task which would be better suited to another language or you just don't understand C idioms and are trying to apply Java/C++ idioms.  For engine development, I never once felt the need for C++ features once I understood C's idioms.
 
Simplicity and the C community:
C is simple, small, and elegant.  The C community encourage simple designs and solutions.  This is one of the big reasons to not use C++.  I see most C++ developers creating over-architected solutions.  For a humorous example of this, check out enterprise fizzbuzz.  I notice there is a lot of reinventing of the wheel among the C++ crowd, not so much with the C crowd.  The majority of C++ libraries I have used proudly roll there own strings, containers, data structures, and often ignore the C++ standard library.  In my experience, C programs and libraries tend to use the C standard library and 3rd party libs instead of rolling their own solutions.
 
C requires very little boilerplate.  When I write in C++ I find my train of thought is constantly broken.  When I write classes, I have to constantly switch between .h/.cpp files, I have to constantly repeat the class name in front of every method, etc...  These interrupting tasks take my mind off the solution at hand.  Contrast this with C where I can focus on solutions instead of boilerplate.
 
One more thing:
I am not Linus Torvalds, I do not believe that C should be used everywhere.  You should use the right tool for the right job.  I love using C for the low-level audio, graphics, and input handing (the engine) and a high-level scripting language for the AI and GUI (the game).
 
I hope this has given you some insight into my decision to use C instead of C++.  I'm sure there are many C++ programmers who do not over-design, but my experience tells me they are the minority (either that or their not loud enough).
 
TL;DR The C community is abundant with simple libraries, simple APIs, and simple solutions.  There is very little to no bickering over the proper language subset and very little reinventing of the wheel.  C requires very little boilerplate allowing you to focus on solutions uninterrupted.

#14scarypajamas

Posted 16 August 2013 - 11:37 PM

The following is going to be a bit of a rant.  Before I start, my intention is not to offend anyone, everyone is entitled to their own opinion.  With that out of the way, here is my story:
 
I used to do all my game/engine development in C++, but switched over to C about 1.5 years ago.  I can say with great certainty I will never go back to C++ (for indie work).
 
My reasons for choosing C have nothing to do with performance, dislike for OOP, or the need for a standard ABI.  My reasons are purely social and empirical.    Here are some of them:
 
The C++ Community:
I find the C++ community to be ridiculously divided on what is "proper" C++.  I can't tell you how many times I've read posts criticizing the subset of C++ chosen for a project.  "Oh, that's not C++, that's C with Class!", "Why aren't you using templates?", "Manual memory management is for grandpas, hipsters like me are using smart pointers!", and it goes on and on...  Is proper C++ boost style with template meta-programming everywhere, IsItJustLikeJavaWith = new UsedEverywhere?, is it c_with_classes_style, etc...  I think the chaos among the C++ community is merely a reflection of how large, divided, and diverse the design of the C++ language is.
 
Let me end this argument once and for all: If the code compiles with a standards compliant C++ compiler, then it is C++.  Period.  End of story.  Just because you don't like the subset chosen, does not mean the code is not C++.  There is no such thing as "Modern C++" or "Modern Java", "modern" is just a buzzword used to sell you on said individuals favorite subset.
 
C++ Design:
One of the philosophies of C is to trust the programmer.  This rule is broken numerous times in C++.  The fact you have to cast between pointer types just creates unnecessary noise in the code, nothing more.  The fact you have to prefix the implementation of a class's method with MyClass:: is dumb.  Objective-C got this right by allowing you to wrap your class method implementations in a @ClassName { } block.  Seriously, prefixing the class on a method is data redundancy.  It is not simple, it is not minimal, it is not DRY.  I'm sure some developers think that because their typing more code their solution is better.  This is not true and C's idioms encourage the complete opposite of this.
 
C++ requires lots of boilerplate.  When I write C++, I end up spending about 40% of my time in the header file and/or writing boilerplate.  With C its about 5%.  Because of this, I do find myself developing faster in C than I do C++.  If you find C slow to develop with, it could be because your using C for a task which would be better suited to another language or you just don't understand C idioms and are trying to apply Java/C++ idioms.  For engine development, I never once felt the need for C++ features once I understood C's idioms.
 
Simplicity and the C community:
C is simple, small, and elegant.  The C community encourage simple designs and solutions.  This is one of the big reasons to not use C++.  I see most C++ developers creating over-architected solutions.  For a humorous example of this, check out enterprise fizzbuzz.  I notice there is a lot of reinventing of the wheel among the C++ crowd, not so much with the C crowd.  The majority of C++ libraries I have used proudly roll there own strings, containers, data structures, and often ignore the C++ standard library.  In my experience, C programs and libraries tend to use the C standard library and 3rd party libs instead of rolling their own solutions.
 
C requires very little boilerplate.  When I write in C++ I find my train of thought is constantly broken.  When I write classes, I have to constantly switch between .h/.cpp files, I have to constantly repeat the class name in front of every method, etc...  These interrupting tasks take my mind off the solution at hand.  Contrast this with C where I can focus on solutions instead of boilerplate.
 
One more thing:
I am not Linus Torvalds, I do not believe that C should be used everywhere.  You should use the right tool for the right job.  I love using C for the low-level audio, graphics, and input handing (the engine) and a high-level scripting language for the AI and GUI (the game).
 
I hope this has given you some insight into my decision to use C instead of C++.  I'm sure there are many C++ programmers who do not over-design, but my experience tells me they are the minority (either that or their not loud enough).
 
TL;DR The C community is abundant with simple libraries, simple APIs, and simple solutions.  There is very little to no bickering over the proper language subset and very little reinventing of the wheel.  C requires very little boilerplate which allows you to focus on solutions and does not break your train of thought.

#13scarypajamas

Posted 16 August 2013 - 11:37 PM

The following is going to be a bit of a rant.  Before I start, my intention is not to offend anyone, everyone is entitled to their own opinion.  With that out of the way, here is my story:
 
I used to do all my game/engine development in C++, but switched over to C about 1.5 years ago.  I can say with great certainty I will never go back to C++ (for indie work).
 
My reasons for choosing C have nothing to do with performance, dislike for OOP, or the need for a standard ABI.  My reasons are purely social and empirical.    Here are some of them:
 
The C++ Community:
I find the C++ community to be ridiculously divided on what is "proper" C++.  I can't tell you how many times I've read posts criticizing the subset of C++ chosen for a project.  "Oh, that's not C++, that's C with Class!", "Why aren't you using templates?", "Manual memory management is for grandpas, hipsters like me are using smart pointers!", and it goes on and on...  Is proper C++ boost style with template meta-programming everywhere, IsItJustLikeJavaWith = new UsedEverywhere?, is it c_with_classes_style, etc...  I think the chaos among the C++ community is merely a reflection of how large, divided, and diverse the design of the C++ language is.
 
Let me end this argument once and for all: If the code compiles with a standards compliant C++ compiler, then it is C++.  Period.  End of story.  Just because you don't like the subset chosen, does not mean the code is not C++.  There is no such thing as "Modern C++" or "Modern Java", "modern" is just a buzzword used to sell you on said individuals favorite subset.
 
C++ Design:
One of the philosophies of C is to trust the programmer.  This rule is broken numerous times in C++.  The fact you have to cast between pointer types just creates unnecessary noise in the code, nothing more.  The fact you have to prefix the implementation of a class's method with MyClass:: is dumb.  Objective-C got this right by allowing you to wrap your class method implementations in a @ClassName { } block.  Seriously, prefixing the class on a method is data redundancy.  It is not simple, it is not minimal, it is not DRY.  I'm sure some developers think that because their typing more code their solution is better.  This is not true and C's idioms encourage the the complete opposite of this.
 
C++ requires lots of boilerplate.  When I write C++, I end up spending about 40% of my time in the header file and/or writing boilerplate.  With C its about 5%.  Because of this, I do find myself developing faster in C than I do C++.  If you find C slow to develop with, it could be because your using C for a task which would be better suited to another language or you just don't understand C idioms and are trying to apply Java/C++ idioms.  For engine development, I never once felt the need for C++ features once I understood C's idioms.
 
Simplicity and the C community:
C is simple, small, and elegant.  The C community encourage simple designs and solutions.  This is one of the big reasons to not use C++.  I see most C++ developers creating over-architected solutions.  For a humorous example of this, check out enterprise fizzbuzz.  I notice there is a lot of reinventing of the wheel among the C++ crowd, not so much with the C crowd.  The majority of C++ libraries I have used proudly roll there own strings, containers, data structures, and often ignore the C++ standard library.  In my experience, C programs and libraries tend to use the C standard library and 3rd party libs instead of rolling their own solutions.
 
C requires very little boilerplate.  When I write in C++ I find my train of thought is constantly broken.  When I write classes, I have to constantly switch between .h/.cpp files, I have to constantly repeat the class name in front of every method, etc...  These interrupting tasks take my mind off the solution at hand.  Contrast this with C where I can focus on solutions instead of boilerplate.
 
One more thing:
I am not Linus Torvalds, I do not believe that C should be used everywhere.  You should use the right tool for the right job.  I love using C for the low-level audio, graphics, and input handing (the engine) and a high-level scripting language for the AI and GUI (the game).
 
I hope this has given you some insight into my decision to use C instead of C++.  I'm sure there are many C++ programmers who do not over-design, but my experience tells me they are the minority (either that or their not loud enough).
 
TL;DR The C community is abundant with simple libraries, simple APIs, and simple solutions.  There is very little to no bickering over the proper language subset and very little reinventing of the wheel.  C requires very little boilerplate which allows you to focus on solutions and does not break your train of thought.

#12scarypajamas

Posted 16 August 2013 - 11:36 PM

The following is going to be a bit of a rant.  Before I start, my intention is not to offend anyone, everyone is entitled to their own opinion.  With that out of the way, here is my story:
 
I used to do all my game/engine development in C++, but switched over to C about 1.5 years ago.  I can say with great certainty I will never go back to C++ (for indie work).
 
My reasons for choosing C have nothing to do with performance, dislike for OOP, or the need for a standard ABI.  My reasons are purely social and empirical.    Here are some of them:
 
The C++ Community:
I find the C++ community to be ridiculously divided on what is "proper" C++.  I can't tell you how many times I've read posts criticizing the subset of C++ chosen for a project.  "Oh, that's not C++, that's C with Class!", "Why aren't you using templates?", "Manual memory management is for grandpas, hipsters like me are using smart pointers!", and it goes on and on...  Is proper C++ boost style with template meta-programming everywhere, IsItJustLikeJavaWith = new UsedEverywhere?, is it c_with_classes_style, etc...  I think the chaos among the C++ community is merely a reflection of how large, divided, and diverse the design of the C++ language is.
 
Let me end this argument once and for all: If the code compiles with a standards compliant C++ compiler, then it is C++.  Period.  End of story.  Just because you don't like the subset chosen, does not mean the code is not C++.  There is no such thing as "Modern C++" or "Modern Java", "modern" is just a buzzword used to sell you on said individuals favorite subset.
 
C++ Design:
One of the philosophies of C is to trust the programmer.  This rule is broken numerous times in C++.  The fact you have to cast between pointer types just creates unnecessary noise in the code, nothing more.  The fact you have to prefix the implementation of a class's method with MyClass:: is dumb.  Objective-C got this right by allowing you to wrap your class method implementations in a @ClassName { } block.  Seriously, prefixing the class on a method is data redundancy.  It is not simple, it is not minimal, it is not DRY.  I'm sure some developers think that because their typing more code their solution is better.  This is not true and C's idioms encourage the the complete opposite of this.
 
C++ requires lots of boilerplate.  When I write C++, I end up spending about 40% of my time in the header file and/or writing boilerplate.  With C its about 5%.  Because of this, I do find myself developing faster in C than I do C++.  If you find C slow to develop with, it could be because your using C for a task which would be better suited to another language or you just don't understand C idioms and are trying to apply Java/C++ idioms.  For engine development, I never once felt the need for C++ features once I understood C's idioms.
 
Simplicity and the C community:
C is simple, small, and elegant.  The C community encourage simple designs and solutions.  This is one of the big reasons to not use C++.  I see most C++ developers creating over-architected solutions.  For a humorous example of this, check out enterprise fizzbuzz.  I notice there is a lot of reinventing of the wheel among the C++ crowd, not so much with the C crowd.  The majority of C++ libraries I have used proudly roll there own strings, containers, data structures, and often ignore the C++ standard library.  In my experience, C programs and libraries tend to use the C standard library and 3rd party libs instead of rolling their own solutions.
 
C requires very little boilerplate.  When I write in C++ I find my train of thought is constantly broken.  When I write classes, I have to constantly switch between .h/.cpp files, I have to constantly repeat the class name in front of every method, etc...  These interrupting tasks take my mind off the solution at hand.  Contrast this with C where I can focus on solutions instead of boilerplate.
 
One more thing:
I am not Linus Torvalds, I do not believe that C should be used everywhere.  You should use the right tool for the right job.  I love using C for the low-level audio, graphics, and input handing (the engine) and a high-level scripting language for the AI and GUI (the game).
 
I hope this has given you some insight into my decision to use C instead of C++.  I'm sure there are many C++ programmers who do not over-design, but my experience tells me they are the minority (either that or their not loud enough).
 
TL;DR The C community is abundant with simple libraries, simple APIs, and simple solutions.  There is very little to no bickering over the proper language subset and very little reinventing of the wheel.  C requires very little boilerplate and allows you to focus on the solution.

#11scarypajamas

Posted 16 August 2013 - 11:35 PM

The following is going to be a bit of a rant.  Before I start, my intention is not to offend anyone, everyone is entitled to their own opinion.  With that out of the way, here is my story:
 
I used to do all my game/engine development in C++, but switched over to C about 1.5 years ago.  I can say with great certainty I will never go back to C++ (for indie work).
 
My reasons for choosing C have nothing to do with performance, dislike for OOP, or the need for a standard ABI.  My reasons are purely social and empirical.    Here are some of them:
 
The C++ Community:
I find the C++ community to be ridiculously divided on what is "proper" C++.  I can't tell you how many times I've read posts criticizing the subset of C++ chosen for a project.  "Oh, that's not C++, that's C with Class!", "Why aren't you using templates?", "Manual memory management is for grandpas, hipsters like me are using smart pointers!", and it goes on and on...  Is proper C++ boost style with template meta-programming everywhere, IsItJustLikeJavaWith = new UsedEverywhere?, is it c_with_classes_style, etc...  I think the chaos among the C++ community is merely a reflection of how large, divided, and diverse the design of the C++ language is.
 
Let me end this argument once and for all: If the code compiles with a standards compliant C++ compiler, then it is C++.  Period.  End of story.  Just because you don't like the subset chosen, does not mean the code is not C++.  There is no such thing as "Modern C++" or "Modern Java", "modern" is just a buzzword used to sell you on said individuals favorite subset.
 
C++ Design:
One of the philosophies of C is to trust the programmer.  This rule is broken numerous times in C++.  The fact you have to cast between pointer types just creates unnecessary noise in the code, nothing more.  The fact you have to prefix the implementation of a class's method with MyClass:: is dumb.  Objective-C got this right by allowing you to wrap your class method implementations in a @ClassName { } block.  Seriously, prefixing the class on a method is data redundancy.  It is not simple, it is not minimal, it is not DRY.  I'm sure some developers think that because their typing more code their solution is better.  This is not true and C's idioms encourage the the complete opposite of this.
 
C++ requires lots of boilerplate.  When I write C++, I end up spending about 40% of my time in the header file and/or writing boilerplate.  With C its about 5%.  Because of this, I do find myself developing faster in C than I do C++.  If you find C slow to develop with, it could be because your using C for a task which would be better suited to another language or you just don't understand C idioms and are trying to apply Java/C++ idioms.  For engine development, I never once felt the need for C++ features once I understood C's idioms.
 
Simplicity and the C community:
C is simple, small, and elegant.  The C community encourage simple designs and solutions.  This is one of the big reasons to not use C++.  I see most C++ developers creating over-architected solutions.  For a humorous example of this, check out enterprise fizzbuzz.  I notice there is a lot of reinventing of the wheel among the C++ crowd, not so much with the C crowd.  The majority of C++ libraries I have used proudly roll there own strings, containers, data structures, and often ignore the C++ standard library.  In my experience, C programs and libraries tend to use the C standard library and 3rd party libs instead of rolling their own solutions.
 
C requires very little boilerplate.  When I write in C++ I find my train of thought is constantly broken.  When I write classes, I have to constantly switch between .h/.cpp files, I have to constantly repeat the class name in front of every method, etc...  These interrupting tasks take my mind off the solution at hand.  Contrast this with C where I can focus on solutions instead of boilerplate.
 
One more thing:
I am not Linus Torvalds, I do not believe that C should be used everywhere.  You should use the right tool for the right job.  I love using C for the low-level audio, graphics, and input handing (the engine) and a high-level scripting language for the AI and GUI (the game).
 
I hope this has given you some insight into my decision to use C instead of C++.  I'm sure there are many C++ programmers who do not over-design, but my experience tells me they are the minority (either that or their not loud enough).
 
TL;DR The C community is abundant with simple libraries, simple APIs, and simple solutions.  There is very little to no bickering over the proper language subset and very little reinventing of the wheel.  C requires very little boilerplate and allows you to focus on the solution at hand instead of switching between h/c files, casting pointers, etc...

#10scarypajamas

Posted 16 August 2013 - 11:33 PM

The following is going to be a bit of a rant.  Before I start, my intention is not to offend anyone, everyone is entitled to their own opinion.  With that out of the way, here is my story:
 
I used to do all my game/engine development in C++, but switched over to C about 1.5 years ago.  I can say with great certainty I will never go back to C++ (for indie work).
 
My reasons for choosing C have nothing to do with performance, dislike for OOP, or the need for a standard ABI.  My reasons are purely social and empirical.    Here are some of them:
 
The C++ Community:
I find the C++ community to be ridiculously divided on what is "proper" C++.  I can't tell you how many times I've read posts criticizing the subset of C++ chosen for a project.  "Oh, that's not C++, that's C with Class!", "Why aren't you using templates?", "Manual memory management is for grandpas, hipsters like me are using smart pointers!", and it goes on and on...  Is proper C++ boost style with template meta-programming everywhere, IsItJustLikeJavaWith = new UsedEverywhere?, is it c_with_classes_style, etc...  I think the chaos among the C++ community is merely a reflection of how large, divided, and diverse the design of the C++ language is.
 
Let me end this argument once and for all: If the code compiles with a standards compliant C++ compiler, then it is C++.  Period.  End of story.  Just because you don't like the subset chosen, does not mean the code is not C++.  There is no such thing as "Modern C++" or "Modern Java", "modern" is just a buzzword used to sell you on said individuals favorite subset.
 
C++ Design:
One of the philosophies of C is to trust the programmer.  This rule is broken numerous times in C++.  The fact you have to cast between pointer types just creates unnecessary noise in the code, nothing more.  The fact you have to prefix the implementation of a class's method with MyClass:: is dumb.  Objective-C got this right by allowing you to wrap your class method implementations in a @ClassName { } block.  Seriously, prefixing the class on a method is data redundancy.  It is not simple, it is not minimal, it is not DRY.  I'm sure some developers think that because their typing more code their solution is better.  This is not true and C's idioms encourage the the complete opposite of this.
 
C++ requires lots of boilerplate.  When I write C++, I end up spending about 40% of my time in the header file and/or writing boilerplate.  With C its about 5%.  Because of this, I do find myself developing faster in C than I do C++.  If you find C slow to develop with, it could be because your using C for a task which would be better suited to another language or you just don't understand C idioms and are trying to apply Java/C++ idioms.  For engine development, I never once felt the need for C++ features once I understood C's idioms.
 
When I write in C++ I find my train of thought is constantly broken.  When I write classes, I have to constantly switch between .h/.cpp files, I have to constantly repeat the class name in front of every method, etc...  These interrupting tasks take my mind off the solution at hand.  Contrast this with C where I can focus on solutions instead of boilerplate.
 
Simplicity and the C community:
C is simple, small, and elegant.  The C community encourage simple designs and solutions.  This is one of the big reasons to not use C++.  I see most C++ developers creating over-architected solutions.  For a humorous example of this, check out enterprise fizzbuzz.  I notice there is a lot of reinventing of the wheel among the C++ crowd, not so much with the C crowd.  The majority of C++ libraries I have used proudly roll there own strings, containers, data structures, and often ignore the C++ standard library.  In my experience, C programs and libraries tend to use the C standard library and 3rd party libs instead of rolling their own solutions.
 
One more thing:
I am not Linus Torvalds, I do not believe that C should be used everywhere.  You should use the right tool for the right job.  I love using C for the low-level audio, graphics, and input handing (the engine) and a high-level scripting language for the AI and GUI (the game).
 
I hope this has given you some insight into my decision to use C instead of C++.  I'm sure there are many C++ programmers who do not over-design, but my experience tells me they are the minority (either that or their not loud enough).
 
TL;DR The C community is abundant with simple libraries, simple APIs, and simple solutions.  There is very little to no bickering over the proper language subset and very little reinventing of the wheel.  C requires very little boilerplate and allows you to focus on the solution at hand instead of switching between h/c files, casting pointers, etc...

PARTNERS