The A-Z of programming languages: Falcon

1 2 3 Page 3
Page 3 of 3

In 0.9 we have introduced an interthread garbage collector that accounts for objects present in more virtual machines. This is already exploited via the sharing of MemBuf instances, but we plan to extend this support to other kind of objects. For example, it is currently possible to send a copy of a local object to another thread via an item queue (the underlying data, possibly coming from a module or from an embedding application, can actually be shared; it's just the representation each VM has of the object that must be copied). This makes it a bit difficult to cooperate on creating complete objects across threads, and even if this works in term of agent-based threading, we're planning to use the new interthread GC system to be able to send deep items across threads. Since 0.9, it is already possible to create deep data externally (i.e. in the embedding application or in a module) and send it to a VM in a different thread.

The only problem left in doing it natively across two different VMs is ensuring that the source VM won't be allowed to work on the object and on any of the data inside it while the target VM is working on it. Even if this may seem a limitation, it's exactly what the "object monitor" approach to multithreading dictates, and it is perfectly coherent with our view of higher level parallel abstraction. 0.9 version also introduces the mechanism of interthread broadcasts, with message oriented programming extended to interthread operations. We still have to work that out, completely, but that's the reason why we're numbering this release range 0.9.

Finally, as the VM have native multithread constructs now, we may also drop the necessity to have different VMs for different threads, as each thread may just operate on its own local context, while common operations on the VM (as loading new modules) can be easily protected. Still, we need to consider the possibility of multiple VMs living in different threads, as this is a useful model for embedding applications.

How can a software developer get into Falcon development? Easily. We can divide the support you may give to Falcon in mainly five areas. I rank them in order of weighted urgency/complexity ratio.

1. Modules. we need to extend the available features of the language, and modules are a good place from where to start, both because they are relatively simple to write and build and because they put the writer in contact with the VM and ITEM API quite directly. At the moment we don't have a comprehensive module writer's guide, but examples are numerous and well commented, and the API of both the VM and items are extensively documented. A skeleton module is available for download from our "extensions" area on the site, and provides an easy kick-off for new projects. Some of the most wanted modules and bindings are listed here.

2. Applications. We'd welcome some killer application as a comprehensive CMS written in Falcon, but even simpler applications are welcome.

3. Extensions and embeddings. As a scripting engine, we welcome people willing to drive their applications with Falcon. For example, the binding with Kross into KDE applications. We have a cute scripting engine binding for XChat, and we'd like to have for other scriptable applications (other IM systems, editors, music players etc). We need also to extend the existing HTTP server module binding engine and to apply it to more servers. At the moment we only support Apache.

4. Falcon core. Maintaining and extending the core system, the core module and the Feathers is still quite challenging: the 0.9 development branch has just started and we need to exploit the most advanced techniques in terms of memory management and compiler optimizations existing around, or finding new ones. We'll introduce at least two more paradigms in this round; logic programming and type contract programming, and there's plenty to work to do on tabular programming. The area is still open, so if you really want to get the hands dirty on the top-level technology in the field, this is the right place and the right time to give a try at that.

5. IDE. We need an IDE for development and debugging of Falcon applications. A terribly interesting tool would be an embeddable IDE that applications may fire up internally to manage their own scripts (consider game mod applications, but also specialized data-mining tools). Falcon has a quite open engine, and integrating it directly into the environment shall be easy. I put it for fifth as an IDE is useless if the language doesn't develop the other four points in the meanwhile, but having an IDE ready when the other four points will be satisfactorily advanced would be really a godsend.

Jumping in is easy -- just get the code you want to work on from our SVN (or make a complete installation of Falcon + dev files and install the skeleton module if you want to write your own extension) and do something. Then give us a voice through our newsgroup, mail or IRC, and you're in. Developers may join as contributors and enter the Committee if their contribution is constant and useful.

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 predetermination 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).

This story, "The A-Z of programming languages: Falcon" was originally published by Computerworld Australia.

Copyright © 2009 IDG Communications, Inc.

1 2 3 Page 3
Page 3 of 3
  
Shop Tech Products at Amazon