<img src="http://tibbo.com/images/ninja/jancy-maskot-350.png" alt="jancy" align="right"/>Зачем вообще создавать новый язык программирования? Их уже существует невероятное количество -- по моему твёрдому убеждению, значительно больше, чем надо. И наверняка далеко не последнюю роль в данном положении вещей играет то, что создание компиляторов -- это невероятно увлекательный процесс. С поправкой на арбузы и свиные хрящики -- это вообще одна из самых "вкусных" работ, о которых может мечтать увлечённый программист.

Непередаваемо здоровским является цветочно-конфетный период -- первый этап изучения теории компиляторов по толстым умным книжкам, и -- тут же! -- её применения на практике, в своём собственном языке. Даже печальная перспектива того, что создатель языка вполне может оказаться его единственным пользователем, не способна перевесить радость творчества и остановить сферического-в-вакууме компиляторного Кулибина. Разумеется, если удовлетворение собственного интереса является не только важной, но и единственной движущей силой всего процесса -- вышеописанная перспектива с неизбежностью будет воплощена в жизнь. Но даже если это и НЕ единственная причина создания нового языка -- перспектива стать одиноким пользователем своего творения всё равно имеет шансы реализоваться.
<habracut>
Мой цветочно-конфетный период романа с компиляторами и радости от ваяния своих первых языков закончился уже очень давно. Можно сказать, что свои отношения я узаконил узами священного брака: компиляторы, отладчики и средства разработки -- это моя основная работа в Tibbo со всеми вытекающими последствиями (да-да, в том числе и в виде насыщения предметом, увеличения процента рутинных задач и т.д.) Поэтому мотивация создания своего скриптового языка программирования у меня была отличная от банального удовлетворения собственного интереса.

<h1>Так зачем же?</h1>
Если максимально кратко сформулировать практическую сторону моей лично и нашей (как компании) мотивации, то она будет звучать так: мы хотели иметь встраиваемый скриптовый движок <b>с указателями</b> на структуры и <b>безопасной адресной арифметикой</b>. Такого не нашлось. И мы сделали язык <a href="http://tibbo.com/jancy/">Jancy</a> ("between-Java-and-C"), в котором есть и С-совместимые структуры, и указатели с безопасной арифметикой, и многое-многое другое:

<b>Уникальные возможности</b>
<ul>
	<li>Безопасные указатели и адресная арифметика;</li>
	<li>Беспрецендентный для скриптовых языков уровень совместимости исходных кодов с C/C++;</li>
	<li>Реактивное программирование (reactive programming) – одна из первых реализаций в императивном языке (на уровне языка, а не в виде библиотек);</li>
	<li>Встроенный генератор лексеров/сканнеров.</li>
</ul>
<b>Принципы дизайна</b>
<ul>
	<li>Объектно-ориентированный язык с C-подобным синтаксисом;</li>
	<li>Бинарная ABI (application-binary-interface) совместимость с C/C++;</li>
	<li>Автоматическое управление памятью через точную сборку мусора (accurate garbage collection);</li>
	<li><a href="http://llvm.org">LLVM</a> в качестве backend.</li>
</ul>
<b>Другие значимые особенности</b>
<ul>
	<li>Исключения как синтаксический сахар над моделью кодов ошибок.</li>
	<li>Свойства (properties) – самая полная реализация;</li>
	<li>Мультикасты (multicasts) и события (events), включая слабые, от которых необязательно отписываться;</li>
	<li>Множественное наследование;</li>
	<li>Const-корректность;</li>
	<li>Поддержка парадигмы RAII (resource-acquisition-is-initialization);</li>
	<li>Локальная память потоков (thread local storage);</li>
	<li>Частичное применение (partial application) для функций и свойств;</li>
	<li>Оператор планирования (schedule operator) для создания указателей на функции, которые гарантированно будут вызваны в заданном окружении (например, в нужном рабочем потоке);</li>
	<li>Перечисления для битовых флагов (bitflag enums);</li>
	<li>Perl-подобное форматирование строк;</li>
</ul>
Более полный список возможностей с примерами использования можно посмотреть тут: <a href="http://tibbo.com/jancy/features.html">http://tibbo.com/jancy/features.html</a>

