Diversity is coming back in the world of programming languages and it is not just a matter of new platforms driving new languages – people are getting interested in the idea that they can use different languages to get different benefits; the idea that one language is good enough for most tasks is a sophism, say some developers.

“Falcons have always been
loyal men’s servants, but
proud and noble. It was just
perfect; it wasn’t just the
name of the person that
inspired me to dare, it was
also exactly fitting what I
wanted my language to be:
fast, elegant, loyal but
noble and proud.”

It is an argument taken up by Giancarlo Niccolai, a native of Bologna in Italy, and the creator of Falcon – a language that is gaining rapid popularity – not an easy thing to do given that it is up against titanic competitors such as Python and Perl but he believes that its twin benefits of efficiency and productivity are compelling words in hard times.

He claims that even the most prominent scripting languages 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 here is one thing I’m proud of in Falcon, it’s that it wasn’t born for the most exotic reasons, but to address the problem of integration and empowerment of massive applications on one side and the necessity do solve complex logic and highly mutable problems on the other. Or, in other words, it was born as a necessary tool.’

RM: What was the chief reason for developing Falcon? GN: For a brief period in 2000-2001, I needed something to speed up the development of some client-server applications with extremely complex configuration options, but we were trying to stuff too many complex things in it and anyhow, it was a never ending new need – new code – new config cycle. Something more flexible was in order.

Once I’d decided to plump for a scripting language and saw some opportunities to employ it to make streaming message processing more flexible. So I began looking for a suitable ready-made solution, but couldn’t find one.

Adapting Python and Lua would have required too much coding, and it would have been “private” code, that is, code that the communities of the two projects wouldn’t have liked to include. There was too much “flexibility” in them, which had an excessive cost and which I didn’t need.

The fact that Python objects were (possibly mutable) dictionaries was a feature I didn’t need. To make the second part of my plan work, I needed external objects to be wrapped into very small structures and be sent in the script as they were; and that, in a multithreading environment. Shaping down those two projects to my needs was going to take more or less the time I supposed I would have employed in writing a smaller but more focused language.

So, a number of reasons led me to write the first nucleus of the current Falcon: “HASTE”, a very small language with a basic VM, which at the time, performed even better than Lua’s and had already some interesting features. For example, methods (functions + objects they are applied on) as first-order items is an invention dating that time.

The project I was working on stopped after a few months as did the development of HASTE. I decided to “complete” it and to rename it Falcon on the 10th anniversary of Giovanni Falcone’s death (Italian magistrate who was assassinated by the Mafia on May the 23rd, 1992. He specialised in prosecuting the Sicilian Costa Nostra.) RM: How did the project go live? GN: As I was walking home from the railway station, I thought that I had this little project in the drawer, and that it may have been the contribution I was striving to give. I thought at how beautiful “Falcon” name was (Falcone in Italian means Big Hawk, Falcon). Falcons have always been loyal men’s servants, but proud and noble. It was just perfect; it wasn’t just the name of the person that inspired me to dare, it was also exactly fitting what I wanted my language to be: fast, elegant, loyal but noble and proud. There have been times when I had to shelve the project, but I began work on it again in 2006 when I was hired by a firm writing software for financial markets.

We had some problems related to real-time financial message processing and monitoring, and when I proposed to use Falcon to address the problems, my boss was very enthusiastic. So, the development began again but this time the outcome had to be industrial grade so to speak, everything was kept open-source, and I put a bit of extra effort to develop the language and its site beyond the mere needs we had at the time. RM: Was there a particular you were trying to solve when you designed the language? GN: The main aim was to allow flexibility at the smallest possible performance cost, and keep the virtual machine and the binary code as compact as possible. It had be embedded into applications and handle objects with high throughput rates, and that meant creating the smallest possible structures around native objects shared between several concurrently running virtual machines in multithreaded applications. When that goal was achieved, I started thinking I could
have used the system to implement also some higher level abstraction that wasn’t easily accessible to other programming languages.
 
The best scripting and untyped language will always be so many times slower than the worst compiled, statically typed language. The payback in using scripting languages must be found in more abstraction and higher level logic profiling of the software solutions. So, other than being as fast as possible, a scripting language must also be as powerful and extensive as possible, and this is the reason why, fulfilled the first goal, we moved into the secondary goal of covering the widest set of programming paradigms we could.

Now we’re focused in creating a programming model which is not just a choice between different paradigms (I.e. OOP vs functional) but that is exactly a merge and an extension of all of them into the others. RM: Why did you choose C++ to base Falcon on, rather than a lower-level language? Does it help with efficiency? Are there similarities between the two languages? GN: C++ doesn’t prevent going low-level. You can use as much C and assembly as you need, even if you’re using a C++ compiler. For sure, C++ also helps with efficiency, as the C++ compiler can take care of things that are required to handle at runtime in C (for example, virtual table displacement is resolved at compile time; using a C structure holding a function vector may require an extra runtime indirection), but the main reason of going C++ was that of being able to access the class abstraction. That allowed faster and more consistent prototyping of some items in Falcon, without forcing us to renounce managing raw memory blocks when the need arises.

Saying that, Falcon and C++ are quite different; I often advise the people involved with the project not to write “library bindings”, but full Falcon-oriented modules. For example, some aspects of modules may be more message-oriented, other may be better addressed by a functional approach, and others yet may be well managed by class hierarchies. You don’t have all this freedom, and thinking in C++ would limit what you can do in Falcon. RM: But are you reducing the interoperability with C applications by doing this?  
GN:  Absolutely not. It is little known, but C++ and C are inter-operable in both ways. For example, Apache web server is a C application, and it embeds Falcon via a mod_falcon which works similarly to mod_php; another pure C application perfectly embedding Falcon is the famous IRC client
“xchat”. A simple comparison with the Python embedding plug-in (written in pure C) shows that our C++ xchat plug-in isn’t minimally disturbed by the fact of being embedded in a C application; on the contrary, the design is clean and the code flows even more elegantly.

