9 ms·

C is better because it doesn't try to program for you, it isn't clever, convenient, or have any ideas about how you structure or solve a particular problem. It

C is better because it doesn't try to program for you, it isn't clever, convenient, or have any ideas about how you structure or solve a particular problem. It gives you basic functionality and then gets out of your hair and lets you ge on with programming without making a grand statement about computer science. For people who actually like to program and don't want the language to do it for you that is pretty attractive. It also turns out that if you remove all the fancy abstraction and write everything out, the code becomes very maintainable and easy to manage. The fact that its about as portable as a program can be helps. I find that most people don't want to write C, but almost everyone is pretty happy interacting with C code written by others, because its simple, fast, portable, easy to integrate, and bind to other languages, and most non-C programmers can read it and have a rough idea of what is going on.

jjnoakes 3y ago
> C is better because it doesn't try to program for you, it isn't clever, convenient, or have any ideas about how you structure or solve a particular problem Why is that better though? I personally appreciate it when cleverness and convenience make my life easier, my programs less buggy and less likely to end up in a CVE, or point me toward better structure. > It also turns out that if you remove all the fancy abstraction and write everything out, the code becomes very maintainable and easy to manage History shows that this isn't true though, not in all cases.
- quelsolaar 3y ago
  > Why is that better though? Some people think so. Hence some where meant for C. > History shows that this isn't true though, not in all cases Not in all cases? I had no idea it was possible to write bad code in C, I must immediately switch to language where all code is always perfect no matter what the programmer does. History does show that most of the largest, longest running, most depended on open source projects like Linux, Apache, Git, MySQL, CPyton, OpenSSL, Gcc, Curl are written in C, so its hard to argue that the language isn't maintainable.
  - PartiallyTyped 3y ago
    The oxidizing of the Linux kernel has already begun, many of the core-tools have been rewritten in rust, large segments of firefox are written in rust, chromium is getting oxidized [1]. I don't think this is a sound argument because of survivorship bias. [1] https://security.googleblog.com/2023/01/supporting-use-of-rust-in-chromium.html https://security.googleblog.com/2023/01/supporting-use-of-ru...
    - placesalt 3y ago
      >> History does show that most of the largest, longest running, most depended on open source projects like Linux, Apache, Git, MySQL, CPyton, OpenSSL, Gcc, Curl are written in C, so its hard to argue that the language isn't maintainable. > I don't think this is a sound argument because of survivorship bias. The argument is that those projects prove large C programs/systems are maintainable. 'Survivorship bias' doesn't enter into it; they are large and have been well maintained. Edit: I remember a time when "correlation is not causation" was the endlessly-repeated phrase. La plus ca change, la plus c'est la meme.
      - PartiallyTyped 3y ago
        > The argument is that those projects prove large C programs/systems are maintainable. 'Survivorship bias' doesn't enter into it; they are large and have been well maintained. It shows that large C programs / systems can be maintainable. My claim is that the projects became maintainable out of necessity, that is, despite C, not because of C. Had C been opinioned around certain things and enforced maintainability out of the box to some degree, then and only then you could claim that C is maintainable, because this speaks for the general case. On the other hand, C is not opinionated about things, so you must enforce maintainability and high standards to get around all the footguns. This is what makes it unwieldy and why Rust is so loved. This plays greatly into the survivorship bias. You claim that C is maintainable because of all the large C projects that were forced to become maintainable. Had they not been maintainable they would not be as large or survive the test of time, and thus you wouldn't be able to cite them as evidence to your claim. In contrast, the oxidification of a lot of software, and the rise of "better C"s that have picked up steam shows that there are languages that are more maintainable and arguably better approaches for most software as they avoid all the footguns. NASA has strict requirements to make it maintainable, e.g. no heap alloc, so when you force yourself to not use language features, it appears that those features make things worse for you. Edit: Anyone care to inform me how my response falls into "low standards" for HN, and so much so that I got flagged and can not comment ?