<h1>Кому это может пригодиться?</h1>
Прежде всего, мы писали язык для самих себя -- Jancy используется в проекте <a href="http://tibbo.com/ioninja/">IO Ninja</a> в качестве встроенного скриптового языка. Однако, если он оказался полезен нам, мы скромно надеемся, что он вполне может помочь и другим. Надежда эта прежде всего опирается на <b>три сильнейшие стороны Jancy</b>, в которых наш язык обладает реальным преимуществом перед аналогами.

<b>1. Высокий уровень совместимости с C/C++</b>
Это относится и к бинарной ABI-совместимости, и к совместимости на уровне исходных кодов. Плюсов здесь много: это и бесшовное подключение существующих C-библиотек, и портирование кода с C/C++ с помощью копипастинга и последующих косметических правок (а иногда и вообще без них), и лёгкость создания на C/C++ новых библиотек для использования из Jancy-скриптов, и эффективность встраивания Jancy-движка в C/C++ приложение и т.д. 

<b>2. Удобные средства для IO-программирования</b>
Тут я прежде всего говорю, во-первых, о поддержке указателей и адресной арифметики, идеально подходящих для разбора и генерации бинарных пакетов, и, во-вторых, о генераторе лексеров (причём инкрементальных, т.е. применимых к разбору IO потоков, приходящих по кускам). Сюда же можно отнести частичное применение и оператор планирования, которые вместе позволяют, например, создать обработчик завершения (completion routine) с захваченными контекстыми аргументами; при этом он будет автоматически вызван в нужном рабочем потоке.

<b>3. Удобные средства для UI-программирования</b>
Два слова: <a href="https://ru.wikipedia.org/wiki/%D0%A0%D0%B5%D0%B0%D0%BA%D1%82%D0%B8%D0%B2%D0%BD%D0%BE%D0%B5_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5">реактивное программирование</a>. Думаю, что со временем поддержка реактивности -- на уровне языка или же в форме костылей вроде препроцессоров и библиотек -- станет неотъемлемой частью любой системы разработки пользовательских интерфейсов (UI). Jancy предлагает реактивность "из коробки", причём, по моему мнению, в совершенно интуитивной форме. Помимо реактивности, Jancy поддерживает всевозможные вариации свойств и событий, что также помогает строить красивые фреймворки пользовательского интерфейса.

При этом, несмотря на примечательные возможности пункта номер три, мы пока не позиционируем Jancy как язык разработки пользовательского интерфейса. Задача-максимум на данный момент -- стать скриптовым языком для низкоуровневого IO программирования, т.е. <b>инструментом системного/сетевого программиста/хакера</b>.

А теперь -- слайды! (c)

<h1>ABI-совместимость с C/C++</h1>
Совместимость это всегда хорошо, а совместимость с де-факто языком-стандартом системного программирования -- это просто здорово, не правда ли?

Jancy-скрипты JIT-компилируются и могут быть напрямую вызваны из программы на C/С++, равно как и напрямую вызывать C/C++ функции. Это означает, что после правильного описания типов данных и прототипов функций в скриптах Jancy и приложении на C++ становится возможно передавать данные естественным образом, через аргументы функций и возвращаемые значения.

Объявляем и используем функции из скрипта на Jancy:
<source lang="cpp">
bool foo (
	char charArg,
	int intArg,
	double doubleArg
	);

bar (int x)
{
	bool result = foo ('a', x, 3.1415);
	// ...
}
</source>
Пишем реализацию на C/C++:
<source lang="cpp">
bool foo (
	char charArg,
	int intArg,
	double doubelArg
	)
{
	// ...
	return true;
}
</source>
Подключаем перед JIT-компиляцией скрипта:
<source lang="cpp">
class MyLib: public jnc::StdLib
{
public:
	JNC_BEGIN_LIB ()
		JNC_FUNCTION ("foo", foo)
		JNC_LIB (jnc::StdLib)
	JNC_END_LIB ()
};

// ...
MyLib::mapFunctions (&module);
</source>
Готово! Никакой упаковки/распаковки variant-подобных контейнеров, явного заталкивания аргументов на стек виртуальной машины и т.д. -- всё работает напрямую. На сегодняшний момент Jancy поддерживает все основные модели вызовов (calling conventions):
<ul>
	<li>cdecl (Microsoft/gcc)</li>
	<li>stdcall (Microsoft/gcc)</li>
	<li>Microsoft x64</li>
	<li>System V</li>
