Principles of program design

What Hacker News says

1. turtleyachtAug 2024
   M.A. Jackson's Principles of Program Design (1975) uses examples in COBOL, but some of its takeaways are

   * A program should correspond 1:1 to its design. "Program structure [should] match the problem structure."

   * Avoid flowcharts (flow of control) until the structure is designed. "Flowcharts tend to conceal structure."

   * (Reuse of) components (before design) are a premature optimization.

   * Write the program by composing primitives, not all of which are actually primitive operations for your machine.

   ---

   (p. 35) In bottom-up design we say instead "this machine is not well-suited to my problem, because the elementary operations are too elementary; I shall therefore use the elementary operations to create a more powerful machine, and the operations of that machine to create one still more powerful, until I have a machine on which my problem can be easily solved".

   ---

   Jackson believes many programs can be described as serial processing of files, so it's a philosophy I'm trying to understand.

   Combined with Dubray's State-Action-Model (SAM), Miro Samek's quantum statecharts, and James Shore's nullables testing, it's a heady revitalization of the next couple decades.

   > nuances of the system are not clear until I have implemented it

   Yes, exactly. Each commit contributes to a graph of discovering each best move (balanced by time or pragmatics). It's hard to draw boxes and scribble when typing things out would surely straighten any gnarls.

   Show morethread
2. bengtsmidenvallSep 2022
   Here is my story! I answered this question in Quora one year ago! What are the best books you would recommend for someone who wants to broden his understanding about algorithms and learn programming concepts as well as ways to build solutions to problems? My answer: Hey! I recommend, Michael A Jackson, Principles of Program Design, JSP. Mr Jackson has literally "been behind my chair all these years…". Had never been able to stay in the programming profession if I did not have this great support for my thoughts in a difficult profession. Thus, here comes the rest of my story and why I recommend this book.I am an elderly gentleman who has been with "game" then late 60s. Have experienced much joy in my years as a software developer in the "Mainframe".That it was so nice, much depends on the profession and the engineering mindset, which I eventually dedicated to me, starting in earnest in 1984 at Bankgirot, Stockholm..It has been incredibly stimulating and fun during all the years of working with the method JSP in its entirety. Its powerful techniques such as process-/ programinvertion and useful backtracking approach. One works for a number of specific work steps and the iterative incremental processing method and its clear graphics technology, the method is also agile. Quickly get up a first draft of any data stream diagram. Using these, you can then also on some or a few A4 pages easily juggle alternative approaches and solutions.It has been a strong guiding light for me it's a bit rough and tricky work programming/system development sometimes are. It's incredibly many activities and details that need to be accomplished within a project is completed. Construction of program logic covers the often a large part of the overall project. Then apply it to have powerful support to "think in his little brain." One must add its intuitive thinking aside and instead be guided by strong practices guidelines. Have known that every day I have developed the method. Have just felt good and even a bit cleverer every day! To have seen this for himself, is a great feeling. Should truth be told, I've often over the years worked at home in the evenings with the data stream and process diagrams to put them in my PC the next day. If the method is used in full, you get features for free, which otherwise are forced o figure out for yourself. The forces early focus on the more complicated questions to manage the work process. With architecture o graphics technology, so the work is done at a higher level of abstraction than when coding a program. On the system so important temporal dimension emerges clearly in the diagrams , they reflect the user's world, that is the function programs to perform. The entire program is reflected now in the diagrams, When the process is finished diagrams allocated operator and conditions .. "Code" is thus needed only to execute the program, not to construct it. However, such errors can be detected in the design unless you can place operations in a natural way the process diagrams. Being forced to start thinking in code and not in user data may be due to the datastreams diagram being incorrectly constructed. So an early review / record before the first test. These last steps are more routine and helps at the same time, it contributes to good reconcilation opportunities. An example of this is that the operations do not naturally find a home in the process diagrams. It can then be incorrectly constructed data stream diagrams, or something is missing in the program specification. During the work, we have now automatically received a complete application documentation. The method is designed so cleverly that you do not have to think of any "no nos" and concepts such as clean code, coupling, cohesion… ..etc. Long source code lists are a thing of the past. Instead, you can fully concentrate on and construct datastream diagrams that show the user world that the program should support.
   Show morethread
