The kind of language stack I'm looking at is, from low to high:
1. Assembly, for those bits that C can't get right.
2. C for those really low level building blocks.
3. C# as a way to glue those C blocks together. Inner loops should be factored into C, not written in C# so that there aren't real performance issues.
4. Something like IronPython or Boo as a more dynamic higher level glue for the C# bits.
5. A custom language for the problem domain for actually scripting the work.
6. A problem factoring language to automagically decide where things fit in the previous 5 languages.
7. Some kind of graphical diagram language so I can programme with a mouse.
You can get monodevelop, mono and boo for the pi. C can be done in either clang or gcc. The problem with Qt is the issue of paradigm lockin: once you're problem domain isn't easily expressed in terms of objects, signals and slots, the Qt paradigm becomes redundant and you have a mass of code in your runtime libraries that doesn't need to be there, and coding structures in your source code that don't properly reflect the problems you are trying to solve.
Ultimately I would like to recraft the language stack so as to reduce the code requirements. That is a long term objective of mine.
Oh, and a 64k demo that requires 64meg of shared runtime library is kinda ugly compared to a 64k demo that runs baremetal on the processor: the former makes your demo like a magic ignition key for a car that someone else has built, and I'm more interested in actually building the car than how the key is made.
