4 ms·

> They must have got something good though. Else why would there entire families of C-like languages ? Network effect. If you wanted to write for unix, you al

> They must have got something good though. Else why would there entire families of C-like languages ? 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...

jstimpfle 9y ago
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?
- kstrauser 9y ago
  > But realistically, you don't do that in C IMHO, that's a self-fulfilling prophecy. If it were reasonably easy to do that in C, it would be done more.
  - YSFEJ4SWJUVU6 9y ago
    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); } Nests as well if you ever wanted to: modfun get_modfun_no_mul(bool mul) { return plus2; } typedef modfun (*modfun_getter)(bool); modfun_getter get_getter(bool allow_mul_opt) { return (allow_mul_opt ? get_modfun : get_modfun_no_mul); }
  - jstimpfle 9y ago
    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.
    - jimktrains2 9y ago
      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.
      - jstimpfle 9y ago
        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).
        jimktrains2 9y ago
        > It's a fact that C doesn't have closures. OK. > That is my point. 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!
- steinuil 9y ago
  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 The declaration of List.map: val map : ('a -> 'b) -> 'a list -> 'b list

jstimpfle 9y ago

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?

kstrauser 9y ago
> But realistically, you don't do that in C IMHO, that's a self-fulfilling prophecy. If it were reasonably easy to do that in C, it would be done more.
- YSFEJ4SWJUVU6 9y ago
  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); } Nests as well if you ever wanted to: modfun get_modfun_no_mul(bool mul) { return plus2; } typedef modfun (*modfun_getter)(bool); modfun_getter get_getter(bool allow_mul_opt) { return (allow_mul_opt ? get_modfun : get_modfun_no_mul); }
- jstimpfle 9y ago
  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.
  - jimktrains2 9y ago
    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.
    - jstimpfle 9y ago
      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).
      - jimktrains2 9y ago
        > It's a fact that C doesn't have closures. OK. > That is my point. 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!
steinuil 9y ago
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 The declaration of List.map: val map : ('a -> 'b) -> 'a list -> 'b list