</ul>
В обратную сторону -- вызов Jancy из C++ -- всё так же просто:
<source lang="cpp">
typedef void Bar (int);
Bar* bar = (Bar*) module.getFunctionByName ("bar")->getMachineCode ();
bar (100);
</source>
Как насчёт вызова системных функций и динамических библиотек (dll/so)? Не вопрос! Jancy предлагает бесшовную интеграцию с динамическими библиотеками:
<source lang="cpp">
library User32
{
	int stdcall MessageBoxA (
		intptr hwnd,
		char const thin* text,
		char const thin* caption,
		int flags
		);
	// ...
}

// ...
User32 user32;
user32.load ("user32.dll");
user32.lib.MessageBoxA (0, "Message Text", "Message Caption", 0x00000040);
</source>
При этом разрешение имён будет производиться по мере обращения, а найденные адреса будут кэшироваться (напоминает DELAYLOAD, с поправкой на явную загрузку самого модуля). Обработка ошибок при загрузке и разрешении имён производится стандартным для Jancy методом псевдо-исключений (подробнее см. следующий раздел). 

Динамический поиск по имени (GetProcAddress/dlsym), разумеется, также возможен -- хотя и не столь элегантен, как предыдущий подход.
<spoiler title="Пример"><source lang="cpp">
typedef int cdecl Printf (
	char const thin* format,
	...
	);

jnc.Library msvcrt;
msvcrt.load ("msvcrt.dll");

Printf thin* printf;

unsafe
{
	printf = (Printf thin*) msvcrt.getFunction ("printf");
}

printf ("function 'printf' is found at 0x%p\n", printf);
</source></spoiler>
Другим немаловажным следствием высокой степени совместимости между Jancy и C/C++ является возможность копипастить из общедоступных источников (таких как Linux, React OS или других проектов с открытым исходным кодом) и использовать определения заголовков коммуникационных протоколов на языке C:
<source lang="cpp">
enum IpProtocol: uint8_t
{
    Icmp = 1,
    Tcp  = 6,
    Udp  = 17,
}

struct IpHdr
{
    uint8_t m_headerLength : 4;
    uint8_t m_version      : 4;
    uint8_t m_typeOfService;
    bigendian uint16_t m_totalLength;
    uint16_t m_identification;
    uint16_t m_flags;
    uint8_t m_timeToLive;
    IpProtocol m_protocol;
    bigendian uint16_t m_headerChecksum;
    uint32_t m_srcAddress;
    uint32_t m_dstAddress;
}
</source>
Кстати, обратите внимание на поддержку целочисленных типов с обратным порядком следования байтов (bigendians). Это, конечно, далеко не масштабное нововведение, но оно здорово упрощает описание и работу с заголовками сетевых протоколов -- здесь обратный порядок следования байтов встречается повсеместно.

<h1>Псевдо-исключения</h1>
Как это ни парадоксально, но одним из следствий ABI-совместимости с C/C++ стал отказ от привычной для C++ программистов модели исключений. Дело в том, что такие исключения совершенно не подходят для мультиязыкового стека вызовов (хотя, конечно, список объективных претензий к C++-подобным исключениям этим не исчерпывается -- горячие споры "за" и "против" исключений всплывают на программистских ресурсах с регулярностью, которой можно только позавидовать). 

Так или иначе, в Jancy используется гибридная модель. В основе её лежит проверка возвращаемых значений, но компилятор избавляет от необходимости делать это вручную. В итоге всё выглядит почти как исключения в C++ или Java, но при этом поведение программы при ошибках на порядок более прозрачно и предсказуемо, а поддержка исключений при межязыковых взаимодействиях (таких, как вызов функций C++ из скриптов на Jancy и наоборот) становится настолько простой, насколько это вообще возможно.
<source lang="cpp">
bool foo (int a) throws
{
    if (a < -100 || a > 200) // invalid argument
    {
        jnc.setStringError ("detailed-description-of-error");
        return false;
	}

    // ...
    return true;
}
</source>
Возвращаемые значения функций, помеченных модификатором throws, будут трактоваться как коды ошибок. В Jancy приняты интуитивные условия ошибки для стандартных типов: false для булева типа, null для указателей, -1 для беззнаковых целых, и < 0 для знаковых. Остальные типы приводятся к булеву (если это невозможно, то выдаётся ошибка компиляции). Очевидно, что функция, возвращающая void, в данной модели не может возвращать ошибки.

