The reasons why are enumerated after the jump.... (Update 9/3) see below
#1: Maintain > BuildMaintaining any codebase is way harder than making it. Waaaaaay harder.
I've been presiding over a rewrite of my own toolset - one that is only 2.5 years or so of my own work - and I'm amazed and appalled at how crufty it is. Lots of important things are held together with spit and bailing wire. Lots of trivial things are massively over-engineered. And -- though I pride myself on being good about code reuse, there's-only-one-way-to-do-it, and extending earlier solutions instead of reinventing things -- it's full of pointless duplication.
And even though it's 90% my own work it's full of conflicting style choices and paradigms. I guess it shows I'm still learning, so I haven't gotten totally stale yet.
#2: Dynamic > StaticI've been looking a lot at possible language alternatives to Python for future tools. I love Python. I mean, in a totally unhealthy, creepy, even stalker-y way. But I don't like being to beholden to any one tech or approach. I'd love to get beyond Python's erratic distribution mechanisms, and Id' really like to get my hands on a decent GUI toolkit that didn't make me program C++ indirectly ( Python Shoes, where are you?)
So, while tinkering with Boo, Cobra, Nimrod and a few other options I've been revisiting the old theological debate about dynamic vs static languages; working on Moonrise (in Unity) has made me realise that C# was designed with the express intention of driving me insane. It seems routinely true that I write 4 times as many lines of C# as I do in Python. I'm sure I'm saving a few bugs because of all the clunky type management stuff, but I think I'd rather just fix the bugs than suffer through the oceans of boilerplate that C# induces.
To be fair, it's a little worse in Unity than in the rest of the world: you can do a lot to make C# suck less using attributes and reflection and other meta-techniques, but those are tougher to do in Unity's special flavor of C#.
Still, I think I've finally made up my mind on this one: I'd rather take the risks that come with dynamic code over the sheer, mind-numbing boredom that comes with obsessive type safety. Especially in a world where overhauling and updating and refactoring code is the real work: building it is just the first chapter.
#3 I hate curly braces.I'm not even trying to deny it anymore. I hate the little bastards. What a waste of space.
#4 I'm ScrewedThe interesting problem - if I end up just getting cozy with my prejudices and preferences - is now how to pick a decent dynamic environment for tools development while (A) not having the code base degenerate into mush and (B) having decent GUI options. And if at all possible, (C), no goddam curly brackets.
The stinky part is that, for the given problem set there really is no obvious winner.
- I could imagine that the combination of Ruby and Shoes would be super productive, even though the Shoes GUI is pretty limited compared to QT or WPF. I could probably tolerate those block ending markers in Ruby, and there is a good set of standard library code out there. The perf is not great but that's my least important problem. I don't think it's much easier to distribute Ruby apps to users than it is to do with Python, however.
- Nimrod looks like a cool little language, but has no equivalent of the Python standardlib.
- Boo and Cobra both use the same CLR as C#, so theoretically you can use them to drive GUI apps with WPF or winforms, but that puts you right back into programming a clunky language through the medium of a nicer one: if I wanted that I'd stick with PyQT.
- (update 9/3): For completeness sake I should mention the combination of Jytron and AWT or Swing. This works right out of the box - if you have Jython, you have a complete GUI toolkit with no downloads, installs or DLLs to manage. You can also compiile Jython to executables, buit it's not a completely transparent process and it seems a bit fiddly. Still, could be an optiom....
- (ipdate 9/3):: I've also been experimenting a lot with compiling IronPython to exes using the IL compiler that comes with IronPython. So far it actually looks pretty good: the exes are smaller than similar Py2Exes or PyInstaller projects and they seem to be less prone to obscure compilation problems too.... maybe some light at the end of the tunnel?
TLDR: There really is nothing that fills the niche of a powerful, flexible language with good GUI and distribution options right now. Sigh.
Please, prove me wrong !
Please, prove me wrong !