Hacker News Reader

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.

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?

The 2nd Edition was published in 1988. I would guess that this this 2012 version just adds an extra foreword and some errata?

Ah that explains a lot thanks

"Modern C" by Jens Gustedt is an excellent book on a more modern approach to C.

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.

> 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.

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.

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.

> 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.

...bungee jumping - where you have to make your own string

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.

> 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.

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.

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 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.

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