Have you faced any hard decisions in maintaining the language?
Yes and no. Yes in the sense that there have been many no-way-back points, and so the decisions were hard at those spots where I had to chose to do one thing rather than another. For example, when I decided to drop the support for stateful function, a cute feature of the former Falcon language which was used to build stateful machines. Stateful machines were quite useful in many contexts, and having language constructs directly supporting them was interesting. But we observed that the cost of entering and exiting EVERY function was too high due to the need to check if it was a stateful function or not, and this lead to abandon those constructs. So, while this kind of decisions were hard in terms of “harness (metallurgy)”, none of the decisions I made were difficult to take.
Every decision was taken after deep technical cost-benefit analysis, the more the “hardness (metallurgy)”, the deeper the analysis. So, with a solid base on which to decide, and having... hard evidence and data on which to work on, every decision was actually easy, as it was the only viable one or the best under technical aspects.
Looking back, is there anything you would change in the language’s development?
I would have made more of an effort to go open source sooner. The market was already quite full by the time I started, so I was a bit shy in exposing the results of my research to the public until proving that my solution was technically better in their specific application field. But this slowed down the development of subsidiary areas, like the modules. Developers may have been attracted not just by a better approach to some problem, but just by the idea of doing something fun with a new tool. I underestimated this hedonistic aspect of open source, and now I am a bit short of breath having to take care of the inner stuff alone. This is why I am so eager to pass my knowledge around and help anyone willing to carry on the project.
Where do you envisage Falcon’s future lying?
In being a good scripting language. For how tautological it may seem, this is not really the case. Many other languages, even the most prominent ones, have overgrown their scope and now are trying to invade areas that were not exactly meant for untyped, ultra-high-level, logic-oriented scripting languages. If it's true that one must find new limits, and break them, it's also true that there's pre-determination in nature. From a peach seed you will grow a peach, and a planet can be many things, but never a star.
By overdoing their design, they're not evolving, they're just diluting their potential. Our aim is to provide an ever growing potential of high-level control logic and design abstraction, at disposal of both application in need of a flexible inner variable logic engine or directly at the command of the developers; this, at an affordable cost in terms of performance (not with respect to other scripting languages, but with respect of doing things the hard-coded way).