- coldtea 3y ago
  >Why is that better though? Doesn't have to be better, preferable is enough. Plus, it is more flexible...
  - jjnoakes 3y ago
    I agree it is more flexible and might be more preferable to some, but it is also more dangerous, and I believe it is harder to maintain as well. Since the comment I replied to specifically said "better", that's what I directed my reply at.
steveklabnik 3y ago
I do think you’ve identified a significant rift between those that prefer C and those who do not. I think you’re being downvoted for the value judgement you’re injecting, though. > gets out of your hair and lets you ge on with programming This is the divergence, I think. For me, the method in which c “gets out of my hair” means that more burden is placed on me, the developer. Which means I have to work more slowly, cautiously, and remember things that a good type system could have been checking for me. And the lack of features means I spend time working around that lack rather than getting real work done. I suspect these preferences are irreconcilable.
- quelsolaar 3y ago
  > I do think you’ve identified a significant rift between those that prefer C and those who do not. I agree. I think the article is very right in identifying that C developers look at programming differently. I think that is a good thing. Even as a Die-Hard C programmer, I celebrate that people use other languages and especially that people are developing new languages like Rust, Odin, Zig and so on. I don't think it wrong for someone to reject C, if its not right for them. Do what works for you. I do think that given Cs massive success, people should perhaps be a bit more interested to figure out why, instead of just dismissing it so fast.
  - comfypotato 3y ago
    Your comments on this thread up to this point sound like a religious fanatic. I greatly enjoyed reading. Goes to show why it’s called “The C Religion”.
    - quelsolaar 3y ago
      I think, most designers of languages want abstractions, convenience, and clevernes. So for people who don't want that we have to cling on to C since there aren't other options ;-)
      - rewmie 3y ago
PartiallyTyped 3y ago
> It also turns out that if you remove all the fancy abstraction and write everything out, the code becomes very maintainable and easy to manage. I was with you on everything until this part. I just don't see how reducing soundness via a weaker type system, and needing to explicitly manage memory vs e.g. Rust, uniq_ptr, shared_ptr, and so on makes things easier to maintain. I also don't see how absence of generics helps here either.
- westoque 3y ago
  this. properly made abstractions are actually more maintainable and easier to manage. for ex, take anybody learning programming about writing to a file, if you write your code using ruby, it would be a lot safer and maintainable than the C counterpart even though the latter is more powerful.
  - rudedogg 3y ago
    Abstractions hide details, and you'll likely need to interact with something the abstraction hides eventually. So then you end up doing one of two things: 1. Learning every detail of the abstraction and the thing it's abstracting, fighting it until you persevere and get it to do what you want 2. Write something from scratch that does exactly what you need Going the #2 route from the start isn't such a bad idea, and has a lot of advantages IMO. The hard thing about all this is that abstractions are beautiful at first. It's not until you're far into a project, or doing something unusual that it all falls apart.
    - Conscat 3y ago
      Uh oh I wrote C code and just multiplied meters by yards and now the program exploded help
    - gpderetta 3y ago
      C has plenty of abstactions. Are you saying that the set of abstractions provided by C are optimal or nearly so?
