1 (изменено: Freeman, 09.06.2023 в 19:04)

Тема: Раскрутка компилятора, финансирование (2018)

Под раскруткой в данной теме подразумевается технология разработки компиляторов, а не получение известности или SEO.

За прошедшее время предыдущий план так и не был реализован, ожидания о его реализуемости оказались завышенными. Одновременно с этим участие в конференции по разработке языков программирования и знакомство с реализациями Nim и АЛФОР позволило пересмотреть отношение к транспиляторам. Разработка Кантора в виде транспилятора была признана допустимой.

Всё это вместе с вновь открывшимися обстоятельствами заставило радикально пересмотреть план реализации Кантора. На данный момент принято, что Кантор как самостоятельный язык не имеет практической ценности, так что задачей ранних этапов является его встраивание в существующие экосистемы в качестве альтернативной реализации, предоставляющей предоставляющей некие возможности, нереализуемые в рамках самой экосистемы и/или считающиеся невозможными. Реализация через Кантор покроет узкие места экосистемы, в первую очередь производительность, -- за счет компиляции в машинный код и частичные вычисления, а сам Кантор будет использоваться как ассемблер новой экосистемы -- вспомогательный язык. В будущем, по мере зрелости и появления сообщества пишущих на Канторе, постепенно будет развиваться сам язык и начнут появляться проекты на нем, -- сначала маленькие, а потом и большие. Раз миграция существующего кода будет отработана на ранних этапах, в дальнейшем нужно будет лишь поддерживать в актуальном состоянии и добавлять новые языки. В случае успеха может быть взрывной рост сообщества.

Tiny C в качестве цели транспиляции позволяет сразу получить генерацию исполнимых файлов и библиотек под несколько популярных платформ, а также REPL и JIT-исполнение. Возможности кодогенерации ограничены самим Tiny C:

  • Архитектуры: основные x86, x86-64; экспериментальные ARM, ARM64.

  • Платформы: Windows; дополнительно: UEFI, *nix, KolibriOS.

Компилятор Tiny C существует в виде библиотеки и может вызываться прямо из Кантора, без генерации промежуточных файлов. Скорость компилятора Tiny C соизмерима со скоростью Delphi, что соответствует идеологии Кантора. Tiny C распространяется под LGPL и может быть использован в коммерческих проектах с закрытыми исходниками.

0 этап
Разработка ядра Кантора как прослойки между входным языком Object Pascal и выводом в ANSI C с последующей трансляцией компилятором Tiny C. На этом этапе еще нельзя будет писать на самом Канторе. На выходе:

  • Компилятор входного языка Object Pascal (диалект Delphi 2007) в объектный код Кантора.

  • Ядро Кантора, реализующее хранение и обработку объектного кода в оперативной памяти.

  • Отекстовщик объектного кода в исходный текст на Канторе для контроля работы ядра.

  • Вывод объектного кода в исходный код на ANSI C (C99), сборка средствами Tiny C.

  • Сборка ядра Кантора самим собой.

Скомпилировать исходники на Канторе на этом этапе еще нельзя. Ядро Кантора пока написано на Delphi. Кодовое название этапа — мини-Кантор.

1 этап
Разработка компилятора входного языка Кантора, соответствующего выводу отекстовщика. На выходе:

  • Возможность разработки Кантора на Канторе, формальная отвязка от Delphi.

На этом этапе начинает работать обратимость кода, подталкивая к необходимости создавать хранилище для него.

1 этап, 2 стадия
Разработка хранилища кода на Канторе, реализующего раздельную компиляцию обратимого кода и функциональность пакетного менеджера. В зависимости от глубины проработки этапа возможна реализация обфускации кода и деление на Community- и Enterprise-версии согласно возможностям обфускатора. На выходе:

  • Удобство распространения кода.

  • Достижение технологического минимума для формирования сообщества, пишущего на Канторе.

  • Появление смысла в постепенной миграции сторонних проектов на Кантор.

Поскольку на данном этапе доступны лишь входные языки Кантор и Object Pascal, практическая применимость стека пока невелика, но создает заделы на будущее:

  • Достижение технологического минимума полного цикла разработки -- добавление новых языков и синтаксисов становится технической задачей и дает возможность строить реалистичные планы расширения охвата и раскрутки.

  • Миграция сторонних проектов на Кантор означает появление первых пользователей и заказчиков.

1 этап, дополнительно
Разработка русскоязычного синтаксиса Кантора, взаимно-обратного англоязычному. Расширение возможностей компилятора и отекстовщика для поддержки данного синтаксиса. На выходе:

  • Возможность проводить натурные эксперименты востребованности программирования на родном языке среди профессиональных программистов, любителей, в системе образования и пр.

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

Финансирование
Думается, разбиение на этапы позволит предметно рассуждать о финансировании проекта. Сейчас трудно оценить скорость разработки. Из текущей точки видится примерно следующее:

  • 1-2 года на 0-1 этапы.

  • 2 000 000 - 5 000 000 ₽.

