Why are there high level languages?

Why the hell would anyone use Python or Ruby over C. The software should be nice to use. It's not nice when the program is slow as fuck.

Their dynamic nature makes debugging software increasingly hard. Basically developing with these higher level languages takes more time than with C.

Every program should be written in C. In most cases, it would be good to also optimize tight loops with Assembly. This way programs would be fast and fun to use.

Languages such as C# and Java have no point at all. They are essentially crippled versions of C. Limited pointers and limited memory management. The virtual machine takes forever to JIT-optimize the code, thus harming the user experience. Not to mention GC, which slows everything down, providing nothing useful in return. GC is shit.

Then there are these C++-retards. Sure, you can in theory make as fast C++-code as C-code, but is it really worth it? Every C++ program in practice is slower, harder to debug, and harder to develop.

Functional languages, such as Haskell are no answer to problem. They abstract the hardware to hell and are very slow in practice.

So tell me: Why is C and Assembly not used for every program today?

>>56

it' also means that you can use the same functions to handle different kinds of data stored continously in memory as they don't start going crazy when they se \x00.

You mean like how EOF can be a valid char inside a FILE stream...? And strings can't hold any composite type other than strings? I guess you're right here -- I'm sure length-prefixing has it's benefits (personally, I'd most likely choose length-prefixing over null-termination, too) but in the end it would probably not fix a whole lot of problems (and introduce some others, like manipulating the length-field instead of the terminator for an attack vector; also: what about portability?)...

But you know what? I'm still not convinced we need HLLs (at least not some of the currently popular ones like Java, like I mentioned). One could make a lang similar to C (in scope and performance) AND have securities.

>>59
Because in this case, building them with hammers and wood costs only about 1/6th and the resulting skyscrapers still have 80% stability compared to the ones built with cement. And now convince the architect that hammers and wood is worse than cement and cranes.

>>60

manipulating the length-field instead of the terminator for an attack vector

that wouldn't be easy because you'd need to overflow something before the string and if everything does prefix-based bounds-checking, you have a problem. attacks on heap (if the allocator uses metadata) work like that but they're based around bounds-checking not being present

what about portability

what about it? neither null-terminated strings nor length-prefixed ones are a hardware-level feature, they're both programming language constructs. C chose null termination because storing additional byte had less memory overhead than storing an additional integer (which, again, is not something you should care about on modern machines). I don't see how 'take the integer x and iterate through x bytes next to it' would be less portable than 'iterate through those bytes until you see \x00'.

But you know what? I'm still not convinced we need HLLs (at least not some of the currently popular ones like Java, like I mentioned). One could make a lang similar to C (in scope and performance) AND have securities.

sometimes, a high level language is just a better choice, especially if performance is not critical (and as I said before, for the vast majority of programs the performance will still be good if you don't add bloat). I don't really like Java though