Ask HN: How can I practice designing data structures well?
2 comments
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.
* 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.
I want to improve my ability to design systems well. And I want to work towards building things with Linus' mindset.
When I work on a problem, I try my best to design it well ahead of time. But I typically don't have a good grasp of the entire system until after I have mostly implemented it. The nuances of the system are not clear until I have implemented it.
What are some techniques you use to understand a system before you build it? What are some good books that outline those techniques? Or is this a skill that one can only gain through trial and error or experience building systems?