Why did you choose C++ to base Falcon on, rather than a lower-level language? What are the similarities between the two languages?
I like OOP and I like the power of C. When I decided to go C++ for Falcon, I was positive that I would have used C for the low level stuff and C++ classes to shape higher concepts. All the applications I had to script were C++, or could integrate with C++. Also, I was told by a friend of mine working in the gaming industry that Virtual Calls was actually more efficient than switches, and we have lot of them in a scripting language. I tested the thing out for myself, and it turned out that modern processors are performing really well in presence of Virtual Calls, so many of the common problems were usually resolved with complex ifs, and switches could be resolved with Virtual Calls instead.
At the beginning I used also STL, which is usually much more performing than any dynamic typing based library (STL maps are at least 10 per cent faster than Python string dictionaries), but that carried on a relevant problem of interoperability with other programs. Falcon was also meant to be a scripting engine, and applications often have different ideas on which version of the STL they would like to use. Moving STL across DLLs is quite hellish and it's a deathblow to the binary compatibility of C++ modules (already less stable than C module binary compatibility by nature). Also, STL caused the code to grow quite a lot, and a lot more than I wanted; so, I temporarily switched back to dynamic typed structures, which are slower, to be sure to clear the interface across modules from external dependencies.
Recently, having found that new compilers are extremely efficient on the fast path of exception raising (actually faster than a single IF on an error condition), I have introduced exceptions where I had cascades of controls for error being generated deep inside the vm.
In short, Falcon uses C++ where it can bring advantages in term of speed and code readability and maintainability, while still being C-oriented on several low-level aspects.
This may seem like reducing the interoperability with C applications; but this isn’t the case. One of our first works as an open source project was the preparation of the FXchat scripting plugin for the famous Xchat program; as many know the Xchat plugin API is pure (and raw) C. Yet, the interface blends gracefully in the framework without any interoperability problems, and even without any particular inefficiency, as the Falcon scripting engine is confined in its own loadable module, and the FXchat module acts as a bridge. The code is even simple and direct, and it is easy to compare it against other scripting language plugins written in C that soon get much more complex than ours.
The same can be said for modules binding external libraries. We bind gracefully with both the DCOP library (written in C++) and the SDL library set (written in C), with complete interoperability and no performance or compatibility problems at all.
How is Falcon currently being adopted by developers?
Falcon is still little known on the scene, and with monsters like Python and Perl around, being fed by big institutions like REBOL and Erlang, the diffidence towards new products is great. On the other hand, it must be said that many developers who have been exposed to Falcon have been impressed by it, so much so that they didn't want to be without it anymore! Sebastian Sauer of the Kross project worked hard to have Falcon in Kross and KDE; Dennis Clarke at BlastWave is redesigning the BlastWave open source package repository Web interface with Falcon and is helping in porting all the Falcon codebase to Sun platforms – AuroraUX SunOS distro has decided to adopt it as the official scripting language (along with ADA as the preferred heavyweight development language). We receive many “congrats” messages daily, but as we practically started yesterday (we went open source and begun getting distributed a few months ago), we have the feeling that there are many interested developers taking a peek, and staring from behind the window to see if the project gets consistent enough to ensure a stable platform for future development.
On this topic, we're starting to receive interesting proposals from some formal institutions. At the moment it's just a matter of interest and work exchange, but if things go on growing with the rhythm we've been observing recently, we'll soon need to fire up an economic entity to back the Falcon PL project.