Помимо этого, в данной модели разработчик волен выбирать, как именно обрабатывать ошибки в каждом конкретном случае. Иногда это удобнее делать проверкой кода возврата вручную, иногда – использовать семантику исключений. В Jancy -- при вызове одной и той же функции! -- можно делать и так и так, в зависимости от ситуации.
<source lang="cpp">
bar ()
{
    foo (10);   // can use exception semantics...
    foo (-20);

catch:
    printf ($"error caught: $(jnc.getLastError ().m_description)\n");
    // handle error
}

baz (int x)
{
    bool result = try foo (x); // ...or manual error-code check
    if (!result)
    {
	    printf ($"error: $(jnc.getLastError ().m_description)\n");
        // handle error
    }
}
</source>
Конструкция finally в большинстве языков традиционно ассоциируется с исключениями. Но в Jancy finally может быть добавлен в любой блок по желанию разработчика. В конце концов, убирать за собой надо даже если никаких ошибок не возникало, не правда ли?
<source lang="cpp">
foo ()
{
     // nothing to do with exceptions here, just a 'finally' block to clean up
finally:
    printf ("foo () finalization\n");
}
</source>
Конечно, допускается и более традиционное использование конструкции finally в случаях, когда исключения-таки ожидаются. 
<spoiler title="Пример"><source lang="cpp">
foo (char const* address)
{
    try
    {
        open (address);

        transact (1);
        transact (2);
        transact (3);

    catch:
        addErrorToLog (jnc.getLastError ());

    finally:
        close ();
    }
}
</source></spoiler>

<h1>Безопасные указатели и адресная арифметика</h1>
Адресная арифметика в скриптовом языке - это то, ради чего всё собственно и затевалось. 

Указатели, при всей своей врождённой небезопасности, в явном или неявном виде являются частью любого языка. Ограничением доступных разработчику видов указателей и операций над ними можно значительно обезопасить язык, упростить обработку неблагоприятных ситуаций во время исполнения и даже отлавливать некорректные операции в момент компиляции при помощи статического анализа. Но если в игру вступает адресная арифметика, полностью переложить анализ на этап компиляции просто невозможно.

Чтобы всегда была возможность проверять корректность операций, указатели в Jancy по умолчанию толстые. Помимо адреса они также содержат валидатор – специальную структуру мета-данных, из которой можно получить информацию о разрешённом диапазоне адресов, типе данных, а также целочисленном уровене вложенности (scope level).

Формула безопасности указателей и адресной арифметики в Jancy такова:
<ol>
	<li>проверка диапазонов при косвенных обращениях по указателям;</li>
	<li>проверка уровня вложенности при присвоениях указателей;</li>
	<li>проверка приводимости при присвоениях указателей.</li>
</ol>
<spoiler title="А как же производительность?">
Данный механизм не бесплатен и действительно выливается в определённые накладные расходы во время исполнения. 

Но во-первых, даже в самом наивном варианте, без каких-либо оптимизаций, два целочисленных сравнения для проверки диапазона или одно для проверки уровня вложенности – это не так страшно, особенно принимая во внимание JIT-компиляцию и тот факт, что Jancy – это всё-таки скриптовый язык. 

Во-вторых, в дальнейшем с помощью статического анализа можно будет избавиться от многих ненужных проверок ещё на этапе компиляции. Ну и в-третьих, для критических по производительности участков кода уже сейчас можно использовать небезопасные (тонкие, thin) указатели без валидаторов – проверки при операциях с тонкими указателями не производятся.
</spoiler>
Проверки допустимого диапазона адресов производятся как в случае явного использования указателя, так и в случае оператора индексации:
<source lang="cpp">
foo (
	char* p,
	size_t i
	)
{
	p += i;
    *p = 10; // <-- range is checked

    static int a [] = { 10, 20, 30 };
    int x = a [i]; // <-- range is checked
}
</source>
В случае указателей на стековые и потоковые переменные, необходимы также проверки уровня вложенности - для предотвращения утечки адресов за границы времён их жизни. Этот механизм работает даже в случае многоуровневых указателей, вроде указателей-на-структуры-с-указателями-на-структуры-и-т-д:
<source lang="cpp">
int* g_p;

bar (
	int** dst,
	int* src
	)
{
	*dst = src; // <-- scope level is checked
}

