Why I'm switching to C in 2019 

It's been a year since I switched to C so I made a follow-up video about my experience using C this year: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-IEbrwh5ghMQ.html

Programming languages come and go. C stays.

2050: why I’m switching to Sanskrit

This time next year I predict the same video but C to assembly

As someone who is literally starting learning C for the main purpose of making something on the N64 (and also the possibility of PS1), it is extremely uplifting to find out that I'm not alone in this crazy desire.

I like the term C-styled C++, a new language called "C+". Best of both worlds.

*"Linus Torvalds liked that."*

From a non-coder who wants to learn, c seems far more understandable and readable than c++ to me.

I like C more than C++ but only because of these reasons: 1. Even though you can develop a program faster in C++ using its abstractions, C++'s cost is that it's easier to make unmaintainable code AND debugging is alot more difficult than in C. C's lack of abstractions means that there's no hidden code or execution etc so it's easier to maintain and alot easier to debug. 2. C is a very simple and minimal language. It's alot easier to master than C++. I could argue that being a C expert would take at least 5 years minimum but C++ would take significantly longer. 3. If I wanted to make an API that can be used by other languages, you have to use C or you need to make a C interface for your C++ code. You could either make your C++ API and then make the C interface, or just implement the library in C. 4. C will force you to learn about the overall system and how computers work, which will overall make you a more powerful programmer.

I programmed in C from 1982 until 1989 when I changed over to C++. Object-oriented is the programming holy grail, but even if you never use classes, C++ is the way to go. If you examine my code you would say it is C more than C++. There is nothing in C++ that requires you do everything the object-oriented way. If you want to write in C then you still should use C++ for two features - default arguments and the ability to declare variables where you first use them rather than at the top of scope. It makes life so much easier and safer to tie declaration to initialization. It makes it simple to rearrange code and prevents access of a variable before it is resolved. Sometimes you decide to add an argument to a call, with C++ default arguments all you have to do is recompile. With C you have to find and correct every existing occurrence. So feel free to write in C, just compile with C++.

Regardless of which language you use, you’re always going to get a million know-it-alls that tell you don’t do that! You should ! And they never tell you why they think that would be the better way to do it. They just want to show you what “programming gods” they think they are when they actually just started to study programming last month. Or they are just parroting something they were told by somebody else without understanding it. Either way, they’re just trolls not worth your attention, that are most likely trying to compensate for their own insecurities.

The argument in favor or against most languages is usually pointless. I program in C and C++ and I do not hate nor love any one in particular. If you ask me what to use for a microcontroller I would chose C if you ask me to write a complex application that makes extensive use of abstract data types were elements in lists or arrays can take on different types and such, then C++ and the STL are the way to go. There is no perfect technology out there a wise developer should chose the best fit for each application.

It might be due to the fact that I've been academically trained to C/C++, but your argument seems meh at best. You're free to do whatever you want with whatever compiler you want, but I thought I'd share my opinions built from 30 years of coding: 1. You don't OOP because it's C++, you do OOP if you need OOP. If you need to keep/change the position of a player, you make a struct, if you have to handle 300 NPCs + players, maybe a more structured representation (classes with inheritance) is a better solution to avoid code duplication and enhance maintainability at scale. 2. "I don't like the tutorials I've used" or "I don't understand the language fully" screams of "find better sources". This comes ofc from my personal experience, as in 6 months as a junior in college I've learnt everything there was to learn about C99 and C++. Having the basics I never really had to use any online source, but I refuse to believe there's no better alternative. Of course, learning the pitfalls of the languages requires slow and "unrewarding" learning, which is why a lot of the poorly written material is just "copy/paste this and have your character move and jump and such in an evening". Fast rewarding paths don't make for good learning. Speaking of modern capabilities, I always suggest the book "Effective modern C++", it's a great source of learning. 3. The reason to use std::vector instead of a C style array[] is because you can't really mess up with a vector, while a typo or a perfectly working but badly designed code can completely wreck your life. A huge amount of OOB exploitation comes from poor array management. If you want to learn how to counter poor design go even lower, rather than stop at C. Using int[] instead of std::vector because it's "simpler", it's quite silly. It still has a place, mind you, but for dynamically allocated resources, not so much. 4. The reason to use std::chrono instead of an #include , is that std::chrono is platform independent. Want to use the best resolution possible whether you're compiling for Win or Linux? Use standard libraries, instead of reinventing the wheel. 5. The dev that responded "because it's idiomatic C++" is an idiot in my book, just like people following fugly practices because it's "more pythonic". I agree with you there, wholeheartidely. "You should do it like that because we do it like that, over here"… yeah, nah. 6. Just like in point 5, the fact that several C devs consider C++ as inferior, or vice versa, is stupid elitism. Facts matter over exclusivism. Linus is not the only one there, one of a major players in the secdev industry claimed that "we don't need C++ to replace C99 for security, we need better people to write better code", while claiming that he was an enlightened C99 dev who could write good code. Funny part is, that he has quite the number of exploitable code he personally written and committed, even post-talk. C is an inherently limited and more vulnerable language. But that doesn't matter if you don't have a C++ toolstack for the platform you're targeting, like NDS or PSX or whatever, so there's that. 7. There is *nothing wrong with C style C++*. Anyone who tells you otherwise is, well, wrong. In fact, the majority of code I wrote over the years could be considered C style C++. But with C++ you have the possibility to use everything you had in C99, better scoping, a better and stricter compiler, plus all the modern features you may use if you feel like it, such as std::string, just to name one. 8. Jumping to C99 when C++ modules are finally in sight feels wrong to my soul. I can't wait to drop the header+import+implementation and jump straight into modules (although I already head-started with in dev builds). 9. You can still code in assembly in both :P I realise this is almost a year old video, and that the CTA hook at the end is just that, a hook, but since the YT algo brought me here I thought I'd share my view regardless, some younger kids/devs might find it interesting. Or not. You do you.

