JS: Node v12 should be used along with its appropiate assertion tools (Mocha + Chai).
Refer to this and this

How can someone call a easier and with different focus a "duplicate kata"?! Not everyone knows how to make a whole code about converting multiples temperatures at the same time --' Stop thinking about only yourselves and consider the newbies that is trying programming and trying this platform as well.

Sample and fixed tests print the solution's output as an additional error message.

here is a translation for ruby :
Ruby translation

I like the idea of testing operator precedence, but it would be great to include more equations (in other words, open it up outside of just the temperature equation, so you can test the user on more examples).

I agree with that suggestion that providing some initial code as a bug fix as well, as it would deepen the solver's consideration of operator precedence to do it as a correction, thanks!

Also I like the example! Change made.

Hi there,

The real question (to me) is actually: why do you so hardly want your kata published? Several persons already told you that we already have a lot of similar things on CW and so, it won't add value to the content of the site. Yes, it's not nice to the work you did, but for a so easy kata, it's not either days of work that you would "loose". So, why not just unpublish it?

Let me do a guess... Would you use it for your work, by any chance? If so, you should use the Qualified version of CW, not the current one. Just a guess, again.

Anyway, why not use your competences to build something new, with context and all, rather than insist on this one?

cheers

I see what you're getting at there, however the copy and paste test alone for duplicate is just another way of saying testing for the same input and output conditions, which I've already addressed as not being the be all and end all. In terms of the wider point you make that this can then be used to bypass the challenge's original intent, the simple answer is that any learning challenge requires genuine participation otherwise it becomes negated so the author shouldn't need to design for teaching anyone who doesn't want to participate and I wouldn't recognise that as criteria.

By your redefinition there would be more duplicates I'm sure, however your redifinition of a duplicate Kata is too narrow and contrived to my understanding, given that Katas should (and mine does) have context, hence why a Kata title, discipline, description, estimated level are supplied in CW, rather than only the solution and tests. With the context, i.e. the full Kata, mine is not a duplicate, but without context and with modification freedom you define (copy and pasting between mine and any of the duplicates you propose is still not enough), then yes mine would be a duplicate.

Bob has to calculate his taxes. He usually uses a calculator and types in his three positions and then multiplies them with his tax rate. Since he sometimes forgets his tax rate, he wrote a program. But it prints the wrong results. Can you help him?

function bobsTaxes(work, personal, cat) {
return work + personal + cat * 19 / 100;
}

Great suggestion, but IMO even then it would still be a duplicate - see my comment on "intent of the Kata author versus intent of the solver". The best way to resolve the duplicate issue once and for all is for the Kata author to take your suggestion and use a different formula altogether for the bug-fixing exercise.

I'll agree that arguments (1) through (3) are strawman, but my fourth argument is indeed perfectly valid and sound. This has to do with the intent of the Kata author versus the intent of the solver. Yes, the Kata author may have intended the solver to write the multiply function from scratch in his/her Kata which would indeed achieve a different objective from purely bug-fixing (although still trivial to the experienced programmer), but consider what the Kata solver could do - he/she could complete the bug-fixing "Multiply" Kata first, and then copy and paste his/her working solution from the bug-fixing Kata to the "writing code from scratch" Kata and pass all tests without actually rewriting the multiply function from scratch which would completely defeat the Kata author's objective. So in the end, the Kata solver would have only learned bug-fixing but not constructing a multiply function from scratch even though he/she has apparently completed two completely "different" Kata (from your definition). See what I'm getting at now?

So let me redefine a "duplicate Kata" in a less ambiguous manner - if there already exists another Kata in CW (either in Beta or approved) whose working solution can be copied and pasted to this Kata to pass all tests with little or no modification (regardless of the intent of the author himself/herself who is not the audience of the Kata), then it constitutes a duplicate. By this definition, your Kata is a blatant duplicate.

@donaldsebleung.

Representations 1,2,3 of my logic are straw man since my argument is that the conditions of input and output alone of a programming challenge are less meaningful vs the context of it (especially, but not only, the described purpose, targeted discipline, targeted audience) to compare two challenges as being duplicates or not, in particular when one challenge can completely change those input and output conditions yet still be completely faithful to the original challenge. My logic would follow that the differences/similarity between your examples 1,2,3 barely enter the comparison in the first place if there is significant context to compare.

Example 4 is at least on the right page to discuss. If the example 4 comparison were made more accurately anologous to the comparisons with my Kata and to challenge the complete argument I have made. It would be as follows:

A bug-fixing challenge, where spotting a bug and fixing the code are the central challenges and, by defintiton of the discipline of the challenge, it should include intial code to fix, is a duplicate programming challenge to another, where the programmer has to write a function from scratch in any way he/she sees fit to achieve an output because getting that output is the central challenge, simply because the black box input and output conditions to test the bug fix happens to be the same as the other challenge (discounting the context similarity in your example that Multply puts in the name as that is not anologous to comparisons between my Kata and candidate duplicates you've put forward).

Can you not see how myopic it is to claim that these two programming challenges are duplicates, by ignoring their significant contexts? For my Kata it's even more obvious given the context it puts forward plus because the particular input and output conditions are not bound to the programming challenge for my Kata (hence I've been able to change those conditions once already to emphasise the use of operator precedence knowledge more) whereas the specifics of the initial code (but not input and output conditions) of a bug fix is heavily coupled to the intended challenge, so there is more debate there.

However, if you you cannot see where your example 4 bug fix Kata, now more fleshed out in context, and my Kata, have these significant differences to their comparisons, this is completely a case of not seeing the wood for the trees.