The Okopipi Project

"This program requires another 20Mb download, a whole shedload of diskspace to install and will eat up 128Mb of RAM" is NOT acceptable for this project.

Say no to any kind of runtime engines - unless you like living in a nightmare of failed installations, big downloads, bloat, ugly programs, hacks to get at low level system functions, etc. Java and C# shouldn't even be on the list of candidate languages.

Small, lean, efficient. That should be goal #1. People who say otherwise are just daydreaming hippies who never wrote a real program or one which had to be installed on millions of machines.

Similarly, Python et. al. - nice theory but it's not going to work out in practice. Python works well when you're hacking around on your own machine and, yes, you can knock up a mickey-mouse program in no time at all. In the long term though it's a false economy and you'll run into the exact same hacks and distribution problems as Java, C#, etc.

By "hack" I mean that when you step outside what the nice runtime library can do then you end up in a nether world of a half baked kludge to map your fancy language onto the low level operating system functions/useful library you found on the web. As soon as this starts happening then you might as well be using C++. I suspect that this project will have an awful lot of this sort of code.

No, what you need for idiot-proof distribution/installation is a single ".exe" file, and a couple of dlls for essential things like cryptography.

You could choose C but why go back to the stone age? C++ has a zillion advantages over C in terms of reliability, scalability and resource management. In a team project C++ has even more advantages because of namespaces, etc.

I submit that for a tray-app which needs to run 24 hours a day, use as few resources as possible, be portable, use lots of low level networking functions, etc. then C++ is the right choice.

Now, problems:

The biggest danger is that the C hacks get into the source code and mess it all up. You're going to need to rule the souce code with an iron fist to avoid this. Anybody who doesn't rely on stack unwinding, reference-counted pointers, etc. for resource management should be prevented from contributing. If you don't understand that last comment then you're the type of programmer I'm referring to, please refrain.

Anybody who types "new thing[]" instead of "std::vector" should be kicked off the team until they've read and *UNDERSTOOD* a few C++ books (and the C++ FAQ!). There whould be *NO* exceptions to this rule - it's a great big red flag that the person simply doesn't grok c++.

Once you've got a few competent C++ programmers working on the core then you can let the hackers work on the user interfaces, etc. Define some nice glue logic between the core and the outside world and let them fight it out to see who can make the nicest/most reliable user interface.

My $0.02...