Early Introduction of Competitive Programming

1. Early Introduction of Competitive Programming Pedro Ribeiro and Pedro Guerreiro

2. Presentation Overview • Competitive programming on teaching • Our automatic judge Mooshak • Use on functional programming • Use on logical programming • Use on imperative programming • Feedback from students • Conclusion

3. Competitive Programming • In our own university courses we use automatic evaluators for programs • Immediate feedback to students • Student’s ranking (competitive attitude) • Increased productivity of the students • Majority of automatic evaluators come from programming contests • Different requirements comparing to a pure pedagogical tool

4. Competitive Programming • Majority of programming contests • Imperative languages (ex: C/C++, Java, Pascal) • Input/OutputProblems • Majority of automatic judges are adapted to that environment • This customary approach • Cannot be used until students learn I/O • Not trivial in some languages or with large input • I/O distracts from the main problem • Written programs should be complete

5. Competitive Programming • It would be good to have automatic evaluation from the very first pieces of code • Large number of small tasks could be tested • More “correctness” • More feedback • “Accepted” message motivates • How to do that? • Separate computation from I/O • Evaluate single functions/procedures • “Call” them with desired input already read • Allow incomplete programs

6. Mooshak • We use Mooshak(open source) • Developed in Portugal (José Paulo Leal, DCC-FCUP) • Programming contests environment • Published on 2000 (mature) • Used on several official contests • ACM ICPC style (local, national and internacional) • IOI style (local, national, workshop) • Other styles (biggest size, smallest runtime, etc) • Since the very beginning Mooshak was designed to be flexible (more languages) and more detailed (different “customized” feedback)

7. Mooshak • Completely web-based • 4 views: contestant, judge, administrator, guest

8. Mooshak • Evaluates program in 3 phases, all of them with different customized command line calls, run on a safe sandbox (safeexec) with boundaries enforces (ex: memory, time): • Compilation • Ok if no messages on stdout • Execution • Error like TLE or Runtime Error are automatically caught • Evaluation • Using return codes define results (Accepted, WA, etc)

9. Functional Languages • Recently we have adopted the functional-first approach to programming using Haskell last :: [a] -> a last [x] = x last (_:xs) = last(xs) • I/O is not trivial • Customary approach is not to compile but to interpret (hugs) • Used like a “shell” (load and then call functions) • Programs do not need a “main” function • Collection of functions

10. Functional Languages • Use since the very beginning • Compile • Load with added “empty” main function • If it is syntactically correct -> no output! • Execute • Add main function which calls function with desired arguments • Input file is the main function itself • Just append this file and run (result will go to stdout) • Evaluate (normal fashion)

11. Functional Languages • At later stage, use normal I/O • Overall, 69 problems were available in Mooshak • 30% of the grade on submissions • Competitive aspect was not enforced but students liked and used it • As side-effect: programming contests

12. Logical Programming Languages Very different paradigm. We use Prolog. last([X],X). last([H|T],X):- last(T,X). • I/O is not trivial • Customary approach is not to compile but to load and query (on Yap – developed in Portugal) • Programs are collections of “relations” (predicates) • Programs do not need a “main” predicate • Collection of functions (database)

13. Logical Programming Languages • Use since the very beginning • Compile • Load the program in the database • If it is syntactically correct -> no output! • Execute • Customized meta-predicate that collects all solutions to a specific query call on another predicate • Multiple output is “native” • Input file is the meta-predicate • Evaluate • The meta-predicate writes something when all solutions are equal to expected (ex: “Ok!”) • Output is just “Ok!”

14. Logical Programming Languages • Overall, more than 60 predicates were available • Different subsets of predicates (ex: lists, with things like length, last element, concatenation or duplicates removal); • More advanced problems to advanced students • Problems from contests (CNPLF – Portuguese Logic and Functional Programming Contest) • Used on evaluation of the course • Submission labs: submit correctly during the lab • Project assignment • Mooshak with intermediate predicates • Leave all problems open to the public • Preparation for exam, refreshing Prolog capabilities

15. Imperative Languages • More conventional imperative languages could benefit from schemes like the ones depicted before • Use from the very beginning. • No need for I/O and to precisely follow the problem description • Evaluate pieces of code • Compile: add rest of program, with main using I/O • We can hardwire the tests or simply read and write from stdin and stdout in the desired fashion • Execute: run the program as usual • Evaluate: evaluate by comparison as usual

16. Feedback from students • 1st year introductory course (Haskell) • 115 responses to survey (more than 90%)

17. Conclusion • Computers excel at boring repetitive tasks • Evaluating large quantity of homework “is” boring • Programming contests “provide” automatic judges • We know them and we can use them • Traditional judge use imperative languages and I/O • However we can easily tweak and adapt them • New approach to teaching • All exercises and assignments are “submittable” from day 1 • Immediate feedback • More productivity (more exercises) • More motivation (challenging environment) • Learning becomes more enjoyable • Side-Effect: exposure to programming contests

18. The End • And that’s all!:-) Questions? Pedro Ribeiro (pribeiro@dcc.fc.up.pt) Pedro Guerreiro (pjguerreiro@ualg.pt) http://www.dcc.fc.up.pt/mooshak/