How do we fix C? Is there already a better alternative for low-level, mission critical programs? A lot of people here have gone around professing that it needs to be replaced - so let's discuss this. This isn't a thread about C++ but if you want to make an argument that C++ is a replacement for C across all platforms then go ahead, but I get the feeling that C++ isn't what most people here think of when discussing a replacement for C.
Personally I think C is great.
Honestly, I have no background in programming. I learned python 8 months ago for fun, made some scrapers, did some plotting, fucked around with some ML models. I just bought K&R and C seems right up my alley. I'm really new, just getting into pointers and arrays, looking into copying some sorting algorithms out just to practice my chops. Also going to actually get around to doing the K&R exercises at some point. Really enjoying the language though, much more of a joy to write than python. I would be interested to see how fat I could take this. What kinds of things do you C people work on? What kinds of things do you do to learn/ practice the basics?
Whatever direction you guys decide to go I volunteer to make the logo
C is a systems programming language that got used for userspace programs by mistake. The Unix operating system was never planned by AT&T, it was personal project by Ken Thompson that got supported once it became usable. Because the OS was made by systems programmers for systems programmers it has an unusual direct interface to the kernel using C. Unfortunately this got copied by every other major OS and now libc are the standard OS interface. Before C existed there were operating systems programmed in Fortran and PL/I that functioned perfectly well. C simply does not belong in userspace programs. The fact that operating systems on personal computers of the 80s and early 90s were so primitive it required the use of a systems language that could directly interface with hardware. Lack of viable alternatives to C in the 90s was another factor in its overuse.
1. C doesn't need fixing.
2.
>Is there already a better alternative for low-level, mission critical programs?
Yes, it's called SparkAda.
There hasn't been a single major project started this decade that uses C. It's a dead language relegated to boomers maintaining legacy code. The COBOL of the 80s.
Embedded Java
>und to doing the K&R exercises at some point. Really enjoying the language though, much more of a joy to write than python. I would be interested to see how fat I could take this. What kinds of things do you C people work on? What kinds of things do you do to learn/ practice the basics?
embedded DSP code
kernel modules/drivers
low-level interfaces like UART communication protocols
HPC software (mostly to wrap around things like CUDA)
at least, that's what I typically use it for
Type-bound procedures would be nice to keep namespaces clean and improve readability in some cases. My main complaint with C is this
void draw(int x, int y, int z, int color) { ... }
when I would rather do
void draw(int x, y, z, color) { ... }
It already is valid syntax for storage class declarations, but for some reason it's kept out of function decl/def.
All the software for the curiosity rover is in C/C++.
I know it's mostly C++ but the C is there for the embedded power systems and stuff.
Also, think of a sawstop. Recent technology. Saves your fingers. C runs on those systems too, as well as many other small usually power-related embedded systems, usually mechatronic.
Define major. Maybe not open source, but there are plenty of companies starting new projects internally for some obscure custom chipset or architecture and C is the go-to language for the software riding on top of these systems. Especially in IoT.
OpenWRT/LEDE
I once wrote a small roguelike in C. Creating complex data structures and the functions to work with them is a completely different experience with C/C++. There's really no limit to how ridiculous you can get, so you feel kind of like a mad scientist creating horrendous monsters. And like a mad scientist, you will likely find yourself defending your creation from angry people with torches.
Actually int is the default type
void draw(x, y, z, color)
is the same as
void draw(int x, int y, int z, int color)
I meant to reply to
I never knew that, thanks. I think the old style still works, too.
int main(argc, argv)
int argc;
char **argv;
{
...
}
What does spark do what standard Ada doesn't?
It is so sparse and simple that the runtime requirements for it are incredibly the basic. Heap is a userspace abstraction, and "strings" are nothing more than what they are in their simplest form- arrays of characters. C is used for anything where determinism and performance are essential, because it allows you to program at an extremely granular level, short of programming in straight assembly. If you master C, you can get into any realm where precise timing and correctness are essential.
>strings in C are arrays of characters
>C is good for things requiring correctness
Are you consciously lying or are you just that brain damaged?
strings are arrays of chars in every language, they just hide it from you. try rereading his post, there's nothing contradictory there.
>Also, think of a sawstop.
>C is being used on tools now
That is the most terrifying thing I've ever heard in my entire life. It should actual be illegal .
>C is a systems programming language that got used for userspace programs by mistake
when C was invented there was no distinction
You can make complex data structures and functions in most languages. It really feels like cniles like you are time travelers from 1991.
>strings are arrays of chars in any language
And that's where you're wrong, kiddo. In C, arrays aren't really arrays because they don't store their length, and strings aren't really strings because they can't store any char. These bits of garbage design cause endless problems.
there's no requirement for an array to report its length, maybe if you started with python
an array with no length is a pointer
With a response like that, I see you've never actually used C. You need to know an array's length at all times for it to be useful. This becomes obvious the moment you pass it into a function and it decays into a pointer.
Also, I started with BASIC on a 6502, so get off my lawn.
>In C, arrays aren't really arrays because they don't store their length
i hope this is bait
>and strings aren't really strings because they can't store any char
yes, they actually can. if you want to use unicode you can use an array of wchar_t or use an array of unsigned char for utf-8.
for all the crying c strings cause, i've never had any problem using them. they're very simple data structures, if you can't handle arrays safely you probably shouldn't be programming.
Lol wut? C is the de facto choice for performance critical code. Those machine learning libraries you use, they use the latest BLAS spec implemented in C. Those games you play all built using an engine programmed in C.
>I hope this is bait
I hope you aren't retarded.
>yes you can
Oh really? Lemme just store a null character then, see what happens... It should work according to you, right?
Wayland
Mpv
Libsodium
Basically, you're retarded.
(you) got me to reply 6/10 bait
You do realize that c and python aren't the only languages that exist right? Languages that existed before C like fortan and Algol-64 had arrays that knew their size. C has no relationship to the underlying hardware. A modern Intel.or AMD CPU doesn't map in anyway to the computing model that C is based on. It sounds like you don't have the faintest idea how program languages are built or designed.
Forgot to mention Wireguard, which is huge as far as replacing legacy VPNs goes.
>You do realize that c and python aren't the only languages that exist
They're the only languages you need.
>A modern Intel or AMD CPU doesn't map in anyway to the computing model that C is based on
CPU's aren't supposed to map to languages, it's the other way around, but I'll just assume this was a typo.
>C doesn't map to moving values into registers and performing operations on them
If you say so.
It's not like any language you have in mind maps any better than C. If I want I can manually manage the cache on many modern architectures in C.
>Oh really? Lemme just store a null character then, see what happens... It should work according to you, right?
null is not a character, and even then double null terminators aren't that uncommon. or just quit crying about it and make your own type.
typedef struct {
size_t length;
uint8_t *data;
} crybabys_tampon_string;
that took me all of 5 seconds to type out.
And they're both pretty shit desu senpai.
>null is not a character
yes it is
>null is not a character
>just rewrite every library
Oh dear, the brain damage is terminal. Tell your family I'm sorry for their loss.
>>C doesn't map to moving values into registers and performing operations on them
>If you say so
I don't say so. People that have actual worked on the compiler "say so". Cniles like you are completely delusional.
queue.acm.org
C has no relationship to the hardware. C has no way of directly manipulating the memory of a modern processor. It isn't a low level language or a drop in replacement for assembly. Modern x86 assembly really couldn't be called a low level language anymore.
Null is a pointer constant and is implementation-defined.
>It's not like any language you have in mind maps any better than C
A functional language would probably map better to a modern processor than any c-style language does. None have seen any use outside of academia. C-- is an example of a language better designed for a modern processor.
it's ascii code 0, a character
REMOVE HEADERS
PROPER STRINGS
That's all it needs really.
>A functional language would probably map better to a modern processor than any c-style language does.
most retarded thing i've read all day, congrats
I tried fasm once and once I started importing functions from dlls and using function call macros I realized I was basically programming in C.
>C has no way of directly manipulating the memory of a modern processor
You can point to raw memory with some run time analysis of your virtual mem. An OS might stop you, but that has nothing to do with the language specification. You could slap together a RISCV many core and run C code on it to manipulate the NoC and cache interactions with the memory directly.
listen you absolute retard, null is a non-printing character. if you pass a null character to a print statement what gets printed? do you actually expect an actual fucking glyph to appear? at some point you have to wonder if maybe you're the problem and not the language, and that point is when you actually think any language in the world is going to magically print a non-existent glyph when your curry ass throws a bunch of zeros at it.
This is real brainlet thinking here. Functional would better on inherently stateful systems. By any chance do you read Medium or Verge?
I'm sorry you don't know anything about how modern processors work. C was designed for hardware that no longer exists.
many characters are non-printing characters, the first 32 ascii characters iirc
Oh my, this guy. I don't even hope you're just pretending anymore. Your retardation is too amusing.
>I'm sorry you don't know anything about how modern processors work
they manipulate memory and registers just like they did when C was concieved, functions are a user-made construct ontop of that that follow a bunch of rules that have nothing to do with how processors work
>You could slap together a RISCV many core and run C code on it to manipulate the NoC and cache interactions with the memory directly.
Or I could use any other language if I have control over the hardware you can implement anything you want to control it directly. Point is C has no way of doing so directly on x86 processor. Any other language with similar resources poured into it could replace it.
You can't deny their combined power:
int sum(int a, int b)
{
return a + b;
}
$ cc lib.c -shared -o lib.so
$ python3 -c 'from ctypes import *; print(CDLL("./lib.so").sum(4, 6))'
10
There’s nothing really to fix, C works and works well for what’s intended to be used for.
It requires time to learn well and master and that’s nothing inherently wrong with that.
The real problem are ‘modern’ programmers used to all sorts of shenanigans that want the compilers and tools to do everything for them.
That article claims billions of dollars have been spent developing the x86 architecture poorly just to avoid upsetting C programmers. Am I supposed to take this seriously?
>they manipulate memory and registers just like they did when C was concieved
No they absolutely do not perform the same way. A modern processor is an incredibly complicated cluster fuck. C doesn't even know what a cache is. C was designed for simple and elegant processors.
C can't be fixed it needs to replaced. It's an archaic memory unsafe language from the 70s that is responsible for almost every major security issue ever. Archaic shit like header files and manual memory management needs to be left in the past as well.
>C works well
We got another brainlet over here, folks! Gather round, gather round, to do the pointing and the laughing. No pointer arithmetic nonsense though, y'hear?
do any languages know what a cache is or is it just a black box on the CPU side?
Functional programs dont model CPUs at all
They try to avoid having state but in machine code manipulating state is all you do
really fast networking applications
>Archaic shit like header files and manual memory management
Enjoy your abysmal cache performance.
Well the guy that wrote it had a big hand in the process. He did a lot of work on clang. He's just telling you the truth. What you don't believe the scumbags at Intel and AMD wouldn't lie about this. They're the only ones with direct control of you hardware. It works out perfectly for them.
so what, have you ever had a good reason to put any of them into a string? if you're cramming non-printing characters into strings you should unironically quit programming. crying about null terminators is something brainlets do to look smart. i've written c for years and never had problems with c strings, only a retard can't handle simple arrays.
No language needs to know because hardware microarchitecure such as cache design are all handled by hardware! What a nonsense thing to say. Why would C naturally expose this to a programmer? It doesn't expose registers either, but you can manipulate them directly with asm. On some architectures you can even manipulate caches directly with special intrinsics. This doesn't invalidate C's memory model at all. The only issue caches introduce is maintaining consistency in multicores and manycores, but this is also something you have control over in C and that the hardware supports.
you dont need manual memory management for good cache performance so long as structure fields and arrays store their data contiguously
>so what, have you ever had a good reason to put any of them into a string?
yes
but that's not the worst thing about null terminated strings
the worst thing is getting the length of a string is an O(n) operation
still lmaoing at your idiocy
keep digging deeper pls
>do any languages know what a cache is or is it just a black box on the CPU side?
No that's the point. At the current point in time their is no low level language available for x86 or arm processors. x86 assembly also doesn't given you access to low level functions of the hardware. Intel and AMD CPUs are black boxes. No one has really come up with a new language that maps closely to an x86 processor. The author of the article said that functional programming matches up closer to CPUs then what we have now but it's beyond my understanding of why.
You probably stopped reading at the first half sentence.
Do you work with js by any chance?
If you're doing heavy string stuff, it's trivial to use or implement a string library, even one that maintains compatibility with standard library functions (via a header). Basically a non-argument.
>The author of the article said that functional programming matches up closer to CPUs then what we have now but it's beyond my understanding of why.
dont believe anyone without understanding why
CPUs dont execute functions, they do ifs, gotos, reads, writes and math operations
>yes
why though? i'm genuinely curious.
>the worst thing is getting the length of a string is an O(n) operation
i would really hope nobody is needing to get the length of strings often enough that it matters. that definitely sounds like a design problem more than a data structure problem.
saying C strings arent shit because you can use something better isnt an argument either
>Why would C naturally expose this to a programmer?
It use to expose all the functionality of the processors it was designed for that's what made it a drop in replacement for assembly. Instead you have to use a bunch of gay tricks to get performance out of the processors because you have zero ways of manipulating these things directly. You don't have total control over every aspect of memory like someone in this thread was implying early and you don't have direct control over how the hardware manipulates memory.
They're simple and performant, that doesn't make them shit.
>the processor doesn't expose an interface
>this is c's fault
stick to js
>why though? i'm genuinely curious.
I use them for file format headers because they're characters that are unlikely to be typed by the user
>i would really hope nobody is needing to get the length of strings often enough that it matters
if you check string equality between VeryLongVerboseString and VeryLongVerboseString2 then you can see what benefit knowing the sting length has
>if you dislike C you must be a webdev
You cniles are getting predictable. I use a nice, sane, well designed systems language and hate javascript about as much as I hate C.
A string that isn't null terminated is also simple and performant
I don't really think it's about executimg functions. It's more or less something about out of order execution not matching up well with imperative programming.
Exactly,
machine code is imperative. You can match the execution order of an imperative program 1 to 1 pretty much. That's why imperative code is good for performance and functional languages are slow
>You don't have total control over every aspect of memory like someone in this thread was implying early
You can but it depends on the architecture, some completely expose control signals for the cache, you can for example bypass the cache altogether or flush it on a timer. x86 isn't everything
And yet you contribute nothing while the best software ever written is written in C.
>when rust is so shit its most popular crypto library is written in %50 assembly because even unsafe rust is worthless
A non null terminated string is simpler and more performant than the C abomination. It's also an actual string, which is always a plus.
Just use python, javascript, or whatever language you're unhealthy attached too instead of incessantly whining about c like a spoiled baby.
Functional programming isn't any better for OoO
Generic type that holds any kind of data. That's all to avoid void* problems.
strcmp is insanely fast on x86 and doesn't require a length to be known. and why wouldn't you use a struct for file headers like literally every other file format?
>my language is best
>but i'm not telling what it is
>rust
Ewww, no, I don't touch that badly designed eyeraping garbage. I use Ada.
Yes the processor doesn't expose the interface so C isn't capable of actual manipulating memory on modern processor. Stop trying wiggle your way out of it by mentioning javascript. First it was python , now javascript. I don't like C like languages very much. Python and javascript aren't exceptions.
Made me chuckle, heh. Now what language do you really use?
>strcmp is insanely fast on x86
and comparing a string while knowing the length is even insanely faster, what's your point
> why wouldn't you use a struct for file headers
structs don't exist in files, files are just a long stream of data, a string if you will
another use for those characters is embedding instructions inside strings, like if you're printing some text and want to embed a change the color or switch to bold you can use an unprintable char to signal the beginning of an instruction
unions are criminally underused. void pointers aren't too bad if you keep them tucked away in structs with enum tags to allow safe dereferencing.