Re-reading Lou Greenaw's “Windows 95 / NT Programming Philosophy”
A small review of the twenty-year-old book was written back in 2016 , published with micro-corrections.
The original confession of the author is called “Zen of Windows 95 Programming”. Let the number “95” not scare you, the key plot is precisely Zen, and not the rapidly changing version numbers of the main operating system of recent decades. The book is a set of recommendations and practices for a vertical (full-stack) developer, allowing not only to survive in the world of modern programming, but also to produce the result of the required quality.
On p. 22, Lou defines the typical reader: “The Zealot of Quality.” For those who in life are quite satisfied with the work according to the methodology "tyap-lyap-commissioning" ("x * yak-x * yak and production"), the book is unlikely to help.
Is the book out of date? At the very beginning, a rapid change in the scene was described in 1995-96, when Windows 95 (to a lesser extent NT) became widespread, the programming interfaces (APIs) changed slightly less than completely, while it turned out to be necessary to maintain the functionality of their programs in three versions at once Microsoft operating systems. At that time, Lou Greenaw himself was thirty years old (p. 87).
Someone complaining about the rapid changes in modern technology? This happened 25 years ago when switching from DOS to Windows, and 20 years ago when changing 16-bit systems to 32-bit ones. Compared to 1995, the current long migration to 64-bit architectures represented the pinnacle of correctness with respect to application programmers fenced off from the inner kitchen of transformations by many layers of abstractions and virtual machines.
The author does not miss a chance to talk about the essence of programming, writing it in the " craft of using a variety of tools in creating levels of abstraction and applying them to solve logical problems ." It would seem that what else is needed for the craft, if not a good cookbook? However, Lou immediately announces (p. 20) that his approach is "talk more about what you should not do “and“ rely on the fact that you will independently judge how to apply this or that advice . ”A little further (p. 48) divides programmers into“ mathematicians ”and“ jewelers ” ".
That is, it’s like a craft. But not quite. And sometimes not at all. In my book I defined software engineering as" an eclectic alloy of technologies that can be used by both lovers of technical creativity and mass-production professionals according to patterns and precedents "however, I do not insist on the interpretation. Programs It is so wide that everyone, if desired, can see and be in him what he wants.
In the introductory part, Lu pragmatically discusses public and private programs (I additionally divide public programs into custom and replicated ones), about the helpfulness of programs, about attitudes towards users, and gives many examples from the category of "horror stories". Then, with a calm heart, she proceeds (p. 63) to the recommendations of the macro level. This includes such topics as localization, global settings with the prospect of their expansion, documentation and the myth of self-documentation, ergonomics and user-friendliness of the interface, testing and reuse of code, functional tests and much more.
The author did not ignore such important topics as the unacceptable neglect of training and education (p. 90) and the need for economic literacy (p. 73) " you must be an economist ."
Comparisons of computer resource requirements are interesting (p. 88). Indeed, if we take, for example, the Windows NT sample of 1996, then for comfortable work with applications (development environment, office, Internet), 16 MB of RAM were required, while the operating system itself needed 8 MB. For Windows 7 or 10 (with the same NT kernel) in 2016, 4 GB of memory is required, of which only 1 GB is used by the OS. The proportion of 1: 2 even dropped to 1: 4. Hence the disappointing conclusion: the problems are not so much in the operating system as in programs.
On page 105, the author smoothly switches to micro-level recommendations. What does Lou see the differences between macro and micro levels? Yes, the fact is that in the absence of design, the programmer immediately goes to the micro level, not even suspecting that the problems pouring into it are largely caused by neglect of macro tasks.
In nature, there are no economists who know only macro- or microeconomics. These are just charlatans. But among those who call themselves programmers, such a quackery is in the order of things!
In the chapter on the micro level, the author also gives a lot of useful tips. I liked this one (p. 109): " Never check for an error that you don’t know how to handle". It may seem that the advice from the series of" harmful "from G. Oster, but this is a false impression. I have come across many times fragments of code such as
rest of the text is devoted to various subjects that are constantly encountered along the path of vertical developers. rye.
On page 147, Lou cites two extreme characteristics of programmers, the Gizmonauts and the Neoluddites. The truth, as usual, is somewhere in between. You can’t choose technologies and tools just because they are new. But it is impossible to rest against horns in old environments and methods if there is a benefit from modernization.
There are some points in the book that seem funny from 2019, for example (p. 154), recommendations for storing hard copies of the sources of their programs. The manuscripts, of course, do not burn, but ...
Despite the fact that the author is a professional C ++ developer, on pages 167-180 Lu gives a lot of reasons for using Delphi " in all new projects ." Indeed, the appearance of Delphi in 1995 was no less revolutionary than the release of the new 32-bit Windows.
Retreating from the book, it is funny in 2019 to hear statements that Delphi is an obsolete product. And that Java or C # is, like - modern environments. Let me remind you that Java appeared only a year, and C # - four years later. For a programmer who began operations somewhere around 2010, all three of these names should look something like Kobol or Fortran.
According to Lou from 1996 (p. 146), a typical situation: a programmer in a hurry makes a mistake, not having time to study alternatives, choosing an unnatural path out of ignorance. For experienced developers in this case, the right decision is to listen to your feelings.
This is Zen programming in any environment. Which I wish you too.
The original confession of the author is called “Zen of Windows 95 Programming”. Let the number “95” not scare you, the key plot is precisely Zen, and not the rapidly changing version numbers of the main operating system of recent decades. The book is a set of recommendations and practices for a vertical (full-stack) developer, allowing not only to survive in the world of modern programming, but also to produce the result of the required quality.
On p. 22, Lou defines the typical reader: “The Zealot of Quality.” For those who in life are quite satisfied with the work according to the methodology "tyap-lyap-commissioning" ("x * yak-x * yak and production"), the book is unlikely to help.
Is the book out of date? At the very beginning, a rapid change in the scene was described in 1995-96, when Windows 95 (to a lesser extent NT) became widespread, the programming interfaces (APIs) changed slightly less than completely, while it turned out to be necessary to maintain the functionality of their programs in three versions at once Microsoft operating systems. At that time, Lou Greenaw himself was thirty years old (p. 87).
Someone complaining about the rapid changes in modern technology? This happened 25 years ago when switching from DOS to Windows, and 20 years ago when changing 16-bit systems to 32-bit ones. Compared to 1995, the current long migration to 64-bit architectures represented the pinnacle of correctness with respect to application programmers fenced off from the inner kitchen of transformations by many layers of abstractions and virtual machines.
The author does not miss a chance to talk about the essence of programming, writing it in the " craft of using a variety of tools in creating levels of abstraction and applying them to solve logical problems ." It would seem that what else is needed for the craft, if not a good cookbook? However, Lou immediately announces (p. 20) that his approach is "talk more about what you should not do “and“ rely on the fact that you will independently judge how to apply this or that advice . ”A little further (p. 48) divides programmers into“ mathematicians ”and“ jewelers ” ".
That is, it’s like a craft. But not quite. And sometimes not at all. In my book I defined software engineering as" an eclectic alloy of technologies that can be used by both lovers of technical creativity and mass-production professionals according to patterns and precedents "however, I do not insist on the interpretation. Programs It is so wide that everyone, if desired, can see and be in him what he wants.
In the introductory part, Lu pragmatically discusses public and private programs (I additionally divide public programs into custom and replicated ones), about the helpfulness of programs, about attitudes towards users, and gives many examples from the category of "horror stories". Then, with a calm heart, she proceeds (p. 63) to the recommendations of the macro level. This includes such topics as localization, global settings with the prospect of their expansion, documentation and the myth of self-documentation, ergonomics and user-friendliness of the interface, testing and reuse of code, functional tests and much more.
The author did not ignore such important topics as the unacceptable neglect of training and education (p. 90) and the need for economic literacy (p. 73) " you must be an economist ."
Comparisons of computer resource requirements are interesting (p. 88). Indeed, if we take, for example, the Windows NT sample of 1996, then for comfortable work with applications (development environment, office, Internet), 16 MB of RAM were required, while the operating system itself needed 8 MB. For Windows 7 or 10 (with the same NT kernel) in 2016, 4 GB of memory is required, of which only 1 GB is used by the OS. The proportion of 1: 2 even dropped to 1: 4. Hence the disappointing conclusion: the problems are not so much in the operating system as in programs.
On page 105, the author smoothly switches to micro-level recommendations. What does Lou see the differences between macro and micro levels? Yes, the fact is that in the absence of design, the programmer immediately goes to the micro level, not even suspecting that the problems pouring into it are largely caused by neglect of macro tasks.
In nature, there are no economists who know only macro- or microeconomics. These are just charlatans. But among those who call themselves programmers, such a quackery is in the order of things!
In the chapter on the micro level, the author also gives a lot of useful tips. I liked this one (p. 109): " Never check for an error that you don’t know how to handle". It may seem that the advice from the series of" harmful "from G. Oster, but this is a false impression. I have come across many times fragments of code such as
try... catchor try... exceptwhere the block catch/exceptwas empty. Because the error sometimes popped up, and the programmer at his micro level didn’t know How to handle it: Not only does this code look awfully ugly, it is also very dangerous, as it leads to unpredictable consequences at other levels of abstraction. The rest of the text is devoted to various subjects that are constantly encountered along the path of vertical developers. rye.
- How to avoid "false negatives" when the program is paranoid in preventing the user from performing any actions (checks like LooksLike () instead of Is ()).
- Separating user interface code from logic. Without casting MVC / MVP spells, the author lists all the advantages of this approach, not forgetting the minuses, which consist primarily of serious additional work.
- Any changes in the framework libraries hang on the programmer the load of their support when changing versions. Quickly resolved adhoc problem turns into a headache when updating the framework.
- About the benefits of binary configuration files and protecting the integrity of the program and its resources.
- Simple rules for using DLLs. It also applies to modern .NET assemblies that are not located in the global cache.
- … and much more
On page 147, Lou cites two extreme characteristics of programmers, the Gizmonauts and the Neoluddites. The truth, as usual, is somewhere in between. You can’t choose technologies and tools just because they are new. But it is impossible to rest against horns in old environments and methods if there is a benefit from modernization.
There are some points in the book that seem funny from 2019, for example (p. 154), recommendations for storing hard copies of the sources of their programs. The manuscripts, of course, do not burn, but ...
Despite the fact that the author is a professional C ++ developer, on pages 167-180 Lu gives a lot of reasons for using Delphi " in all new projects ." Indeed, the appearance of Delphi in 1995 was no less revolutionary than the release of the new 32-bit Windows.
Retreating from the book, it is funny in 2019 to hear statements that Delphi is an obsolete product. And that Java or C # is, like - modern environments. Let me remind you that Java appeared only a year, and C # - four years later. For a programmer who began operations somewhere around 2010, all three of these names should look something like Kobol or Fortran.
According to Lou from 1996 (p. 146), a typical situation: a programmer in a hurry makes a mistake, not having time to study alternatives, choosing an unnatural path out of ignorance. For experienced developers in this case, the right decision is to listen to your feelings.
This is Zen programming in any environment. Which I wish you too.