Not in the usual sense as worshiping the memory of someone deceased or something passed. Here is the full blown religion of Memory with its own philosophical foundation called memoidealism:
This is a case when powerful software metaphors provide novel insights into Nature.
- Dmitry Vostokov @ SoftwareGeneralist.com -
Comments in italics are mine and express my own views, thoughts and opinions
Developer’s Guide to Debugging by M. Wloka, et al.:
Memory debugger vs. general debugger (p. 33)
The missing code as a bug (p. 34)
Valgrind examples (pp. 36 - 39) - Gflags, Application and Driver Verifiers are analogs of memory debuggers in Windows world. Also Visual Studio and MFC runtime have capabilities to detect various classes of memory errors
Increased resource consumption when using memory debuggers (p. 42) - this is true when full page is enabled on Windows or user mode stack trace DB
Notion of non-standard memory handlers to curcumvent bugs in dynamic memory usage (pp. 42 - 43) - skip free/delete and release all heap at once at the end - I used this 
Concurrent Programming on Windows by J. Duffy:
Data publication / privatization via transfer of ownership (p. 33)
Assume that received references via parameters or function arguments are shared by default (p. 34)
Shallow vs. deep immutability (p. 34)
SSA - Static Single Assignment (p. 34) - uses of C++ const for SSA enforcement (p. 38)
Dynamic Single Assignment Verification (p. 38)
Distinction between data vs. control synchronization (pp. 38 - 39)
Critical region as serialized sequence of operations (p. 40)
Code- vs. data-centric critical regions (p. 42)
Semaphore as a generalization of a critical region (p. 42) that allows N threads to enter that region (counting semaphore)
Mutex as critical region with N == 1 - binary semaphore (p. 42)
Software Factories by J. Greenfield, et. al.:
This book I bought a few years ago and just started reading mainly because of my current work on DebugWare: The Art and Craft of Writing Troubleshooting and Debugging Tools book where I advocate a Software Tool Factory approach.
The book is written by architects of Visual Studio Team System (from backcover)
Root causes of software problems: monolithic construction, excessive generality, on-off development and process immaturity (p. xvii)
Solution: integration of languages, patterns, frameworks and tools (p. xvii)
Broad horizontal domains (p. xvii) - troubleshooting and debugging is one of them
SF provides unique variants of an archetypical product (p. xviii) - unique special debugging tools as variants of an ultimate debugging tool
- Dmitry Vostokov @ SoftwareGeneralist.com -
The subtitle of this blog has changed from “All you need to know to become a successful software engineer” to “Connecting Software with Engineering, Science, Philosophy and Religion” to reflect the shift in content towards the broader spectrum of topics since its foundation almost a year ago. The original idea to provide short independent survey articles about various aspects of software engineering now becomes one of categories of posts on this blog.
- Dmitry Vostokov @ SoftwareGeneralist.com -
This is a new book planned by OpenTask with the some preliminary details:
The Variety of Software: The Richness of Computation (ISBN: 978-1906717544)
- Dmitry Vostokov @ SoftwareGeneralist.com -
He was a co-editor of Encyclopédie together with Diderot. His views about reality were rational. Being a mathematician he strongly defended the view of mathematics as an ideal form of knowledge and considered physics as a base science. (*) The modern view of mathematics as an ideal form of software and physics as a knowledge base of hardware makes Jean le Rond d’Alembert (1717 - 1783) stand as one of the early software scientists and philosophers.
(*) The Oxford Companion to Philosophy, 2nd edition, p. 188
- Dmitry Vostokov @ SoftwareGeneralist.com -
“We all hold philosophical beliefs” (*). Where did software come from? Is it real? Can it evolve into some sort of intelligence? If yes, do we have a moral right to abort some projects which may lead in the future to intelligent software forms? Would it be software like we define it today or it finally evolves into something new? Where and when there is a line dividing intelligent and non-intelligent software? What about killing a running instance of software or shutting down its hardware? Are we some sort of software too? If software is real does it more real than we are? Did software exist before us? Is there any software God or gods? Can we consider ourselves as software gods? Freedom of software and its output, perhaps in some distant future? These are fundamental questions that come to a mind of any philosophically inclined software engineer or a computer scientist. And most answers to them require to take a certain philosophical stance and hold beliefs not possible to verify or test at the moment.
(*) Philosophy, by S. Law, p. 14-15
- Dmitry Vostokov @ SoftwareGeneralist.com -
No reading today, only planning a pocket book as a selection of expanded, edited and commented posts with philosophical inclinations:
Software and Philosophy: An Anthology of Metaphorical Bijections (ISBN: 978-1906717513)
- Dmitry Vostokov @ SoftwareGeneralist.com -
According to Cardinal Thomas de Vio Cajetan we proportionally qualify God and its creatures as “good” (*). For example, God is more “good” than its creations. The same proportionality exists between finite software creations and their infinite (in comparison) creators. Can be software more “good” than its creator? Quite possible… But more often it is the other way around. In the software world this problem is also complicated by the difference between software components and their execution, a one to many relationship. Therefore, when we talk about “this good software product”, do we refer unequivocally to specific instances of software execution, all possible executions or software creators?
(*) The Oxford Companion to Philosophy, 2nd edition, p. 119
- Dmitry Vostokov @ SoftwareGeneralist.com -
Comments in italics are mine and express my own views, thoughts and opinions
Developer’s Guide to Debugging by M. Wloka, et al.:
Seems the book doesn’t mention Debugging Tools for Windows and WinDbg at all but this is circumvented by the authors’ blog featuring a link and related books. The book uses GDB (primary) and Visual Studio debugger (secondary) for examples.
Larger object files with debug information - Visual C++ can store debugging symbols in separate PDB files
Basic GDB commands (pp. 25-30)
Debugger expression evaluation feature (p. 30) - caught my attention and got a vision of using it for tracking pre-, post-conditions and method invariants
Concurrent Programming on Windows by J. Duffy:
Serialized threads (p. 25)
Data race (p. 26)
Stale read and unrepeatable read (p. 28). The latter happens when a second thread reads too early.
Serializability is not sufficient for correctness. Serialization orders must be legal - need for critical regions (p. 30)
Linearization points - when a batch atomic updates are visible to other threads (p. 30)
CLR AppDomains as intra-process isolation (p. 32)
Cache as an isolated state of master copy (p. 32)
Isolation by convention (p. 32) - commonplace, reminds me guidelines for ownership of COM interfaces
- Dmitry Vostokov @ SoftwareGeneralist.com -
The same process suddenly reveals a different law (*). Although in the preceding definition the notion of a process should be taken generally, in the software world it often happens when a running process or an operating system suddenly exhibits all sorts of strange, sudden and unexplainable behaviour after some time or when running in a different environment. Here we can consider an environment as a sort of law under which a process operates (Chambers) or a process output and interaction as a law (Babbage). As a consequence of this we can never know whether our program crashes or hangs in the future.
(*) The Oxford Companion to Philosophy, 2nd edition, p. 76
- Dmitry Vostokov @ SoftwareGeneralist.com -