8 ms·

I don't like how people on the internet hate on C all the time. To me C is a wonderfully simple and elegant language that I can most of the time very clearly ex

by aap_ 7y ago

I don't like how people on the internet hate on C all the time. To me C is a wonderfully simple and elegant language that I can most of the time very clearly express my thoughts in. I find that this not the case with many other languages. This is the reason I use C. Of course compiler writers are trying to sabotage this but I don't write any critical code so if I get hit by an occasional bug it's not a big problem. I think C is misunderstood, perhaps because it is used everywhere and standards for critical pieces of software are applied to non-critical ones. E.g. never freeing memory, even leaking it by destroying all references to it, can be totally fine if your program just runs for a few seconds. Just allocate what you need, throw it away, and let the OS clean up when you're done. This is perfectly fine but I feel like many people wouldn't accept this kind of code because it's not acceptable in other circumstances. Anyway, the author makes a few good points that are important but often overlooked, but I don't think I'd agree with him on the safety aspect in section 6. Making a safe C implementation doesn't really appear possible. If you allow casting integers to pointers, how do you implement these saftey checks he's talking about?

GlennS 7y ago
I feel like C has to go in the bucket of 'bad languages' these days, because it doesn't have sensible unicode support built in. But that doesn't mean you can't have fun with it, or write good computer programs. It just means that user inputted text is always going to be a pain.
- Nursie 7y ago
  To be fair it doesn't really have strings 'built in' particularly well either. It directly manipulates memory patches, and the string support that is there is mostly a very simple abstraction on that. If you want support for unicode etc, there are libraries.
  - solarkraft 7y ago
    But then that brings you compatibility issues, overhead ...
    - Nursie 7y ago
      If you want to avoid development overhead, absolutely, C is a terrible language to pick. I'm not sure what you mean by compatibility issues in this context?
      - solarkraft 7y ago
        I'm thinking about differen string representations used by different libraries. Is this not true?
        Nursie 7y ago
        Honestly all I've encountered default strings (and people shy away from those now) and LibICU stuff. I think ICU has become a defacto standard but I have been out of C for a few years. This tends to be important for strings you're going to show to the user (or input you gather from them), maybe most of the C in the world isn't aimed at interfaces like that...
- deleted 7y ago
  [deleted]
- jstimpfle 7y ago
  Actually the best way to deal with unicode in almost all situations is to use UTF-8, and dealing with UTF-8 in C is trivial. For other encodings, well you need to decode explicitly (or just go for wide chars). Shouldn't come as a surprise, and not a big deal either.
drb91 7y ago
I stopped writing C because string manipulation sucked.
- aap_ 7y ago
  I never really got that complaint, I'd like to see some examples of what people consider so ugly about C strings.
  - dgellow 7y ago
    Why is this comment being down voted? Not everybody here is familiar with C string manipulation, if you down vote or complain at least give more detail that "it sucks". @aap_, I asked a similar question some time ago and got some answers, you can check the thread here: https://news.ycombinator.com/item?id=19302581 https://news.ycombinator.com/item?id=19302581 The direct answer I got was: > I'm guessing because an off-by-one or an extra skip might mean you miss the end of the string and go off into la-la land feeding whatever garbage happens to be in memory to your parser? That would mostly be a C issue (as it has no string abstraction at all).
    - coldtea 7y ago
      >Why is this comment being down voted? Not everybody here is familiar with C string manipulation, if you down vote or complain at least give more detail that "it sucks". Well, if someone is not familiar, why do they read a subthread on the matter? Shouldn't they better start with a tutorial on C/C strings? Even if people on this thread gave arguments, how would they (not familiar with C and C strings) would evaluate them? They could be totally bogus.
  - flohofwoe 7y ago
    I agree, but C (the language) doesn't even have the concept of a 'string'. It's just the convention how some C standard library functions interpret an array of bytes with a zero at the end. At least in C it's quite obvious that strings are not trivial if you want both an intuitive way to work with strings, and high performance. The C++ std::string type is neither intuitive to work with, nor does it allow to write high-performance code. For string processing it's really better to use another language with different trade-offs.
