QuoteOriginally posted by: CuchulainnQuoteOriginally posted by: Traden4AlphaQuoteOriginally posted by: CuchulainnQuoteOriginally posted by: CuchulainnWhat is a developer's mental model? For example, the customer has written this specWhat's triggered in Grammar-Pattern Programmer's head? How does it pan out?No one?This is a serious question. It's a bit like this but then for computers My first reaction is that the diagram is incomplete unless everyone is typing blind commands. Where does "old price" come from and who sees it? It's also unclear what the ORMS does. Does it only hold the current price state or does it accumulate a time series on each traded instrument?If the trader submits a long spreadsheet with many price changes, the grammar-pattern programmer would probably sort by date, sort or reorganize by symbol, and then foreach the symbols or rows. If end-of-the-week prices are all that matters, then there's some clever algie vector comparison code that extracts the last price foreach symbol in the spreadsheet. If the trader is entering price deltas, then the algie would use cumulative sums and some tricks to extract to cumulative deltas. If the spec calls for continuous updating, then the algie code and the looper code may be pretty similar.This diagram is incomplete (of course). But the added value is that all stakeholders are looking at the same page. The answers should help elicit precise requirements.The danger I think is the high-level architecture will be immediately lost using a grammarian approach based on low-level data.Either view can lead to poor design of the high-level architecture. To me, the grammarian approach is the mathematical approach of thinking about invariant truths in the system that must hold true for all items, all times, all states, all etc. The code then expresses a transform or update that maps a previously valid system state (the set of states on a set of items or times) to the next valid system state. It's a highly abstracted view which certainly has both advantages and disadvantages.To me, the non-grammarian approach can get lost in the weeds of the procedural steps and lose the big picture of what must hold true for all items, all times, all states, all etc. The non-grammarian is too busy writing loops and doing one-thing-at-a-time to see the macrostructures and optimize them. That said, computers at the level of their individual cores are intrinsically procedural machines so the non-grammarian may write code that is more efficient at the lower level even if their architecture is less efficient at the higher level. Of course, if we view the machine at the multicore/CUDA level, then the machine is a grammarian one!In this diagram, it's not clear what must be kept true in this system. For example, it's not clear whether "old price" is ALWAYS the previous price in the market, the previous price seen by the trader, the previous price recorded in the ORMS (i.e., not including the data team's pending updates), or the previous end-of-week price in the price report. Determining what must be always true about "old price" may have a significant effect on the architecture.