Ian Bicking: the old part of his blog

Re: Falcon

Just saw an announcement about Falcon, a new programming language (via). Reading the documentation, it seems quite reminiscent of Python, or maybe it's just that I'm not getting a wide enough perspective. Anyway, following similar posts on Boo and Prothon, here's the differences with Python that I can see:

I can't say what Python has that Falcon doesn't (since I don't know Falcon), but it's probably quite a lot. Many parts seem somewhat sloppy -- like load -- and make me think of it more like Tcl or Lua than Python. The author uses the term "scripting language" a lot. I honestly can't figure out what it offers; it doesn't compare itself or justify itself with respect to other languages. Considering its similarity to Python (since there's many more points where they are identical, compared to these points where they differ) it would be nice to see a why-Falcon-instead-of-Python document or something. Actually, I don't know Lua, but if I did I suspect I'd see strong similarities there as well.

If this were a language based on Parrot (if it was ready), or .NET, or the JVM, it could be a plausible language to use. I don't really get it as a standalone language, though -- the investment cost is too high for very little return.

There's a thread of discussion here, though it seems to focus on lambdas, because functional programming obsessives care about lambdas and equivalencies even when most programmers are busy thinking about programming (okay, maybe it's just that I'm tired of Lambda The Ultimate discussions).

Created 17 Feb '05
Modified 18 Feb '05


Looks very very similar to Lua (www.lua.org).
# Jonas Galvez

I think being implemented in C++, this has one of the same problems Prothon had. There are no standard libraries or existing 3rd party libraries that you can use. You can't directly use Python modules, .NET libraries, or Java libraries. You have to start all over. No GUI toolkit, for example. Other languages like Jython, Groovy, IronPython and Boo don't suffer from this problem.

You might also check out LiveLogix. It runs on top of the CPython VM, so you can still use Python modules.

# Carson

Thanks for your reviewing; I am absolutely pleased you found many things in Falcon "kudos"; for the rest, we'll do something before beta ;-).

Some note about Falcon:

Falcon is not meant to build BIG applications out of it. I.e. this is a clear statement in RUBY (a language capable to do small + large apps), and this is also somehow claimed but never quite attained by Python. The target of Falcon is to be fast enough to be a sensible choice over C for some duty, embeddable and powerfull to do small thing quite well. Also, yes, to be C++.

You know there's no problem in linking C in C++; the other way around is often more hacky, and that's was the reason of my choice. Also, I have proof of the fact that C++ compilers provide better optimizations for quite a lot of things. Finally... the api is more clear, and that's important to me.

A couple of precisations: - About try/catch; actually, what you are going to catch is 99% an Error class or subclass item. The fact is that in 99% of the progrmas I noticed that selecting which kind of error have been raised is just a pain. So, if you really need that, you may easily use the switch statement over the error variable to detect it's error type. Remember that you don't have switch in python... so, having a pre-branch has more sense.

However, this is not a (completely) fixed decision. I may introduce a per-type or per-class catch filter later on, but the catch-all catch statement will stay. Also, the Falcon VM provides unstoppable exception, that may not be handled by scripts; they are not present in Python (i.e. you can block a syntax error if you use a catch-all statement), so a catch-all statement as LESS sense in python...

Falcon is alpha. It may change a lot before beta, but I am currently quite satisfied with it now; I am just making module serialization more clever and much smarter object data access, but for the rest I am really happy with it. For the ppl that was lamenting lack of GUI, I will add an embedded AWT (abstract windowing toolking), something like the Java one but more focused on GTK concepts (that is, intelligent placement instead of fixed one, unless otherwise specified). So we'll have an AWT and many DRIVERS that will provide the AWT with real output.

Bests, Gian.

# Giancarlo Niccolai

Oh, I forgot. About namespaces, I don't think they are necessary in untyped languages, especially not namespaces a-la-python. A very similar thing may be easily implemented by exporting a singleton object with the same name of the module, if the need arises.
# Giancarlo Niccolai