[vucetica]

I was in 6th grade when I found "The C Programming Language" on the floor in my friend's house. I picked it up, took it home, and read it cover to cover. I didn't have a computer then, but I was absolutely sure about what I wanted to do in my life.

Thank you, Mr. Ritchie and Mr. Kernighan for opening the world of computer science for me.

[dhosek]

I was lent a copy of K&R by an English teacher¹ in my high school (this was 1984ish). I still remember the smell of coffee and nicotine that was imbued in its pages and any time I deal with C code, the sense memory comes back to me.

For a while, under the influence of K&R and The TeXbook, I contemplated going to Stanford to study computer science and then working at Bell Labs. I did neither.

⸻⸻⸻

1. About ten years ago, I decided to try to reach out to him and thank him and comment about how out paths kind of were the inverse of each other—he had a degree in computer science but ended up teaching high school English, I had a degree in English and ended up programming computers—and I discovered that he had died a few months previous. Whenever possible, get in touch with those who influenced you earlier if just to say hi and thanks.

[jeffrallen]

I ordered it by inter-library loan in 1991 to rural Oregon. I had recently learned 6502 assembly language, so pointers seemed "obvious". A few years later in CS101 I had such instinctive feel for them I could hardly explain them to my fellow students.

Thank you K&R.

[bear8642]

> so pointers seemed "obvious"

Indeed - having come from low level route, never really understood why people get so confused with them

[dhosek]

I can remember writing a large Pascal program in the 80s and really wishing I had function pointers available so I could pass in a reference to a function. I look back on that as an autodidact programmer and realize that I had some vague instinctual notion of stuff that would become commonplace as OO and functional paradigms took over.

[mistrial9]

surprising -- I picked up the same, also read it cover to cover, and wondered over and over what kind of thinking leads to the small assembly'ish idioms and quirky character IO definitions. "Structured Programming" was obvious to me, and using that design to build non-trivial programs was very compelling, but the constant emphasis on small, tricky ways to move around a character seemed driven by some intense factory of machine parts thinking, not clean abstractions or consistant naming or human-readable coding. I immediately wanted to try this "big phone network" core OS language on my portable home computer with apparently one-one hundred thousandth of the capacity. Other home computer companies were publishing C compilers rapidly with lots of feature tradeoffs, so there was no question that C was the thing to use for me. Not good design at all though -- machine requirement driven totally.

[voakbasda]

I recently worked to update a Linux-based system that was originally built by a team that had previously implemented the same product on a microcontroller-based system. The Linux drivers are obviously direct ports of the old subsystems, without any apparent effort to understand or leverage existing kernel drivers or subsystems that could have simplified (or outright replaced) their custom functionality. It is unholy.

Now, this might sound absurd by the standards of today (because it is), but this was the transition that every programmer had to make back when high level languages were introduced. It takes time to adapt to a paradigm shift, so it hardly seems surprising when vestiges of the “old ways” can be seen peeking through the curtains of the new abstraction.