bitwize 3y ago
I think it's high time to bury the myth of the "bondage and discipline language". Study after study has shown that, comparing development of the same application in C vs. a language with a very strong type system such as Ada, the application in the language with the very strong type system costs less to develop and has far fewer errors. The fact that C "gets out of your hair", i.e., doesn't provide checking for certain kinds of correctness, is an anti-feature.
jcranmer 3y ago
> C is better because it doesn't try to program for you, it isn't clever, convenient, or have any ideas about how you structure or solve a particular problem. Oh, C very much does have ideas. One of the big problems I have with C is that it has a surprisingly limited feature set that makes it difficult or impossible to express certain programming styles. Want to describe a function that returns multiple values? Well, you can't really do that (especially if you want this to mean "use two registers"). How about using unwind to express exceptional control flow? Can't do that either. Or if you want a function with multiple entry points? Or coroutines? C's fundamental inability to express certain kinds of control flow [1] greatly limit your ability to structure your code in ways that might make the code clearer. > It also turns out that if you remove all the fancy abstraction and write everything out, the code becomes very maintainable and easy to manage. I think experience has shown that this is not the case. The closest kernel of truth you might find is that if writing code requires a certain amount of tedium, that tends to limit the scale you can grow a codebase to, and size is one of the largest drivers of complexity. While it's definitely the case that abstraction can decrease maintainability, it is a mistake to think that it necessarily does so. Indeed, abstraction is often necessary to make code more maintainable. For example, when I design APIs, I think very hard about how to design it in such a way that it's impossible to misuse the API. So I make my APIs distinguish between UTF-8 strings and Latin-1 strings, so you can't be confused as to what's in them, or even distinguish between a row number and a column number. The other thing to bring up is that we know quite well that humans are pretty bad at doing tedious, repetitive tasks with high accuracy. And computers are pretty good at that! What this suggests is that languages should be designed so that things that are tedious and repetitive--such as propagating errors up a stack, or cleaning up resources on failure--can be done by the compiler and not the programmer. As we've seen with things like gotofail, C is a language which lacks features that enable work to be pushed onto the compiler and not the programmer, and code written in C suffers as a result of that. [1] And there's even more exotic kinds that I could get into--this is merely the list of features available in languages you've probably heard of, maybe even used!
- kps 3y ago
  >Or if you want a function with multiple entry points? `entry` was a reserved word in K&R, but not implemented.
em-bee 3y ago
i haven't come across a single language that would limit me in how i structure my code. that is, i didn't feel limited. whether it was python, ruby, smalltalk or even lisp. heck, once i translated a program from pike to common lisp. the structure of both programs was identical despite everyone claiming that lisp is so much different. it can be, but it doesn't force you to be. most non-C programmers can read it and have a rough idea of what is going on that's because most programmers can read most other languages and have an idea what's going on. that's not at all a special feature of C.
- pornel 3y ago
  > i haven't come across a single language that would limit me in how i structure my code Rust is one of the languages that limits how the code and data can be structured. Often it's either the Rust way, or it's going to be awkward or not even compile (e.g. it doesn't like doubly-linked lists, structs containing a references to their own data, mutable getters, and a few other common patterns). This is often very off-putting to people coming from C who want to do things their way, and end up fighting with the compiler over every line of code.
  - em-bee 3y ago
    i haven't had an opportunity yet to work with rust. it is something i want to try. i actually like the idea of being constrained and forced to find different ways to solve a problem because i think i can learn something from that. i guess that haskell should be equally challenging. i actually expected that challenge from lisp too, but i was rather disappointed to discover that this wasn't the case and lisp isn't really that much different, neither was smalltalk. it's a nice language, but message-passing doesn't feel any different from method/function calling, so it's not really a different paradigm that affects the structure of your code.
    - kazinator 3y ago
      In Lisp, you can just use what you know and not challenge yourself; you're not constrained or forced. Any such challenge has to be self-imposed. You can learn enough to be able to work in it, and then just use it like Fortran.
