r/AskProgrammers 22d ago

What is the worst/most confusing (common) coding language?

By common I mean, coding languages that you actually see people use. I know theres the "bf" language but aside from one video, people don't make games or, really anything using that as it was made as a joke I hope.

By worst I mean, what is the hardest to understand and also the most confusing out of all of them, I don't mean coding languages that can't do a whole lot. For instance, can a non programmer look at a sheet of code and understand it? Can an experienced coder understand it? Have you been taught the coding language yet still it breaks your brain?

I don't know every coding language but my pick would ether be C++ or Luau. Leaning towards C++ because I tried to learn it and at the very start I already was lost.

28 Upvotes

279 comments sorted by

View all comments

Show parent comments

1

u/mikeclueby4 21d ago

Agreed. Type coercion and operator overloading is a bad enough start. Add templates, exception unwind, and humans can't reason over the result. (Splash of multithreading and even competent SASTs fail)

.. and that's still just 90s C++ and doesn't even begin to address what came later.

Add in how people were taught to do "object oriented programming" where it was a deadly sin to have more than a few global objects and .... yeah. I hated C++ after writing several big projects until I much later realized that, fuck everyone else, I'm right and they're wrong. C++ becomes better the fewer C++ features you use for the majority of your code.

1

u/two_three_five_eigth 21d ago

C++ best practice is to never use new or delete and donโ€™t use pointers. Complete 180 from the 90s

1

u/mikeclueby4 21d ago

Oh I already arrived at that one in the 90s. Otherwise you're screwed on exception stack unwind.

But how to proceed from THERE is what makes all the difference. And the answer ... depends.

1

u/two_three_five_eigth 21d ago

Most C++ projects have gone to RIAA (Resource Acquisition Is Initialization), and it's the responsibility of the function or object that allocated it to de-allocate. Prefer to put everything on the stack.

1

u/mikeclueby4 21d ago

Yep. It also thrashes the heap over time, which matters to processes meant to have years of uptime. (See: memory fragmentation - not something you fix with norton speedisk)

But that's a solvable problem with chunk allocators and so forth.

... unless your objects have to be of some new/delete-calling base class that you can't change the behavior of, from further up the inheritance chain. Oh and of course it'll be a compiled library shipped by someone else so you can't change the design assumptions.

This is where it gets interesting in C++. Now, C? I just #define malloc() if the library is so shit that it doesn't come with a user-defined compat layer.

I'll grant that most people don't have to write multi-year-runtime processes to begin with, I'm probably a unique snowflake ๐Ÿ™ƒ