DDJ书评(2003.11):Unix Zen and Now(有 The Art of Unix Programming)

Review by Jack J. Woehr
Copyright (C) Dr. Dobb's Journal, November, 2003

The white-robed roshi and juvenile shaved-head monk on the cover suggest that Eric Raymond probably intended to call his book “The Zen of UNIX Programming.” Cooler editorial heads prevailed and we ended up with The Art of UNIX Programming.

Though Raymond covers everything from operating-system origins (including IBM/VM and DEC VMS) and HTTP, C, Lisp, and C++, to Docbook and CVS (and every blessed thing beyond and between), The Art of UNIX Programming is not a tutorial.

Raymond rambles through a bizarre exposition of what he finds to be the “kozmik trooths” of the UNIX programming environment. If you’re actually trying to learn UNIX programming, this is the wrong book. To the extent the book has focus, the focus is something like this:

Eric drove the Reader’s chariot out onto the Field of UNIX. They stood for a while between the two armies of the Ideal and the Necessary. The Reader threw down his keyboard and said, "I shall not fight!" Eric then expounded the True Nature of the Programming Field, the Knower and the Known. The Reader, now wiser, picked up his keyboard afresh and coded on.

In case you think I’m stretching the point, here are a few headings—just a few, mind you—to give you some of the savor of the opus:

  • TCP/IP and the UNIX Wars: 1980–1990
  • Blows Against the Empire: 1991–1995
  • Case Study: C Considered as Thin Glue
  • Security Wrappers and Bernstein Chaining
  • Case Study: Metaclass Hacking in fetchmailconf.
  • The “Separated Engine and Interface” Pattern
  • The Present Chaos and the Possible Way Out

The book is always informative, albeit in a patchwork fashion. Raymond palms off metaphysics as computer science and confounds aesthetics with epistemology as well as any of us FORTH programmers did a couple of decades ago. He also manages to broaden the reader’s perspective, in a critique that sports a literary sheen. It would be a more intellectually uplifting workplace if more gifted programmers were as erudite as Raymond, though it is possible in that case that less actual work would be performed.

The Art of UNIX Programming settles down around Chapter 14 (Languages) or 15 (Tools), and starts giving some practical programming advice. In this book much is true and much is good. The reading of it does serve to stimulate the imagination and the pride of communal ownership of the UNIX Ideal.

In contrast, UNIX Systems Programming: Communication, Concurrency and Threads, by Kay Robbins and Steven Robbins, is not at all a fanciful book. It’s about How. To. Program. UNIX. Emphasis on multiprogramming.

UNIX Systems Programming is as dry as (or drier than) a Sun Microsystems manual, and typeset identical to Sun publications, just in case the point was otherwise missed. It’s the second edition of the 1995 opus Practical UNIX Programming: A Guide to Communication, Concurrency and Multithreading. We’re informed in the Preface that the title was changed “to better convey [sic] what the book was [sic] about.”

UNIX Systems Programming is nerdly arcana for corporate staff programmers. That’s why I was surprised the authors missed an important point about threading. Thread implementations are mined with guarantees that functions will appear in libraries whether they have the desired effect or not. The function pthread_attr_setschedpolicy() has tripped up programmers before: POSIX insists it appear in a compatible library without demanding that it actually perform its specified work. Solaris pthread programmers know to #ifdef for Solaris and use the nonportable platform function thr_setconcurrency().

UNIX Systems Programming is detailed, indexed, cross referenced, generally accurate, useful, enduring, attractive, and hardbound. If you do serious UNIX programming and do not yet have a complete overview of pipes and/or sockets and/or exec calls and/or POSIX threads, this book is a good bet, but a close perusal of your system manuals will still be necessary.

