Talk:Compare a list of strings

Planned task changes

I'd like to make the following changes to this task:

Instead of requiring tests for equality + less-than, require tests for equality + less-than-or-equal + greater-than

Rationale: When I created the task, I had the Perl and Perl 6 solutions in mind, for which less-than and less-than-or-equal testing would work the same way – so I just picked one. But it turns out that in other languages, the less-than-or-equal test would actually be simpler, and I don't want to hold them back from showing that off. (For example, the C++ solution could simply use the is_sorted function without a custom comparator lambda; the Java solution could probably replace Arrays.stream(a).distinct().sorted().toArray() with just a.sort(); etc.) So, I think the task should cover both strict and non-strict order testing to show the difference; and to mix it up let's change the strict one from 'ascending' to 'descending'.

Turn the guideline for presenting solutions in a minimalistic way, into a requirement

i.e. instead of saying "There is no need to ..." say "Don't ...", and reword the rest of that paragraph to make the intention clearer. And enforce it by flagging examples that don't follow it with {{needs-review}} or similar. And maybe add the following pseudocode illustration to the task description, to show how different languages could comply with it:

<boolean expression involving strings>  // All equal
<boolean expression involving strings>  // Ascending
<boolean expression involving strings>  // Strictly descending

IMPORT all, zip FROM standard_library

<boolean expression involving all, zip, and strings>  // All equal
<boolean expression involving all, zip, and strings>  // Ascending
<boolean expression involving all, zip, and strings>  // Strictly descending

<boolean expression involving is_equal and strings>    // All equal
<boolean expression involving is_ordered and strings>  // Ascending
<boolean expression involving is_ordered and strings>  // Strictly descending

...given these custom subroutines:

IMPORT <various stuff> FROM standard_library

SUBROUTINE is_equal
    ...
END SUBROUTINE

SUBROUTINE is_ordered
    ...
END SUBROUTINE

Rationale:

Most Rosetta Code tasks encourage implementers to show their solutions in the form of a complete, ready-to-run program that also demonstrates the functionality using a few test cases. And for most tasks that makes sense.

But in this task, the "demonstration code" (properly initializing the program, populating the arrays, looping over test cases, calling the tests, printing the output, properly terminating the program) would in most languages be larger and more attention-grabbing than the code for doing the tests themselves and effectively "drown it out". Such a poor signal-to-noise ratio makes it much more difficult to compare the solutions from different languages - which, for a conceptually simple task like this, should be easy. Not to mention it makes it difficult to know which imported libraries are needed for the actual test, and which for the demo code.

Thus, I'd all examples to show each test as a stand-alone boolean-returning expression, plus comments to tell which one is which – in the form pioneered by the Python solution. (Yeah, I didn't follow it quite so strictly in my own Perl & Perl 6 solutions at first, but I fixed that quickly :D)

Since the task is only a few days old and still in draft status, I hope that making those changes is okay, but since there are already 12 solutions (and I'm not well accustomed with the unwritten rules of Rosetta Code), I'd like to get the go-ahead from one of the admins/moderators for this first.

This is also the chance for anyone to voice (substantiated) objections...

Cheers, --Smls (talk) 15:16, 1 July 2014 (UTC)

Hi Smls, I don't think this should be for administrators as much as it should be for non-newbies. As a non-newbie I should point out that although draft, the twelve implementations makes it more difficult to make a change and get everyone to update. Against that though, it has only been a day so the implementors should still be "around".

I am inclined to think that if you really want to make the change and that change will invalidate some entries, then you could do it but also add:

tags to all the entries that need updating so people are more likely to find out that their particular languages implementation needs changing.

That's one opinion :-)

--Paddy3118 (talk) 16:56, 1 July 2014 (UTC)