Add 2017-08 scripting research article

README.md

@@ -0,0 +1,21 @@
+# Overview
+
+This is a work in progress. This example is used to evaluate
+[Pelican static site generator](http://getpelican.com) to power
+Opensource Game Studio home website.
+
+# Usage (internally)
+### Generate local copy
+
+`cd pelican`
+
+`pelican -s pelicanconf.py`
+
+### Serve local copy
+
+`cd output`
+
+`python -m SimpleHTTPServer`
+
+The site is served at [http://localhost:8000](http://localhost:8000).
+

pelican/content/articles/2017-07-openscenegraph-guide-ru.md

@@ -1,5 +1,5 @@
 Title: OpenSceneGraph cross-platform guide
-Date: 2017-07-01 00:00
+Date: 2017-07-17 00:00
 Category: News
 Slug: openscenegraph-cross-platform-guide
 Lang: ru

pelican/content/articles/2017-07-openscenegraph-guide.md

@@ -1,5 +1,5 @@
 Title: OpenSceneGraph cross-platform guide
-Date: 2017-07-01 00:00
+Date: 2017-07-17 00:00
 Category: News
 Slug: openscenegraph-cross-platform-guide
 Lang: en

pelican/content/articles/2017-08-scripting-research-ru.md

@@ -0,0 +1,60 @@
+Title: Изучение скриптования
+Date: 2017-08-16 00:00
+Category: News
+Slug: scripting-research
+Lang: ru
+
+![Изучение скриптования]({attach}/images/2017-08-scripting-research.png)
+
+Эта статья описывает изучение скриптования в июле 2017.
+
+**Наша основная цель использования скриптового языка - это наличие платформо-независимого кода, выполняемого без изменений на каждой поддерживаемой платформе.**
+
+Редактор 0.10 использует Python в качестве подобного кода с помощью [SWIG](http://swig.org/). SWIG позволяет использовать практически любой код C/C++ из языков вроде Python, Ruby, Lua, Java, C# и т.д.. SWIG помог нам впервые оценить прелесть платформо-независимого кода. К сожалению, SWIG работает лишь в одном направлении: из C/C++ в язык назначения. Это приводит к тому, что основное приложение должно быть написано на языке назначения, а код C/C++ может быть использован лишь в виде библиотеки.
+
+Основное приложение на языке Python вполне подходит для десктопа, но не для мобилок и веба, где языки C и C++ являются единственными языками, поддерживаемыми нативно на каждой платформе. Конечно, существуют проекты вроде [Kivy](https://kivy.org), которые позволяет разрабатывать кросс-платформенные приложения на Python, но они не поддерживаются нативно. Отсутствие нативной поддержки выливается в огромную головную боль при изменении API у Android и iOS.
+
+Необходимость в приложении на C/C++ и поддержке скриптов приводит к обязательному интерпретированию скриптового языка самим приложением. Это как раз то, что SWIG, Kivy и подобные проекты не позволяют сделать.
+
+**Наша вторичная цель использования скриптового языка - это возможность расширения кода C++.**
+
+Одни модули Редактора 0.10 написаны на C++, а другие на Python. С точки зрения основного приложения, все модули равны. Для приложения нет никакой разницы, на каком языке написан конкретный модуль.
+
+Для достижения этой гибкости мы ввели так называемое Окружение (Environment). Каждый модуль регистрирует ключи (keys), на которые он отвечает, а Окружение доставляет соответствующие сообщения. Технически такое поведение можно достигнуть с помощью наследования базового класса и переопределения его методов как в C++, так и в скриптовом языке.
+
+**Python был первым языком, который мы рассмотрели в качестве платформо-независимого скриптового языка.**
+
+Т.к. мы уже использовали Python, то логично было начать изучение с него. Мы хотели проверить, можно ли запустить код Python на каждой поддерживаемой платформе. К сожалению, результаты были удручающими, т.к. документация CPython (реализация Python, используемая по умолчанию на десктопе) никак не упоминала ни мобилки, ни веб. Всё, что мы нашли, - это пара форков CPython лохматых годов, которые якобы работают либо на Android, либо на iOS. Такой раздрай нас не устроил.
+Мы также рассмотрели [PyPy](http://pypy.org), ещё одну реализацию Python, но она тоже не содержала информации о мобилках и вебе.
+
+Это было чётким сигналом об отсутствии интереса к мобилками и вебу со стороны сообщества Python. Либо об отсутствии времени даже на то, чтобы описать использование Python на данных платформах. В любом случае, такое положение вещей нас не устроило.
+
+**[Wren](http://wren.io) был вторым языком, который мы рассмотрели в качестве платформо-независимого скриптового языка.**
+
+Wren был первым языком из длинного списка малоизвестных скриптовых языков.
+
+Wren преподносился как небольшой и простой язык. Согласно документации, основная цель Wren - это быть встроенным в приложение. По иронии судьбы, у автора [не было времени описать в документации встраивание Wren](http://wren.io/embedding-api.html) в приложение. Когда мы [спросили о сроках публикации](https://github.com/munificent/wren/issues/465) этой критически важной части документации, мы [получили в ответ ссылку на тикет](https://github.com/munificent/wren/issues/402), в котором другой человек спрашивал тот же самый вопрос полгода назад!
+
+На этом мы закончили отношения с Wren.
+
+**[Chai](http://chaiscript.com) был третьим языком, который мы рассмотрели в качестве платформо-независимого скриптового языка.**
+
+Chai был в том же длинном списке малоизвестных скриптовых языков. Он преподносился как язык, специально предназначенный для встраивания в приложения C++. Мы без проблем вызвали функцию C++ из Chai, но нам не удалось вызвать метод класса. [Мы попросили о помощи](http://discourse.chaiscript.com/t/cannot-call-a-function-that-accepts-a-string-and-a-vector/334), но ответом была лишь тишина.
+
+Нам пришлось завершить отношения с Chai.
+
+**Lua был четвёртым языком, который мы рассмотрели в качестве платформо-независимого скриптового языка.**
+
+Lua является популярным языком для встраивания. Мы решили попробовать очевидный вариант. Документация выглядела многообещающе, однако под конец чтения главы [C API](https://www.lua.org/pil/24.html) у нас не было ни малейшего представления, как наследовать класс C++ в Lua.
+
+Этот вопрос заставил нас найти библиотеку, которая смогла бы на него ответить: [Sol2](http://sol2.rtfd.io). Первая попытка вызвать функцию C++ из Lua провалилась. Правда, на этот раз наш вопрос был услышан, и [мы получили ответ](https://github.com/ThePhD/sol2/issues/465)! Мы были сильно удивлены.
+Далее мы попытались наследовать класс C++ в Lua, чтобы переопределить методы класса. Нам это не удалось с первого раза, но автор Sol2 [снова помог нам](https://github.com/ThePhD/sol2/issues/468).
+
+В тот момент мы поняли, что это начало долгого и взаимовыгодного сотрудничества с Sol2/Lua.
+
+**Поиск скриптового языка открыл для нас следующую истину: люди важнее технологий.**
+
+Существует множество скриптовых языков, которые выглядят привлекательно на первый взгляд, но которые мертвы. Почему? Потому что у некоторых авторов нет времени на пользователей. В ответ пользователи предпочитают не тратить своё время на проекты подобных авторов.
+
+На этом мы заканчиваем описание изучения скриптования в июле 2017.
+

pelican/content/articles/2017-08-scripting-research.md

@@ -0,0 +1,62 @@
+Title: Scripting research
+Date: 2017-08-16 00:00
+Category: News
+Slug: scripting-research
+Lang: en
+
+![Scripting research]({attach}/images/2017-08-scripting-research.png)
+
+This article describes scripting research in July 2017.
+
+**Our first goal of using a scripting language was to have a platform-independent code that runs unchanged on every supported platform.**
+
+OGS Editor 0.10 supports Python for such a code thanks to [SWIG](http://swig.org/). SWIG provides a way to wrap almost any C/C++ code and use it in dozens of languages like Python, Ruby, Lua, Java, C#, etc.. SWIG really helped us taste the beauty of platform-independent code. However, SWIG only works one way: from C/C++ to a target language. This means the main application must be in the target language, and C/C++ code can only be used as a library.
+
+Having the main application in Python works fine for the desktop, but not so great for mobile and web, where C and C++ are the only natively supported cross-platform languages. There are projects like [Kivy](https://kivy.org), which allow you to develop cross-platform applications in Python, but they are not supported natively. This means it's a lot of headaches when Android and iOS APIs change.
+
+Having the main application in C/C++ and the need to support scripting means that a scripting language should be interpreted by the application. This is what SWIG, Kivy, and similar projects are not meant to fulfill.
+
+**Our secondary goal for using a scripting language was to allow to extend C++ code.**
+
+OGS Editor 0.10 has some modules written in C++, and some in Python. The modules are equal from the perspective of the main application; it doesn't care what language the module is written in.
+
+To achieve such flexibility, we introduced a so-called Environment. Each module would register the keys it responds to, and Environment would deliver corresponding messages. 
+Technically such behaviour is achieved by inheriting a base class and overriding its methods in both C++ and a scripting language.
+
+**First, we evaluated Python for the role of cross-platform scripting language.**
+
+Since we already used Python, we started to research the possibility to run Python code on every supported platform. The result was disappointing because CPython (the default Python implementation used on the desktop) does not mention mobile and web platforms. We only found some years old forks of CPython that were claimed to work either on Android or iOS. Such a disarray was not suitable for us.
+We also had a look at [PyPy](http://pypy.org), another Python implementation. It also did not mention support for mobile and web platforms.
+
+This was a clear indication that Python community doesn't care for mobile and web platforms. Or that nobody had time to provide the information about building Python on such platforms. Either way, it was not acceptable for us.
+
+**Second, we evaluated [Wren](http://wren.io) for the role of cross-platform scripting language.**
+
+Wren was the first scripting language we stumbled upon in the long list of non-mainstream scripting languages.
+
+Wren claimed to be small and easy to learn. Wren also claimed to be intended for embedding in applications. Ironically, the author [had no time to document how to do the embedding in the first place](http://wren.io/embedding-api.html). When [we asked for the time estimates of publishing](https://github.com/munificent/wren/issues/465) the critical part of the documentation, [we just got a reference to another issue](https://github.com/munificent/wren/issues/402) where the other guy was asking the same question half a year ago!
+
+That's when we ended our relationship with Wren.
+
+**Third, we evaluated [Chai](http://chaiscript.com) for the role of cross-platform scripting language.**
+
+Chai was in the long list of non-mainstream scripting languages, too. Chai was promising because it claimed to be specifically tailored for embedding in a C++ application.
+We successfully managed to call a C++ function from inside Chai but failed to call a member function. [We asked for help](http://discourse.chaiscript.com/t/cannot-call-a-function-that-accepts-a-string-and-a-vector/334), but nobody replied.
+
+We had to end our relationship with Chai.
+
+**Fourth, we evaluated Lua for the role of cross-platform scripting language.**
+
+Lua is the mainstream language for embedding. So we decided to try the obvious choice. Documentation looked promising, too. However, by the end of reading the [C API](https://www.lua.org/pil/24.html) chapter we had no clue how to inherit a class inside Lua.
+
+This led us to search for libraries that wrap Lua C API syntax into something more meaningful for C++. That's how we found [Sol2](http://sol2.rtfd.io). Just as before, the first attempt to call a C++ member function from Lua failed. But unlike before, we asked for help and [got the help](https://github.com/ThePhD/sol2/issues/465)! This was a refreshing surprise for us.
+Next, we tried to inherit a class in Lua and override the class methods. We failed, but [the author helped us out again](https://github.com/ThePhD/sol2/issues/468). In the end, we succeeded in inheriting a class and overriding its behaviour.
+
+That's when we understood it's a start for a long and mutual relationship with Sol2/Lua.
+
+**This search for a scripting language taught us one important lesson: people matter, not technologies.**
+
+There are lots of scripting languages that look shiny on the outside but are dead. Why? Because some authors don't have time for users. In return, users don't have time for the authors' projects.
+
+That's it for describing scripting research in July 2017.
+