C styled C++ is the only legitimate one. The ++ operator comes after the language identifier, so you don't update your style till after you have finished writing. That's just elementary syntax

When the inventor of a language (Stroustrup, C++) says he doesn't expect most programmers to know ALL the language, I'm inclined to think that the language is just 'dangerous' because it becomes increasingly difficult to understand all the code you may come across and the consequences (side effects) of all the code you write yourself. Knowing all of C is much easier.

As for me, I've studied a bachelor's degree in videogame design and development specialized in programming and finished like 3 years ago. One could say I've been using Object Oriented programming languages for almost 5 years, and it hasn't been until now that I realized how much unnecessary abstractions and superfluous ideas have been forced into my head. Recently I've switched to pure C (trying to apply Data Oriented Programming principles) making me realize how much easier it is when you think in terms of what your computer needs to do. At the end of the day, code is read by humans but bytecode is executed by a machine, never forget that guys! P.S: thanks to Mike Acton CppCon 2014 talk.

I have been coding for 36 years. C is by far my favorite. I have used C, C++, Asm for various systems, Basic, Pascal, AMOS, more scripts languages than I can remember, and so on. I think there are more than 50 languages if I count them all. No language hits that sweet spot quite like C does. A really good choice switching to it.

There are very few things I missed after switching from C++ to C for my small personal projects. Type safety is a big one, C likes to see a lot of things as ints and just treats them all as equivalent types so when I accidentally pass COMPONENT_VELOCITY_MASK instead of COMPONENT_VELOCITY_ID (which are both from separate enums, BTW) I get nothing. No error, no warning, it just sees them both as compatible int types. I ended up wrapping a lot of functions in macros so I pass COMPONENT_VELOCITY and the macro adds _MASK or _ID as necessary. Or I wrap things in structs since structs are always distinct types. But all of that is busywork to make up for C's weak type system, and that's not fun at all. Operator overloading is one that is not necessary but makes things a whole lot more expressive. In particular, when writing my physics engine I had a bug where I was doing the math right on paper, but in unrolling that into an inside-out sequence of function calls I made a mistake. It's not a mistake that would have occurred if C had overloaded operators and I could just add or scale vectors like in C++. It's not a huge problem and it's something you can work around, but again it's more work to overcome a shortcoming in an archaic language. Also, while I'm not a big fan of object-oriented programming with huge class hierarchies and the headaches that entails I think we can all agree that encapsulation is a good thing. Whether you call them classes or modules, having an easy way to limit the ways something outside a module can modify what's inside the module is a fundamental principle of sane programming. If you can make no assumptions about the state of your program because anything can modify anything else then things get so tedious. I've done this in C by providing a set of public functions in the header file and a second set of private functions only available to compilation units that define a symbol like SOME_MODULE_INTERNAL before including it. However, that doesn't prevent code outside the module from modifying struct members themselves which kinda defeats the purpose. I know one time I just defined a pointer to that struct as void* when outside the module and the real pointer type when inside the module which works for pointers, but for things you want to pass around as values then things get more complicated. You would have to make an equivalent type with the same size and guarantee it's the same size, and things get more complicated if you want both public and private members. That sounds like a lot of work I don't want to do. So trying to solve this problem in C in a way where you can make hard assumptions about your code like you can in C++ ends up feeling like fighting an archaic language again. So if I were to start up those types of projects again I definitely would not use C and instead use a narrow subset of C++. I guess it all comes down to the philosophies behind the compilers. C assumes the programmer knows what they're doing, but C++ strives to make programs correct at compile-time. That just seems like the C compiler is working against me and the C++ compiler with me.

