Everybody I know found it confusing at first, but its logical, and modular. I don't know a language with a better type declaration syntax. It gets impractical when you define function that return functions that return... because these expression grow on the left and right simultaneously. But realistically, you don't do that in C, and other than that, I find it easy to read the type of any expression...
const int *x[5];
*x[3]; // const int
x[3]; // const int *
x; // ok - there is first a decay of x[5] to *x, so: const int **
Is there any other syntax that has this modularity?
It is quite reasonably easy enough compared to any real practical programming task. For example:
// your ordinary function declarations
int plus2(int i) { return i + 2; }
int times2(int i) { return i * 2; }
typedef int (*modfun)(int);
// a very reasonable syntax altogether
modfun get_modfun(bool mul) { return (mul ? times2 : plus2); }
C is a systems programming language. It doesn't have closures or other features from functional programming. In other words, you can't "create functions at runtime". That is why you basically never see a function returning another function.
So, go is also a "systems" language, so the terms more or less meaningless now. Assuming you mean a language we can easily compile to an independent binary capable of being run directly on a microprocessor with no support, I offer you rust as a counter-example.
Also, functional programming and returning functions does not mean they are created at runtime.
It's a fact that C doesn't have closures. That is my point. I happen to like that fact, but you don't have to agree with me.
And "creating functions" means: closing over variables ("closures"), or partial application. I think it takes at least that to be able to return interesting functions.
(and whether go is a systems programming language is at least debatable. I think the creators have distanced themselves from that. It depends on your definition of "systems". You can't really write an OS in go).
Not unless your first two sentences have absolutely nothing to do with each other. Your point appears to be that because it's a low-level language it doesn't have these features, which is false.
> I happen to like that fact, but you don't have to agree with me.
Or I just think you don't have any experince using better languages. That isn't to say that other language could supplant C, but just that it's difficult for me to image actually liking the C type system (or lack thereof) and lack of first class functions. It's incredibly limiting and requires a lot of hoops to be jumped through to do anything interesting.
> And "creating functions" means: closing over variables ("closures"), or partial application.
Well, you said at runtime. Of course you can "create" functions at compile or programming time!
> Your point appears to be that because it's a low-level language it doesn't have these features, which is false.
I would think that first class closures do indeed _not_ belong in a low-level language. They hide complexity, and you want to avoid that in low-level programming. Not necessarily for performance reasons, but more from a standpoint of clarity (which in turn can critically affect performance, but in subtler ways).
> Or I just think you don't have any experince using better languages.
Nah, I have experience in many other languages, including Python, C++11, Java, Haskell, Javascript, Postscript. The self-containment, control, robustness and clarity I get from a cleanly designed C architecture is just a lot more appealing to me. The only other language I can stand is Python, but for complex things, it becomes actually more work. For example, because it's so goddamn hard to just copy data as values in most languages (thanks to crazy object graphs).
> It's incredibly limiting and requires a lot of hoops to be jumped through to do anything interesting.
It depends on what you are doing. It's a bad match for domains where you have to fight with short-lived objects and do a lot of uncontrolled allocations and string conversions. My experience in other domains (including some types of enterprise software) is more the opposite, though. Most software projects written in more advanced languages are so damn complicated, but do nothing impressive at all. They are mostly busy fighting the complexity that comes from using the many features of the language. But those features help only a bit (in the small), and when you scale up they come back and bite you!
> Well, you said at runtime. Of course you can "create" functions at compile or programming time!
Closures and partial application are done at runtime. The values bound are dynamic. So in that sense, the functions are indeed created at runtime. I sense that you were of the impression that a closure would actually have the argument "baked" in at compile time (resulting in a different code, at a low level) instead of the argument being applied at runtime. That's not the case, unless optimizations are possible. If that was really your impression, this makes my point regarding avoiding complexity and that closures do not belong in a low-level language. (Look up closure conversion / lambda lifting)
I'm really not sure what you mean by "modularity". There's a lot of languages with much more readable and composable type declarations than C. For example in OCaml:
let x : (int list ref, string) result option =
let x1 : int = 0 in
let x2 : int list = [ x1 ] in
let x3 : int list ref = ref x2 in
let x4 : (int list ref, string) result = Ok x3 in
Some x4
Network effect. If you wanted to write for unix, you almost had to use C originally.
> Plus, to me C syntax is particularly good.
It's meh. It's not the most straightforward when defining complex types like arrays or function pointers.
> You're writing real words and the computers does the things you tell it to. To the letter.
So yeah, about that...