The Book That Split in Two at the Pointer Chapter

Compilers, from K&R and Turbo C to cross-compiling on embedded Linux — and the class that first made me wonder what to do next.

A look back — long before any of the tools we argue about now.

A few memory fragments around the word compiler. I came to C still thinking programming = BASIC, knowing just enough to say that an interpreter and a compiler weren’t the same thing, and picked up the rest through coursework and odd freelance jobs. Mostly C and C++, mostly straight out of the textbook.

The C Programming Language / Turbo C 2.0

The first fragment is the textbook from my very first class as a freshman: The C Programming Language — K&R, probably the second edition. In my memory it’s really two different books, split right at the chapter where pointers appear. A couple of things hit hard: how absurdly clean the switch/case statement was, and the small thrill of finally understanding binary search and shell sort.

The next fragment is Turbo C, carried home on a floppy to do homework on. This was before I’d gotten my hands on Windows 95 — you could build an honest-to-goodness .exe under MS-DOS and run it. Against the backdrop of fumbling with GDB at school, this was the tool that showed me how beautiful an IDE and a real debugger could be. I splurged on a thick manual — in Korean, which was a luxury then — and a group of us passed it around for ages.

Borland C++ / Visual C++

In my sophomore year, the upperclassmen handed down a bit of bad folklore: that people who’d learned C would pick up C++ easily. I struggled with that for a long time. Part of it was that we learned OOP a little later, and the code I wrote was probably C with a thin shell bolted on. Unlike Turbo C, which installed off a floppy or two, C++ was hard to come by — this was the era of installing Windows 95 from twenty floppy disks, and these tools were expensive and genuinely difficult to get set up.

Get Chaesang Jung’s stories in your inbox

For some reason I had a vague resentment of Microsoft back then, so I rooted for Borland on principle — but to take freelance jobs I ended up using whatever I had to. I remember spending more effort wrangling the environment and installing drivers than actually touching code, and for a long stretch, whatever I built at home had to be rewritten anyway once I carried the floppy to a school machine. I’ve been a VI user the whole way through, but this was when I used emacs, strictly for debugging assignments. I got fairly good with the shortcuts — never good enough to convert.

aCC / gcc

When the embedded-Linux world arrived and cross-compiling showed up as an assignment, I found myself prying compilers open again. Mostly I worked past the parser — tweaking hints and code generation, trying various optimizations. That stretch is the one where you fix builds without really knowing why they broke, or why they suddenly work, and you get through it on patience and careful versioning. You’d finally patch something into shape, and then mainline would shift under you and you’d be back to resolving merge conflicts.

At home I ran something called Cygwin, and I patiently put up with an awkward Linux install on a heavy laptop. Later, in grad school, gcc doubled as a hefty benchmark — a popular one for performance work — and judging by how many of those memories are of things not working, I clearly didn’t have the chops yet to do serious development in a world without Google or much of an internet.

The compiler class

I took the compiler course in my junior year, I think. It was part lecture, part the professor’s back-in-my-day stories, with a final exam everyone knew was fixed in advance; it started from parsers, and even at the time there was an argument over whether the course was actually useful. I found it genuinely fun — though I still remember the sting of the professor handing exams back in descending order of score.

Why does this course — or the compiler itself — even exist? The history runs surprisingly deep. As he told it, the technicians who had to work the machines were stuck writing in assembly or machine code, found it unbearably tedious, and so built a product to make the computer do that work for them. It must have been in the making from the old days when a human still made the faster call. And it was around this class that I really began to wonder what I should do next.

Part of 90s Computer Science Stories — first-person notes on growing up with computers and studying CS in Korea in the 1980s and ’90s. See the full series →

Adapted from my Korean essay on Brunch: brunch.co.kr/@chaesang/42