I have resonated with this video so much that i cant explain in words honestly. I'm myself a self taught programmer for 15 years now, and a cs grad aswell, have been always struggling in between when to go cpp or c, I mean I could do both but I honestly feel the same shit about what's been said in the video about cpp, there's always never ending modern features to keep yourself up to date and feels like you can never 'make happy' those overlord cpp programmers, or get even yourself happy and satisfied with cpp . C looks like very minimalistic yet extremely powerful language that its power comes from the simplicity and mini-city? of the language

I love this video Nick, and I think you're bang on with your perspective.

I've been programming in C for nearly 30 years, and during that time I've made several forays into different languages including C++. I abhor C++. Sure, it has some conveniences, but I've found that I prefer the bare-bones simplicity of C. I feel like I'm in complete control of my code. While there's generally a hiccup mostly due to the occasional misplaced pointer or memory leak, but, if you're as meticulous a coder as I, these problems are usually very easy to track down. So, BOOOOO @ C++.

The thing is that when you write c code you know that you are programming a computer. You know what the computer will internally do with your code. This sensation is totally lost with java or modern c++ or python or whatever. That's why I like c

I first learned how to program in Java at college. Looking to expand my horizons, I was recommended to learn C by one of the professors at college. I loved it. I loved the way the language gets things done, how you express your ideas with, the idea of structures, it's simplicity and clarity, but most importantly, I loved how it showed me and taught me to think more like a machine, to be aware of what state my program is and will be, and to be aware at a deeper level of static memory, heap, stack fame, and all that good stuff. I jumped to C++ thinking that I was going to love it as well, after all, C++ is just a super-set of C, right? Not quite. I didn't like it. I don't like how it seems to want to be able to do anything so there are a bizillion ways to do the same thing and a bunch of features that you might not need ever in your life, and I didn't like how at every point of the learning process I couldn't shake the thought of "this could be achieved with structural programming in C and be less cluttered" or the thought "if I really needed to use classes, why bother with all this crap and not just use Java or C#?" C++ felt like an awkward transition between C and any other higher level OO language like Java or C# or even Python.

I'm a simple man, I like simple languages. Seriously, though. I might be a programmer, but I'm not very smart. The complexity of C++ had my head spinning. Plus, coming from Java, I love OOP, but I also like to understand the implications of my code. C++ hides too much. With C, I understand what my code does.

I now use c++ almost like c, I agree with you

I'm using c++ because it seems easier to me. It is really about personal option what you like more.

Looking back at my time with C++ (and C#) I feel like I spent way too much time thinking about classes. Sometimes I couldn't help myself - if I found the same props in multiple classes I felt an urge to create a shared inheritance. Now that I'm mostly working in JS without classes I feel like I'm way more productive. When I built a function in C++ and just needed to throw together some one-off objects I often found myself spending way too much time creating and refactoring classes which slowed me down in terms of getting to the meat of the actual logic. And looking back I feel like it rarely made my code easier to read. Now, this isn't a pro-JS post. I'll admit JS is not a good language. But when it comes to workflow and readability I feel like my JS projects are superior to my C++ / C# projects. This came as a shock to me a few years ago, as I had loathed dynamically typed languages before. Yeah, sometimes I do miss the lack of strong typing - especially for compile time error checking. But I do love how much time I can save by not doing overthinking trying to figure out clever classes.

C: I have struct variable named Chair. I can sit on the Chair with the function sit(). C++: I have an object of a Chair class derived from the abstract base class Furniture, with a virtual method called action() that I override to sit on the chair and it's being managed by the ChairHandler class. Jokes aside, I agree with this video for much the same reason. There are some features I wish C had that aren't there for historical reasons, but for me it's never been worth the additional baggage that C++ brings. C prides itself on minimalism, portability & performance yet it's quite expressive given how small of a language it is. To me it isn't really obvious C++ do things better, just differently (and in a way I personally don't like) so I've never felt compelled to use it for those reasons.

Maybe I'm just in the minority then but I'm quite a fan of C++. There a definitely things which I don't like about (I'm looking at you compile times!), but I don't think I'd switch to anything else in place of it. Maybe because I started with Java I was just so use to object oriented code that I do it without even thinking; I also think I probably mesh with C++ more because I have quite a mathematical background, and the balance of control and convenience is hit quite nicely in my opinion.

