I don’t do it so much anymore, but I use to code a lot of Perl. And having scalars, lists, and hashes as fundamental data types built in to the language made it very easy to construct more complicated data structures like data frames.
I’m with you in that my code never uses
containers.Map, and that is a shame because often a hash is what I’m looking for. I usually resort to
find (O(n) performance) which are fine only as long as the problem set is small.
Even the ostensible alternatives in Octave don’t work well. Octave’s
struct data type is built on top of C++ std::map. This should be a good solution as the field names are the keys in std::map and the C++ STL keeps those keys in sorted order and guarantees search time is logarithmic (presumably, O(log2 (n)). But, because of inadequacies on our side, the performance of a lookup like
isfield is linear in size (O(n)). See this bug report about that issue GNU Octave - Bugs: bug #58105, isfield needs time proportional to... [Savannah].
Perhaps this is just a long-winded way to say that we need to improve things in Octave, and once improved it needs to be adopted by both core Octave programmers and by regular users. If pass-by-value helps increase adoption then I’m all for it.