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?

>>1
C was called a high level language when it came out, and everybody was questioning why anybody would use it, when everything can be done in asm under greater control. They were wrong as you are wrong.

>>35
securityfag/(wannabe-)haxanon here. I'm not talking about security industry, I'm talking about security as a concept. if you don't have non-executable stack and other hardening features, a badly written C program can be exploited by the same fucking code Aleph Zero published 20 years ago. if you have those (as they're usually on by default), it can still be attacked, just with a bit more work.

>>36
Java is a shitty language with annoyingly verbose syntax that runs on a shitty virtual machine, I said so myself. even then, consequences of using wrong string type in Java are minor when compared to the consequences of wrong string handling in C.

>>38
Bullshitter

the answer is to use devices that are open by design and avoid closed systems as much as possible

Not everyone can live like Stallman.

>>39
That's a problem with programmers who will try to add bloat no matter what, but there's far less of them using C than other HLLs (presumably because they've jumped to those HLLs instead.)

>>40
Features != bloat. C can make you reconsider that ridiculously complex O(n³) algorithm that would be obvious and trivial to write in a different HLL, so you'll think harder and might come up with a simpler O(n) one instead.

As for string handling, using strcat() and friends is usually stupid, especially if it's in a loop. You're supposed to avoid copying or moving strings whenever possible.

>>44
sweet dubs, girlbro

>>44
do you have to live like Stallman though? a basic fucking computer allows you to install any OS you want, most of which give you root. many Android-based phones have unlocked bootloaders so you can flash a software with root on them without needing to hack anything. having to gain root through exploits has one big disadvantage: malware can do that too (see: recent Android ransomware which gets code exec through browser exploitation and root privs through towelroot).

>>44

C can make you reconsider that ridiculously complex O(n3) algorithm that would be obvious and trivial to write in a different HLL, so you'll think harder and might come up with a simpler O(n) one instead.

Are you speaking from experience or your ass? Because in my extensive experience that simply isn't true: where in high level languages an efficient algorithm might be slightly more verbose than a naive one, in C it's significantly more complicated than the already verbose naive case, plus there are several especially inefficient but at least somewhat succinct patterns like C-strings or linked lists that even experienced programmers end up using against their better judgment.

>>41
C was called a ``portable assembly'' when it came out. It wasn't the first of its kind either.

>>48
C is acutally a ripoff of https://en.wikipedia.org/wiki/BLISS

>>45
Check 'em

>>44
You look more ignorant and willfully so with every post you make.

That's a problem with programmers who will try to add bloat no matter what, but there's far less of them using C than other HLLs (presumably because they've jumped to those HLLs instead.)

Define bloat. You always shuffle around your goalposts and never actually have a point.

Features != bloat. C can make you reconsider that ridiculously complex O(n3) algorithm that would be obvious and trivial to write in a different HLL, so you'll think harder and might come up with a simpler O(n) one instead.

Algorithmic optimization is 100% orthogonal to the language used. And reducing the big-O qualities of an algorithm is far easier in higher level languages where you don't have to worry about the bit-level implementation details, so the very opposite of what you say is true: It is easier to do the algorithmic research work into a HLL than it is to do it in C.

>>42
I'm just saying that string handling isn't as complicated as you want to make it look like in C. And just adding more complexity doesn't necessarily fix real (==security, stability, etc) problems. What does fix most of C's string memory issues are the strn_() functions and things like snprintf() and %.*s.
Also,

Pascal-style length-prefixed strings

doesn't fix shit. When people can mishandle/abuse string terminators, they can also mishandle/abuse length-prefixing.

>>52
it's not that it's complicated, the correct functions are easy to use. it's just that it's not consistent because you have a few different variants of same function and some of them do bounds checking, some of them don't, some of them append null byte, some of them don't and you won't guess which does which if you're not used to handling strings in C. again, I'm talking from experience of doing vuln research and code review at a major multinational corporation, people get that shit wrong all the fucking time and half of the time if not for OS- or compiler-level hardening you'd be able to exploit that shit with the most primitive shellcodes.

When people can mishandle/abuse string terminators, they can also mishandle/abuse length-prefixing.

theoretically they can but length-prefixing allows for bounds checking at runtime with very little overhead, meaning it will be harder to fuck it up. a well-designed length-prefixed string handler won't let you write past the assigned length without explicit reallocation and overwriting the prefix would require overflow in memory before the string so the attack isn't as trivial as AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA[insert shellocde here] at worst and AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA[insert lengthy ROPchain here] at best

>>53

theoretically they can

Then they will, no?

well-designed length-prefixed string handler

Well, one could probably also write a memory-safe string system for C that uses zero termination then that does the things (or similar things) you described. So the problem isn't how the string is represented. Length-prefixed just isn't the silver bullet.

some of them append null byte, some of them don't

Yeah, well, that is indeed somewhat confusing sometimes. But you don't need the null byte sometimes, either (e.g. with %.*s, strncmp(), strncpy(), etc).

But let's be honest here: I think the one big problem with C and strings is that it doesn't offer dynamic allocation. I think C works just fine with fixed-length/pre-allocated strings. When you need dynamic strings, you have to at least write a wrapper for a dynamic string struct -- but even then some of the C string functions will come in pretty handy.

>>50
Check 'em

>>54
Well, one could probably also write a memory-safe string system for C that uses zero termination then that does the things (or similar things) you described. So the problem isn't how the string is represented. Length-prefixed just isn't the silver bullet.

it isn't a silver bullet but writing such a handler is easier here: you don't need to iterate through a string in search for a nullbyte. this means that the security vs muh performance becomes a false dilemma. 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.

But let's be honest here: I think the one big problem with C and strings is that it doesn't offer dynamic allocation. I think C works just fine with fixed-length/pre-allocated strings. When you need dynamic strings, you have to at least write a wrapper for a dynamic string struct -- but even then some of the C string functions will come in pretty handy.

no disagreement here

>>54
I'm really not following when you say C doesn't offer dynamic allocation with respect to strings. Any chance you can elaborate?

>>57
he probably means that there's no built-in dynamic data type for string data like in higher level languages (even C++), you need to handle reallocations yourself

Why do people build skyscrapers with cement and cranes instead of just using hammers and wood?

>>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.

The ``string system for C'' that exists is not less safe than the one in ``modern'' languages such as java.

>>60

building them with hammers and wood costs only about 1/6th

The opposite is true. It costs at least 6x more programmer hours to build some software in C than it does in FIOC or Lisp for example. 1 programmer hour = $20-$100. If you have numerous programmers, you can buy a new i7 every 15 minutes or so.

still have 80% stability compared to the ones built with cement

More like 20% the stability. Even Linus writes buffer overflows and mem leaks, so what hope do you have?

>>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

>>60,63
A much better solution than either length-prefixed or null-terminated strings has been around for a long time.
https://en.wikipedia.org/wiki/Data_descriptor

If people used x86 segmentation properly or some other segmented or object-based architecture had caught on, this is how we would do strings.

>>64
Yes, it's unfortunate that VMS has mostly died out. Enjoy your loonix.

CHECKEMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMm

>>64
Segmentation gives automatic array bounds checking, unfortunately it needs assembly fiddling and OS support, so it is out of reach for majority of apps.

C programmers need to wait O(n) time to get the length of their string, and then they turn around and lecture people about efficiency!
It seems like people here who use C and assembler (I'm talking about the people in this thread, not real programmers like kernel devs and demoscene members) only do so to reimplement basic software from 20-30 years ago and act infinitely smug about it. Look at the suckless people, or Cudder and that web browser.
To the C lovers: can you show us an example of something you wrote that isn't a rehash of crust UNIX shit or a 1990s web browser?

>>68
No

>>68

C programmers need to wait O(n) time to get the length of their string

No, C programmers have the choice of storing the length in a separate structure in case they need it, or not storing and hence saving the 7 bytes. It's a win-win situation, something called "choice" that you don't get in the HLLs.

>>70
Choice is the worst thing to give programmers. This is how ENTERPRISE was spawned.

The entire point of higher level is not having to care about implementation. Being able to use a tuple without having to know whether it's an array, a linked list, a struct or whatever the fuck. Sometimes the actual computing done by the program is so little you won't really notice the difference, or the heavy-load part is implemented in a different language.

>>71
Isn't the whole point of to inhibit a programmers choice based on choices made by incompetent bosses?

>>64

A much better solution than either length-prefixed or null-terminated strings has been around for a long time.

So, is it 10 or 19 sizeof(pointer) overhead per array? Either way, no wonder multics was stillborn.

Golang is a nice high level language

>>75
look, the goy fell for the Golang ruse!

>>76
Golang is a nice high level language

>>77
Goylang is a shitty high level language
(nice dubs btw)

>>77
Golang lacks generics, or anything similar (like sepples templates which are actually super powerful). Golang is shit. It also has GC. GC is shit. Rust is the future.

>>79
There is a preprocessor hack to bring templates to Golang, but it sucks. The whole Golang sucks because of their retarded fucking cat-v retro philosophy, the ``UNIX way''. They glorify the crippled nature of old school programming for no apparent reason other than hipster fanboyism. This is why they left out generics, because C doesn't have it and it's ``not simple''. Well no shit it's not simple, but we're not mental midgets here. The designers made the fatal mistake of assuming simplicity of implementation guarantees simplicity of usability. Golang intentionally makes you do things the hard and verbose way while simultaneously claiming to be simple and elegant, case in point:
if err != nil {
log.Fatal(err)
}
This line is repeated ad nauseum in Go codebases just because Go designers were too pretentious to implement error handling which literally every other post-2000 programming language has built in.

Go is stuck in a dead purgatory between the Python/Ruby/Perl space and systems programming (C, C++, Fortran, maybe Rust), where it is only tangentially applicable for each but totally applicable for neither.