Процесс разработки подразумевает написание документации по окончании каждого этапа и регулярное ведение блога на Хабре для привлечения внимания к проекту. Этим должен заниматься отдельный человек -- евангелист.

Вероятно, нужен и второй разработчик, но не для написания кода, а для проведения технических консультаций и мозговых штурмов. Должен обладать широким кругозором. Частичная занятость.

2 этап

Второй этап подразумевает дальнейшее развитие подсистемы вывода типов и реализацию модели частичных вычислений, что означает достижение технологического минимума готовности Кантора для практического применения в качестве альтернативной реализации поддерживаемых на данный момент языков программирования.

2 этап, направление А
Расширение входного языка Object Pascal до диалекта одной из последних версий Embarcadero Delphi, реализация входного языка Delphi Form (DFM). На выходе:

  • Альтернативная реализация компилятора Delphi, генерирующая намного более компактные выходные файлы за счет взаимного анализа кода и DFM посредством механизма частичных вычислений.

Практическая и коммерческая ценность данного направления сомнительна, оно может быть отдано на откуп сообществу. В качестве альтернативы Embarcadero Delphi может быть взят диалект Free Pascal последней ревизии, -- удобство сборки и размер выходных файлов в теории актуальны и для пользователей Lazarus/CodeTyphoon.

2 этап, направление Б
Реализация компилятора входного языка Python в объектный код Кантора. Фактически это означает реализацию полноценного и быстрого компилятора Python и ускорение существующего кода на Python в десятки раз. Технологически это серьезный вызов для Кантора -- первая боевая проверка на реальном, неадаптированном коде. На выходе:

  • Подтверждение достаточности и работоспособности механизмов вывода типов и частичных вычислений для покрытия возможностей динамической типизации, проверка реализуемости компиляторов языков типа Python, JavaScript и Ruby машиной Кантора.

  • Выяснение фактического объема работ по адаптации внешнего кода, необходимого для миграции проектов на Кантор, обкатка процедуры миграции на сообществе разработчиков.

Это направление видится намного более привлекательным, в том числе коммерчески. Для лучшего охвата аудитории целесообразна реализация JIT-машины Кантора для популярных веб-серверов.

2 этап, направление В
Реализация компилятора входного языка C или сразу C++ в объектный код Кантора. Безнадежное с коммерческой точки направление, которое не может быть отдано на откуп сообществу из-за его важности для дальнейшего развития Кантора как платформы системного программирования. На выходе:

  • Достижение технологической возможности для миграции большей части кода, написанного на C/C++, качественный рост потенциального охвата аудитории разработчиков.

  • Возможность сборки Кантора Кантором, отвязка от Tiny C.

2

Re: Раскрутка компилятора, финансирование (2018)

Для тех кто сомневается, нужно ли делать Паскаль, не лучше ли сразу брать Си, дабы получить доступ к намного большей базе кода, а не каким-то жалким проектам на Delphi... Уж поверьте, если можно было вот так сразу реализовать Си, именно это и было бы сделано. Увы, для реализации Си на платформе Кантора есть технические сложности, без решения которых не удается выстроить реалистичный план реализации.

В отличие от Паскаля, в Си сильно используется препроцессор, что для незрелой платформы Кантора пока трудно преодолимое препятствие. Необходимо наработать решения на чем-то более предсказуемом и подходить к Си уже с некоторым багажом. Идеологически Кантор и Си различаются довольно сильно, и на данный момент попросту нет ресурсов, чтобы можно было развивать платформу объектного кода и частичных вычислений и одновременно с этим решать сложности, возникающие при трансляции в нее Си. При таком подходе время разработки довольно скоро устремится в бесконечность.

Так что извините, но нет. Си будет позже.

Представленный план верен. При должном финансировании его можно реализовать, я готов брать на себя ответственность.

3

Re: Раскрутка компилятора, финансирование (2018)

Замечание по поводу 2 этапа, направление Б (компилятор Python):

Grumpy is a Python to Go source code transcompiler and runtime that is intended to be a near drop-in replacement for CPython 2.7. The key difference is that it compiles Python source code to Go source code which is then compiled to native code, rather than to bytecode. This means that Grumpy has no VM. The compiled Go source code is a series of calls to the Grumpy runtime, a Go library serving a similar purpose to the Python C API (although the API is incompatible with CPython's).

Нужно изучить, служит данный инструмент лишь компилятором, или это способ миграции на Go. Кантор подразумевает постепенную миграцию.

4

Re: Раскрутка компилятора, финансирование (2018)

Есть мнение, что плохая оптимизация в TinyC поспособствует развитию высокоуровневой оптимизации в платформе Кантора (режим make), в том числе качественного построения целевого кода декларативного ООП, то есть будет развивать сам Кантор.