On 14 December 2017 at 08:17, Windt, W.K.F. van der (Fred) < [email protected]> wrote:
> > It surprises me that no one has pointed out that having complex tables > > assembled/compiled into a program is generally a Bad Idea. Almost always > > such tables have to be updated and that tends to require a programmer, > > rather than anyone with a text editor, if the tables are read into > storage at > > program start, which generally is not going to be a significant > overhead. Then > > one is also not limited by whatever restrictions are in the > > compiler/assembler. > > I completely agree but we make a difference between tables with > 'functional' data and 'technical' data. Functional data is stuff like > country codes, currency codes, holidays etc. Technical data is stuff like > program parameters, system configuration and the like. Maintaining this > technical data requires a dev engineer anyway. > > My =literal problem does not occur in a *table* but a (technical) data > *structure* that cannot easily/efficiently be represented by a table... > Indeed, that makes a lot of sense. Some time ago I replaced 15 KLOC of "evolved" flat code by a small 1 KLOC table-driven engine. My table was constructed from 3 different external sources, so I ended up with a pipeline that generates the HLASM input to build the tables. I expected it would burn more CPU in return for easier maintenance, but it turned out to be cheaper to run (likely some of the redundant pieces were now skipped, and probably the small code base sits better in cache). Rob