baz ()
{
    int x;
    bar (g_p, &x); // <-- runtime error: scope level mismatch
}
</source>
Наконец, проверки приводимости призваны предотвратить разрушение самих валидаторов. Действительно, что если мы приведём создадим указатель на указатель, приведём его к указателю на char и затем байт за байтом затрём валидатор мусором? Jancy просто не даст это сделать: компилятор и runtime разрешают приведения только там, где это безопасно.
<spoiler title="Подробнее">
Jancy делит все типы на категории POD (plain-old-data) и не-POD. Понятие POD в Jancy несколько отличается от аналогичного в C++. Возможно, в этой связи стоило придумать новый термин, чтобы избежать путаницы, но в итоге я решил не плодить новые сокращения. Кроме того, мне кажется, что POD в Jancy гораздо точнее отражает смысл понятия “plain-old-data”. 

В Jancy POD – это данные без мета-данных. Их можно смело побайтно копировать и модифицировать и при этом ничего не сломать. Агрегация POD данных, будь то включения полей, наследование (тут отличие от C++) или объединение в массивы – тоже приводит к POD. Всё, что содержит мета-данные, а именно классы, безопасные указатели на данные и их любые агрегаты – это не-POD. 

Компилятор Jancy разрешает приведения не-POD типов тогда и только тогда, когда в результате приведения не появляется возможность разрушить или подменить мета-данные. Для ситуаций, в которых на этапе компиляции это неизвестно (например, мы производим приведение к дочернему типу, так называемый downcast) – существует специальный оператор динамического приведения. Оператор динамического приведения компилируется в вызов встроенной функции, которая возвращает указатель на запрошенный тип, или null, если приведение невозможно.

Для примера подготовим тестовые типы, которые мы будем приводить друг к другу:
<source lang="cpp">
struct A
{
    int m_a;
}

struct B
{
    int m_b;
}

struct C: A, B
{
    int m_c;
}

struct D: C
{
    char const* m_s;
}
</source>
Здесь A, B, C – это POD (причём последний тип не был бы POD в C++), D – не POD, т.к. этот тип содержит мета-данные в виде валидатора указателя m_s. Теперь рассмотрим возможные операции приведения.

Приведения к родительским типам (upcast) всегда разрешены и не требуют явного оператора приведения ни для POD, ни для не-POD:
<source lang="cpp">
foo (D* d)
{
    C* c = d;
    A* a = с;
}
</source>
POD-типы могут быть произвольно приведены друг к другу с помощью оператора приведения:
<source lang="cpp">
bar (B* b)
{
    char* p = (char*) b;
    C* c = (C*) b; // <-- unlike C++ no pointer shift
}
</source>
Приведения от POD-типов к не-POD-типам разрешены только в случае результирующего константного указателя:
<source lang="cpp">
foo (D* d)
{
    char* p = (char*) d;  <-- error
    char const* p2 = (char const*) d; // OK
}
</source>
Приведение к дочерним типам (downcast) возможно с помощью оператора динамического приведения: 
<source lang="cpp">
bar (B* b)
{
    D* d = dynamic (D*) b;
    A* a = dynamic (A*) b; // not a downcast, but still OK
}
</source>
Динамическое приведение возможно благодаря содержащемуся в указателе валидатору, а значит и информации о типе. Помимо динамического приведения, Jancy также предлагает операцию динамического определения размера, который доступен из того же валидатора - хотя это и не имеет отношения к безопасности указателей, в определенных ситуациях это очень удобно:
<source lang="cpp">
foo (int* p)
{
    size_t size = dynamic sizeof (*p);
    size_t count = dynamic countof (*p);
}

//...
bar ()
{
	int a [100];
	foo (a);
}
</source>
</spoiler>
Уважаемые хабровчание приглашаются поиграться с нашим <a href="http://tibbo.com/jancy/live_demo.html">online-компилятором</a> и на деле опробовать, как всё это работает (читайте: попытаться подсунуть компилятору пример скрипта с указателеми, который его свалит ;)

Подробнее про указатели в Jancy читать тут: <a href="http://tibbo.com/jancy/features/pointers.html">http://tibbo.com/jancy/features/pointers.html</a>

