It’s May and 3 years have passed since I decided to give Juce a try, for using with my PILS programming system.
I’ll celebrate this with a summary of my experience with Juce bindings and some thoughts on where to go.
Why Juce?
Juce wasn’t the obvious choice for binding to a dynamic language since it comes with no meta information, unlike Qt, wxWidgets, OpenOffice’s UNO, to mention some of the cross platform frameworks I had struggled with.
Of these, UNO seemed neat, well-structured and fairly well documented but impossible to get working on my MS Windows box. I felt like a kid glaring at sweets in a glass jar without being able to twist open the lid, and no mom to help.
Qt seemed rich-featured and well-documented but its introspection was half-baked and I disliked the preprocessing system and the signalling mechanism. Besides, there were some issues with the licensing before Nokia bought the framework.
So I went for wxWidgets which was a big mess, with inconsistent handling of object ownership and far too much platform-specific code, meaning I had to loads of manual tinkering to create useful bindings and I never could rely on things really working cross-platform.
The feature that made me go for Juce bindings was this method pair:
JUCEApplication::moreThanOneInstanceAllowed()
JUCEApplication::anotherInstanceStarted()
To spare the more sensitive ones among you, I shall not detail the pains it took to implement a similar functionality in wxWidgets. But believe me, it took a month’s work. After that, I decided I’d rather do my own bindings generator for Juce than putting up with wxWidgets - or trying to get to terms with existing bindings generators.
Why dynamic programming?
I’ll also spare you from detailing the wonders of PILS programming here but I will throw in some general remarks on the usefulness of dynamic programming.
Sure, anything dynamic programming can do, C++ can do better and faster, provided you have enough programmer time and know what you want.
But when you experiment with new ideas, interpreted languages can do wonders in short time. They allow you to change critical parts of a program while it’s running, and see the results at once.
For my part, I have exploited this trait in creating specialised code analysis tools with PILS. Changing the search/rewrite rules dynamically while I was working in the app would led to fast and usable results.
But the most important use might be experimental UI design. Being able to adjust the looks of a running application can really boost development speed.
(In my opinion, one of the reasons opensource applications like Gimp etc. are stuck with arcane user interfaces is, the C/C++ programmers that create them don’t know how to experiment with UI concepts because their tools are lame in that respect. Explorative programming with dynamic languages is needed here.)
Also, deployment can be simpler, i.e. you can change the looks and workings of an application by storing parts of it as scripts in a database.
I am sure some of you Juce Geeks & Ubergeeks have had your teeth sunken in Python, Ruby, Javascript or whatever, and some of you might miss the taste and wonder what you could do with Juce bindings for these languages.
I’ll conclude this for now and add something about the strengths and weaknesses of Juce in its present form later, with some suggestions on what might be done about it.
(To the Great Leader Kim Il … oops i meant Julian: I acknowledge your supreme wisdom and I’m not instigating a revolt to throw you off the throne but I do think we need to talk about the future.)