[plt-scheme] ICFP Contest Reminder

Don't let this scare you. In the end it's about
  - analyze the problem and design your data properly
    make up example
  - write down contracts for each piece
  - write down examples for each pieces and develop tests
  - organize into a template
  - write code
  - run tests
+ edit the code, re-run tests

Also, develop in iterations:
  - focus on some basic important functionality
  - get it right
  - test
  - add functionality
do it all over.

-- Matthias


On Jun 1, 2004, at 8:36 PM, Raymond Racine wrote:

>   For list-related administrative tasks:
>   http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>
> 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.
>
>
>
>
>
>
>