<h1>Функции-автоматы</h1>
Безопасные указатели и адресная арифметика идеально подходят для разбора и генерации бинарных пакетов:
<source lang="cpp">
dissectEthernet (void const* p)
{
	io.EthernetHdr const* hdr = (io.EthernetHdr const*) p;
	switch (hdr.m_type)
	{
	case io.EthernetType.Ip:
		dissectIp (hdr + 1);
		break;

	case io.EthernetType.Ip6:
		dissectIp6 (hdr + 1);
		break;

	case io.EthernetType.Arp:
		dissectArp (hdr + 1);
		break;

	// ...
	}
}
</source>
Но существует и другой класс протоколов -- протоколов, не полагающихся на бинарные заголовки и вместо этого использующих некий язык запросов/ответов. В этом случае для анализа IO-потоков требуется писать парсер данного языка. При этом надо озаботиться предварительной буферизацией данных -- часто нет гарантии, что транспорт доставил сообщение целиком, а не по кусками.

Поскольку данная задача является типовой в IO-программировании, Jancy предлагает встроенный инструмент для её решения. Функции-автоматы Jancy призваны облегчить первую и самую рутинную стадию написания любого парсера -- создание лексера/сканнера. Работает это по принципу известных лексер-генераторов типа <a href="http://en.wikipedia.org/wiki/Lex_(software)">Lex</a>, <a href="http://en.wikipedia.org/wiki/Flex_lexical_analyser">Flex</a>, <a href="http://www.complang.org/ragel/">Ragel</a>:
<source lang="cpp">
jnc.AutomatonResult automaton scanRx (jnc.Recognizer* recognizer)
{
	%% "getOption"
		createToken (Token.GetOption);

	%% "setOption"
		createToken (Token.SetOption);

	%% "exit"
		createToken (Token.Exit);

	%% [_\w][_\w\d]*
		createToken (Token.Identifier, recognizer.m_lexeme);

	// ...
}
</source>
Внутри функции-автомата описан список распознаваемых лексем в виде регулярных выражений. После описания каждой лексемы следует блок кода, который надо выполнить при её обнаружении во входном потоке. Вся эта кухня компилируется в табличный ДКА, состояние которого хранится во внешнем объекте jnc.Recognizer (указатель на этот объект передаётся в аргументе recognizer). В нём же накапливаются символы потенциальной лексемы, и он же неявно вызывает нашу функцию-автомат, выполняя при этом необходимые переходы между состояниями. 

Совокупность функции-автомата и этого управляющего объекта-распознавателя и представляет собой наш лексер. При этом данный лексер будет инкрементальным, то есть способным разбирать сообщения, приходящие по частям:
<source lang="cpp">
jnc.Recognizer recognizer (scanRx); // create recognizer object

try 
{
    recognizer.write ("ge");
    recognizer.write ("tOp");
    recognizer.write ("tion");
    recognizer.eof (); // notify recognizer about eof (this can trigger actions or errors)

catch: 
    // handle recognition error
}
</source>
Отметим, что, как и в Ragel, возможно переключаться между разными функциями-автоматами, что позволяет, в частности, создавать контекстно-зависимые ключевые слова (или, если сказать по-другому, разбирать мульти-языковый вход).
<spoiler title="Пример"><source lang="cpp">
jnc.AutomatonResult automaton scanGlobal (jnc.Recognizer* recognizer)
{
	%% '#'
		recognizer.m_automatonFunc = scanPreprocessor; // switch to pp-specific keywords

	// ...
}

jnc.AutomatonResult automaton scanPreprocessor (jnc.Recognizer* recognizer)
{
	%% "if"
		createToken (Token.If);

	%% "ifdef"
		createToken (Token.Ifdef);

	// ...
	%% '\n'
		recognizer.m_automatonFunc = scanGlobal; // switch back
}
</source></spoiler>
Функции-автоматы с одной стороны, и безопасные указатели с адресной арифметикой с другой позволяют с удобством разбирать протоколы и IO-потоки любого типа.

<h1>Заключение</h1>
Несмотря на то, что программирование пользовательских интерфейсов (UI) не является главным назначением Jancy на данный момент, мы всё равно хотели бы продемонстрировать подход к реактивному программированию, который используется в Jancy -- я считаю, что нам удалось найти оптимальный компромисс в сосуществовании императивного и декларативного начал в реактивном программировании. Рассказ об этом пойдёт в следующей статье.

Тем временем мы приглашаем вас опробовать возможности языка Jancy (как описанные в данной статье, так и многие другие) на страничке <a href="http://tibbo.com/jancy/live_demo.html">живой демки компилятора</a>. Также вы можете скачать, собрать и поиграться с библиотекой JIT-компилятора Jancy и примерами её использования - всё это доступно на страничке <a href="http://tibbo.com/jancy/downloads">downloads</a>.