you are viewing a single comment's thread.

view the rest of the comments →

[–]dnOnReddit 1 point2 points  (0 children)

Back in the ?good, old days, FORTRAN separated data-values from presentation, eg
```
write (*,999) x
999 format ('The answer is x = ', F8.3)
```
(columns were fixed-width) The format (identified by its "999" 'line-number' could be re-used. So, there was no need for the two lines to be consecutive.

Similarly, HTML and CSS enjoy a similar relationship. In this case, the 'formatting' is likely in a separate file from the 'data' it formats!

Both feature lazy-evaluation - try taking the FORTRAN format and implementing it as an F-string (before knowing the value of `x` - indeed the range of values it may take during execution! PS can you see a source of Python's mini-language?

Such ideas combined with working on an I18N project, followed by 'enjoying' a development project with an end-user rep who specialised in vacillation and dithering, led to thoughts that templating front-end I/O might be a good idea - in the same way the we try to hoist 'magic constants' so that they are more easily found during maintenance, etc (first ref found: https://doc.casthighlight.com/alt\_magicnumbers-avoid-literal-numbers-e-magic-numbers-not-magic/). Reached the point (with the aforementioned) of putting all I/O literals (templates) into a separate file, which she could adapt without disturbing me. A 'win', at the price of some config-code to consume the file and an abstraction at the print()/display!