Talk:Longest string challenge: Difference between revisions

Line 24:

:RC is occasionally more than a straightforward chrestomathy with clear directions. Sometimes, the directions require hard thinking about the nature of a language and the various possible indirect ways to satisfy requirements or the spirit of the task. Beyond chrestomathy, RC is about illumination of the nature of problems and the tools that solve them. To that end, it's sometimes the case that the less direct the solution (by some necessity), the more illustrative it is of the shape of a language. This task also got me thinking about [http://irclog.perlgeek.de/rosettacode/2011-08-13#i_4272285 how one might distinguish between kinds of tasks]. --[[User:Short Circuit|Michael Mol]] 01:59, 15 August 2011 (UTC)

:: I'm happy that the task has generated a lot of discussion and thinking. It seems to be a bit more of a can of worms than I'd hoped for and I really hope it can be salvaged in a fair and reasonable way. I expect that the task description will need a concise summary of the intent so people don't go too literal on it. --[[User:Dgamey|Dgamey]] 03:20, 15 August 2011 (UTC)

=== Revised task description candidate ===

This problem and challenge is inspired by one that used to be given as a challenge to students learning Icon. It was intended to be tried in Icon and another language the student was familar with. The basic problem is quite simple the challenge and fun part came through the introduction of restrictions. Experience has shown that the original restrictions required some adjustment to bring out the intent of the challenge and make it suitable for Rosetta Code.

It's a fun one to play with - especially if you also try to find solutions in other languages.

Basic problem statement:

:Write a program that reads lines from standard input and, upon end of file, writes the longest line to standard output.

:If there are ties for the longest line, the program writes out all the lines that tie.

:If there is no input, the program should produce no output.

Original list of restrictions:

:1. No comparison operators may be used.

:2. No arithmetic operations, such as addition and subtraction, may be used.

:3. The only datatypes you may are use are integer and string. In particular, you may not use lists.

An additional restriction became apparent in the discussion.

:4. Do not re-read the input file. Avoid using files as a replacement for lists.

Because of the variety of languages on Rosetta and the wide variety of concepts used in them there needs to be a bit of clarification and guidance here to get to the spirit of the challenge and the intent of the restrictions.

:The basic problem can be solved very conventionally and that's boring and pedestrian. The original intent here wasn't to unduly frustrate people with interpreting the restrictions, it was to get people to think outside of their particular box and have a bit of fun doing it.

:The guiding principle here should be that when using the language of your choice, try to solve this creatively showing off some of your language capabilities. If you need to bend the restrictions a bit, explain why and try to follow the intent. If you absolutely can't get around one, say why in your description.

:Now having said that the restrictions require some elaboration.

::* In general, the restrictions are meant to avoid the explicit use of these features.

::* "No comparison operators may be used" - At some level there must be some test that allows the solution to get at the length and determine if one string is longer. Comparison operators, in particular any less/greater comparison should be avoided. Various approaches allow for detecting the end of a string. Some of these involve implicitly using equal/not-equal; however, explicitly using equal/not-equal should be acceptable.

::* "No arithmetic operations" - Again, at some level something may have to advance through the string. Often there are ways a language can do this implicitly advance a cursor or pointer without explicitly using a +, - , add, subtract, etc.

::* The datatype restrictions are amongst the most difficult to reinterpret. In Icon strings are atomic and structured datatypes like lists are quite distinct and have many different operations that apply to them. This becomes a bit fuzzier with languages like APL, C, or J. The intent would be to avoid using an easy structure to accumulate the longest strings and spit them out. There will be some natural reinterpretation here.

::: For example, in C a string is an array of chars using a couple of arrays as strings is in the spirit using a second array in a non-string like fashion would violate the intent.

::: Also, in APL or J arrays are the core of the language so ruling them out is unfair. Meeting the spirit will come down to how they are used.

::* The added "No rereading" restriction is for practical reasons, re-reading stdin should be broken. I haven't outright banned the use of other files but I've discouraged them. Somewhere there may be a language that just sings when doing file manipulation and where that makes sense; however, for most there should be a way to accomplish without resorting to an externality.

:At the end of the day for the implementer this should be a bit of fun. As an implementer you represent the expertise in your language, the reader may have no knowledge of your language. For the reader it should give them insight into how people think outside the box in other languages. While the implementations may be a bit artificial in the context of this task, the general technique may be useful elsewhere.

Task

Implement a solution to the basic problem that adheres to the spirit of the restrictions.

Describe how you circumvented or got around these 'restrictions' and met the 'spirit' of the challenge. Your supporting description may need to describe any challenges to interpreting the restrictions and how you interpretation. If you make any assumptions, like the inputs are trimmed of trailing blanks, you should state them.

This task is likely to encourage multiple different types of solutions. They should be substantially different approaches.

Given the input: (etc. as is current).

:Comments folks? --[[User:Dgamey|Dgamey]] 13:30, 15 August 2011 (UTC)

==Similar to [[Averages/Mode]]==