Music Player Ideas - Part One

So it's been a while since I've done any Muine work or even anything at all since my computer has been out of order and I have been too busy and broke to get it set up again. Well, things are changing, I've got some parts on the way and we'll bring this blazing fast Pentium II back up to suck my life away chasing bugs sometime next week.

So, to get a jumpstart on this whole shift back to hacking (it's cold and icky outside anyway), here is a brainstorm for my next project. This post is similar to the one I made a few months ago (note the "Gnome 2.18! Booyah!" ~ Gnome 2.20 was recently released on its six month time-schedule).

I'm not seeking to terribly re-invent the wheel, although music players are a dime-a-dozen now. What would make my player stand out from the crowd? Well, having worked on Muine a fair bit, most of my ideas are realized in that project. However, I have my own objections to other ideas and design decisions.

I think the name "Calliope" is not taken and might work. So, let's go with that. What would Calliope look like, to the user and the programmer?

Coding for a new project
(User interaction to follow)

1. Written in .Net/Mono. If glue code is needed, consider generalizing it in a seperate library. This incurs an unfortunate overhead compared to C/C++ but I believe it is well worth it.
2. Written in Boo. Boo is a beautiful little language inspired by Python. I came from the Perl/Python/Ruby world with little C/C++ experience (my skills are still poor). I loved the .Net platform for it's power in sharing libraries (even ones written in C) and statically-typed nature. Many bugs which show up in runtime with interpreted languages instead show up at compile-time in compiled languages. Like essentially everyone, I strongly associated .Net with C#. However, I loathed having to type far more than I believed I needed to in order to get my point across. Boo is much more intelligent than C# but is a .Net language so it's fully interoperable with other .Net languages such as VB.Net, C# and Nemerle. As the Boo homepage puts it, Boo is "a finger friendly language."
3. Designed to be portable. No *nix-isms or Gnome dependencies (like Muine). Even possibly consider seperating the front-end from the back-end and making the front-ends pluggable. We don't want to turn into "crazy theme heaven" but it'd be nice to make it look like Windows, Mac, Gnome, or KDE on their respective platforms rather than a one-size-fits-all model. If statement 1 is followed, it may be possible to even run on different platforms without recompiling!
4. Tested from the beginning. Unit tests and other forms of automated testing can be very helpful. I went from simply running the program and doing a couple simple tasks and hoping it didn't crash to making much more robust programs and libraries that were unit tested, thus catching many bugs automatically. It's much easier to start with testing than to implement it later. At first it feels awkward and inane but it is well worth the extra bit of effort. Before you commit, write unit tests. Always do bounds-checking. NUnit is the unit testing suite par exellence.
5. Documented. They say, "If it was hard to write, it should be hard to understand." Well, "they" obviously never had to work on a collaborative project or even come back to one several months later. Perl is joked about for being a "write-once" language because you can never decipher what it was that you had hacked together. I'm not suggesting full-on formal comments that take more space than the actual code, just a quick summary and notes. I haven't tried it yet but the Natural Docs parser looks nicer than the C# XML comments.
6. Easy to build. The NAnt build-engine is much superior to 'make' but requires awkward, long-winded XML. I have written a set of XSLT scripts called AutoNant to make everyone's life much simpler. It requires a standardized code tree though and doesn't support multiple directories under src/ (which, IMHO, is good because it forces people to split off libraries). Symlinks are used to tie the whole system together, including dependencies so you can build the whole shebang if a library changes. Of course, this means it doesn't work on systems which don't support symlinks (namely, Windows XP and earlier ~ Vista has mklink, which should work) but for distribution, the whole thing can be tar'ed up with dereferenced links (thus importing copies of dependencies' source if they are small and obscure).
7. Well-organized. Organizing your code makes life easier. I use a pattern of: Objects, Variables, Constructors, Properties, Public Methods, Private Methods. Each section has a header and within that section, all methods are alphabetical and sub-categories are defined if needed. Please don't make 1000 line classes or 100 line methods. I also try to call only one method per statement (thus: foo (bar (baz)); becomes: bar_baz = bar (baz); foo (bar_baz);). This seems to help keep code clear. I'm simple-minded, I know so things need to be kept in short phrases. Indeed, 80 (78, actually) characters is about right (I don't indent for namespace or class so that saves a few) for reading without being crazy verbose and jamming too much on a line. Finally, use tabs to line up statements please, that's why God invented them.