you are viewing a single comment's thread.

view the rest of the comments →

[–]Vulptex[S] 4 insightful - 1 fun4 insightful - 0 fun5 insightful - 1 fun -  (5 children)

C is as fast or faster than C++ and it's usually clean. The problem is bloat and excessive OOP.

[–]package 2 insightful - 1 fun2 insightful - 0 fun3 insightful - 1 fun -  (3 children)

No offense but this is typically the attitude of programmers fresh out of HS that obsessively optimize despite the real world cost of an "expensive" operation being something like +1 nanosecond and 3 extra bytes of memory, or think that the number of function calls in a section of code directly correlates to the performance of that section.

Much of the ugliness of C++ is a result of abstractly describing the lifetimes and locality of data, which in many cases can allow the compiler to generate more optimal code that is actually faster than what a simpler C program could achieve.

[–]Vulptex[S] 2 insightful - 1 fun2 insightful - 0 fun3 insightful - 1 fun -  (2 children)

Huh. I've always seen older people agree with me, because even C++ is too "outdated" nowdays to be taught in schools. Not only that, but schools are what encourage the "best practices" which are actually the worst. This is usually excessive OOP, little to no optimization, pointless commenting, getters and setters and other waste of time bloat, using features for the sake of using them, and thinking about inheritance and object structures before the actual program. Basically busywork, it seems like you're getting something accomplished but it's not advancing your program any. And it ends up being a bloated, unreadable mess that has to be completely refactored to make even small changes.

There's a reason a lot of top programmers stick to C and other "old" languages. They not only produce faster programs, but they're much cleaner and more maintainable, and you don't waste time with all those complicated abstractions. Many open source projects also do this for the same reason. And apparently corporate codebases are horrific, so they probably need to reconsider their practices as well. But unfortunately most people don't worry about how well something works when it comes to technology, only how new it is.

I'm not sure what you're talking about for C++ and lifetimes and locality of data. Most of the abstractions are trying to hide that, not specify it. C is notorious for making you work directly with memory and raw low-level data. It's no harder than using abstractions, just different. But it works better because it does exactly what you tell it to, not many gotchas.

[–]package 2 insightful - 1 fun2 insightful - 0 fun3 insightful - 1 fun -  (1 child)

Huh. I've always seen older people agree with me, because even C++ is too "outdated" nowdays to be taught in schools. Not only that, but schools are what encourage the "best practices" which are actually the worst. This is usually excessive OOP, little to no optimization, pointless commenting, getters and setters and other waste of time bloat, using features for the sake of using them, and thinking about inheritance and object structures before the actual program. Basically busywork, it seems like you're getting something accomplished but it's not advancing your program any. And it ends up being a bloated, unreadable mess that has to be completely refactored to make even small changes.

This is exactly how I felt during high school as someone who had already spent many years learning to code outside of school. While I'll agree schools don't generally spend enough time on real world use cases, the reason you are being taught these concepts is because they aren't necessarily obvious, and just because you are already familiar with these things doesn't mean everyone is. Many of these concepts, like OOP, are easier to digest as something like the classic car+tires example, which is obviously not a realistic use case. It's busywork, yes, but that's because it's a lesson. The same goes for things like commenting; while you aren't going to be putting comments on every single line of your code, it's a good exercise to reenforce the purpose of the code being written. It's also good practice for learning how to describe functionality in a concise way, which IS something you'll be expected to do in real world programming regardless of the language, especially since tools exist for automatically generating documentation from comments in a project.

There's a reason a lot of top programmers stick to C and other "old" languages. They not only produce faster programs, but they're much cleaner and more maintainable, and you don't waste time with all those complicated abstractions. Many open source projects also do this for the same reason.

"Top programmers" generally branch out to whatever is new and popular and don't limit themselves to a single language, especially not a low-level language. Code is still written in C (as well as C++ and some more esoteric languages) because existing codebases use those languages.

And apparently corporate codebases are horrific, so they probably need to reconsider their practices as well.

This is because the overly verbose dumpster fire that is Java was super popular once, and companies used applets for cross-compatibility just like companies use Electron and/or SPAs today.

But unfortunately most people don't worry about how well something works when it comes to technology, only how new it is.

Nonsense. People choose what takes the least amount of effort and time to produce a reasonable result. Currently that would be JS and Node JS. A while ago it would have been Python, and Java before that.

I'm not sure what you're talking about for C++ and lifetimes and locality of data.

This is now sounding like you aren't actually familiar with C++ beyond coursework; one of the main abstractions of C++ is RAII and specifically move/copy constructors. In conjunction with references and const declarations, these allow you to describe the ownership of an object and safely pass it between various scopes. Along with classes this also enables you to make guarantees to the compiler regarding the intended state of an object, what data it carries with it and which methods are valid to use with it. Whereas in C, you're passing around raw primitives/structs, pointers to those primitives/structs, and pointers to functions, which all give the compiler none of the context it needs to effectively inline function calls or remove unnecessary initialization/copying.


Look, I understand exactly where you're coming from. I felt the same when I was younger. In the real world you'll quickly realize your current attitude toward abstraction is only going to hold you back, lower your productivity, make those who inherit your code want your head on a pike, and keep you from some genuinely exciting and satisfying types of programming.

[–]Vulptex[S] 1 insightful - 2 fun1 insightful - 1 fun2 insightful - 2 fun -  (0 children)

Oh no, what I mean is we're taught that it's a good practice to waste time coming up with intricate OOP structures instead of actually programming something. And they tell us to comment everything it's doing when it's completely obvious, as if a non-programmer should be able to read it, not to explain why you're doing something.

Code is still written in C (as well as C++ and some more esoteric languages) because existing codebases use those languages.

And also because those languages still suit a lot of things better than others. C and C++ aren't dead, new projects are started in them all the time.

Currently that would be JS and Node JS. A while ago it would have been Python, and Java before that.

Holy shit hell no not javascript that's a nightmare. It never works right and you have callback hell and a bunch of other crap. If you think C is hard JS is 100x harder. Python is easier, but very slow and not too powerful. Java is easier but not as powerful and a bit slower. But the real reason those languages are easier is because of the abundance of libraries available for them, not because the language itself is inherently easier.

one of the main abstractions of C++ is RAII and specifically move/copy constructors.

Yes, those are in C too. You just have to actually do them instead of hiding them behind an interface that makes it look like nothing much is happening.

In conjunction with references and const declarations, these allow you to describe the ownership of an object and safely pass it between various scopes.

C has const, and references are the same thing as pointers.

Whereas in C, you're passing around raw primitives/structs, pointers to those primitives/structs, and pointers to functions, which all give the compiler none of the context it needs to effectively inline function calls or remove unnecessary initialization/copying.

Can you give me an example? Classes and other abstractions would usually prevent the compiler from being able to make those optimizations, not help it. The only exception is templates, which can be done in C, even though people don't use them for some reason. You just can't mangle the names of the generated functions (which makes sense, so you get the expected assembly output). And nowadays even that might not matter, because compilers are starting to make indirect function inlines.

[–][deleted] 2 insightful - 1 fun2 insightful - 0 fun3 insightful - 1 fun -  (0 children)

OOP is nonsensical for most problems in combinatorics. It took me a long time to wrap my head around this fact.