В рамках серии The A-Z of Programming Languages появилось интересное интервью с Джанкарло Николаи, разработчиком скриптового языка Falcon.
В первую очередь, интервью отличается (на мой взгляд) от предшествующих. Поскольку посвящено подробному обсуждению причин, побудивших Николаи на разработку собственного языка, и целей, которые им преследуются. Т.е. речь идет не о каких-то давних воспоминаниях и не о текущих взглядах на жизнь конкретного человека. А о процессе развития живого и растущего проекта. Такие вещи меня сильно впечатляют.
Но, пожалуй, больше всего мне понравилось очень здравое и взвешенное описание причин, по которым Николаи решил использовать в реализации Falcon-а C++, а не C:
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.
После длительного участия в священных войнах на профессиональных форумах, такие слова воспринимаются как бальзам на душу. А то уже очень неприятно наблюдать помойки, вроде обсуждения выхода новой версии компилятора FreePascal.
Ну и сам язык, Falcon, после прочтения интервью заинтриговал. Создан с прицелом на высокую скорость исполнения и легкую интеграцию в host-приложение (в том числе, как я понял, удобное отображение внутренних структур host-приложения на объекты Falcon-а). Года полтора назад мне пришлось заниматься добавлением возможности скриптования в свой большой C++ный проект. Тогда после анализа возможности интеграции Ruby (очень медленный), Python (специфический синтаксис) и Lua (очень быстрый) я выбирал между Lua и собственной реализацией языка. Выбрал, в итоге, собственную реализацию, поскольку благодаря Curl-подобному синтаксису там было просто реализовывать предметно-ориентированные языковые конструкции. Хотя, конечно, читабельность if-ов и switch-ей пострадала. Если, со временем, придется сменить собственный велосипед на более традиционный скриптовый язык, то обязательно рассмотрю Falcon.
Комментариев нет:
Отправить комментарий