all 38 comments

[–]ID10T 6 insightful - 3 fun6 insightful - 2 fun7 insightful - 3 fun -  (1 child)

"There are two types of computer languages; those that people hate and those that nobody uses."

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

Poor lolcode

[–]EternalSunset 5 insightful - 3 fun5 insightful - 2 fun6 insightful - 3 fun -  (7 children)

C++ is built to be fast, not pretty. You can't have something that runs as fast as assembly and still looks as clean and easy to understand as Python. Most of the features that haven't been added to C++ despite being heavily requested weren't added because they would have made the code run slower. Langs like Java and Go can still run pretty fast while looking significantly more elegant than C/C++, but C++ is still the undisputed king when it comes to raw speed and that's why it still is widely used despite being a pain to work with.

[–]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 - 1 fun1 insightful - 0 fun2 insightful - 1 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.

[–]GeorgeCarlin 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.

[–]TaseAFeminist4Jesus 3 insightful - 1 fun3 insightful - 0 fun4 insightful - 1 fun -  (0 children)

C++ is built to be fast, not pretty.

None of the C++-specific parts make it any faster than C. They are intended to make it more... powerful? legible? intuitive? modern? I really can't put my finger on what they're going for.

Maybe there's a mission statement or a quote from Stroustrup out there that explains it. To me, the whole thing seems to stem from a 1980s-vintage belief in OOP that I'd hope is completely obsolete in 2022. OOP has accomplished nothing.

[–]magnora7 5 insightful - 2 fun5 insightful - 1 fun6 insightful - 2 fun -  (1 child)

The fact it's as old as it is, and it's still relevant, speaks to how powerful it is. Almost all languages of a similar age lack the complexity to be able to still function in the modern age, and C++ is able to keep up, even though it's not at all pretty in terms of writing code. Most modern programming languages are just skins for C++, to make it easier to program in

[–]Vulptex[S] 5 insightful - 2 fun5 insightful - 1 fun6 insightful - 2 fun -  (0 children)

The same thing can be said of regular C though, to a much greater extent, and it is fairly pretty.

[–]GeorgeCarlin 4 insightful - 2 fun4 insightful - 1 fun5 insightful - 2 fun -  (9 children)

I hope you will try Rust then. I'm not really doing Rust myself. But I heard a lot of good things about it from students and colleagues.

Maybe I'll even visit a lecture about it next summer.

I started with Java about 15 years ago and then took off to Haskell and Erlang mostly. These are my homes, so to say.

That is why I can remember these kind of problems only very dimly. But i can relate to them. Being the reason me searching for alternatives in the first place.

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

Rust is good in very specific plain programming, but it restricts the use of data far more than necessary.
If you work with complex data structures, it becomes much much harder than it needs to be.

With C or C++ you can just deal with the complex data in simple steps.
In Rust the complex data-structure (like recursive graphs) is impossible by definition, so you need to create something to replace it.
And this replacement adds another layer of complexity.

The excuse Rust-programmers use, is that complex data structures are wrong. But they never programmed any complex system to begin with.
So you see that Rust is only used for simple things that have no such structures. High end programs, like triple-A games or graphical tools are not rust-friendly.

If you want to replace C or C++, I would currently advice Nim.
And for very complex systems, Elixir.

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

After reading this, I will definitely give it a try. I am torturing myself a lot with Merkle trees recently. Since I've been hitting some dead ends recently anyway, why shouldn't I start from scratch ?

[–]zyxzevn 4 insightful - 1 fun4 insightful - 0 fun5 insightful - 1 fun -  (0 children)

Just don't do any complex data structures. And follow the guidelines.
As long you stay within the rust-box it works ok.

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

Nim is genius. Static types and generics and no hassle with JavaScript and meta-programming ? It even has lamda-expressions !

What the fuck more can you even ask for ?

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

I made some small things with Nim, like a reader for HTML that converts into a database.
The structure is very simple and the generics are very meta and can be combined with macros.