Agree 100%. Only C++ stuff I like is function overloading (strictly for math functions) and raw string literals which are useful when typing out opengl shaders.

I'm a PS1 programmer also, I did some stuff with it in 2001 and in 2016. You can code C++ with it.. but it all depends on the toolchain. Nice vid man!

One other downside of C++ is its community... There are not much C++ questions on forums that are answered by C++ programmers without having them fight during pages, because they all disagree on the right feature to use (the Correct one, the Modern one) among 100 different features that C++ offers (thanks to all the layers of updates it has been through..... - _-)

Great video. I wanna pick up my first p language and contemplating between C and Rust. Thoughts on both? I can't find great book for beginners on Rust. I think i have great book on C, C Programming A Modern Approach & Absolute Beginner's guide to C. I feel since Rust is probably the future due to memory safety and it begin high level language?, but learning material for Rust is still not good enough i feel. Syntax for Rust resembles more of Python with fewer lines of code, another plus. If i get stuck with bad book i will probably lose interest. Any suggestions and recommendations?

I started programming professionally around the time of DOS 1.0. I've gone from 4GL (now defunct), to Pascal, C, COBOL, C++, and now work in C#. There are lots of other languages along they way that I used to develop code (JavaScript / Typescript, Java, blah, blah, blah...). If I want efficiency without going to assembler (yes I can do that too), then it's C. If I want structure: C#. Use the right tool for the job. The problem isn't OOP, or even C++. The problem is the fact that OOP / C++ is so powerful, it has become a dumping ground for grand ideas and frameworks that essentially suck. And since software development has "evolved," development processes demand this grandiosity. Not everything needs to be reused. The term "keep it simple" has been lost.

I've also been learning how to program for the Playstation 1, hell, it's why I even started using C in the first place. Since starting that project I've slowly been preferring C more and more over the C++ and C# I've been using for years.

This is a really great video dude. Thanks for being honest and objective.

I like to know and expect the generated executable machine code so i prefer C rather than C++

Big props for saying that the vid is not trying to convince anyone and that it's more of your subjective reception. Now regarding the tutorial comments: It's fine to start with a C-style C++ when learning. No beginner will immediately understand std::copy(arr.begin(), arr.end(), std::ostream_iterator(std::cout, " ")); vs a simple printf() in a loop. Claiming differently is like blaming 5 yo kid for not understanding and remembering all of the English grammar rules. I'm a fan of modern C++ and it's newer features but I do not push for overcomplication, especially for beginners - language is already complex enough and constructive criticism is justified. While it has a large power, you must first get that level of expertise to equip that weapon. Also no C++ project uses all of it's features. OOP is never required. Just because language offers virtual functions and unlimited multiple inheritance it does not mean it's always the right thing to do. I'm writing a C++ tutorial by myself and have already made some "insurance" in case of any crtiticism. Meta tutorial FAQ and lesson design decisions rationale - I start with very simple "C part of C++" and slowly move upwards while at the same time listing all pros/cons of each introduced feature. A lot of modern C++ stuff is really good, but you need first to learn it's C fathers in order to understand what's the purpose.

I made the transition from C to C++ in a team environment more than 20 years ago. What I discovered was that if C++ was to be marginally more of a benefit than a ball and chain, the people using it had to operate within almost impossibly tight programming standards. In my opinion 'OO' stands for Opportunity to Obfuscate.

I appreciate that you openly said that while you were using C++ you didn't know enough about it so wanted to try C. I "started" with C89, and when I look at a lot of other languages, I can understand computer-science-wise why they'd want this or that opportunity that C (C89) doesn't offer or offers poorly, but at the same time, *I* have *my* limitations. There is still work that can be done in C, and other "more primitive" languages, which I find suitable for how I want things to go, and I am good in those. Sometimes it's not a case of fluency or disagreements, just a matter of taste and what we find ourselves compatible with!

At least you aren't switching to java

The problem is how C++ is being taught. Lot of the tutorials often skip the basics and go straight to the advanced things. But it isn't always fault of the teacher, sometimes it's also the students to blame. They want to skip the basics, because they find them boring and want to go straight to programming computer games, which is one of the most difficult thing in software engineering. My recommendation: Start with C, learn something about computer architecture and hardware, write yourself some really low level code like for Arduino, AVR or other small embeded CPU. Then try to write some bigger more complex program and experience the problems with a lot of code. Then start with C++, but not the most modern C++ standard, C++98, and learn how its additions help you maintain larger code base, what are classes good for, what is inheritance and polymorphism, what are templates. Then study C++03, C++11, C++14, C++17, .... It will take you a shitload of time, but that's the only way to properly understand all of it. C++ is not a quick-start language, it cannot be learned in 10 days, remember this joke i.redd.it/1fl5yi6bbpzz.png When you start with C++ as your first language and you go straight to the most modern standard, of course your head will blow up and you will search other language to escape to.

