From mboxrd@z Thu Jan 1 00:00:00 1970 From: dds@aueb.gr (Diomidis Spinellis) Date: Fri, 9 Sep 2016 09:06:41 +0300 Subject: [TUHS] Comments on "C" In-Reply-To: References: <20160908133038.CF61818C0CB@mercury.lcs.mit.edu> <008601d20a06$11aa2310$34fe6930$@ronnatalie.com> Message-ID: <4a7fc027-ad96-29c4-99c7-042fcc204caf@aueb.gr> On 09/09/2016 06:02, Ronald Natalie wrote: >> On Sep 8, 2016, at 6:06 PM, Dave Horsfall wrote: >> On Thu, 8 Sep 2016, Ron Natalie wrote: >>> Most of my complaints about C are because it's "standard" library was >>> awful back in the seventies and it really didn't improve much over the >>> years. >> >> That "portable I/O" library was certainly atrocious, but at least STDIO >> was an improvement. > > Not much. The functions have all of their portable IO library ugliness. Don’t get me started on fread/fwrite. > Ane why gets and fgets have different semantics and all the various functions take the stream parameter in > different places. Let's put things into perspective. A rarely talked-about innovation of C was that the language was separate from the libraries. At the time each language came with built-in commands for performing I/O and (if you were lucky) handling strings. These were part of the language's syntax and semantics; any additional facilities provided through libraries were second class citizens. C gave us a lean language that could be implemented and run without the overhead of its "library" facilities. This made it suitable for writing an OS kernel and later for writing embedded systems applications and for porting to other operating systems. It also made any add-on library a first class citizen. In a program there's no difference between calls to the "standard" stdio.h or string.h functions and calls to add-on libraries such as those in dbm.h or mp.h. The C library may be deficient, but when its interfaces were devised it was not "The C Library", but a number of functions and headers that (I guess) the people at Bell Labs whipped together to simplify their life when writing application code. It doesn't show the careful design that went into other places (the C language, the Unix system calls, the shell), because I think it was expected that people would quickly come up with better alternatives. In the end this "good enough" design spread widely and then got standardized (by removing Unix-specific functionality and a few rough edges) into what we now call the C Standard Library. My complaint is that some APIs that were designed later, such as the C++ STL and the Python libraries, didn't adopt more consistent naming conventions.