In programming it is like an improvement on LISP with types. And it encourages you to keep things plain and simple.
It even looks like Python.

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

I started working a book about it yesterday. Which says a lot. I'm not a guy easily convinced by new stuff.

But nim I just didn't know about.

I still wonder how the fuck this could happen, but that is not the point here. I wanted to try out something else than Erlang or Julia for a long time. As my main languages.

Seemingly every one of my colleagues does Rust, so nim is perfectly fine for me.

I'm always the offbeat guy. Every one knowing me knows that. I've got to defend the spin on a legend here, you know ?

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

Hey, let me know if you have any updates about rust.

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

I've never tried Rust before, but from what I've heard it and C are the best.

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

I very much like Rust

[–][deleted]  (3 children)

[deleted]

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

    Python sucks ass yeah

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

    Python doesn't suck, but people try to use it as a programming language when it's meant primarily as a scripting language.

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

    Oh yeah, I forgot about the compile times.

    [–]HongKongPhooey 3 insightful - 2 fun3 insightful - 1 fun4 insightful - 2 fun -  (4 children)

    I cant argue with any of things you said, but I'll take C++ over javascript and most of the newer languages any day.

    Fuck virtual memory bullshit.

    Fuck garbage collection

    Fuck dynamic typing

    Fuck interpreted languages altogether

    Personally I like Rust, and think it is a lot of the things C++ should have been

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

    C works on anything. My windows box. My Linux box. My dos box. My microcontroller.

    But, Microsoft likes rust, so it's got to be good and stable.

    Hold on a sec, I just threw up in my mouth, I gotta swallow this crap now.

    Holy shit, my tongue feels like it is burning with acid puke.

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

    C works on anything. My windows box. My Linux box. My dos box. My microcontroller.

    So does Rust

    But, Microsoft likes rust, so it's got to be good and stable.

    It is memory safe unlike C/C++ and just as fast on benchmark tests

    https://medium.com/star-gazers/benchmarking-low-level-i-o-c-c-rust-golang-java-python-9a0d505f85f7

    C is a great langauge, I like it and was defending it, but I like Rust for a lot of the same reasons

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

    For every platform you're almost guaranteed to have a C89 compiler. Other languages don't have as widespread support, even C99.

    [–]chickenz 1 insightful - 1 fun1 insightful - 0 fun2 insightful - 1 fun -  (0 children)

    the first topic covered in this video is BINARY BLOAT...

    video: why i hate the rust programming language.

    https://www.youtube.com/watch?v=ksTyCQwHGro

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

    OOP is a neat idea, but it doesn't work that well in practice. At least there's a C++ standard now, once upon a time you had to learn a compiler specific implementation.

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

    Even with the standards there's still a lot of compiler-specific stuff. Even C99 support can't be found everywhere. And there are some useful features, especially in C++, which can only be accessed through compiler-specific extensions.

    [–]chickenz 1 insightful - 1 fun1 insightful - 0 fun2 insightful - 1 fun -  (0 children)

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

    OOP is fine and great for many problems. However, with most OOP languages...everything has to be Object Oriented whether it makes sense or not.

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

    OOP is fine and great for many problems

    I can't think of any problems where OOP has more benefit over the complexity it adds, but it's been a couple decades since I touched a compiler.

    [–]Vulptex[S] 3 insightful - 1 fun3 insightful - 0 fun4 insightful - 1 fun -  (1 child)

    Why? Compilers are great. The difficulty of compiled languages is very much exaggerated. In fact I think C is one of the easiest other than how few libraries are written for it. Native compilation, no OOP, raw data management. Not as hard as everyone says it is.

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

    My love for programming died. Just one of those things. I don't even use a computer unless I have to. It's fantastic.

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

    Actually Java is the only one I can think of that forces OOP on you. However if OOP is available the so-called "best practices" tell you to use it for everything, and treat that as dogma.

    Still, I have yet to see any case where OOP solves problems procedural code couldn't handle just as well.