3 ms·

As someone who uses mainly python, rust and js, as well as C on embedded. I recently came around reading The C Programming Language (2nd edition) and was surpri

by atoav 4y ago

As someone who uses mainly python, rust and js, as well as C on embedded. I recently came around reading The C Programming Language (2nd edition) and was surprised how many of the language decisions I found extremely horrible. I mean all the examples in the first chapter teach you how to do stuff with strings that will fail the moment you throw Unicode into the mix, and no programmer should use ASCII for any but the lowest level stuff today. I see this as a relic from older, nobler times and the language is interesting to learn about especially since it is the base of a lot of things, but if C was a sport it would be free climbing, or maybe something even more dangerous that requires a lot of skill that I can't think of now. In Rust there are many string types (e.g. OsString, CString, String, PathBuf, ..) because the truth is that you need to know the rules that the string your program reads or creates must adhere to, if there is no type system that will enforce those rules to you. The way a properly written program has to deal with strings in the different parts of systems could be explored in an entire programming career. Similarily Rust tends to make you handle all the errors that could occure with file I/O. This can feel complicated, but it could also serve as a reminder on how many potential errors we don't handle in other programming languages (or at least as a big questionmark how these other languages handle or don't handle these errors). Surely you could also ignore those error cases in Rust and just have your program crash, but then it was your active decision and not something that hit you out of nowhere like a bag of bricks, with the only realistic option of ignoring it and hoping it will not happen again. If anything something like Rust gave me a much better understanding why actual good C programs are akin to art. Freeclimbing in a minefield and all that.

rmind 4y ago
It is very easy to say, retrospectively, in year 2022, that the decisions were horrible. You are talking about the language and decisions made in 1970s. The knowledge was different. The computers were different, their capability was different. Try running your Python on PDP-7, an 18-bit system! ASCII vs EBCDIC is a computer architecture issue and it's unfair to blame the language that it doesn't have automatic/transparent support for EBCDIC (stuff from 1960s, by the way!). Unicode simply didn't exist at that time. And so on and so forth. On the contrary, I would say C aged really well for a language which was created to support an entire zoo of computers and operating systems. It is worth pointing out that the language has progressed a lot since then and you don't have to deal with many old headaches if you write C on a modern CPU architecture.
- atoav 4y ago
  I do not disagree with any point you made. Not at all. I just think an introduction to the language in the year 2022 should at least aknowledge that the form of string handling shown in the first part of the book should not be imitated. I can see how those examples would make perfect sense in a different age. Maybe I can give the book the benefit of the doubt as it was published in 2012. Do you have any book recommendations for a more modern C approach?
  - Calavar 4y ago
    The 2nd Edition was published in 1988. I would guess that this this 2012 version just adds an extra foreword and some errata?
    - atoav 4y ago
      Ah that explains a lot thanks
  - SAI_Peregrinus 4y ago
    "Modern C" by Jens Gustedt is an excellent book on a more modern approach to C.
- pjmlp 4y ago
  On the surface that explanation might make sense, then we start diving into computer archeology and discovering what was being done outside Bell Labs with NEWP, JOVIAL, ALGOL variants, PL/I variants, BLISS, Mesa, Modula-2, PL.8, Lisp, Fortran,.... Naturally it tends to be forgotten, as most UNIX folks set the genesis of computing world in Bell Labs.
- formerly_proven 4y ago
  > On the contrary, I would say C aged really well for a language which was created to support an entire zoo of computers and operating systems. This is the case only because the standardized C was more-or-less created as a superset of the many, many C variations that have sprung up until that point. It's also the reason why C leaves so many things up to the implementation or entirely undefined. Ultimately, this made C a highly portable language, while writing conformant and portable C programs is very difficult.
adhesive_wombat 4y ago
> C was a sport it would be free climbing I think maybe motorcycle racing. Fast, close to the ground, and one seemingly-trivial mistake away from a gruesome result. But also a rush when it goes well, responsive to riders knowing their machines and the terrain inside and out and eligible for lucrative sponsorships.
- jll29 4y ago
  ...bungee jumping - where you have to make your own string
  - adhesive_wombat 4y ago
    I'd say that's more true if you've been handed a strange new micro with a unique architecture and an untried toolchain. Make your rope as best you can but once you jump it's up to luck and whether the gods are feeling beneficent if you survive, and if you do, if you still have your limbs and retinas attached.
nuc1e0n 4y ago
By your logic, should z/OS not be used then because it is old and has quirks? EBCDIC is bizarre by modern standards. Non contiguous alphabet for instance.
- Joker_vD 4y ago
  Both Cyrillic and Greek are non-contigious in Unicode, does it make Unicode bizarre by modern standards as well?
SimplyUnknown 4y ago
The first edition of the C programming language was released in 1978, the second version in 1988. The first time something on Unicode was mentioned was also 1988, and the consortium was founded in 1991. UTF-8 was proposed in 1992. Simply put, the book doesn't deal with alternatives to ASCII because there hardly were alternative text encodings at the time of writing in the western world, which is clearly the focus of an English book written by a Canadian and American. Moreover, the point of the book was to propose the C programming language and showcase how the language works. It's not a book on best practices or how to use C in the real world today. There are other resources for that.
anonymoushn 4y ago
The first program that may have some issue with UTF-8 seems to be on page 18. The trouble with writing a UTF-8 aware "character counting" program is that the definition of "character" is pretty complex. A "correct" program would not fit on one page, and would need to be updated as more emoji ligatures are added to the standard. It would perhaps be good to clarify that "character" means "byte" in this program. The line counting program on page 19 is correct for UTF-8 inputs. The word counting program on page 20 works as specified (the specification says it only uses 3 specific delimiters) for UTF-8 inputs. The digit counting program is correct for UTF-8 inputs. The "longest input line" program doesn't really specify what "longest" means, but it finds the one with the most bytes. There are maybe 2 examples that don't work on UTF-8, if the standard is that "longest line" and "character counting" programs should detect that ":regional_indicator_s::regional_indicator_u:" is 2 characters while ":regional_indicator_u::regional_indicator_s:" is 1 character. Such programs may not make a very good introduction to programming though.
icedchai 4y ago
That book is well over 30 years old. Unicode was in the planning stages, but definitely not a thing yet. The decisions were "fine" for the time. This makes me feel even older, since I taught myself C with that book (and another, platform-specific, Amiga book) back when I was a teenager in the late 80's.
lelanthran 4y ago
> I recently came around reading The C Programming Language (2nd edition) and was surprised how many of the language decisions I found extremely horrible. I mean all the examples in the first chapter teach you how to do stuff with strings that will fail the moment you throw Unicode into the mix Define "fail" and define "Unicode". Does "fail" mean "iterates through bytes and not characters"? Does "fail" mean "can't recognise different encodings of the same 'character'"? Does "Unicode" mean UCS2, UTF-16, UTF-32 or UTF-8? Because, to be honest, quite a log of 'unicode-aware' languages will "faiol" the same way, and they don't have the same excuse as 'strlen()' does, namely being 35 plus years old. I think the fact that Unicode handling can still be such a mess in applications written on platforms and languages that came decades after C tells me that this is not an easy problem. C handles UTF-8 byte sequences with the current string functions just fine. You're going to have to manage the mapping between byte sequences and glyphs being displayed to the user, which you're going to have to manage anyway because "Unicode" is so ambiguous. Whatever support a modern language has for Unicode doesn't help all that much when the user-facing glyph isn't part of the language. What your language thinks is a character and what the end-user thinks is a character are two different things. C is not very different in this regard.
ranger207 4y ago
I learned C in a college class where we built a simulated computer from transistors up through assemble before moving to C. From that perspective the K&R C book is fantastically elegant: you can really see why C is sometimes described as a "portable assembly" because it maps closely to assembly instructions and conventions. As a first language above assembly, it's a fantastic language for doing work on limited systems. As a modern application language in the current world of high level abstractions like Unicode and the Internet, it's simply too simple. It was designed for and works relatively well for systems thst you understand completely all the way down to the metal

by atoav 4y ago

rmind 4y ago

It is very easy to say, retrospectively, in year 2022, that the decisions were horrible. You are talking about the language and decisions made in 1970s. The knowledge was different. The computers were different, their capability was different. Try running your Python on PDP-7, an 18-bit system! ASCII vs EBCDIC is a computer architecture issue and it's unfair to blame the language that it doesn't have automatic/transparent support for EBCDIC (stuff from 1960s, by the way!). Unicode simply didn't exist at that time. And so on and so forth. On the contrary, I would say C aged really well for a language which was created to support an entire zoo of computers and operating systems. It is worth pointing out that the language has progressed a lot since then and you don't have to deal with many old headaches if you write C on a modern CPU architecture.

atoav 4y ago
I do not disagree with any point you made. Not at all. I just think an introduction to the language in the year 2022 should at least aknowledge that the form of string handling shown in the first part of the book should not be imitated. I can see how those examples would make perfect sense in a different age. Maybe I can give the book the benefit of the doubt as it was published in 2012. Do you have any book recommendations for a more modern C approach?
- Calavar 4y ago
  The 2nd Edition was published in 1988. I would guess that this this 2012 version just adds an extra foreword and some errata?
  - atoav 4y ago
    Ah that explains a lot thanks
- SAI_Peregrinus 4y ago
  "Modern C" by Jens Gustedt is an excellent book on a more modern approach to C.
pjmlp 4y ago
On the surface that explanation might make sense, then we start diving into computer archeology and discovering what was being done outside Bell Labs with NEWP, JOVIAL, ALGOL variants, PL/I variants, BLISS, Mesa, Modula-2, PL.8, Lisp, Fortran,.... Naturally it tends to be forgotten, as most UNIX folks set the genesis of computing world in Bell Labs.
formerly_proven 4y ago
> On the contrary, I would say C aged really well for a language which was created to support an entire zoo of computers and operating systems. This is the case only because the standardized C was more-or-less created as a superset of the many, many C variations that have sprung up until that point. It's also the reason why C leaves so many things up to the implementation or entirely undefined. Ultimately, this made C a highly portable language, while writing conformant and portable C programs is very difficult.

adhesive_wombat 4y ago

> C was a sport it would be free climbing I think maybe motorcycle racing. Fast, close to the ground, and one seemingly-trivial mistake away from a gruesome result. But also a rush when it goes well, responsive to riders knowing their machines and the terrain inside and out and eligible for lucrative sponsorships.

jll29 4y ago
...bungee jumping - where you have to make your own string
- adhesive_wombat 4y ago
  I'd say that's more true if you've been handed a strange new micro with a unique architecture and an untried toolchain. Make your rope as best you can but once you jump it's up to luck and whether the gods are feeling beneficent if you survive, and if you do, if you still have your limbs and retinas attached.

nuc1e0n 4y ago

By your logic, should z/OS not be used then because it is old and has quirks? EBCDIC is bizarre by modern standards. Non contiguous alphabet for instance.

Joker_vD 4y ago
Both Cyrillic and Greek are non-contigious in Unicode, does it make Unicode bizarre by modern standards as well?

SimplyUnknown 4y ago

The first edition of the C programming language was released in 1978, the second version in 1988. The first time something on Unicode was mentioned was also 1988, and the consortium was founded in 1991. UTF-8 was proposed in 1992. Simply put, the book doesn't deal with alternatives to ASCII because there hardly were alternative text encodings at the time of writing in the western world, which is clearly the focus of an English book written by a Canadian and American. Moreover, the point of the book was to propose the C programming language and showcase how the language works. It's not a book on best practices or how to use C in the real world today. There are other resources for that.

anonymoushn 4y ago

The first program that may have some issue with UTF-8 seems to be on page 18. The trouble with writing a UTF-8 aware "character counting" program is that the definition of "character" is pretty complex. A "correct" program would not fit on one page, and would need to be updated as more emoji ligatures are added to the standard. It would perhaps be good to clarify that "character" means "byte" in this program. The line counting program on page 19 is correct for UTF-8 inputs. The word counting program on page 20 works as specified (the specification says it only uses 3 specific delimiters) for UTF-8 inputs. The digit counting program is correct for UTF-8 inputs. The "longest input line" program doesn't really specify what "longest" means, but it finds the one with the most bytes. There are maybe 2 examples that don't work on UTF-8, if the standard is that "longest line" and "character counting" programs should detect that ":regional_indicator_s::regional_indicator_u:" is 2 characters while ":regional_indicator_u::regional_indicator_s:" is 1 character. Such programs may not make a very good introduction to programming though.

icedchai 4y ago

That book is well over 30 years old. Unicode was in the planning stages, but definitely not a thing yet. The decisions were "fine" for the time. This makes me feel even older, since I taught myself C with that book (and another, platform-specific, Amiga book) back when I was a teenager in the late 80's.

lelanthran 4y ago

> I recently came around reading The C Programming Language (2nd edition) and was surprised how many of the language decisions I found extremely horrible. I mean all the examples in the first chapter teach you how to do stuff with strings that will fail the moment you throw Unicode into the mix Define "fail" and define "Unicode". Does "fail" mean "iterates through bytes and not characters"? Does "fail" mean "can't recognise different encodings of the same 'character'"? Does "Unicode" mean UCS2, UTF-16, UTF-32 or UTF-8? Because, to be honest, quite a log of 'unicode-aware' languages will "faiol" the same way, and they don't have the same excuse as 'strlen()' does, namely being 35 plus years old. I think the fact that Unicode handling can still be such a mess in applications written on platforms and languages that came decades after C tells me that this is not an easy problem. C handles UTF-8 byte sequences with the current string functions just fine. You're going to have to manage the mapping between byte sequences and glyphs being displayed to the user, which you're going to have to manage anyway because "Unicode" is so ambiguous. Whatever support a modern language has for Unicode doesn't help all that much when the user-facing glyph isn't part of the language. What your language thinks is a character and what the end-user thinks is a character are two different things. C is not very different in this regard.

ranger207 4y ago

I learned C in a college class where we built a simulated computer from transistors up through assemble before moving to C. From that perspective the K&R C book is fantastically elegant: you can really see why C is sometimes described as a "portable assembly" because it maps closely to assembly instructions and conventions. As a first language above assembly, it's a fantastic language for doing work on limited systems. As a modern application language in the current world of high level abstractions like Unicode and the Internet, it's simply too simple. It was designed for and works relatively well for systems thst you understand completely all the way down to the metal