Re: Competition fuels obsession over Perl

[Abigail-II]

I've participated twice in the European ACM programming contest (finished one time near the bottom, the other time, we missed being send to the World finals because while we made the "cut" (I think the top 6 or top 8 were to be send), there were too many teams from the same country that finished before us), and those times, the only allowed language was Pascal.

I've also organized regional contests in later years (writing most of the scoring software in AWK - but this was the first time a Perl book appeared on my desk). From what I remember from those times (late 80s, early 90s), the most important aspect in being succesful is terminal time management. You have 4 team members, 6 to 10 problems, and just one terminal. Another, very important, aspect is being able to handle the input border cases correctly. It's very frustrating to get your submission rejected time after time (with no reason or error message other than whether it compiled or not), only to find out the vague wording of the problem allowed for a different input format than you were programming for.

It's a bit easy to say "well, if only we were allowed Perl, then we could have done all the problems with time to spare". That's like saying "if we could make use of a bicycle, we could do the marathon in world record time". A programming contest that allows for Perl to be used can be as hard as one that allows C or Pascal. You just have to adapt the problems. Parsing problems that are tricky to do right in C or Pascal might be easy in Perl. On the other hand, there's much to say for not allowing Perl. You want a contest to be 'all-round', so it should problems that might involve parsing, or searching for strings in a large set. Using tools that already have solved those problems is kind of pointless.

Abigail

[flyingmoose]

I viewed the contest as an algorithmic challenge, not a language challenge. If it were a language challenge, yes, adaptation is crucial -- but, at least to me, Computer Science is about algorithms, not languages. It's important to know your memcpy() and your pointers, but that isn't what computer science is about, per se. Folks are supposed to be able to learn and use any language, and to use them well.

I think you're right about Pascal though. It was Pascal, not Fortran. I had learned Pascal as my first non-BASIC language, though there is no real point of using a language that dogmatic without any decent library functions! Today remember "use crt;" and that's about all the Pascal I know at this point.

The terminal access aspect really stunk. The way our teams were parititioned, I ended up drawing on the whiteboards more than anything, but we suffered at the terminal because other folks could not translate my ideas into code well. So, yes, there was a huge social/time-management aspect to it as well. It's hard working with people that don't work well with you ... a good life lesson, I suppose, if you are into that. (I'm not!)

I kind of liked the impartial rejection messages though. "WRONG!" was all you ever got back from the judges ...

While I agree "using tools that solved the problems already is kind of pointless", I don't see anythign wrong with attacking algorithmic problems with say, just the standard Perl installation (no CPAN).

Though I wasn't ever involved, I particularly liked the race car problem at the ICFP: here. ... language essentially doesn't matter in the contest, thought does.

[Abigail-II]

While I agree "using tools that solved the problems already is kind of pointless", I don't see anythign wrong with attacking algorithmic problems with say, just the standard Perl installation

It depends on what kind of algorithmic problems your problem is about. If it's a parsing problem, there's a gigantic difference between using Pascal and Perl. The former will force the programmer to make an algorithm. The latter only needs a few buttons to be pushed. If the problem asks for complex matrix manipulation, it's going to be a lot easier in APL than in C.

If you want to focus on solving algorithms, you let everyone use the same language, or set of languages, and you pick reasonably 'bare-bone' languages, like Pascal and C. You don't pick Perl, Python, or APL.

Abigail

[flyingmoose]

I didn't see any parsing problems at all. They were all far more conceptual. A lot of Perl code I write (don't know about you), looks like this from 30,000 feet.

A) Slurp Stuff B) Mangle Stuff C) Do Something that is actually interesting ... D) Mangle Stuff E) Store Stuff

C is always 85% of the thought process, but in other languages, A&B might be 50% of the labor. Boring!

As computer scientists, step C ("Do something that is really interesting") is most important. For programmers (ok it was a "Programming" contest), A,B and C,D are important -- someone will usually supply specs on C -- or you'll look it up. You aren't going to be doing anything highly innovative, most likely.

Maybe you had different problems, but reading input and storing it were never the focus of the problems I saw. A lot of graph theory, recursive analysis, things like that. Parsing is just drudgery to a lot of folks, esp in C (which is why Perl makes programming fun). We all know how to do it, but we'll never do anything profound that way.

College shouldn't be about writing parsers and other such drudgery. Everyone needs to know how to write them, but research and innovative solutions is the where it should be at.

Chosing a common language is good for competitions, I agree, you would set an imbalance if only some folks knew a rare kick-butt language and brought into onto the field. That's like bringing a gun to a knife fight.