[plt-scheme] ICFP Contest Reminder

On Tue, 2004-06-01 at 18:17, Connor Ferguson wrote:
> >>on 6/1/04 5:31 AM, Neil W. Van Dyke wrote:
> 
> > For list-related administrative tasks:
> > http://list.cs.brown.edu/mailman/listinfo/plt-scheme
> > 
> > ifconfig <nslookupifconfig at hotmail.com> writes at 00:41 01-Jun-2004 +0200:
> >> I wanted to ask if anyone is planning on participating with DrScheme
> >> or not?
> > 
> > Some younger women and men should join together to form Team PLT.
> > 
> But if I do enter, it will be with DrScheme.
> 
> -Connor

As someone who has toyed with ICFP for the last 3 years, and attempted a
serious run at last years contest, here are some thoughts on the contest
based on my experiences.

1) Be prepared.  IRC channels, CVS setup, accesses granted, core members
etc.... all prearranged.
2) Think, then code it.
3) Upfront effort in breaking the code into distinct modules with some
agreed upon interfaces BEFORE the code starts to fly is a good thing.  
4) I think 3 people +/- 1 is ideal for a core team.
5) There is PLENTY of opportunity to participate at the part time level
and support a core team without committing to the marathon.

Every contest involves writing code which generates a solution.  Every
contest also involves writing code to verify solutions, sanity check
solutions, QA solutions, and usually to "visualize" solutions.  Last
year for example, every team ended up writing a separate tool to trace
the cars path over the racetrack bitmap. You can participate at the tool
level without committing to the marathon.  There tools are small and
generally are in the 1-3, 4-5 hr commitment range.

The code generated in a typical ICFP can be categorized as follows:

I.  Base Infrastructure:   Parsers for the input data.  Writers for the
specified output format for submittal.  This is just "crank it out" code
to "get" to a point where you can start addressing the meat of the
problem.  A framework into which one or more solution strategies can be
inserted is an ideal base infrastructure to an ICFP problem.

II. Core Algorithm/Strategy which generates a solution.

III. Ancillary, standalone support tools.
Solution verifiers.  Visualizers etc.

Usually core team is so desperate to get to Phase II, Core Strategy,
that Phase I is a minimal band aid, and Phase III is given short shift
because of lack of resources (this is an area where part timers can be
key).

By Saturday afternoon and evening the "marathoners" are into Phase II,
have a bare, minimal framework in place (read/parse in data, base
support code, a hopelessly naive strategy that dumps out the simplest of
solutions or pseudo solutions) and are now starting into the meat and 
potatoes of a sophisticated solution generating algorithm.  Some teams
will split and tackle the problem with two different strategies and
later recombine (or not) on the the most promising approach.

Now that a very bare bones framework is in place, and the core teams
attention has shifted focus, part timers can really help out by
"shoring" up the infrastructure/framework code with unit/functional
tests, mix in log/trace/debug code, data validation, overall robustness,
speed optimization, refactoring, shifting hard coded params to config
files and invocation parameters....

>From the "stand alone" tool perspective a part timer can contribute at
the contest start by whipping out a nice support tool, or on Sat/Sun by
adding enhancements to the tool suite.  Tool code is as critical to
winning as recognizing the correct algorithmic approach to the problem
solution.

Historically, very sophisticated entries have been eliminated from the
contest because they "died" when the input data file was empty for
example.  Because of this the last few contests moved away from a
program submittal which is feed arbitrary data inputs by the judges to a
submittal (with generating code) of a solution data file generated from
input data given as part of the problem statement.

In all of these areas its pretty easy to help out without too much
collision or overlap occurring.

In summary.

A part timer can be a valuable resource throughout the contest period
Fri, Sat, Sun and Mon.

R.

P.S. On a side note, for whatever the reason, historically the typeless
languages have not done as well as the strongly typed.  Even though the
typeless languages are empirically considered the superior rapid
prototyping languages.  If you believe this is an unnatural imbalance of
the very fabric of the language universe, participate, prove them wrong.

P.P.S
Get yourself to #scheme, #sml, #ocaml, #haskell, #dylan, .... before the
contest to seek out a team on IRC FreeNode.

P.P.P.S
Even more fun is to go there after the contest starts and observe the
chaos.