I was thinking about learning c or ++. Since i dont care about 3d gfx or gaming, but computing for infrastructure and mission critical operations use, i think c would be best.

I find it so much more fun to write code in C than C++. C is simple and powerful. You have the control of writing assembly with just enough abstraction that you don’t hate your life.

I've been working with C for the past 10 years, in the past year I've been working on python and you wouldn't believe it. I keep going back to C.

Give a look at nim. It is a modern language that compiles to C, you can choose to use a garbage collector or to manualy manage memory, and is not object oriented

A year into programming. I've wrote Js, C++, and C. I prefer C for now.

I can see how OOP can be more close to real life but I just hate it when they ask you to do everything with it. It’s so verbose.

I just stopped using getters and setters in my Java code for 99% of the cases. That kind of encapsulation is usually useless.

i love C you really get a feel for what the computer is doing with C.

After BASIC I graduated directly to machine code in ‘82. My Z80 machine had 2k usable RAM and I couldn’t even afford the space for a Hex Loader... Once I got access to an Archimedes in ‘90, I ran a comparative test between ARM Assembly, FORTH, Pascal, and C. The optimizing C compiler destroyed even my hand-tuned assembler code! C++ allows you to de-optimize your pure C when it makes sense, but I still think in C!!!

I was already using C++ as a Better C but now Im starting to write more code in C to see if the advantages of C++ are really worth it.

So there are a ton of misconceptions in this video and in the comment section, as an avid c++ programmer I'd like to access them: 1 - OO programing is bad - this is partially true, the OO approach does incentivize new programmers to write bad enterprise code, but just because you can eat tide pods, doesn't mean you should! Use the language features when you should, not when you can, this decisions are your job as a software engineer/ computer scientist. 2 - C++ "idioms" are nothing but syntax sugar and aren't better than the equivalent c code - this is false, when using this abstractions, not only are you using code that has been written and re-written by a lot of really dedicated coders, but also, it helps the compiler when optimizing your code. (The std string library, for example, isn't just a wrapper around char*, it does a lot of small string optimizations that would take a lot of function calls in c, but are implicit in c++) 3 - There is no hidden code execution in C - partially true, C++'s abstractions may have hidden run-time costs if used incorrectly, and these aren't well documented, but in C there is also hidden code being executed that most people don't know about. Did you know that malloc isn't a kernel call? 4 - C is minimal and easier to master - true, C++ is really complex (some would say bloated but I don't think so), and because of this it isn't uncommon to look at standard C++ and not understand what the code is doing. But I'd also say that if you aren't able/ willing to learn new tech, then this really isn't a profession for you. :( 5 - You need C to make an API to talk to other languages - Partially true, C++'s OO approach makes it easier to interface with high level languages, and if you really want/ need the c bindings, is as easy as putting your functions inside an "extern C" block. 6 - C will force you to learn how computers work making you a better programmer - false, If you really want to learn about "how computers work" program in assembly, there's a reason we don't do that... Multi-threads are a nightmare in C, making it easier in C++ doesn't make you a worst programmer, just makes you a more efficient one, high level abstractions aren't an excuse to not learn about your hardware. 7 - C works on all OS - true, but so does C++, fun fact: C++ used to be transpiled to C, a language can work in all OS as long as there is a compiler for them, and there is one for C++ on most OS. 8 - Debugging in C is better as there is no hidden code - false, in C++ (and in C as well) you should be sure that the "hidden code" (either from a library or the std) doesn't have any errors so there is no need to debug it (you wouldn't debug malloc for example). If the code you are referring to was written by you, then it isn't hidden and you can very easily jump into it. As a side note I'd like to say that just because people miss use inheritance that doesn't mean that it's inherently bad (pun intended), most of the time, you shouldn't be using it, but when you should it is really useful and makes your code base easier to maintain. Also, if you have setters and getters who only set and get a variable (without any additional steps like setting a flag for example) those variables can and should be made public. Another example of bad enterprise coders, and miss informed RU-vid tutorials being confused with a language flaw...

Just got The C Programming Language as a gift for my Birthday 😊

hello i saw interesting you r video. im i have a doubt im electrical/electronic engineer. the unique thing that i know is assembler and c. and i use it to program microcontrollers and microproccesors. But which other uses have c in the programming universe? saluts

