Slashdot Mirror
Linux Programming by Example
What's To Like There are many things to like about this book (over and above the fact that page 118 has my all-time favourite UserFriendly cartoon on it :-). Linux Programming by Example (LinuxPbE hereafter) takes a steady, incremental path through the concepts required to write software that can effectively interact with the Linux environment.
It is a truism many of us have proven multiple times in our lives that one of the finest learning tools available to programmers is to read and grok good, working code, written in the language that we are learning. LinuxPbE takes this philosophy and walks you through actual example code from various Unixes and Linux. The first part of the book, specifically chapters one through six, covers all of the aspects of Linux programming necessary to understand the Unix V7 ls program in its full glory in chapter seven. I feel that this approach works very well.
Part two dives into processes, walking us through creating them, managing them, communicating with them by using pipes and sending them signals. A few other general topics are included for completeness. Part three then covers the art and tools of debugging in fairly substantial detail.
All the code in the book is very well laid out, with line numbers provided to the left, and comments (in a small sans-serif font) on the right-hand side of the code. This is a very readable combination that is enhanced further by the fact that at each logical division, an explanation is given of the design and implementation used by that section.
I can't resist admiring the addition of the essay "Teach Yourself Programming in Ten Years" by Peter Norvig. This is a classic exploration of the effort needed to attain mastery of any skill, concluding that the minimum length of time required is ten years. The inclusion of this article, to me, speaks well of the author and his understanding of the learning process. One can only hope that those learning from this book will come to the same understanding and realise that the book is the start of their journey to mastering Linux programming.
What's To ConsiderNothing notable.
Summary If you want to learn how to do this stuff for real, then this book will get you started. As "Teach Yourself Programming in Ten Years" explains, no book is going to cause you to become an expert in 24 hours, 24 days or even, perhaps, 24 months. That said, this book will be useful for many of those ten years, so run or surf to your favourite bookstore and purchase it now.You can purchase Linux Programming by Example from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Sheesh, with X you can cut and paste between machines
It would explain how to work nicely with KDE and GNOME and what the differences would be. Also, how to make a robust applicaiton that is easily integrated into both environments. It would explain QT v. GDK. It would explain what I, as a programmer should do to make my application work well with others. It would explain how to make a nice installer. How to detect required packages, What command-line options are standard, what API and hook functions should be available.
Instead of "Learning to Program using LINUX", it would be "Learning to Program FOR LINUX". I would like to know what conventions exist so I would not try to reinvent the wheel.
Most of this is freely available information that is easy enough to find already. But, I would be willing to pay for a one stop shop that would get me started in the right direction.
I have yet to see a book that would be a good getting started guide, and then, a good reference. For now, most projects I start by tinkering and prodding, (which is good too), but I would love to create more powerful applications.
I think you are confusing "powerful" with "high level". C is an extremely powerful language, second only to assembly, in that you can write programs in C to do anything within the capabilities of the underlying hardware. The tradeoff you make when using a relatively low-level language is that many common tasks are a pain in the ass, memory management being one of the obvious examples. But the other side of that tradeoff is that higher level languages make common tasks trivial at the expense of rendering certain less-common tasks difficult or even impossible. The designers of high-level languages are quite conscious of this as is demonstrated by the near-universal provision for interfacing with code written in C.
Power and ease-of-use are not the same thing. Many people use different text editors for programming (vi, emacs) than they do for editing email (pico, joe). Languages are no different.
Proud member of the Weirdo-American community.
Go grab a "Linux" program at random. Any "Linux" program. Cervisia, GIMP, Emacs, bash, Xmms, etc. Funny thing, they all build and run flawlessly on Solaris, FreeBSD, IRIX, etc. Why? Because they're NOT "Linux" programs!
Unless you're writing stuff that depends upon a Linux kernel, you're not doing Linux programming, you're doing standard Unix programming. glibc is nothing more than GNU's libc. And libc is pretty damned standard.
Don't blame me, I didn't vote for either of them!
Nobody masters a language anymore. You master _techniques_. Languages are just syntaxes to implement those techniques.
To put your analogy to use, there's really only so many ways (techniques) to build a cabinet. The different programming languages would be the different tools you use to apply those techniques to build a cabinet.
The nice thing about learning different languages is it often reveals to you new ways of doing things, which you can then apply to languages you already know.
You'd do well to learn Perl or PHP, btw.