Writing an LZ is a concrete algorithm, just like implementing the AES encryption scheme. Writing a go program, much like writing a game, or any other big project with fuzzy definitions is not solved by planning. I can plan on writing a neat MC scheme and decide what data structures to use, and what the memory management is, and whatnot. And when I'm finished (because with a thorough planning there is no point in prototyping unless you want to spend 2x time) find that the data structure I used has bad scaling for an MC engine. Then, to redesign the data accessors and structure. The new one works better, but tweaking of the tree genersting loop was needed, making it use 2x memory, making it nom-scalable. Repeat ad-nauseam.

When I started programming in my degree, we were assumed to plan ahead and "all this". Then I found out that in real world problems (mathematics in particular) it's better to get it done and then refine than plan and get it perfect. Because these plans rely on assumptions on what will work without having any working knowledge on the problem domain.

_________________
Geek of all trades, master of none: the motto for my blog mostlymaths.net

This is going nowhere, clearly more a confusion of terminology than anything else, central to that the meaning of "abstract".

AFTER a complete abstract plan there may be a need for intermediate planning. I say may, because now we are talking about the experience and skill of the individual programmer. When you mention making an unwise choice of (real) data structures in your planning that can only be in this intermediate sort of planning. At the abstract plan level, data structures are still abstract, not committed to any particular real representation.

You (perhaps rightly) describe LZ2 as "simple". But even that has some subtleties that had best be noticed while still at the abstract level or likely to be bugs that are very mysterious and hard to fix (and unlikely to be detected by testing because you won't be testing for that special situation).

Michael