Subbed! Because I agree with you. I know that's the worst reason ever but I agree with you so strongly it makes me think you might be equally enlightened on other topics 😁

You surely have a point there! I quite often search for solutions and ideas online, and whenever there's that straightforward, easy-to-read Cish treatment for the problem, there's always someone saying "well, hey, don't use this, you can just cast this and that instead blah blah". I'm more than usually tempted to think about why people think that kind of coding is better, since it makes things way harder to understand and debug. I might be wrong, but I believe programmers that are more connected to the "bare metal" way of things find it slightly harder to deal with abstractions as their way to go...

Most of what C++ does for me I can do myself in C, and with a lot less aggravation. One thing that seemed magic about C++ was the way the throw-catch would destruct and clean up as it goes up the stack. Now that I've discovered the talloc library I see it can be done with setjmp-longjmp. talloc is amazing for keeping memory clean. I had programmed C++ for years before I discovered Scott Meyers' books. It blew my mind that I had been writing C++ without that huge body of knowledge. But that is C++'s big negative. If you have to memorize *that much* stuff just to be an effective C++ programmer, that reflects poorly on the language. The opposite of elegance. I feel much more at peace, and omnipotent, writing C.

The only reasons I use C++ is STL and that it handles strings better than C. Are there any STL alternatives in C?

Start with C and now write mainly in C++. Forgot about OOP, if ppl switch back to C then where is their standard library, dynamically allocated array, string, smart pointer? Do C has anything similar or do I have to re-invent the wheel?

I'm very much tempted after listening to this to launch into a sermon about object orientation in general. I would never say that it is wrong to use OOP. After all, some problems actually lend themselves to a object oriented solution. The only problem is that far more problems lend themselves to a procedural/functional solution. I find that it is nearly impossible to explain this to diehard C++ programmers. Why? Most have very little notion of programming without an object oriented language. The problem here is just education. There are a few generations of coders out there who have been educated to think that a language like C is obsolete, because it is not an object oriented language. I have my own theory about why computer science education has lost it's way, but that would be too lengthy to get into here. Even Bjarne Stroustrup himself admits that he never intended that C++ would be used produce only object oriented solutions, but at the same time he keeps saying that C has been made obsolete by C++. I think he wants people to use C++ to do structured programming, using encapsulation as the primary organizing feature. Still, for me, what makes C stand out, is the same thing that made it stand out back in 1982 when I got my undergrad degree in computer science: When you are writing code with and understanding and concern for the underlying hardware, there is just no better language. Yes, such coding can be done in assembly language, but it's very hard to write assembly language that can be ported to other hardware configurations. OOP, in general, has failed to live up to it's promises, especially reusability. The famed "reusability" has never happened on a large scale. In fact, it seems that the only reusability that has really materialized is in language features themselves, container classes and the like. I think that this failure comes down to a simple problem: object orientation has a lot to do with how the programmer views the problem and it's solution, and this can be radically different from programmer to programmer. For me, there's little doubt that C++ is a powerful programming language, but two things are destroying it. (1) Complexity. The beauty of C is in it's simplicity, and with regular and copious help from the C++ Standards Committee, there is precious little of this simplicity to be found today, save for the saving grace that you can still write C-like programs in C++. This complexity also makes it more time consuming to learn, and because it is now so top heavy, it seems almost like programmers can code with radically different styles on the same project, which leads to difficulties. (2) Expense. There's little doubt that C++ is an expensive choice for a project. It seems that other languages are much better at trying to do it all.

Why I'm switching to Assembly in 2021 Comming soon.. stay tuned.

Started programming in the late 70s and early 80s with BASIC and 8 bit assemblers, moved to Pascal a few years later, then C, then C++ where I've been happily programming ever since. My initial C++ was very C like and to a small extent still is, though I do use templates a lot. What I like about C++ is that you can express much more in fewer lines of code and more readily manage the complexities of very big programs. Templates and inheritance for example let you neatly provide similar functionality without having to cut & paste chunks of code around the place. Less code means less maintenance. For short console applications I still use C as I find it is quicker to write in that scenario. For bigger stuff, C++ all the way. What's great is that you can mix and match to suit your needs. The other area where C like code wins is in GPU compute and shader languages (Cuda, DirectCompute, OpenCL, etc...) which are all pretty much C syntax without much OO.

Watched this with a big smile on my face.