Absolute OpenBSD: UNIX for the Practical Paranoid, by Michael Lucas, is the book all newbies exploring one of the free or open-source community’s most secure and austere operating systems have long demanded. It is the “missing manual” to obtaining, installing, using, and administering OpenBSD. Much of this information can be gleaned from the FAQs at the OpenBSD web site (http://www.openbsd.org/) and all of it has been asked, over and over again, on the mailing lists. Absolute OpenBSD is nicely written, organized in the order newbies need during install, cleanly laid out, and well indexed. New users should buy the book at the same time they buy the OpenBSD distribution CD. Because, if it’s half as good as I’m saying it is, Absolute OpenBSD will save newbies weeks of anguished whining on the mailing lists.

The Art of UNIX Programming
Eric S. Raymond
Addison-Wesley, 2003
512 pp., $39.99
ISBN 0-13-142901-9

UNIX Systems Programming: Communication, Concurrency And Threads, Second Edition
Kay A. Robbins and Steven Robbins
Prentice Hall, 2003
912 pp., $69.99
ISBN 0-13-042411-0

Absolute OpenBSD: UNIX for the Practical Paranoid
Michael W. Lucas
No Starch Press, 2003
600 pp., $39.95
ISBN 1-886411-99-9

  • 0
  • 1
  • 0
  • 一键三连
  • 扫一扫,分享海报

超级经典!!! The Art of Unix Programming Eric Steven Raymond Table of Contents 目录 Requests for reviewers and copy-editors Preface Who Should Read This Book How To Use This Book Related References Conventions Used In This Book Our Case Studies Author's Acknowledgements I. Context 1. Philosophy Culture? What culture? The durability of Unix The case against learning Unix culture What Unix gets wrong What Unix gets right Open-source software Cross-platform portability and open standards The Internet The open-source community Flexibility in depth Unix is fun to hack The lessons of Unix can be applied elsewhere Basics of the Unix philosophy Rule of Modularity: Write simple parts connected by clean interfaces. Rule of Composition: Design programs to be connected with other programs. Rule of Clarity: Clarity is better than cleverness. Rule of Simplicity: Design for simplicity; add complexity only where you must. Rule of Transparency: Design for visibility to make inspection and debugging easier. Rule of Robustness: Robustness is the child of transparency and simplicity. Rule of Least Surprise: In interface design, always do the least surprising thing. Rule of Repair: Repair what you can — but when you must fail, fail noisily and as soon as possible. Rule of Economy: Programmer time is expensive; conserve it in preference to machine time. Rule of Generation: Avoid hand-hacking; write programs to write programs when you can. Rule of Representation: Use smart data so program logic can be stupid and robust. Rule of Separation: Separate policy from mechanism; separate interfaces from engines. Rule of Optimization: Prototype before polishing. Get it working before you optimize it. Rule of Diversity: Distrust all claims for one true way. Rule of Extensibility: Design for the future, because it will be here sooner than you think. The Unix philosophy in one lesson Applying the Unix philosophy Attitude matters too 2. History Origins and history of Unix, 1969-1995 Genesis: 1969-1971 Exodus: 1971-1980 TCP/IP and the Unix Wars: 1980-1990 Blows against the empire: 1991-1995 Origins and history of the hackers, 1961-1995 At play in the groves of academe: 1961-1980 Internet fusion and the Free Software Movement: 1981-1991 Linux and the pragmatist reaction: 1991-1998 The open-source movement: 1998 and onward. The lessons of Unix history 3. Contrasts The elements of operating-system style What is the unifying idea? Cooperating processes Internal boundaries File attributes and record structures Binary file formats Preferred UI style Who is the intended audience? What are the entry barriers to development? Operating-system comparisons VMS Mac OS OS/2 Windows NT BeOS Linux What goes around, comes around II. Design 4. Modularity Encapsulation and optimal module size Compactness and orthogonality Compactness Orthogonality The DRY rule The value of detachment Top-down, bottom-up, and glue layers Case study: C considered as thin glue Library layering Case study: GIMP plugins Unix and object-oriented languages Coding for modularity 5. Textuality The Importance of Being Textual Case study: Unix password file format Case study: .newsrc format Case study: The PNG graphics file format Data file metaformats /etc/passwd style RFC-822 format Fortune-cookie format XML Windows INI format Unix textual file format conventions Application protocol design Case study: SMTP, a simple socket protocol Case study: POP3, the Post Office Protocol Case study: IMAP, the Internet Message Access Protocol Application protocol metaformats The classical Internet application metaprotocol HTTP as a universal application protocol BEEP XML-RPC. SOAP, and Jabber Binary files as caches 6. Multiprogramming Separating complexity control from performance tuning Handing off tasks to specialist programs Case study: the mutt mail user agent. Pipes, redirection, and filters Case study: Piping to a Pager Case study: making word lists Case study: pic2graph Case study: bc(1) and dc(1) Slave processes Case study: scp(1) and ssh Wrappers Case study: backup scripts Security wrappers and Bernstein chaining Peer-to-peer inter-process communication Signals System daemons and conventional signals Case study: fetchmail's use of signals Temp files Shared memory via mmap Sockets Obsolescent Unix IPC methods Client-Server Partitioning for Complexity Control Case study: PostgreSQL Case study: Freeciv Two traps to avoid Remote procedure calls Threads — threat or menace? A fearful synergy 7. Transparency Some case studies Case study: audacity Case study: fetchmail's -v option Case study: kmail Case study: sng Case study: the terminfo database Case study: Freeciv data files Designing for transparency and discoverability The Zen of transparency Coding for transparency and discoverability. Transparency and avoiding overprotectiveness. Transparency and editable representations. Transparency, fault diagnosis, and fault recovery Designing for maintainability 8. Minilanguages Taxonomy of languages Applying minilanguages Case study: sng Case study: Glade Case study: m4 Case study: XSLT Case study: the DWB tools Case study: fetchmailrc Case study: awk Case study: PostScript Case study: bc and dc Case study: Emacs Lisp Case study: JavaScript Designing minilanguages Choosing the right complexity level Extended and embedded languages When you need a custom grammar Macros — beware! Language or application protocol? 9. Generation Data-driven programming Regular expressions Case Study: ascii Case Study: metaclass hacking in fetchmailconf Ad-hoc code generation Case study: generating code for a fixed screen display Case study: generating HTML code for a tabular list Special-purpose code generators Yacc and Lex Glade Avoiding traps 10. Configuration Run-control files Case study: The .netrc file Portability to other operating systems Environment variables Portability to other operating systems Command-line options The a to z of command-line options Portability to other operating systems How to choose among configuration-setting methods Case study: fetchmail Case study: the XFree86 server On breaking these rules 11. Interfaces Applying the Rule of Least Surprise History of interface design on Unix The right style for the right job Tradeoffs between CLI and visual interfaces Case study: Two ways to write a calculator program Unix interface design patterns The filter pattern The cantrip pattern The emitter pattern The absorber pattern The compiler pattern The ed pattern The rogue pattern The ‘separated engine and interface’ pattern The CLI server pattern Language-based interface patterns Applying Unix design patterns The polyvalent-program pattern The Web browser as universal front end Silence is golden III. Implementation 12. Languages Unix's Cornucopia of Languages Why Not C? Interpreted Languages and Mixed Strategies Language evaluations C C++ Shell Perl Tcl Python Java Emacs Lisp Trends for the Future Choosing an X toolkit 13. Tools A developer-friendly operating system Choosing an editor vi: lightweight but limited Emacs: heavy metal editing The benefits of knowing both Is Emacs an argument against the Unix philosophy? Make: automating your development recipes Basic theory of make(1) Make in non-C/C++ Development Utility productions Generating makefiles Version-control systems Why version control? Version control by hand Automated version control Unix tools for version control Run-time debugging Profiling Emacs as the universal front end Emacs and make(1) Emacs and run-time debugging Emacs and version control Emacs and Profiling Like an IDE, only better... 14. Re-Use The tale of J. Random Newbie Transparency as the key to re-use From re-use to open source The best things in life are open Where should I look? What are the issues in using open-source software? Licensing issues What qualifies as open source Standard open-source licenses When you need a lawyer Open-source software in the rest of this book IV. Community 15. Portability Evolution of C Early history of C C standards Unix standards Standards and the Unix wars The ghost at the victory banquet Unix standards in the open-source world IETF and the RFC standards process Specifications as DNA, code as RNA Programming for Portability Portability and choice of language Avoiding system dependencies Tools for portability Portability, open standards and open source 16. Documentation Documentation concepts The Unix style Technical background Cultural style The zoo of Unix documentation formats troff and the DWB tools TeX Texinfo POD HTML DocBook The present chaos and a possible way out DocBook Document Type Definitions Other DTDs The DocBook toolchain Migration tools Editing tools Related standards and practices SGML XML-Docbook References How to write Unix documentation 17. Open Source Unix and open source Best practices for working with open-source developers Good patching practice Good project- and archive- naming practice Good development practice Good distribution-making practice Good communication practice The logic of licenses: how to pick one Why you should use a standard license Varieties of Open-Source Licensing X Consortium License BSD Classic License Artistic License General Public License Mozilla Public License 18. Futures Essence and accident in Unix tradition Problems in the design of Unix A Unix file is just a big bag of bytes File deletion is forever The Unix API doesn't use exceptions ioctl(2) and fcntl(2) are an embarrassment The Unix security model may be too primitive Unix has too many different kinds of names for things File systems might be considered harmful Problems in the environment of Unix Problems in the culture of Unix Reasons to believe A. Glossary of Abbreviations B. References C. Contributors
作者:Eric Steven Raymond 副书名:unix编程艺术英文版 出版日期:2003 出版社:其它 页数:549 ISBN:9780131429017 文件格式:CHM 书籍简介 Dedication To Ken Thompson and Dennis Ritchie, because you inspired me. Preface Unix is not so much an operating system as an oral history. – NealStephenson There is a vast difference between knowledge and expertise. Knowledge lets you deduce the right thing to do; expertise makes the right thing a reflex, hardly requiring conscious thought at all. This book has a lot of knowledge in it, but it is mainly about expertise. It is going to try to teach you the things about Unix development that Unix experts know, but aren’t aware that they know. It is therefore less about technicalia and more about shared culture than most Unix books — both explicit and implicit culture, both conscious and unconscious traditions. It is not a ‘how-to’ book, it is a ‘why-to’ book. The why-to has great practical importance, because far too much software is poorly designed. Much of it suffers from bloat, is exceedingly hard to maintain, and is too difficult to port to new platforms or extend in ways the original programmers didn’t anticipate. These problems are symptoms of bad design. We hope that readers of this book will learn something of what Unix has to teach about good design. This book is divided into four parts: Context, Design, Tools, and Community. The first part (Context) is philosophy and history, to help provide foundation and motivation for what follows. The second part (Design) unfolds the principles of the Unix philosophy into more specific advice about design and implementation. The third part (Tools) focuses on the software Unix provides for helping you solve problems. The fourth part (Community) is about the human-to-human transactions and agreements that make the Unix culture so effective at what it does. Because this is a book about shared culture, I never planned to write it alone. You will notice that the text includes guest appearances by prominent Unix developers, the shapers of the Unix tradition. The book went through an extended public review process during which I invited these luminaries to comment on and argue with the text. Rather than submerging the results of that review process in the final version, these guests were encouraged to speak with their own voices, amplifying and developing and even disagreeing with the main line of the text. In this book, when I use the editorial ‘we’ it is not to pretend omniscience but to reflect the fact that it attempts to articulate the expertise of an entire community. Because this book is aimed at transmitting culture, it includes much more in the way of history and folklore and asides than is normal for a technical book. Enjoy; these things, too, are part of your education as a Unix programmer. No single one of the historical details is vital, but the gestalt of them all is important. We think it makes a more interesting story this way. More importantly, understanding where Unix came from and how it got the way it is will help you develop an intuitive feel for the Unix style. For the same reason, we refuse to write as if history is over. You will find an unusually large number of references to the time of writing in this book. We do not wish to pretend that current practice reflects some sort of timeless and perfectly logical outcome of preordained destiny. References to time of writing are meant as an alert to the reader two or three or five years hence that the associated statements of fact may have become dated and should be double-checked. Other things this book is not is neither a C tutorial, nor a guide to the Unix commands and API. It is not a reference for sed or yacc or Perl or Python. It’s not a network programming primer, nor an exhaustive guide to the mysteries of X. It’s not a tour of Unix’s internals and architecture, either. Other books cover these specifics better, and this book points you at them as appropriate. Beyond all these technical specifics, the Unix culture has an unwritten engineering tradition that has developed over literally millions of man-years1 of skilled effort. This book is written in the belief that understanding that tradition, and adding its design patterns to your toolkit, will help you become a better programmer and designer. Cultures consist of people, and the traditional way to learn Unix culture is from other people and through the folklore, by osmosis. This book is not a substitute for person-to-person acculturation, but it can help accelerate the process by allowing you to tap the experience of others.
©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页
钱包余额 0