At the same time, we have modules linking with pure C libraries, as MySQL, GD2, GTK, SDL and so on, and there isn’t the minimal need for wrapping or bridging across them. RM: How can a software developer get into Falcon development? GN: Easily. Two things:

1) Step in our chat channel at #falcon@irc.freenode.net or also through the chat client in the “contacts” area of our site; or

2) send a request clicking the button “join now” at our site. In this case, as long as the traffic allows me, I personally reply and ask for what the developer would like to do.

There are plenty of things to do in all the areas of the project, from documentation to web design to Falcon based application design, to library binding and module writing. RM: Looking back, is there anything you would change in the language’s development? GN: Of course.  In the original design, a compiler created the bytecode which was totally closed and static. It was then possible to feed a module multiple times in multiple, concurrently running VMs, which would have used it read-only, and created a local image of the varying data. 10 years ago, with totally different technologies powering embedded devices and supporting mission-critical applications, this was a very sensible solution, which had also the advantage of exploiting each bit of the rare multithreading resources while minimizing the footprint of each running element.
 
Today things have changed, and the bits spared in separating static bytecode from their runtime representation is not worth the cost in term of complexity needed to support this model. Also, while Falcon was never thought as a REPL oriented language (it was designed to be compiled and run in separate locations, as i.e. Java), some of the paradigms we’re now willing to include are better served by a REPL enabled engine. This is why we’ll be moving towards flexibility, even at
a cost of some performance in the raw VM loop, and we’ll complete this change in version 0.9.8. I am keeping track of the changes we’re introducing in my personal blog, and discussion is open.

However, this will be a one-way change; after this, the engine will keep its current aspect until at least version 2.0.

After 0.9.8, we’re completing the design of version 1.0 with type contracts and logic/constraint programming (and more functional programming with the introduction of symbols as first-order items); very possibly, native fuzzy logic (with fuzzy variables) will be in the picture. Then, we’ll optimize everything and reach 1.0 adding the optimization we never had the time (or actually, the stringent need) to introduce.
RM: What are your debugging tools? Debuggers, Printins or something else? GN:  Everything, depending on the conditions and on the needs. GDB and MS Visual Studio are usually my best friends, but there are times when they can’t help. Debugging a MT application in a step-by-step mood is rarely bearing interesting results. In that case, I put a #include <stdio.h>
on top and start printf’ing sensible code areas. I cherished the idea of adding some tracing functions you could turn on-off at compile time but I never found bugs hard enough to resist a couple of hours of printf’ing, so in the end, I always thought the effort wasn’t worth it – in Italy, we say that ‘the game isn’t worth the candle.’ RM: Do you think programmers are overly in love with new things such as new languages and new tools? GN: I’d say it was very much the reverse. Programmers are curious about new tools and new things in general, but they tend to develop affection towards programming languages and other kind of commonly used tools (for example, editors). It has something to do with habits and more consistently with learning curves, but it’s also more profound.

Once you create a complex system composed of yourself, a way of expressing your ideas through a language and the tools that allow you to express those ideas becomes something rather special.  De-constructing this system to compose a new one requires energy, will, and believable hints that the system that it’s going to be formed will be better than the previous one.

And worse: there’s just an objective, tangible and real cost in de-constructing your old system and creating a new one. There is also a psychological attachment that goes beyond the mere real cost of change. It’s an affection related to the fact that one tends to highly value the choices he makes, especially when they involve a great cost of some sort. One prefers to be right than wrong, and changing means also changing mind. And it hurts. RM: Most innovations in software have emerged from experience and experiment, without any appeal to an underlying theory. When John Backus invented FORTRAN, he had no theory to work by. What is stopping the same thing happening now? GN: Who said it’s not happening anymore?

Theory is relevant; I learned that multithreading is really all about theory and mathematically proving that there aren’t unexpected paths in your logic: if there is a chance over a billion that you cause a deadlock because of bad timings on a certain operation, you’ll just have to wait a few seconds for that operation to be repeated billion of times, and to witness the deadlock. In functional programming, definition of the problem, and meta-definition of the tools needed to solve it are everything you have. In databases, transaction definition and theoretical normalization are what saves you the day. So theory is indeed relevant.

But it stops to be relevant after you’ve dealt with it. Once you’ve done your math, you’re then alone with your problem again. Programming is solving problems given constraints, and once you managed your constraints, you still have your problem to solve.

So, innovation is and will continue to emerge through experience and experiment, and most notably, it will emerge to address some real problems people face. RM: Are there skills apart from programming that you think would-be programmers should develop? GN: The ability to learn certainly. A programmer should be able to learn a new programming language in 3 days, given a decent manual.

What must be cultivated first and foremost is the ability to find the most essential elements of a problem, and the new problems that a given solution may bring.  I think a programmer must also know their limits, and be able to acknowledge their errors. Programmers are creators, and feeling the power of creation tend to boost your ego. The most dangerous peril that a programmer may confront is being a slave of his own ego, which sometimes brings the inability to see one’s own faults, and to estimate its own limits. We do errors. The sooner we’ll admit an error, the sooner we’ll be able to fix it, the less our professional stance, and lastly our own EGO, will suffer from it. RM: Would you still do programming for fun even if you quit tomorrow? GN: For sure, I have tons of interests. Music, oriental literature, linguistics and so on, so I can’t say my life would be empty without coding. But coding defines what I am; it’s a need, so I can’t say I program ‘for fun even if I get tons of fun while coding.