pjmlp 7y ago
C was already hated on BBS and USENET during the early 90's. You will find my nick on those archives at the C++/Pascal trenches side.
- ChrisRR 7y ago
  Fads have always come and gone. C was already 20 years old in the 90s so it was a fair target for hating in favour of something newer and shinier.
  - pjmlp 7y ago
    In the early 90's C was still hardly a thing outside the UNIX computer lab. Mainframes were written in a mix of Assembly and safe system languages (IBM i, z and Unysis ClearPath are the survivors). 8 and 16 bit home micros OSes were largely written in Assembly, and all system languages were in equal footing as platform guests.
    - jasode 7y ago
      >In the early 90's C was still hardly a thing outside the UNIX computer lab. That's not what I remembered. Back in 1989, I bought the very popular Microsoft C 5.1 compiler (in shrinkwrapped box) from the Egghead retail store. Egghead was basically a smaller version of CompUSA. Also, non-UNIX publications like PC Magazine and BYTE had ads for Borland Turbo C. Watcom C was also a competitor. In the late 1980s and early 1990s, if one wanted to write COTS software for DOS on IBM PC compatibles, it was either assembly or C Language. Other languages like dBASE/Clipper/4GL were for LOB apps instead of COTS. In 1985, both Lotus 123 v3 and MS Excel were written using C. It was more like the early 1980s before the personal computer revolution when the C Language was mostly tied to UNIX.
      - pjmlp 7y ago
        It was very regional. Back in the Iberian Penisula, Turbo Basic, Turbo Pascal, TASM, NASM reigned on the PC for COTS. Amiga demoscene was all about AMOS and 68000 Assembly. I code since 1986, touched my very first C compiler in 1992. By then I already had used Timex 2068 Basic, 48+ Basic, CP/M on +3 A, Z80, Turbo Basic, Forth, Turbo Pascal 3 - 6, Dbase III Plus, 8086 with TASM. Thankfully also in 1992, I got hold of Turbo C++ 1.0, and I was settled on my opinion about C.
johannes1234321 7y ago
"There are only two kinds of languages: the ones people complain about and the ones nobody uses." (Bjarne Stroustrup) I guess that doesn't only apply to C++, but also C. :)
atilaneves 7y ago
Everybody's brain works differently. Maybe C is the language for you. Maybe your tradeoffs are different from mine and you're ok with dealing with segfaults and security exploits. AFAIC if I never again have to write string handling code in C it'll be too soon."|"|"|"|
- sureaboutthis 7y ago
  There are standard C libraries that handle strings very well. Are you saying other languages don't have security exploits? And in 35 years of writing in C, I have only had a very few segfaults while writing new code but never in production so I don't know why you think it happens so often unless your knowledge is only from reading reddit headlines.
  - atilaneves 7y ago
    > There are standard C libraries that handle strings very well. I'm not aware of any. I've never encountered a language that is more frustrating than C to manipulate strings in. > Are you saying other languages don't have security exploits? No, I'm saying they have fewer. Far fewer. > And in 35 years of writing in C, I have only had a very few segfaults while writing new code but never in production Good for you. In 25 years of writing C and working with dozens of other programmers writing C in that time, I've lost count of how many segfaults and memory corruption errors I've had to debug. I don't miss those days and never want to go back. > unless your knowledge is only from reading reddit headlines. It is not. See above.
