I came across the book, Beautiful Code: Leading Programmers Explain How They Think (Theory in Practice (O'Reilly)), several months ago and was immediately intrigued. Could this be a book to do so much of what I want to achieve here? In short, no. The editors want us to read thirty or so examples and learn something about what makes code beautiful. In principle, I can agree with this thesis, as I have learned a lot about writing better code from reading what others have programmed.
The book provides 33 chapters, the shortest is 6 pages and the longest is over 30. And the quality is inversely proportional to the length. The shorter contributions are far more likely to achieve their goal of demonstrating beauty in programs, as their programs are more self evidently beautiful. Short contributions just need fewer pages for their beauty. Thus in reading 550 pages, one will find long sections of slow development to reach an uncertain conclusion as to the quality of a contributor's code, punctuated by shorter gems of programming.
To compound the difficulties in reading, I have yet to discern the method to the organization of the chapters. Programmers use a wide variety of languages and the book is no different. For example, the chapters using Fortran were skipped due in part from my lack of knowledge of the language. Yet the final chapter used Lisp and was rather interesting, even though I have virtually no experience with it either. But that chapter succeeds because the point is not based in the language, and changing its examples to pseudo-code would be just as workable.
To conclude, the premise is still valid. And so I will remain hopeful for a future rewrite that discards about 20 chapters and provides some degree of transition between each. Perhaps even confining the languages down to a handful, but just deciding this might be intractable.
No comments:
Post a Comment