84 Books Like Software Tools in Pascal

Modern Unix systems (including Linux) offer a wealth of APIs. This book provides detailed instruction, including sample code, on how to make the best use of them. It is a one-stop-shop for mastering the details of Unix programming in C.

I recommend the book because it is thorough, authoritative, and clearly written. Richard Stevens was a well-known author and consultant and his books are models of clear exposition. Steven Rago is an experienced Unix developer and author as well.

The previous books all cover programming at the user level – how to write regular programs for a Unix / Linux system. But what about the operating system itself?

This classic work explains the operating system code of the 6th Edition Unix system, which ran on Digital Equipment Corporation (DEC) PDP-11 systems. If you want to learn the basics of operating system implementation by reading real, working code, this is the place to start.

This is worth reading, even if you never intend to write kernel code, since an understanding of how the operating system works makes it easier for you to correctly use the system calls (APIs) that the operating system provides.

This book looks at UNIX System V Release 2 and Release 3, describing a more modern version of Unix.  It presents pseudo code of the internal algorithms with diagrams of the major data structures used by the system.

Here too, knowing how the operating system works will help you write better code to take advantage of the services provided to you.

Supposedly, Linus Torvalds read this book before he produced the first Linux kernel!

Next to Fred Brooks' The Mythical Man-Month, this is perhaps the most classic of all classic programming books.

The authors write: "Besides showing how to make effective use of the language, we have also tried where possible to illustrate useful algorithms and principles of good style and sound design."

The book is astoundingly practical as a tutorial, which is itself a testament to the Unix "pipe" model of programming: By page 13, they've introduced getchar and putchar, and by the end of Chapter 1, twenty pages later, you've implemented a host of useful utilities including cat, wc, and detab. In Chapter 5 you implement a function recognizable as the now-standard qsort; in Chapter 8 you implement malloc itself.

Now, I recommend "K&R1," not the more popular "K&R2." The first edition was issued in 1978 at a slim 225 pages; the second edition, a decade later, added conformance with ANSI… show more.

This tour de force probably couldn't get written today. Kernighan and Plauger take snippets of Fortran and PL/I code from real, published textbooks and find things to fix about them. Now, many of their specific concerns are relics of the "structured programming" wars of the 1960s (overuse of arithmetic IF and GOTO) or quirks of the programming languages in question (undeclared variables silently getting the wrong type); but this is educational in itself. If you wonder what's so bad about GOTO, or why we need to declare functions and variables before use, this book may enlighten you. And despite its age, almost every example finds some present-day analog. For example, Kernighan and Plauger's advice to avoid manually counted Hollerith strings in Fortran applies equally to manually counted array bounds in C++: don't write "int a[5]" when you can write "int a[]". The authors boil every couple of pages down to… show more.

When people think about software engineering they mostly think about programming, but that’s not where a project starts. It starts with requirements.

(Really it sometimes starts with company politics, bickering, excuses, and backstabbing, but requirements gathering is often the official start.)

A good set of requirements keeps developers pulling in the same direction; a bad one can make the team inefficient, cause endless arguments, set developers against each other, and make the project feel like Lord of the Flies. I’ve seen projects scrapped and restarted from scratch or even canceled due to poor documentation.

Every software developer should know at least a little about writing so they can produce clear requirements and documentation.

This book isn’t specifically about writing documentation (which is something of an art in itself), but it can help you learn how to make your business writing more effective. This book won’t turn you into Shakespeare,… show more.

Software engineering involves several phases such as requirements gathering, design, programming, testing, and deployment.

This book explains techniques that allow you to build quality and robustness into every phase of the process. It discusses design, classes, defensive programming, collaboration, refactoring, and more.

The book uses many examples in an assortment of languages but the concepts apply to any programming language. In fact, the main themes like building error detection into every step of the process generalize to even non-programming parts of the development process.

If you’re an experienced developer, you may have discovered some of this book’s ideas elsewhere or even on your own, but you only need to pick up one or two new tidbits to make the book worthwhile.

Okay, hear me out. Yes, this book was published in 2007. Yes, it’s ostensibly about ActionScript, the coding language in Flash, which no one uses anymore. But you won’t use this book to learn ActionScript or Flash: You’ll use it to learn how to make things move with code, in any language. You’ll skip over the ActionScript-specific parts in favor of the lucid explanations and helpful illustrations. Your visual brain will appreciate seeing how sines, cosines, and tangents are relevant—and necessary!—to make digital things move. (Your heart will wish your brain had paid better attention in trigonometry class years earlier, but hey, no regrets!) The chapters “Trigonometry for Animation” and “Velocity and Acceleration” alone are worth the purchase price.

This book is essential in that it follows a systematic and scientific approach to software development, advocating for clarity in expressing algorithms, providing a rigorous framework for designing and reasoning about programs, and, fundamentally, always focusing on formal methods and mathematical techniques to ensure correctness and efficiency in programming code.

Most importantly, the book doesn’t just show you how to prove programs correct, but also teaches how to arrive from a definition to an efficient and correct solution, so I would recommend this to every developer.

Robert Glass is one of the foundational leaders of the discipline of software engineering. He’s done it all and seen it all. This book includes 55 facts and 10 fallacies about many aspects of software engineering, grouped into the major categories of management, the life cycle, and quality. Based on my own experience, I can vouch for the validity of all the points Glass makes.

These timeless truths can help you avoid going down an ineffective path, wasting time only to rediscover the same facts on your own. There’s no need to retrace the missteps from the past. Books like this can keep your energies focused where they will provide the most value to your customers.