in reply to To use a module...or not.
when you have done that and digested it all, then you all might be able to make some cogent comments on my module and the reasons (or not) for using it.
the ST, GRT and orcish sorts are NOT replacements for simple sorts but for complex sorts with slow key extractions. the poster with the simple sort of a hash didn't get it at all. the essence of these sort styles are caching of the extracted key. if extracting the key is easy and cheap (like when sorting a hash) then you won't save much if anything by using one of these methods. i never claimed the module was meant to be faster for them (and if you know annything about algorithm theory and O() notation you will get it), they also only improve things when the input set grows to a certain size and the key extraction is slow (-M is a great example).
finally, if the ST is easy for you to write and understand, that is great. try groking and using the GRT (which beats the ST in almost all speed tests) as easily. the beauty of sort::maker is that you can choose the sort key caching style and NOT change anything but a single keyword. sometimes one caching style is best and you can't always predict it without proper benchmarks. and sort::maker includes a very flexible table driven benchmark/test that you can use on your own data. getting back to the readability point, of course sort::maker doesn't lessen the amount of information needed to specify a sort but it does make it more readable for the vast majority. if you don't care then don't use it as it isn't for you (you get no soup either! :). i have already gotten plenty of good feedback (including a report of a 50% speed up and some bug fixes) so i am satisfied i did the job i set out to do (if only 5 years later).
enough for now. read the paper and slide show before you respond to this. i will not read any posts from those who haven't as it is a waste of my time.
uri (the G in GRT).