Rereading Lou Greenzaw "The philosophy of programming Windows 95 / NT"
A small review of the book of twenty-year excerpt was written in 2016 , publish with mikropravkami.
In the original, the author’s confession is called “Zen of Windows 95 Programming”. Do not be afraid of the figure "95", the key story is exactly Zen, and not the rapidly changing version numbers of the key operating system of the last decades. In modern terms, the book is a set of recommendations and practices for the 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 page 22, Lou defines the typical reader: "A fanatic of quality." For those who, in their lives, are quite satisfied with the work on the “hip-loop” method of operation (“x * yak-x * yak and production”), the book is unlikely to help.
')
Is the book out of date? At the very beginning, the rapid scene change in 1995–96, when Windows 95 (to a lesser extent NT) became widespread, was described, the programming interfaces (APIs) changed slightly less than completely, and it turned out to be necessary to maintain the efficiency of its programs in three versions at once. Microsoft operating systems. Lou Greenzow himself at that time was a little over thirty years old (p. 87).
Someone complains 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 for application programmers, fenced off from the internal 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 various tools in creating levels of abstraction and using them to solve logical problems ." It would seem that what else is needed for the craft, if not a good cookbook? However, Lu immediately declares (p. 20) that his approach is “ to talk more about what you should not do ” and “ rely on the fact that you will judge for yourself how to apply this or that advice ”. A little further (p. 48) divides programmers into “mathematicians” and “jewelers”.
That is, as if craft. But not really. And in places and not at all. In my book, I defined soft engineering as an “ eclectic fusion of technologies that can be used both by technical creativity professionals and mass production professionals using patterns and precedents ”, however, I do not insist on interpretation. Programming is so wide that everyone, if desired, will be able to see and be in him what he wants.
In the introductory part, Lou pragmatically discusses public and private programs (I additionally divide public programs into custom-made and replicable programs), the helpfulness of programs, attitudes towards users, and cites many examples from the category of “horror stories”. Then, with a calm heart, (p. 63) proceeds to macro-level recommendations. This includes such plots as localization, global settings with the prospect of their expansion, documenting and the myth of self-documentation, ergonomics and user-friendliness of the interface, testing and code reuse, functional tests and much more.
The author did not ignore such important topics as the unacceptable neglect of education and training (p. 90) and the need for economic literacy (p. 73) “ you must be an economist ”.
Interesting comparisons of requirements for computer resources (p. 88). Indeed, if you take, for example, the Windows NT model of 1996, then for comfortable work with applications (development environment, office, Internet), 16 MB of RAM was required, while the operating system itself needed 8 MB. Windows 7 or 10 (with the same NT kernel) in 2016 requires 4 GB of memory, 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 the programs.
On page 105, the author smoothly proceeds to micro-level recommendations. Where does Lou see the macro and micro differences? Yes, in the absence of design, the programmer immediately goes to the micro level, not even suspecting that the problems that are flowing in him are largely generated by disregard for macro tasks.
In nature, there are no economists who know only macro or microeconomics. They are just charlatans. But among those who call themselves programmers such 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 (p. 109): " Never check for an error that you don’t know how to handle ." It may seem that the advice from the “harmful” series from G. Oster, but this is a wrong impression. Many times I came across fragments of a code like
The following text is devoted to a variety of subjects that are constantly encountered on the way of vertical developers. I will list only a few.
On page 147, Lou cites two extreme characteristics of programmers, the “hisonauts” and the “non-Luddites”. The truth, as usual, is somewhere in the middle. You can not choose technologies and tools just because they are new. But it is impossible to rest with horns on old environments and methods, if there is a benefit from modernization.
There are some moments in the book that seem funny from 2019, for example (p. 154), recommendations for storing hard copies of the source codes of their programs. Manuscripts, of course, do not burn, but ...
Despite the fact that the author is a professional C ++ developer, on pp. 167-180, Lou cites a lot of reasons for using Delphi " in all new projects ." Indeed, the emergence of Delphi in 1995 was no less revolutionary event than the release of the new 32-bit Windows.
Departing from the book, in 2019, it is amusing to hear claims that Delphi is an outdated product. And that Java or C # is, like, modern environments. I will remind that Java has appeared all year, and C # - four years later. For a programmer who started his activities somewhere in the area of 2010, all three listed names should look something like Cobol or Fortran.
According to Lou from 1996 (p. 146), a typical situation: a programmer in a hurry makes a mistake without having time to study alternatives, choosing an unnatural way through ignorance. For experienced developers in such a case, the right decision is to listen to your feelings.
This is Zen programming in any environment. What you want.
In the original, the author’s confession is called “Zen of Windows 95 Programming”. Do not be afraid of the figure "95", the key story is exactly Zen, and not the rapidly changing version numbers of the key operating system of the last decades. In modern terms, the book is a set of recommendations and practices for the 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 page 22, Lou defines the typical reader: "A fanatic of quality." For those who, in their lives, are quite satisfied with the work on the “hip-loop” method of operation (“x * yak-x * yak and production”), the book is unlikely to help.
')
Is the book out of date? At the very beginning, the rapid scene change in 1995–96, when Windows 95 (to a lesser extent NT) became widespread, was described, the programming interfaces (APIs) changed slightly less than completely, and it turned out to be necessary to maintain the efficiency of its programs in three versions at once. Microsoft operating systems. Lou Greenzow himself at that time was a little over thirty years old (p. 87).
Someone complains 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 for application programmers, fenced off from the internal 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 various tools in creating levels of abstraction and using them to solve logical problems ." It would seem that what else is needed for the craft, if not a good cookbook? However, Lu immediately declares (p. 20) that his approach is “ to talk more about what you should not do ” and “ rely on the fact that you will judge for yourself how to apply this or that advice ”. A little further (p. 48) divides programmers into “mathematicians” and “jewelers”.
That is, as if craft. But not really. And in places and not at all. In my book, I defined soft engineering as an “ eclectic fusion of technologies that can be used both by technical creativity professionals and mass production professionals using patterns and precedents ”, however, I do not insist on interpretation. Programming is so wide that everyone, if desired, will be able to see and be in him what he wants.
In the introductory part, Lou pragmatically discusses public and private programs (I additionally divide public programs into custom-made and replicable programs), the helpfulness of programs, attitudes towards users, and cites many examples from the category of “horror stories”. Then, with a calm heart, (p. 63) proceeds to macro-level recommendations. This includes such plots as localization, global settings with the prospect of their expansion, documenting and the myth of self-documentation, ergonomics and user-friendliness of the interface, testing and code reuse, functional tests and much more.
The author did not ignore such important topics as the unacceptable neglect of education and training (p. 90) and the need for economic literacy (p. 73) “ you must be an economist ”.
Interesting comparisons of requirements for computer resources (p. 88). Indeed, if you take, for example, the Windows NT model of 1996, then for comfortable work with applications (development environment, office, Internet), 16 MB of RAM was required, while the operating system itself needed 8 MB. Windows 7 or 10 (with the same NT kernel) in 2016 requires 4 GB of memory, 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 the programs.
On page 105, the author smoothly proceeds to micro-level recommendations. Where does Lou see the macro and micro differences? Yes, in the absence of design, the programmer immediately goes to the micro level, not even suspecting that the problems that are flowing in him are largely generated by disregard for macro tasks.
In nature, there are no economists who know only macro or microeconomics. They are just charlatans. But among those who call themselves programmers such 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 (p. 109): " Never check for an error that you don’t know how to handle ." It may seem that the advice from the “harmful” series from G. Oster, but this is a wrong impression. Many times I came across fragments of a code like
try... catch or try... except where the catch/except block was empty. Because the error sometimes popped up, but the programmer at his micro level did not know how to handle it. Not only does such code look awfully ugly, it is also very dangerous, as it leads to unpredictable consequences at other levels of abstractions.The following text is devoted to a variety of subjects that are constantly encountered on the way of vertical developers. I will list only a few.
- How to avoid “false negatives” when the program paranoidly prevents the user from performing any actions (checks like LooksLike () instead of Is ()).
- Separate user interface code from logic. Without casting MVC / MVP spells, the author lists all the advantages of this approach, not forgetting the disadvantages, which consist, first of all, in serious additional work.
- Any changes in the framework libraries hang on the programmer the weight of their support when changing versions. The adhoc problem quickly resolved turns into a headache when updating the framework.
- The benefits of binary configuration files and the protection of the integrity of the program and its resources.
- Simple rules for using a DLL. 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 “hisonauts” and the “non-Luddites”. The truth, as usual, is somewhere in the middle. You can not choose technologies and tools just because they are new. But it is impossible to rest with horns on old environments and methods, if there is a benefit from modernization.
There are some moments in the book that seem funny from 2019, for example (p. 154), recommendations for storing hard copies of the source codes of their programs. Manuscripts, of course, do not burn, but ...
Despite the fact that the author is a professional C ++ developer, on pp. 167-180, Lou cites a lot of reasons for using Delphi " in all new projects ." Indeed, the emergence of Delphi in 1995 was no less revolutionary event than the release of the new 32-bit Windows.
Departing from the book, in 2019, it is amusing to hear claims that Delphi is an outdated product. And that Java or C # is, like, modern environments. I will remind that Java has appeared all year, and C # - four years later. For a programmer who started his activities somewhere in the area of 2010, all three listed names should look something like Cobol or Fortran.
According to Lou from 1996 (p. 146), a typical situation: a programmer in a hurry makes a mistake without having time to study alternatives, choosing an unnatural way through ignorance. For experienced developers in such a case, the right decision is to listen to your feelings.
This is Zen programming in any environment. What you want.
Source: https://habr.com/ru/post/452946/
All Articles