JohnFen 3y ago
> C is better because it doesn't try to program for you, it isn't clever, convenient, or have any ideas about how you structure or solve a particular problem. This is much of why I prefer to use C (well, I actually prefer to use C++-as-a-better-C, but since I'll omit almost all of of what C++ brings, it's still C for all intents and purposes). Other reasons I prefer C include producing small executables (and, more importantly, being able to effectively control executable size), that it is the most portable language (in the sense that there are C compilers for just about every computer platform in existence), and it is both readable and concise.
fulafel 3y ago
Avoiding the UB footguns does steer you pretty hard if you try to write secure & portable C. For example keep away from signed integers and dynamic memory & pointer arithmetic.
rramadass 3y ago
> It also turns out that if you remove all the fancy abstraction and write everything out, the code becomes very maintainable and easy to manage. This is key to the success of C (also the main reason stated by Linus Torvalds for his choice of the language). You can write really complicated code which may take time to unravel/comprehend but nothing is really done behind your back nor hidden (please let's not start with UB :-).

jjnoakes 3y ago

> C is better because it doesn't try to program for you, it isn't clever, convenient, or have any ideas about how you structure or solve a particular problem Why is that better though? I personally appreciate it when cleverness and convenience make my life easier, my programs less buggy and less likely to end up in a CVE, or point me toward better structure. > It also turns out that if you remove all the fancy abstraction and write everything out, the code becomes very maintainable and easy to manage History shows that this isn't true though, not in all cases.

quelsolaar 3y ago
> Why is that better though? Some people think so. Hence some where meant for C. > History shows that this isn't true though, not in all cases Not in all cases? I had no idea it was possible to write bad code in C, I must immediately switch to language where all code is always perfect no matter what the programmer does. History does show that most of the largest, longest running, most depended on open source projects like Linux, Apache, Git, MySQL, CPyton, OpenSSL, Gcc, Curl are written in C, so its hard to argue that the language isn't maintainable.
- PartiallyTyped 3y ago
  The oxidizing of the Linux kernel has already begun, many of the core-tools have been rewritten in rust, large segments of firefox are written in rust, chromium is getting oxidized [1]. I don't think this is a sound argument because of survivorship bias. [1] https://security.googleblog.com/2023/01/supporting-use-of-rust-in-chromium.html https://security.googleblog.com/2023/01/supporting-use-of-ru...
  - placesalt 3y ago
    >> History does show that most of the largest, longest running, most depended on open source projects like Linux, Apache, Git, MySQL, CPyton, OpenSSL, Gcc, Curl are written in C, so its hard to argue that the language isn't maintainable. > I don't think this is a sound argument because of survivorship bias. The argument is that those projects prove large C programs/systems are maintainable. 'Survivorship bias' doesn't enter into it; they are large and have been well maintained. Edit: I remember a time when "correlation is not causation" was the endlessly-repeated phrase. La plus ca change, la plus c'est la meme.
    - PartiallyTyped 3y ago
      > The argument is that those projects prove large C programs/systems are maintainable. 'Survivorship bias' doesn't enter into it; they are large and have been well maintained. It shows that large C programs / systems can be maintainable. My claim is that the projects became maintainable out of necessity, that is, despite C, not because of C. Had C been opinioned around certain things and enforced maintainability out of the box to some degree, then and only then you could claim that C is maintainable, because this speaks for the general case. On the other hand, C is not opinionated about things, so you must enforce maintainability and high standards to get around all the footguns. This is what makes it unwieldy and why Rust is so loved. This plays greatly into the survivorship bias. You claim that C is maintainable because of all the large C projects that were forced to become maintainable. Had they not been maintainable they would not be as large or survive the test of time, and thus you wouldn't be able to cite them as evidence to your claim. In contrast, the oxidification of a lot of software, and the rise of "better C"s that have picked up steam shows that there are languages that are more maintainable and arguably better approaches for most software as they avoid all the footguns. NASA has strict requirements to make it maintainable, e.g. no heap alloc, so when you force yourself to not use language features, it appears that those features make things worse for you. Edit: Anyone care to inform me how my response falls into "low standards" for HN, and so much so that I got flagged and can not comment ?
coldtea 3y ago
>Why is that better though? Doesn't have to be better, preferable is enough. Plus, it is more flexible...
- jjnoakes 3y ago
  I agree it is more flexible and might be more preferable to some, but it is also more dangerous, and I believe it is harder to maintain as well. Since the comment I replied to specifically said "better", that's what I directed my reply at.

steveklabnik 3y ago

I do think you’ve identified a significant rift between those that prefer C and those who do not. I think you’re being downvoted for the value judgement you’re injecting, though. > gets out of your hair and lets you ge on with programming This is the divergence, I think. For me, the method in which c “gets out of my hair” means that more burden is placed on me, the developer. Which means I have to work more slowly, cautiously, and remember things that a good type system could have been checking for me. And the lack of features means I spend time working around that lack rather than getting real work done. I suspect these preferences are irreconcilable.

quelsolaar 3y ago
> I do think you’ve identified a significant rift between those that prefer C and those who do not. I agree. I think the article is very right in identifying that C developers look at programming differently. I think that is a good thing. Even as a Die-Hard C programmer, I celebrate that people use other languages and especially that people are developing new languages like Rust, Odin, Zig and so on. I don't think it wrong for someone to reject C, if its not right for them. Do what works for you. I do think that given Cs massive success, people should perhaps be a bit more interested to figure out why, instead of just dismissing it so fast.
- comfypotato 3y ago
  Your comments on this thread up to this point sound like a religious fanatic. I greatly enjoyed reading. Goes to show why it’s called “The C Religion”.
  - quelsolaar 3y ago
    I think, most designers of languages want abstractions, convenience, and clevernes. So for people who don't want that we have to cling on to C since there aren't other options ;-)
    - rewmie 3y ago