3. bengtsmidenvallSep 2022
   Part No-1. Quora Question! "What are the best books you would recommend for someone who wants to broden his understanding about algorithms and learn programming concepts as well as ways to build solutions to problems?" My answer:I recommend Principles of Program Design, JSP. Michael J has literally "been behind my chair all these years". Had never been able to stay in the programming profession if I did not have this great support for my thoughts in a difficult profession, here comes the rest the story and why I recommend this book.I am an elderly gentleman who has been with "game" then late 60s. Have experienced much joy in my years as a developer in the Mainframe. That it was so nice, much depends on the profession and the engineering mindset, which I eventually dedicated to me, starting in earnest in 1984 at Bankgirot, Stockholm..It has been incredibly stimulating and fun during all the years of working with the method JSP in its entirety. Its powerful techniques such as processinvertion and useful backtracking approach. One works for a number of specific work steps and the iterative incremental processing method and its clear graphics technology, the method is also agile. Quickly get up a first draft of any data stream diagram. Using these, you can then also on some or a few A4 pages easily juggle alternative approaches and solutions. It has been a strong guiding light for me it's a bit rough and tricky work, system development sometimes are. It's incredibly many activities and details that need to be accomplished within a project is completed. Design of program logic covers often a large part of the overall project. Then apply it to have powerful support to "think in his little brain." One must add its intuitive thinking aside and instead be guided by strong practices guidelines. Have known that every day I have developed the method. Have just felt good and even a bit cleverer every day! To have seen this for himself, is a great feeling. Should truth be told, I've often over the years worked at home in the evenings with the data stream and process diagrams to put them in my PC the next day.If the method is used in full, you get features for free, which otherwise are forced and figure out for yourself. The forces early focus on the more complicated questions to manage the work process. With graphics , so the work is done at a higher level of abstraction than when coding a program. On the system so important temporal dimension emerges clearly in the diagrams,they show the user's world, that is the function programs to perform…….continued.
   Show morethread
4. terminalcommandOct 2017
   Full disclosure: I have not dabbled with data science, nor I'm an experienced programmer.

   But many of the CS pioneers dealt with the issue of reading input, processing it, and giving a meaningful output. Recently I've stumbled upon Jackson's Principles of Program Design and it has really helped me in writing a parser. IMHO general understanding of structuring a program goes a long way than arbitrary design patterns. I now am a propenent of modular programming. For me it resembles functional programming and TDD. Basically it states your program should be made up of numerous self-contained modules that can be independently tested.

   For data science workflow it could be an import package, further divided in modules such as general helpers and implementations for different file types; a computation package etc.

   Show morethread
5. brudgersMay 2015
   <rather late book report>

   Principles of Program Design, Michael Jackson. I found a very good copy with free shipping for less than $5.00. It is absolutely brilliant. It is a conventional technical book style presentation of the many software engineering principles SICP presents using new journalism techniques. One of the cool things is that Jackson dogfoods his methodology to illustrate deeper computer science concepts (e.g. the necessity of a start state for a state machine) with practical examples rather than theory. It does more showing than telling.

   </rather late book report>

   The relief staff in the bullpen includes:

   Programming Clojure, Stuart Halloway.

   Elements of ML Programming, Jeff Ullman.

   Extreme Programming in Practice, Newkirk and Bob.

   Show morethread
6. turtleyachtSep 2023
   You should build up primitives and compose them instead.

   ---

   In top-down design we say, in effect, "this problem is too complex for me; I shall dissect it into a number of smaller problems, and those into smaller problems still, until I have a set of problems simple enough to solve."

   In bottom-up design we say instead "this machine is not well-suited to my problem, because the elementary operations are too elementary; I shall therefore use the elementary operations to create a more powerful machine, and the operations of that machine to create one still more powerful, until I have a machine on which my problem can be easily solved."

   -- Jackson, M.A. Principles of Program Design (1975)

   Show morethread