5 ms·
If it had native support for JSON and supported GO like co-routines then a lot of its utility would be applicable to other scenarios that use fancy languages. T
by sys_64738 7y ago
If it had native support for JSON and supported GO like co-routines then a lot of its utility would be applicable to other scenarios that use fancy languages. This is what I always find surprising, C’ syntax is robust so add these missing gaps to the current language and weall win.
- CDSlice 7y agoIsn't that basically Go's whole thing? It has syntax that is really close to C, Go style co-routines (obviously), and I believe it has good JSON support. You do have to use a GC and you lose some of the really low level bits but I would wager most C programs don't need to have no GC and be able to do the really low level stuff. The ones that do probably don't need the goroutines and JSON and stuff.
- SlowRobotAhead 7y agoI have an embedded project with an RTOS for things you would do with coroutines, CBOR and JSON handling. I would not appreciate a garbage collector when it came time to debug a dumb pointer or overflow error. Doing it in C obviously. I can’t really consider Go embedded because I’m maxing the chip out now in C without including a Go VM or whatever you call it. This isn’t all as rare as you might think.
- petee 7y agoThey're not standard, but have you checked out libmill.org or libdill?
- krapp 7y ago>C’ syntax is robust so add these missing gaps to the current language and weall win. If every feature everyone wanted was added to C, it would just turn into a bloated mess like C++, or like PHP, with tons of bad decisions baked into the language that can't really be avoided. Features like this belong in libraries - the stdlib should remain as minimalistic as possible.
- saalweachter 7y agoIf everything everyone wanted was added to C, it would be C++. :-) The C++ evolution is essentially an iterative cycle where people hackily create new language features with insane preprocessor and template hackery, and then the Standards Committee comes in and takes the most popular hacks and tries to turn them into real language features. And then people create new hacks on top of that. C says, you want object oriented polymorphism, you've got structs and function pointers, what more do you need?
- krapp 7y ago>C says, you want object oriented polymorphism, you've got structs and function pointers, what more do you need? No, C says your first mistake was wanting object oriented polymorphism. Your second mistake will be implementing it.
- saagarjha 7y agoMost large C projects end up succumbing to something like this at some point.
- cardiffspaceman 7y agoI participated in the coding of several arcade games in Z80 assembler in the late 80s. Not "a" large project but a collection of small ones. These programs, by the time I came aboard and started sharing code with those to make the games I was involved in, had also "succumbed" to this force. The shared bedrock of all these games was code that used certain Z80 registers as pointers to take advantage of instructions that read or wrote fixed offsets from those pointers. The first byte of the record pointed at by the pointer was the type and the next 4 bytes were the position. The rest of the record depended on the type. That was us doing the best we could with 8-bit processors when our competition was using 68000.
- Mikhail_Edoshin 7y agoMany C projects indeed have polymorphism (I believe io libraries do exactly that to implement the idea that "everything is a file"), but this is rather different from object-oriented polymorphism.