*laughs in erlang*
this post was submitted on 08 Jun 2026
299 points (98.7% liked)
Programmer Humor
31836 readers
540 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 3 years ago
MODERATORS
My first ever big boy language was C++ (after Basic, and Logo). I was in middle school, tried to self-learn from learncpp.com, only to realize that I had mostly learned C, with cin-cout instead of printf/scanf. So I just decided to migrate to C. Nowadays, I mostly code in Rust, Go, and Python. But my experience with C has been extremely helpful. Can't say the same about C++ though.
I think there is something to be said for keeping a language simple, though. The basic semantics of a language should be comprehensible to everyone, let the standard library have all the wacky stuff someone wanted decades ago. (macros - the lisp kind, not the C kind - make this easier)
I've spent decades programming C++. I wonder how it would've been had I started with C++11 or later? I feel like I had to do a lot of unlearning with that release which made things more difficult perhaps that they needed to be?
Similarly, I started Python towards the end of 2 and had to unlearn for 3. I seem to have bad timing in these things…
nobody should have to use c++ anymore now that rust and zig exists
header files are an invention of the devil
Header files are a thing of beauty! Languages that can't abstract away definitions suck (or are like script languages, which is fine for scripting).
definitions shouldn't be split into multiple places and i will die on this hill
load more comments
(1 replies)
What do you mean by "abstract away", and what about it is exclusive to headers?
Eg most languages have something like a trait or interface wherein you can put a list of definitions (optionally with a default aka "inline" implementation) which are then actually implemented elsewhere. This is considered useful by everyone because it allows multiple implementations to be associated with 1 name. They are generally not desired in cases where only 1 implementation will ever be written.
AFAIK the only use case where headers accomplish the same is if they're treated as documentation for an API that could be implemented by any library.
Admittedly certain programming styles benefit immensely from headers, despite the drawbacks to "design as you go" programming.
I like c/c++ headers because you can put the "code" in one file, and use the header file in your others where you need access to that code. And you can do that on a compile level. No need to for example compile a c# library that you'll then use.
In c# (for example) you'll include all the code in another file, when you just need one function. In c++ you include only all the definitions, if that makes sense.
In c# it quickly becomes a garbled mess IMO.
Sure, you can make libraries, but make libraries for every file? That's not optimal either.
So I guess I like it as it lets you split up code on a lower level, very convenient IMO.
load more comments
(1 replies)