My take is the language itself doesn't matter *that* much compared to the libraries and dependencies you are using. All the modern day libraries have some absurd overheads and really bottleneck you when attempting to run at a high framerate or on bottom of the barrel hardware. Of course, if you just use all the abstractions and design patterns like the "big boys", you'll end up with mediocre performance as well. People don't remember how 20 years ago you could run the whole operating system, internet browser, icq and mIRC at the same time, and use only 32MB RAM on a 200MHz CPU. And the whole thing would fit on a 300MB HDD. Meanwhile Discord for example uses more than 300MB disk space and 300MB RAM. You can't tell me Discord is bigger than Windows 98. Chrome can't even open a blank window without taking 500MB. We live in a mess.

I honestly hate how C++ gets such a bad rap for pretty stupid reasons.

I've been programming in C and assembler since the early 80s and c++ since the early 90s (and several other languages along the way). I generally use basic C++ (sort of c-styled) with templates where required for performance (macros would do the job, but would be even less understandable). I think that people underestimate the cost of training graduate programmers to use modern C++ and focus on "malloc is evil" instead.

Loved your reflexion.

You don't like setters and getters? Don't use them! :) You don't like templates? Don't use them! :) You don't like multiple inheritance? Don't use it! :) None of those are mandatory features of C++! But let's be also honest here: once you'll have written your Point data structure and fast linear algebra functions to work with integers for pixels, and later on you code another game but with OpenGL, and you want to use floats, you'll wish you had written a Point. And why should anybody even be against RAII?

yeah, if way you are using c++ is very similar to c then it is best to use c directly, in particular if you don't like hidden code. C++ power comes from destructors, templates, compile times checks and the increased declarative style. if you don't like using those, or the people you are working with are not able to, then c is better.

I honestly don't mind OOP stuff, but I see what you're getting at. I'm in the process of making games for the sega saturn and it's all C. I like it, but kind of wish I could do classes and objects as my projects get bigger.

I am shifting to C++ to program embedded systems. Any suggestions.

Underrated

Yup, my preference is C. I wrote a few games in the late 90's and 00's, mostly in C.

Thanks! Awesome video!

I've used both extremely extensively and I prefer C at every turn. There's 2 things that make C++ more or less objectively better and that's because templates are a semantic generic system, which makes them far better than the barely useful macros either language claims to support, and proper syntactically encodable namespaces. C namespacing is essentially "well just don't give it the same name or only make it useable from a library". But that does mean large enough projects or general enough libraries end up with a slew or Daisy chain of underscores if you are oike me and care about proper namespaces. I've also made the conscious switch to C a mor or less permanent decision and haven't had any issues. It has libraries offering all the same functionality as C++, and I'm currently in the process of writing a Lisp to replace the C macro system. It will compile before you compile C. Effectively removing my only complaints about C

I don't really know either of these languages, but I enjoyed the video :)

Personally I find things like auto and templates to be useful so I use C++. Although I can understand why some people hate C++.

Do you recommend using some specific library for containers and data structures in C or do you usually write your own code for that now that you are using C?

I'll just compile C++ most of the time and use whatever feature I prefer. If I like to write C style at places, I do so. If I like some C++ or newer C++ features, I might consider using them. What annoys me is the dogmatic approach of some C++ programmers, where you are not supposed to use certain things because they are considered deprecated. Also, in some oldschool platforms of course C is the only option, like when I code for 3DO and I have to use an old ARMC compiler. I don't mind as I keep my coding style not affected by dogmas and I use whatever tools I have in my posession.

A cool thing I learned from C is to write my code in a more elegant way instead of relying data structures provided by the STL

After working with C++ for a few years, and having been practicing it for over a decade, I love the static typing aspects of it, I like templates as well, but their usage in even a slightly bigger project quickly increases the compile times to a point where it becomes a pain. I'm definitely no paradigm priest though, object-oriented code is appropriate sometimes, but not all the time, especially multiple inheritance, or inheritance trees deeper than two, should be avoided for the most part imho. I have contemplated going C multiple times, as there are some benefits to it, especially if familiar with good practices, but honestly, Rust seems like the perfect fit, even if I still have a lot to learn about working with the borrow-checker, and sometimes around it.

Folks, you can write excellent abstractions in C, including OO abstractions. I've done it in the past. I've written a full OO library with single inheritance, exception-handling, and Design by Contract ala Eiffel, and it was all pure C. Programming in my C library was refreshing and robust, and as long as I used and built atop my core library, I never saw memory corruption. After building up a healthy core library of classes, new code would work often the first time. Sure, my programs might trigger assertion violations, because of the built-in runtime error checking, but the error-checking harness was extremely helpful in identifying errors, which I fixed quickly. My programs were very robust and easy to understand because of the clarity and care in how I wrote the code. Now, professionally, I've used C, C++, and Java, because I must deal with codebases in these languages. Use what's relevant. Write clear code whatever you use.

