4 ms·

+1 C is ugly. - Why do I need to typedef a struct to make it look like any other type? - Why do function pointers look so bad? - Error handling in C? Those g

by codexon 16y ago

+1 C is ugly. - Why do I need to typedef a struct to make it look like any other type? - Why do function pointers look so bad? - Error handling in C? Those goto exception; if(0){exception:} sure look fantastic. - int* var1, var2; var2 is an int, not an int* ... The language lets you stick the * right next to the type as though it modifies the type. Which it does in casts. (how do I escape asterisks on here?) - A system language where int can be 32 bits or more. And probably more from people more experienced in C than me.

berntb 16y ago
Well, OK... C is ugly. That doesn't hinder that it is also beautiful. I did C for ten years, on and off. I stopped. C is an old love where the break up wasn't bad, it was just me that changed. I realised what I really liked -- to get shit done! That is, to take an idea or a specification and make it exist in the "real" world. That implies the importance of speed, so I can get to the next idea. C just isn't for maximising speed of development, unless for really low level stuff. Sometimes, I mourn a bit for what could have been.
ComputerGuru 16y ago
- You don't. C99 treats structs like classes. - Typedef them. - If done right, it can be quite unobtrusive. - That's not how it should be written. This is a 100 times clearer: int *var1, var2; - Not really. And don't use int, int32_t is where it's at.
- sid0 16y ago
  int *var1, var2; is not clear at all. var1 has type "int pointer", and for each type T, its pointer type is represented as the type T*. It's just one of the many ways the C user interface is broken beyond reason. The point is not that you can't do good things in C. The point is that it is very easy to do bad things in C. A good UI makes good things the natural way to do things, and actively discourages bad things. C's UI is the opposite.
  - geoka9 16y ago
    It's just one of the many ways the C user interface is broken beyond reason. I'd say this one is just a question of preference. I happen to like to be able to declare my variables together with my ponters. A good UI makes good things the natural way to do things, and actively discourages bad things. C's UI is the opposite. In my opinion, that's the beauty of C: unlike Java (and, to a little extent, C++) it doesn't dictate how you write your programs. You are free to shoot yourself in the foot, but you also get to decide exactly how you want your code to look and feel.
    - sid0 16y ago
      The small cost of not being able to declare your variables together with your pointers is nothing compared to the confusion it avoids. int* var1; is the way I (and I suspect anyone who's studied theoretical algebraic data types) think about my variables and types. It sucks that C forces me to mentally translate it to a much less satisfying form. I'm not sure what being ridiculously easy to make errors in has to do with dictating how to write your programs.
- JackdawX 16y ago
  "- That's not how it should be written. This is a 100 times clearer: int var1, var2;" Somewhat aside from the actual article, but this might actually be the least clear way to write a definition, since the pointer marker appears to belong to var1, but not the overall definition of int. Here is how I would automatically read the definitions: "int var1, var2;" Of type int (variable), create var1, var2. "int var1, var2;" Of type int and type * (pointer), create var1, var2. "int var1, var2;" Of type int, create pointer var1, pointer var2. "int *var1, var2;" Of type int, create pointer var1, default (variable) var2. Not sure how this works for and against C, since the language definition is really old at this point and by the standards of its time C is really clear. But languages have moved on and a standard has emerged over the intervening time that is a bit more logical. Also, I think this article is a real piece of fluff :).
kragen 16y ago
C's designers agree with you about the notation for types and declarations, which was one of the things they fixed when they designed Go.

by codexon 16y ago

berntb 16y ago

Well, OK... C is ugly. That doesn't hinder that it is also beautiful. I did C for ten years, on and off. I stopped. C is an old love where the break up wasn't bad, it was just me that changed. I realised what I really liked -- to get shit done! That is, to take an idea or a specification and make it exist in the "real" world. That implies the importance of speed, so I can get to the next idea. C just isn't for maximising speed of development, unless for really low level stuff. Sometimes, I mourn a bit for what could have been.

ComputerGuru 16y ago

- You don't. C99 treats structs like classes. - Typedef them. - If done right, it can be quite unobtrusive. - That's not how it should be written. This is a 100 times clearer: int *var1, var2; - Not really. And don't use int, int32_t is where it's at.

sid0 16y ago
int *var1, var2; is not clear at all. var1 has type "int pointer", and for each type T, its pointer type is represented as the type T*. It's just one of the many ways the C user interface is broken beyond reason. The point is not that you can't do good things in C. The point is that it is very easy to do bad things in C. A good UI makes good things the natural way to do things, and actively discourages bad things. C's UI is the opposite.
- geoka9 16y ago
  It's just one of the many ways the C user interface is broken beyond reason. I'd say this one is just a question of preference. I happen to like to be able to declare my variables together with my ponters. A good UI makes good things the natural way to do things, and actively discourages bad things. C's UI is the opposite. In my opinion, that's the beauty of C: unlike Java (and, to a little extent, C++) it doesn't dictate how you write your programs. You are free to shoot yourself in the foot, but you also get to decide exactly how you want your code to look and feel.
  - sid0 16y ago
    The small cost of not being able to declare your variables together with your pointers is nothing compared to the confusion it avoids. int* var1; is the way I (and I suspect anyone who's studied theoretical algebraic data types) think about my variables and types. It sucks that C forces me to mentally translate it to a much less satisfying form. I'm not sure what being ridiculously easy to make errors in has to do with dictating how to write your programs.
JackdawX 16y ago
"- That's not how it should be written. This is a 100 times clearer: int var1, var2;" Somewhat aside from the actual article, but this might actually be the least clear way to write a definition, since the pointer marker appears to belong to var1, but not the overall definition of int. Here is how I would automatically read the definitions: "int var1, var2;" Of type int (variable), create var1, var2. "int var1, var2;" Of type int and type * (pointer), create var1, var2. "int var1, var2;" Of type int, create pointer var1, pointer var2. "int *var1, var2;" Of type int, create pointer var1, default (variable) var2. Not sure how this works for and against C, since the language definition is really old at this point and by the standards of its time C is really clear. But languages have moved on and a standard has emerged over the intervening time that is a bit more logical. Also, I think this article is a real piece of fluff :).

kragen 16y ago

C's designers agree with you about the notation for types and declarations, which was one of the things they fixed when they designed Go.