- Rename the repo to be shared and add yourself as a contributor, instead of branding it as yourself.
- Organize the files by src/ALGO/LANG/author-name.EXT. That way the emphasis is on the algorithm, then the language. I don't care much about who implemented it, other than to differentiate it from others' implementations for quality, etc.
- Provide a common-ish API. You don't want to stick your entire algorithm into main(), that's not useful. You want a nice clean interface, so that the consumers of this repo can copy-paste these clean implementations into their own code. Maybe remove main() entirely, and stick it into src/ALGO/LANG/main.EXT. That way I can consume an entire file from your repo without modifying it.
- Provide unit tests. If you separate out main(), you could do stick all the tests into src/ALGO/LANG/tests.EXT. The value of this type of repo would be that I can grab a clean, well tested copy of -sort and use it directly.
- Edit: Change from underscores to dashes in filenames. Underscores are for losers :). Use dashes whenever you can.
- Add lots more algorithms, not just basic ones.
- Get a few friends to add some algorithms, then thoroughly review them in comments on GitHub.
- Provide speed test comparisons of each implementation, stick them in src/ALGO/LANG/speed-tests.EXT
- Now that we are getting fancy with the testing, etc., provide a Makefile or some such for building the various test programs and running unit and speed tests on them.
- Edit: Stub out lots of potential algorithms. Even if you don't know how to implement them, create the directory and main.EXT for them, then open a ticket so that others can implement them. Give everyone that submits a pull request committer access, so they might work directly on this repo and not deal with any friction by having to wait for you.
There is probably more, but the above would eat nicely into that first 100 hours. I have no idea what you'd personally get out of this on the other end. Probably nothing. On the other hand, this could become the repository to check for a weird "2x faster with smaller memory usage" implementation of a red-black tree, or a clever general number sieve, etc.
You have a ton of great suggestions in here, all taken into consideration and this will definitely help the repo be much better by tomorrow. I will get on it. Thank you.
Most helpful post in the thread vs. "lel it's already been done xD links to wiki site"
>On the other hand, this could become the repository to check for a weird "2x faster with smaller memory usage" implementation of a red-black tree, or a clever general number sieve, etc.
Precisely my aim. Thanks for understanding this!! Apparently other people think I'm trying to make it a primary learning resource or something...
I recommend you comment out all code, write the tests and then un-comment the code line by line.
This not only tests the code, but tests the tests and assures that you are covering the edge cases the code contains already.
// Kendrick Ledet 2013
As if git blame wasn't enough, let's stick our full names in every file prefixed with our name. People have got to know that I'm the one who created this sample algo code!! <waits for applause>
I'm not exactly sure what you're getting at here, or why you're trying to be funny in what I wanted to be a relatively serious affair. The implementation as well as the comment were both written way before I even had the idea for this repository.
Also,
1. Kennyledet just so happens to be my Github name. The full name comment at the top is not a listed convention.
2. The convention of putting your github username is actually a feature. Do you suggest just clumping everything together under one algo folder, where filenames could be similar and possibly conflict? :)
Again, it's not about people discovering me, it's about making this popular on Github so more practicing programmers can share, discuss and learn new algorithms. Please think more logically here..
P.S., I know what git blame is. Don't try to undermine the point here. I wanted the file structure to be flat and adhere to those conventions for more reasons than you probably think I have. You're welcome to start your own repo and try and get it as active as this one has within 2 hours...Then I'll close mine.
Thanks.
Please don't get the wrong idea. Clearly it's not about me. If you have a suggestion to keep things more "unbranded", let me know. I could just put it under an organization.
Also, I think the organizational style on Github is more suitable for what this has the potential to be.
I would love if I could clone the code on RosettaCode to my machine, add things, and send the change requests right back from the power of the command line. We're both programmers, so of course we know it's doable with code. And I could go ahead and code that script. However, it's not really practical.
Thanks though, you just gave me a new idea for a command line utility (not just limited to Rosettacode's wiki)
P.S., I will add a link to it in the README.
See: https://github.com/WardCunningham/smallest-federated-wiki
I have been planning to join a few competitions, and definitely some hackathons in 2014.
This is great practice, and I encourage you to go for it, but for those interested in looking at algorithms implementations, or looking to cut their teeth and contribute implementations, I'd encourage you to look at already existing algorithm repositories.
>instead
Look guys, this is not trying to replace anything. It's something new. It should be supplemental to one's journey, I'm not trying to pass this off as some attempt to be even the main resource for learning algorithms. That would be foolish.
>This wheel was invented, but it's better for traction in the snow
We really need to stop holding ourselves back so much in this field, it's not really proper for us.
Thanks for the link though, it will be added.
Right now I have algorithms implemented in Go, Java and C/C++
https://github.com/learnalgorithms/datastructures
Accepting contributions :)
There is however a definitive resource on the web: http://calgo.acm.org