PartiallyTyped 3y ago

> It also turns out that if you remove all the fancy abstraction and write everything out, the code becomes very maintainable and easy to manage. I was with you on everything until this part. I just don't see how reducing soundness via a weaker type system, and needing to explicitly manage memory vs e.g. Rust, uniq_ptr, shared_ptr, and so on makes things easier to maintain. I also don't see how absence of generics helps here either.

westoque 3y ago
this. properly made abstractions are actually more maintainable and easier to manage. for ex, take anybody learning programming about writing to a file, if you write your code using ruby, it would be a lot safer and maintainable than the C counterpart even though the latter is more powerful.
- rudedogg 3y ago
  Abstractions hide details, and you'll likely need to interact with something the abstraction hides eventually. So then you end up doing one of two things: 1. Learning every detail of the abstraction and the thing it's abstracting, fighting it until you persevere and get it to do what you want 2. Write something from scratch that does exactly what you need Going the #2 route from the start isn't such a bad idea, and has a lot of advantages IMO. The hard thing about all this is that abstractions are beautiful at first. It's not until you're far into a project, or doing something unusual that it all falls apart.
  - Conscat 3y ago
    Uh oh I wrote C code and just multiplied meters by yards and now the program exploded help
  - gpderetta 3y ago
    C has plenty of abstactions. Are you saying that the set of abstractions provided by C are optimal or nearly so?

bitwize 3y ago

I think it's high time to bury the myth of the "bondage and discipline language". Study after study has shown that, comparing development of the same application in C vs. a language with a very strong type system such as Ada, the application in the language with the very strong type system costs less to develop and has far fewer errors. The fact that C "gets out of your hair", i.e., doesn't provide checking for certain kinds of correctness, is an anti-feature.

jcranmer 3y ago

