IIRC the previous discussion, one way to fix this problem is to make a package that can parse strings easily using a C like format, like the expected in the contests. Something like
#lang racket (require compatibility/scanf) (let-values ([(x y) (scanf "%d %d" (read-line))]) (display (+ x y))) It's not very idiomatic, but it may be helpful for this particular use. IIRC another problem is that in the contest you are not allowed to install the packages you wish, you can only use the default installation. But I think that the idea is not to allow everything in the default installation. So my proposal is to add another installation mode for Racket * minimal: Only the core and some minimal packages * main: The normal set of packages, (only idiomatic) batteries included. * community (new): everything in the ring 1, including the kitchen sink. With a minimal curation and a minimal baseline of features (like no breaking the installation). (And a compatible license.) The packages may disappear/change/reappear from version to version. All the additional packages may be experimental/unstable/unsuported. Is this acceptable in a competition? Is this acceptable as another "official" Racket distribution? Gustavo On Fri, Jul 21, 2017 at 4:35 PM, Brian Mastenbrook <br...@mastenbrook.net> wrote: > On 07/21/2017 12:49 PM, Matthias Felleisen wrote: >> >> >>> On Jul 21, 2017, at 1:56 AM, Sorawee Porncharoenwase >>> <sorawee_porncharoenw...@brown.edu> wrote: >>> >>> Sorry for reviving an old thread. As someone who did a lot of programming >>> competition in the past, I can totally see why IO in Racket is difficult. As >>> mark.engelberg said, the goal is to solve as many problems as possible. >>> After the competition is over, it's over. No one is going to care about >>> maintainability or good coding practice if it makes coding slower. >> >> >> Which is why I think programming competitions are a direct attempt to >> undermine computer science and computer-science education. >> >> Having said that, if you want to use Racket for competitions, you and Mark >> Engelberg should get together and produce a high-utility IO library. We can >> then include it in the distribution. > > > Just as a counterpoint, I have this kind of ad-hoc parse-this-produce-that > problem all the time in the "real" world. When the logic of the problem is > sufficiently complex I'll swallow the overhead of doing it in Racket, or > I'll use Perl to transform the input into something I can read in Racket. It > would be nice to have an I/O library that made it easy, but I don't have any > specific thoughts about how to do that. > > I don't think computer science education should ignore this kind of problem > though. It's very important to teach students how to solve problems > methodically with a design recipe, how to collaborate with others, and how > to reason about their programs. But it's also important that programmers > (and also or even especially those who don't program for a living) be > comfortable with using the machine to solve or automate the solution to > one-off problems that would otherwise require a lot of manual fiddling with > data. Being fluent with this kind of programing gives people the confidence > they need to solve smaller problems or explore potential solutions to large > problems in an unstructured manner before tackling the methodical, "right" > solution. > > -- > Brian Mastenbrook > br...@mastenbrook.net > https://brian.mastenbrook.net/ > > > -- > You received this message because you are subscribed to the Google Groups > "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to racket-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
