Redundancy in Contributing guidelines

[BrandonLMorris]

Since all problems of a given language are compiled and run the same way, there should be no need for a Makefile and bash script for each solution.

A better solution would be to have a single script at the top-level directory that can take an problem name and language type as arguments, and compile/run the desired solution with any/all input*.txt files. The solution can be found by the path and file extension, and if multiple solutions are available, the user can select the one they prefer.

After all, the emphasis should not be on running the code, but understanding the code.

[jwowillo]

I like that solution. The one problem is that when you look at sites like Codeforces and Kattis, they support so many languages and compilers. New versions also come out very often. The top level bash script would have to have support for compiling 15 languages if we go by Codeforces options. This also now has to be maintained as new versions are released.

The two solutions I see are providing a smaller set of baseline starters, like maybe c++14, java8, python2 and 3, Go, and maybe a few others. Then we could either allow users contribute their build scripts as they add solutions with new languages, or take the hit and maintain this Makefile, or allow compilation to be deferred to a build script in their solution if it exists. It'd be nice to have one of these options work though, because a lot of the difficulty for the user would be removed.

Finally, I like the idea of automatically finding the input. The one problem is with different naming conventions for input files. You mentioned input.txt which is what I like to do. I know Mitch likes to do .in a lot. I've also seen people that put input files and output files in their own directory. A standard would need to be agreed on. Finally, if this is done, it would be a really easy step to also have a solution checker that compares generated output to expected output using a diff tool to determine if a solution is correct.

[BrandonLMorris]

We don't need so support every language under the sun (in fact, we shouldn't for purposes of competition cooperation). My point is that there's no need to rewrite execution code for every problem. We should write it once for a given language, and then it's done.

It doesn't matter what the input/output files are named. A solution checker seems like overkill, since it's just the sample input and output. There's no need to reimplement the AUACM judge just to make sure a couple of lines match.

What's the point of all this, anyway? Why are we trying to make it so easy for the user to run the solution when that's not the most important part? I'm under the impression that this repo serves as a centralized collections of solutions to programming problems. If that's the case, running the solutions shouldn't be a real concern for users, since the goal is to learn and understand. After all, if we're assuming that the users are competent enough to write Makefiles and bash scripts, why do we think they can't figure out how to compile and run a solution?

I presumed the facilitation of executing solutions would speed up merging PR's, but it doesn't sound like that is your main purpose of having run scripts and Makefiles.

[jwowillo]

I agree that no execution code is necessary. The only problem is there's no way of marking how a user should build run the program otherwise. If we are solely treating at as something you read, instead if running, I am fine with that.

Given a yes answer to above, we can remove that section from the readme and make necessary adjustments to problem folders.

On Sep 28, 2016 8:55 AM, "Brandon" notifications@github.com wrote:

We don't need so support every language under the sun (in fact, we shouldn't for purposes of competition cooperation). My point is that there's no need to rewrite execution code for every problem. We should write it once for a given language, and then it's done.

It doesn't matter what the input/output files are named. A solution checker seems like overkill, since it's just the sample input and output. There's no need to reimplement the AUACM judge just to make sure a couple of lines match.

What's the point of all this, anyway? Why are we trying to make it so easy for the user to run the solution when that's not the most important part? I'm under the impression that this repo serves as a centralized collections of solutions to programming problems. If that's the case, running the solutions shouldn't be a real concern for users, since the goal is to learn and understand. After all, if we're assuming that the users are competent enough to write Makefiles and bash scripts, why do we think they can't figure out how to compile and run a solution?

I presumed the facilitation of executing solutions would speed up merging PR's, but it doesn't sound like that is your main purpose of having run scripts and Makefiles.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/AuburnACM/Competitive-Programming/issues/2#issuecomment-250173421, or mute the thread https://github.com/notifications/unsubscribe-auth/AISWQCHtRm6XjOUrXZLLU9cmyHrH4UDJks5qunHZgaJpZM4KIyi5 .

[mcprice30]

This may not be related to the above concerns, could we think about potentially organizing the repository so that it is easier to find a problem? Such as adding separate directories for each problem source (AUACM / Kattis / etc)?

[jwowillo]

I guess that depends on what feature you think is more important. Problem source is one way, but you could also organize by problem tags, difficulty, alphabetical, etc.

[BrandonLMorris]

I like organizing by source. Finding tags can be done with a simple grep on the directory

$ grep -r "bfs" .

The same could be applied to problem source if the url is included

[jwowillo]

Per the readme description, the URL is part of the standard header.

[BrandonLMorris]

I realize that. I'm still in favor of separate directories based on source.

[jwowillo]

OK! So I guess since Mitch liked that too and I'm fine with it, it's a consensus.

[BrandonLMorris]

10/10 would consensus again