> C is better because it doesn't try to program for you, it isn't clever, convenient, or have any ideas about how you structure or solve a particular problem. Oh, C very much does have ideas. One of the big problems I have with C is that it has a surprisingly limited feature set that makes it difficult or impossible to express certain programming styles. Want to describe a function that returns multiple values? Well, you can't really do that (especially if you want this to mean "use two registers"). How about using unwind to express exceptional control flow? Can't do that either. Or if you want a function with multiple entry points? Or coroutines? C's fundamental inability to express certain kinds of control flow [1] greatly limit your ability to structure your code in ways that might make the code clearer. > It also turns out that if you remove all the fancy abstraction and write everything out, the code becomes very maintainable and easy to manage. I think experience has shown that this is not the case. The closest kernel of truth you might find is that if writing code requires a certain amount of tedium, that tends to limit the scale you can grow a codebase to, and size is one of the largest drivers of complexity. While it's definitely the case that abstraction can decrease maintainability, it is a mistake to think that it necessarily does so. Indeed, abstraction is often necessary to make code more maintainable. For example, when I design APIs, I think very hard about how to design it in such a way that it's impossible to misuse the API. So I make my APIs distinguish between UTF-8 strings and Latin-1 strings, so you can't be confused as to what's in them, or even distinguish between a row number and a column number. The other thing to bring up is that we know quite well that humans are pretty bad at doing tedious, repetitive tasks with high accuracy. And computers are pretty good at that! What this suggests is that languages should be designed so that things that are tedious and repetitive--such as propagating errors up a stack, or cleaning up resources on failure--can be done by the compiler and not the programmer. As we've seen with things like gotofail, C is a language which lacks features that enable work to be pushed onto the compiler and not the programmer, and code written in C suffers as a result of that. [1] And there's even more exotic kinds that I could get into--this is merely the list of features available in languages you've probably heard of, maybe even used!

kps 3y ago
>Or if you want a function with multiple entry points? `entry` was a reserved word in K&R, but not implemented.

em-bee 3y ago

i haven't come across a single language that would limit me in how i structure my code. that is, i didn't feel limited. whether it was python, ruby, smalltalk or even lisp. heck, once i translated a program from pike to common lisp. the structure of both programs was identical despite everyone claiming that lisp is so much different. it can be, but it doesn't force you to be. most non-C programmers can read it and have a rough idea of what is going on that's because most programmers can read most other languages and have an idea what's going on. that's not at all a special feature of C.

pornel 3y ago
> i haven't come across a single language that would limit me in how i structure my code Rust is one of the languages that limits how the code and data can be structured. Often it's either the Rust way, or it's going to be awkward or not even compile (e.g. it doesn't like doubly-linked lists, structs containing a references to their own data, mutable getters, and a few other common patterns). This is often very off-putting to people coming from C who want to do things their way, and end up fighting with the compiler over every line of code.
- em-bee 3y ago
  i haven't had an opportunity yet to work with rust. it is something i want to try. i actually like the idea of being constrained and forced to find different ways to solve a problem because i think i can learn something from that. i guess that haskell should be equally challenging. i actually expected that challenge from lisp too, but i was rather disappointed to discover that this wasn't the case and lisp isn't really that much different, neither was smalltalk. it's a nice language, but message-passing doesn't feel any different from method/function calling, so it's not really a different paradigm that affects the structure of your code.
  - kazinator 3y ago
    In Lisp, you can just use what you know and not challenge yourself; you're not constrained or forced. Any such challenge has to be self-imposed. You can learn enough to be able to work in it, and then just use it like Fortran.

JohnFen 3y ago

> C is better because it doesn't try to program for you, it isn't clever, convenient, or have any ideas about how you structure or solve a particular problem. This is much of why I prefer to use C (well, I actually prefer to use C++-as-a-better-C, but since I'll omit almost all of of what C++ brings, it's still C for all intents and purposes). Other reasons I prefer C include producing small executables (and, more importantly, being able to effectively control executable size), that it is the most portable language (in the sense that there are C compilers for just about every computer platform in existence), and it is both readable and concise.

fulafel 3y ago

Avoiding the UB footguns does steer you pretty hard if you try to write secure & portable C. For example keep away from signed integers and dynamic memory & pointer arithmetic.

rramadass 3y ago

> It also turns out that if you remove all the fancy abstraction and write everything out, the code becomes very maintainable and easy to manage. This is key to the success of C (also the main reason stated by Linus Torvalds for his choice of the language). You can write really complicated code which may take time to unravel/comprehend but nothing is really done behind your back nor hidden (please let's not start with UB :-).