i don't even know where to start. i would first say you should read my article on sorting in perl at sysarch.com. then read the talk slides on sort::maker at stemsystems.com/sort/slides/slides.

I had already read and understood A Fresh Look at Efficient Perl Sorting long ago. I both use and advocate using the GRT for most sorts where the extraction function is expensive and the dataset larger than a few dozen.

I have now read the slides. Whilst they were fine, I don't think that I saw anything that I hadn't already read in the POD.

Perhaps you would extend me the same courtesy by (re)reading my meditation, including following a few of the links provided.

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.

Sorry that you thought that my comments were not cogent.

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).

Assuming you have re-read my post, you will see

1. The poster's sort was far from a "simple sort of a hash".
2. You will also have seen that I produced both ST and GRT versions of the required sort of nested hashes with compound keys.
3. That I never claimed that you had "claimed that the module was faster", nor did I say, suggest nor imply that it was slower. The issue of speed was simply not a factor in my meditation.
4. That I do "get it".

You may also notice that I had nothing bad to say about your module--I'll repeat that. I had nothing bad to say about your module.

Hell, I'll even quote a couple of bits for you.

• It's an impeccably pedigreed module; cleanly coded; well documented etc.

• There is nothing wrong with the module, not it's interface design, nor it's documentation.

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.

Answered I think.

(I could give a list if references here where I have advocated and demonstrated the use of the GRT over the ST, and produced benchmarks to substantiate my conclusions...but you SNIP.)

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.

And I acknowledge all of that.

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.

This is the ONLY area where I had a problem.

I (personally, IMO, which carries no more weight than any reader chooses to give it. etc. ) didn't find the descriptive qualities of the module's use to be preferable to reading the coded sort itself.

Maybe that's only because I am--reluctant to use the term expert, so shall we say--sufficiently familiar with both perl code, and the standard methods of construction for STs and GRTs, that I prefer to read the code.

And that was the purpose of my meditation!

To ask the question, was I alone in finding it easier to read and write the code as a single coherent entity, than to break the code up into little bits and try visualise how they come together...?

I mentioned that I also have a similar problem with the callback interfaces presented by various HTML::* modules.

(For me) this extends to many of the XML::* modules, tye's Algorithm::Loops loops() function, File::Find(::*) and many others.

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).

My meditation was not billed as a review or a critic of your module. Far from it.

I actually thought that my having 'discovered it' on CPAN, and mentioning it here (I don't recall seeing it mentioned here before), might raise it's profile for those who prefer to use modules for such things. I even said as much.

• If you like the idea of encapsulating your ST sorts (or GRTs & Orcish Manouvers), then there is an existing module that will do this for you Sort::Maker

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.

I also asked the question: How would you simplify/clarify the coding of ST?

I could not work out how to use your module to code this nested hashes with compound keys sort. I was hoping someone would show me. None did.

I hope you don't feel this response to be as much of a waste of your time, as I feel it was a waste of mine to defend my meditation.

uri (the G in GRT).

BrowserUk (the '' in "nobody special" :)