Talk:Longest string challenge

Generalization

This is an interesting programming challenge. An active discussion is needed to strike a balance between generalization and defeating the task.

• I would expect to see a number of languages mark this as omit.
• Would this only be possible for languages with implicit iteration?
• Would it be fair to relax the lists to lists of lists or supplementary lists in cases of languages like C that represent strings as arrays?
• Etc.

How about a discussion here of how this would apply to a few languages (say in the top 20 or so)?

Similar to Averages/Mode

The problem statement itself (without the restrictions) is very similar to Averages/Mode, except that you do not need to compute the counts of elements, instead taking the length of the string serves as its "count". --208.80.119.69 00:43, 13 August 2011 (UTC)

Except that in mode you can use comparison operators and arithmetic operators. You're not allowed to do either here. Besides that, I still don't think it's really that similar. --Mwn3d 00:59, 13 August 2011 (UTC)

Can't load https link

Firefox won't load the reference link due to invalid SSL cert. --Ledrug 00:08, 13 August 2011 (UTC)

In firefox you can *temporarily* accept the cert. The site is scheduled for upgrade and I can ask if there is a way that http can be allowed for anonymous users. --Dgamey 11:55, 13 August 2011 (UTC)

The TWiki Twisty (show/hide) appears to break in newer firefox and IE. If you have something like NoScript and don't trust the scripts on the site it will show all of the hidden material below the headings. --Dgamey 11:55, 13 August 2011 (UTC)

Rereading

I think the task description should explicitly forbid (or permit, if that was the intent) reading the input twice. —Kevin Reid 03:08, 13 August 2011 (UTC)

An interesting point. Since I was not the originator of the challenge, I can't answer. My take is if it isn't explicitly forbidden and it's not a cheat on one of the restrictions it should be allowed without stating it explicitly. As there are a lot of very creative people out there the list of techniques could get quite large. --Dgamey 12:20, 13 August 2011 (UTC)

Well, my preference is that given that the task is to read from "standard input", and standard input may not be a seekable file, this is prohibited implicitly (and so should also be prohibited explicitly to avoid permitting semi-broken solutions). —Kevin Reid 14:43, 13 August 2011 (UTC)

Restrictions

What is the purpose of the restrictions? This is a chrestomathy. We would get a better language comparison, if we removed the restrictions. Markhobley 09:24, 13 August 2011 (UTC)

The basic task is very simple, the point of the restrictions is try and get people to think a bit out of the box and make it a bit more challenging. --Dgamey 12:00, 13 August 2011 (UTC)

I'm not sure whether that is the objective of rosettacode, because this is a chrestomathy. If the task has a good implementation that can be achieved through the use of operators, then we should be able to use them here. This could possibly be a challenge for a programming challenge site, but I don't know of one off hand. Alternatively, we could possibly make the restrictions optional. Markhobley 14:55, 13 August 2011 (UTC)

Intent of Restrictions

Beyond thinking outside the box, the restrictions need to be clear and will probably get reworded.

All of the restrictions apply to any called routines such as libraries. I suppose if there was a native built-in library function that returned the longest strings that would be allowable; but, library routines shouldn't be used to cheat on the restrictions. --Dgamey 12:35, 13 August 2011 (UTC)

No comparisons

"No comparison operators may be used."

This would also cover built-in comparison functions like lt(a,b). Instead of "operators" it should probably read "operators/functions" or "operations" possibly with "built-in" in front. Now if you can write a comparison function that doesn't use these things, that would work. --Dgamey 12:35, 13 August 2011 (UTC)

(1) Do equality operators count as comparison operators? In particular, do "pointer-equality" operators which do not even do data-structure-specific examinations count? (2) Do pattern-matching (regular expressions, structural patterns, etc.) operators count? —Kevin Reid 14:44, 13 August 2011 (UTC)

No arithmetic operations

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

I think this is clear. --Dgamey 12:35, 13 August 2011 (UTC)

Use only integers and strings

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

To avoid semantic arguments, "lists" means lists/arrays/vectors in the broader sense. However, clearly in the case of C, where strings are arrays of characters, this needs to be relaxed a bit. Using arrays for other than strings would be a cheat here. --Dgamey 12:35, 13 August 2011 (UTC)

Not pointless

I had to chuckle at the comment on the C submission as I think it proves the point quite well. Clearly, I need to document the point better :)

While I think about how to word it, let me explain. This site allows people to compare implementations in different languages. Restrictions force people to find other ways. To choose the road less traveled. Now this may require a technique that would be useful in some other problem but perhaps overkill in the simple unrestricted case. This can show people different techniques. The C contribution's cmp procedure is a case in point (I think). My C is very rusty (entirely seized up) and it doesn't look like a cheat to me. But I only have an inkling of how it may work. I'd have to crack my old copy of K&R and scratch my head a bit for it to be clear. A fluent C programmer would 't need to, but on the other hand they wouldn't be on this site to read code. Where I failed in the task description is to require people to provide some description of how they got around the restriction so that people coming from other languages will be able to understand. I'll add this to the task description. --Dgamey 13:01, 13 August 2011 (UTC)