[HN Gopher] The Development of the C Language (2003)
___________________________________________________________________
The Development of the C Language (2003)
Author : cpeterso
Score : 172 points
Date : 2023-09-09 06:33 UTC (16 hours ago)
(HTM) web link (cm.bell-labs.co)
(TXT) w3m dump (cm.bell-labs.co)
| jug wrote:
| I like the curiosity of the Amiga OS that was developed in an
| interim period between BCPL and its successor C. Amiga OS was
| originally based on a port of TRIPOS to the Motorola 68000 by
| MetacomCo. It was eventually replaced but it would take some
| time. In AmigaOS 1.x, AmigaDOS is still based on TRIPOS and thus
| written in BCPL. BCPL didn't have native pointers so applications
| were difficult to write and error-prone. AmigaOS 2.x rewrote it
| in C but maintaining compatibility to BCPL where possible so IIRC
| it was somewhat littered with shims for that. Only in AmigaOS 4
| was the BCPL heritage completely shed, 20 years later!
|
| Nowadays, AmigaDOS sounds like a true antiquity but at the time,
| I remember I always found the shell surprisingly capable and
| modern! Especially for what was first and foremost a home
| entertainment system (although Commodore didn't want it to be
| only that). We even mounted volumes under arbitrary names, much
| like on Unix, had RAM drives and even RAD drives -- semi-
| persistent drives that made use of the fact that its RAM circuits
| were persistent enough to survive reboots!
|
| I absolutely felt like I was thrown back in time when finally
| going PC and I suddenly no longer had my DOS able to multitask in
| a visual environment with all these features, and rather had to
| challenge myself with freeing up 600 KB of conventional RAM...
| 0x445442 wrote:
| Yeah I really wish the copyright holders would give it up and
| open source OS4. It's one the few sweet spot personal OS's that
| are single user multi tasking. I guess AROS is close but it's
| clunky.
| dboreham wrote:
| Amiga cane decades after C. It was only due to a geographic
| quirk that people were still using BCPL at that time. They
| could have used C (for years) but chose not to.
| kazinator wrote:
| Pretty much exactly one decade after C.
| flohofwoe wrote:
| It took me until around 1998 before it felt "right" for me to
| finally switch from my beloved Amiga 3000 to PCs running either
| Win95 or NT4, and even then some specific use cases (like
| trying to work on the command line) felt entirely medieval
| compared to the Amiga. At least the games were better on PC
| though.
| ngcc_hk wrote:
| Wonder who is not. Even cpm ... ibm Tso and vm/cms ... not to
| mention unix.
| kazinator wrote:
| > _Amiga OS that was developed in an interim period between
| BCPL and its successor C_
|
| Wut?
|
| BCPL: 1967
|
| C: 1975
|
| Amiga: 1985
| adrian_b wrote:
| More accurately, the earliest "C Reference Manual" that I
| have seen has the date 1974-01-15.
|
| It includes all the new features that have differentiated C
| from B, most of which have been implemented during the summer
| of 1973. Therefore, by January 1974 C was complete.
|
| The next significant modifications of the language after that
| date have occurred only during the ANSI standardization
| process (which ended in 1989, so perhaps the poster above has
| meant that Amiga happened between K&R C and ANSI C).
| icedchai wrote:
| I first learned C on an Amiga, back in 1989 or so (Lattice
| C compiler, which became SAS/C.) All the books and
| documentation at the time was K&R style. Around 1991 or so,
| I remember reading K&R second edition, which was ANSI C.
| [deleted]
| tgv wrote:
| Perhaps because compilers were expensive back then.
| aap_ wrote:
| What's fascinating is that I recently found some code that I
| believe was written in NB [1]. It's compiled to threaded code
| (like B) but knows about chars (like C). It doesn't quite match
| the story, but I don't know what else it could be
|
| [1]
| https://inbox.vuxu.org/tuhs/ZKyl8drfW%2FBs1LVa@minnie.tuhs.o...
| ChrisArchitect wrote:
| (1993)
| ChrisArchitect wrote:
| huge discussion about this only a few months ago:
|
| https://news.ycombinator.com/item?id=36652934
| pieterr wrote:
| (1993)
|
| A real classic!
|
| https://news.ycombinator.com/item?id=36652934
| pjmlp wrote:
| From the language authors themselves,
|
| "Although the first edition of K&R described most of the rules
| that brought C's type structure to its present form, many
| programs written in the older, more relaxed style persisted, and
| so did compilers that tolerated it. To encourage people to pay
| more attention to the official language rules, to detect legal
| but suspicious constructions, and to help find interface
| mismatches undetectable with simple mechanisms for separate
| compilation, Steve Johnson adapted his pcc compiler to produce
| lint [Johnson 79b], which scanned a set of files and remarked on
| dubious constructions."
|
| Random dude on Internet, I know better.
| msla wrote:
| From my own recollection, the construction
| (void) var;
|
| for unused variables is specifically to silence certain
| versions of lint which would otherwise complain.
| kevin_thibedeau wrote:
| Nowadays it silences -Wunused-perameter. I'm not a fan as it
| just adds nonfunctional clutter only needed to appease a
| tool. The tools are supposed to work on our behalf, not
| against.
| flohofwoe wrote:
| I much prefer being warned about unused variables and
| explicitely having to silence those warnings on a case by
| case basis though - especially when refactoring (one option
| is to use a wrapper macro MAYBE_UNUSED(bla) macro, or GCC's
| __attribute__((unused)) or the C++ [[unused]], or the C23
| [[maybe_unused]].
|
| But of all those options, "(void)bla;" might actually be
| the least clutter (and at the same time the most
| compatible).
| mtklein wrote:
| I agree that (void)bla is desirably clear, pithy and
| unambiguous. And I like something like this if I'm
| dealing with functions with more than a couple unused
| parameters: static void unused_(int x,
| ...) { (void)x; } #define unused(...) unused_(0,
| __VA_ARGS__)
|
| This way you can just have one
| `unused(foo,bar,baz,quux);` line at the top of the
| function listing all unused parameters.
| loup-vaillant wrote:
| We can also silence -Wunused-perameter by omitting the
| parameter name in the prototype. No clutter, I'm personally
| fairly happy with this solution. _(Note: the declaration in
| the header can sill name the parameter, it won 't bring the
| warning back.)_
| ludocode wrote:
| That's only in C++. As far as I know in C you need to
| name all parameters (although maybe that rule has been
| relaxed in newer versions of C.)
| flohofwoe wrote:
| C23 finally relaxes that rule:
|
| https://www.open-
| std.org/jtc1/sc22/wg14/www/docs/n2510.pdf
|
| (although some C compilers already allowed it in non-
| pedantic mode)
___________________________________________________________________
(page generated 2023-09-09 23:01 UTC)