Dan Gookin - Tiny C Projects

Every time I read that C is becoming obsolete, another article pops up on how C continues to be one of the most popular, in-demand programming languageseven as it passes its 50th birthday. Disparagement aside, C is the primary language used for system programming, networking, gaming, and coding microcontrollers. Even those trendy languages that the cool kids boast about most likely have their core originally written in C. Its not going away any time soon.

I often refer to C as the Latin of computer programming languages. Its syntax and even a few keywords are borrowed heavily by other languages. Just as knowing Latin helps you understand and learn French, Italian, Spanish, and other languages, knowing C allows you to easily understand and learn other programming languages. But dont stop there! Honing your C skills is just as important as exercising a muscle. And what better way to work on and perfect your C programming abilities than to continually write small, useful programs?

I feel the best way to learn programming is to use small demonstration programs. Each one focuses on a specific part of the language. The code is short and easy to type, and it drives home a point. If the little program can do something impressive, inspiring, or silly, all the better.

My approach contrasts with other programming books Ive read. These tedious tomes often list a single, huge program that drives home all the concepts. Typing 100 lines of code when you have no clue whats going on is discouraging, and it misses one of the more delightful aspects of programming: instant feedback.

Somehow, the habit of writing tiny programs sticks with me, even beyond when Im writing a C programming book or teaching an online C programming course. For years, Ive been coding tiny programs on my blog at https://c-for-dummies.com/blog . I do so to provide supplemental material for my readers and learners, but also because I enjoy coding.

Of course, to make small programs meaningful, they must dwell in the ancient command-line, text-mode environment. Graphics are limited. Animation is dull. The excitement, however, remainsespecially when something useful is presented all within only a few lines of code.

My approach echoes the way I code: start small and grow the code. So, the programs in this book may begin as only a dozen lines of code that output a simple message. From there the process expands. Eventually a useful program emerges, all while remaining tiny and tight and teaching something useful along the way.

Who knows when the mood will hit you and you decide to code a handy command-line utility to improve your workflow? With a knowledge of C programming, the desire, and a few hours of your time, you can make it happen. Its my hope that this book provides you with ample inspiration.

I set out to be a fiction author. At one point, I was engaged in personal correspondence with a magazine editor who liked my stuff, but nothing was ever published. Then along came a job at a computer book publishing house, CompuSoft. There I combined my self-taught skills in programming with my love of writing to help craft a series of technical books. It was there I learned how to write for beginners and inject humor in the text.

Six years and 20 titles later, I wrote DOS For Dummies, which revolutionized the computer book publishing industry. This book showed that technological titles could successfully impart information to a beginner by using humor. The entire industry changed, and the For Dummies phenomenon continues to this day.

Computer books have diminished as an industry, thanks to the internet and humanitys disdain for reading printed material. Still, its been a great journey and I have many people to thank: Dave Waterman, for hiring me at CompuSoft and teaching me the basics of technical writing; Bill Gladstone and Matt Wagner, for being my agents; Mac McCarthy, for the insane idea of DOS For Dummies; and Becky Whitney, for being my long-time, favorite editor. She has taught me more about writing than anyoneor perhaps just taught me how to write in a way that makes her job as editor easy. I appreciate all of you.

Finally, to all the reviewers: Adam Kalisz, Adhir Ramjiawan, Aditya Sharma, Alberto Simes, Ashley Eatly, Chris Kolosiwsky, Christian Sutton, Clifford Thurber, David Sims, Glen Sirakavit, Hugo Durana, Jean-Franois Morin, Jeff Lim, Joel Silva, Joe Tingsanchali, Juan Rufes, Jura Shikin, K. S. Ooi, Lewis Van Winkle, Louis Aloia, Maciej Jurkowski, Manu Raghavan Sareena, Marco Carnini, Michael Wall, Mike Baran, Nathan McKinley-Pace, Nitin Gode, Patrick Regan, Patrick Wanjau, Paul Silisteanu, Phillip Sorensen, Roman Zhuzha, Sanchir Kartiev, Shankar Swamy, Sriram Macharla, and Vitosh Doynov, your input helped make this a better book.