After 35+ years of programming in a 1/2 dozen language variants the vast majority of solid code I've built has been in C. Most currently a variant of Objective C where the first parameter of every "class method" function call is the data for the "object" instance.

Not using Lisp to do everything is an injustice.

Eggsembly is the Best Language, hands down :P

25+ years programming in C++. Earlier this year I dug up a C project I'd written 35 years ago thinking to convert it to C++, but part way thru I decided to just try refactoring it in modern C -- note to C++ programmers: C++ is based on a specific dialect of C89 and is *not* a superset of C but a derivative, and each C++ standard has made the divide larger by trying to retcon newer pieces of C into C++. There was actually some significant learning involved in switching to C17. Working in C was delicious for a while, but was ultimately a satisfying reminder of where C++ promised to take us while underlining how badly it has gone wrong, so badly that folks like Scott Meyers wanted out. "Modern C++" has become a celebration of needless complexity and showmanship which relies entirely on idioms rather than simple expression, which is simply a posh way of saying: the language doesn't specifically support that, but if you sacrifice chickens the right way, it can be made to happen. What this leads to is a lack of statement of intent. C++ programs aren't hard to debug because they're hard to read, but because it's frequently hard-to-impossible to tell what the author intended. As a person who has promoted and taught companies to transition to C++11 and 14, I still want to kick someone for deciding on "std::move" as the way to express "I want an rvalue reference of this", I am so tired of having to explain to engineers "I know it says move, but it doesn't actually move it". One engineer replied "so it's more like a python decorator? C++ has functions that are decorators instead of functions?" and I didn't know what to say. What you should hate about C++ is it's templating DSL, hierarchical inheritance and aversion to 'invented elsewhere'. A huge portion of what's wrong with C++ festers from not having a way to describe purely functional contracts, because people call those interfaces and java did that. While not endorsing it as a replacement for C or C++, I would encourage anyone wanting to improve their C and/or C++ to learn enough GoLang to write a program that stretches the legs of their interface concept. I found myself bringing a lot of re-invigoration back from go to my C++ and C coding that quickly spread among my colleagues.

The reason for using classes with getters and setters is that if in the future you need to adjust a value or call some other action before each get or set, you can do that a lot easier than going through your entire codebase and finding each and every place where you do that and copying the same code all over the place. I only use getters/setters where i think i will need to override the function in some cases to calculate a value for certain subclasses instead of just reading the value..

C++ supports C. So, I can use the good features of both of them. So, I stay with C++.

there is a third low level lang called Rust

I use c++ only because string, map and queue are contained in standard library. (strings can change size as I push new chars in it while using *char I'd have to allocate space for new char array that is one byte bigger and copy the contents of original char array)

I just switched to Commodore Basic V2 in 2019, to write a program that will modernize the entire internet by making the overlap between PETSCII and Codepage 437 characters easily available for the web - if you have a C64. ;-)

Just use what you find useful from each and let's be done with this already, seriously.

Why not move to Rust?

First thing, I'm a uni student, so I don't have that much experience outside the curriculum. Now, my personal favourite PL is C. But I find it easy to get very frustrated with it especially when dealing with system programming. What I find interesting in OOPL, is the hierarchy of systems that you can create, and I find myself kinda replicating that by creating libraries that look like classes. And in my option, instead of passing void pointers it is easier to overload a function or create an interface class. As a language I love C the most, and I find it the most intuitive (try working with lisp), but you can't deny that large projects with many modules that can be used interchangeably can benefit from OOP.

I switched from C++ coding to C style C++ coding, because recently i really understood why we use classes in the first place. Though I'm not sure, if i will switch to C in the future, because, well, I like how much the std library offers us and that i can attach functions to data types.

I once expanded on the details of C++ and how it is often used to make perfectly functional C-code into gibberish in a job interview...they did not hire me as I showed a clear lack of understanding of the basics of programming :)

I just write all my programs in assembly.

As a newer developer working in .NET, I have been learning functional programming in my free as it seemed to address a lot of the stuff I didn't like about OO. I may have to jump into C afterwards and see the other side.

My first semester of EE we learned C programming which I really enjoyed. It was easy to understand and dare I say intuitive (well after some practice). The second semester we learned C++ and the goal was to introduce us to OOP as a concept. Sparing you the details: I somehow managed to wrap my head around overloading operators, classes and inheritence. Where I threw in the towel was templates.. Is there anyone how can make use of them in a code? Because it gets so convoluted so fast that I don't think there is any one human being who can comprehend those god damn templates.