> I wasn't trying to be pedantic, I was trying to point out... I agree! > but it's easy to do and easy to reason about I agree it's an obvious/intuitive appr

> I wasn't trying to be pedantic, I was trying to point out... I agree! > but it's easy to do and easy to reason about I agree it's an obvious/intuitive approach to take, just like OOP. However, from a computational and software maintainability standpoint, I think it rarely pays out. > How one should best solve the problem depends on the scope of the problem and what you need to do downstream That's right, however ADTs are very rarely occurring naturally in what I do (I've dabbled in quite a few areas). I've found them to occur naturally in parsers (because languages have forks in their syntaxes), but even there I've had great gains by avoiding ASTs altogether, and making multiple streams, supported by a ADT stream of simple data that does not contain real data but only "joins" the other ones (it contains only a type-flag and a pointer into one of the other streams). I think ADTs are the right choice whenever the ordering between a set of things with heterogeneous types is very important. If that's not the case, code can be vastly simplified by sorting the data by their types and processing them as separate bins - separately and independently.