ernst_klim 7y ago
>To me C is a wonderfully simple and elegant language Yeah, language without metaprogramming, parametric polymorphism, objects, exceptions, RAII, ownership, decent type system, decent comprehensive library, barely any modern features, yet 700 pages standard. Language so simple and elegant, that no one could write it without stepping into one of its numerous pitfalls. God, everything is bad about this language: grammar is ambiguous, syntax often is barely readable, type system is weak and absent, preprocessor uses text substitutions making your code error-prone and hard to debug, modules? ha, text substitution is the answer. It feels like if all the bad decisions one could make regarding PL development were made at once. There were dozens of examples how to make a decent programming language: C is not decent by any means. It's literally a javascript of the embedded, a abysmal yet ubiquitous language which is there only because of UNIXs' success and legacy. In embedded, I would prefer C++ or Ada definitely.
- sangnoir 7y ago
  > Yeah, language without ... decent comprehensive library I'm sorry, did you just say C doesn't have a comprehensive library?! I agree with your other points (but posit that they are not always negative; some of the 'flexibility' is useful in the domains where C dominates. Most of the shortfall can be covered by tooling, linting and standards. It's been almost a decade since I last used C, but I think the complaints are overblown. Some tools have sharper edges than others, but there are there to accomplish a goal.
  - ernst_klim 7y ago
    >I'm sorry, did you just say C doesn't have a comprehensive library?! Data structures? Lists, Hashtables, Maps, Strings, Refcounted pointers, Weak pointers, Ephemerons, iterators for mentioned? C library is a joke even by 1970 standards. >Most of the shortfall can be covered by tooling, linting and standards. The amounts of CVEs prove you wrong. Besides, a typical C-coder considers himself smarter than type checker, otherwise he would be using another language (ML, Rust, Ada, C++).
deleted 7y ago
[deleted]

by aap_ 7y ago

GlennS 7y ago

I feel like C has to go in the bucket of 'bad languages' these days, because it doesn't have sensible unicode support built in. But that doesn't mean you can't have fun with it, or write good computer programs. It just means that user inputted text is always going to be a pain.

Nursie 7y ago
To be fair it doesn't really have strings 'built in' particularly well either. It directly manipulates memory patches, and the string support that is there is mostly a very simple abstraction on that. If you want support for unicode etc, there are libraries.
- solarkraft 7y ago
  But then that brings you compatibility issues, overhead ...
  - Nursie 7y ago
    If you want to avoid development overhead, absolutely, C is a terrible language to pick. I'm not sure what you mean by compatibility issues in this context?
    - solarkraft 7y ago
      I'm thinking about differen string representations used by different libraries. Is this not true?
      - Nursie 7y ago
        Honestly all I've encountered default strings (and people shy away from those now) and LibICU stuff. I think ICU has become a defacto standard but I have been out of C for a few years. This tends to be important for strings you're going to show to the user (or input you gather from them), maybe most of the C in the world isn't aimed at interfaces like that...
deleted 7y ago
[deleted]
jstimpfle 7y ago
Actually the best way to deal with unicode in almost all situations is to use UTF-8, and dealing with UTF-8 in C is trivial. For other encodings, well you need to decode explicitly (or just go for wide chars). Shouldn't come as a surprise, and not a big deal either.

drb91 7y ago

I stopped writing C because string manipulation sucked.

aap_ 7y ago
I never really got that complaint, I'd like to see some examples of what people consider so ugly about C strings.
- dgellow 7y ago
  Why is this comment being down voted? Not everybody here is familiar with C string manipulation, if you down vote or complain at least give more detail that "it sucks". @aap_, I asked a similar question some time ago and got some answers, you can check the thread here: https://news.ycombinator.com/item?id=19302581 https://news.ycombinator.com/item?id=19302581 The direct answer I got was: > I'm guessing because an off-by-one or an extra skip might mean you miss the end of the string and go off into la-la land feeding whatever garbage happens to be in memory to your parser? That would mostly be a C issue (as it has no string abstraction at all).
  - coldtea 7y ago
    >Why is this comment being down voted? Not everybody here is familiar with C string manipulation, if you down vote or complain at least give more detail that "it sucks". Well, if someone is not familiar, why do they read a subthread on the matter? Shouldn't they better start with a tutorial on C/C strings? Even if people on this thread gave arguments, how would they (not familiar with C and C strings) would evaluate them? They could be totally bogus.
- flohofwoe 7y ago
  I agree, but C (the language) doesn't even have the concept of a 'string'. It's just the convention how some C standard library functions interpret an array of bytes with a zero at the end. At least in C it's quite obvious that strings are not trivial if you want both an intuitive way to work with strings, and high performance. The C++ std::string type is neither intuitive to work with, nor does it allow to write high-performance code. For string processing it's really better to use another language with different trade-offs.

pjmlp 7y ago

C was already hated on BBS and USENET during the early 90's. You will find my nick on those archives at the C++/Pascal trenches side.

ChrisRR 7y ago
Fads have always come and gone. C was already 20 years old in the 90s so it was a fair target for hating in favour of something newer and shinier.
- pjmlp 7y ago
  In the early 90's C was still hardly a thing outside the UNIX computer lab. Mainframes were written in a mix of Assembly and safe system languages (IBM i, z and Unysis ClearPath are the survivors). 8 and 16 bit home micros OSes were largely written in Assembly, and all system languages were in equal footing as platform guests.
  - jasode 7y ago
    >In the early 90's C was still hardly a thing outside the UNIX computer lab. That's not what I remembered. Back in 1989, I bought the very popular Microsoft C 5.1 compiler (in shrinkwrapped box) from the Egghead retail store. Egghead was basically a smaller version of CompUSA. Also, non-UNIX publications like PC Magazine and BYTE had ads for Borland Turbo C. Watcom C was also a competitor. In the late 1980s and early 1990s, if one wanted to write COTS software for DOS on IBM PC compatibles, it was either assembly or C Language. Other languages like dBASE/Clipper/4GL were for LOB apps instead of COTS. In 1985, both Lotus 123 v3 and MS Excel were written using C. It was more like the early 1980s before the personal computer revolution when the C Language was mostly tied to UNIX.
    - pjmlp 7y ago
      It was very regional. Back in the Iberian Penisula, Turbo Basic, Turbo Pascal, TASM, NASM reigned on the PC for COTS. Amiga demoscene was all about AMOS and 68000 Assembly. I code since 1986, touched my very first C compiler in 1992. By then I already had used Timex 2068 Basic, 48+ Basic, CP/M on +3 A, Z80, Turbo Basic, Forth, Turbo Pascal 3 - 6, Dbase III Plus, 8086 with TASM. Thankfully also in 1992, I got hold of Turbo C++ 1.0, and I was settled on my opinion about C.

johannes1234321 7y ago

"There are only two kinds of languages: the ones people complain about and the ones nobody uses." (Bjarne Stroustrup) I guess that doesn't only apply to C++, but also C. :)

atilaneves 7y ago

Everybody's brain works differently. Maybe C is the language for you. Maybe your tradeoffs are different from mine and you're ok with dealing with segfaults and security exploits. AFAIC if I never again have to write string handling code in C it'll be too soon."|"|"|"|

sureaboutthis 7y ago
There are standard C libraries that handle strings very well. Are you saying other languages don't have security exploits? And in 35 years of writing in C, I have only had a very few segfaults while writing new code but never in production so I don't know why you think it happens so often unless your knowledge is only from reading reddit headlines.
- atilaneves 7y ago
  > There are standard C libraries that handle strings very well. I'm not aware of any. I've never encountered a language that is more frustrating than C to manipulate strings in. > Are you saying other languages don't have security exploits? No, I'm saying they have fewer. Far fewer. > And in 35 years of writing in C, I have only had a very few segfaults while writing new code but never in production Good for you. In 25 years of writing C and working with dozens of other programmers writing C in that time, I've lost count of how many segfaults and memory corruption errors I've had to debug. I don't miss those days and never want to go back. > unless your knowledge is only from reading reddit headlines. It is not. See above.

ernst_klim 7y ago

>To me C is a wonderfully simple and elegant language Yeah, language without metaprogramming, parametric polymorphism, objects, exceptions, RAII, ownership, decent type system, decent comprehensive library, barely any modern features, yet 700 pages standard. Language so simple and elegant, that no one could write it without stepping into one of its numerous pitfalls. God, everything is bad about this language: grammar is ambiguous, syntax often is barely readable, type system is weak and absent, preprocessor uses text substitutions making your code error-prone and hard to debug, modules? ha, text substitution is the answer. It feels like if all the bad decisions one could make regarding PL development were made at once. There were dozens of examples how to make a decent programming language: C is not decent by any means. It's literally a javascript of the embedded, a abysmal yet ubiquitous language which is there only because of UNIXs' success and legacy. In embedded, I would prefer C++ or Ada definitely.

sangnoir 7y ago
> Yeah, language without ... decent comprehensive library I'm sorry, did you just say C doesn't have a comprehensive library?! I agree with your other points (but posit that they are not always negative; some of the 'flexibility' is useful in the domains where C dominates. Most of the shortfall can be covered by tooling, linting and standards. It's been almost a decade since I last used C, but I think the complaints are overblown. Some tools have sharper edges than others, but there are there to accomplish a goal.
- ernst_klim 7y ago
  >I'm sorry, did you just say C doesn't have a comprehensive library?! Data structures? Lists, Hashtables, Maps, Strings, Refcounted pointers, Weak pointers, Ephemerons, iterators for mentioned? C library is a joke even by 1970 standards. >Most of the shortfall can be covered by tooling, linting and standards. The amounts of CVEs prove you wrong. Besides, a typical C-coder considers himself smarter than type checker, otherwise he would be using another language (ML, Rust, Ada, C++).

deleted 7y ago

[deleted]