Так есть масса трансляторов из подмножества Python — куда-то еще. Почему бы не пропустить промежуточное звено в виде Julia и не транслировать прямо в LLVM? Разумеется, раз уж мы про разработку компиляторов говорим, то я буду рекламировать не готовые инструменты, а простое введение на тему того, как подобный транслятор сделать самому :) http://dev.stephendiehl.com/numpile/

прикольная идея)

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

А что Вы там обнаружили для себя?

Определения эквивалентности внутренним способом. Это довольно философски интересно

Я не называю что-то, что разработчик интуитивно чувствует, но не может доказать -- "известным фактом", поэтому для меня этот доклад как раз сделал известным разницу выразительных средств и понятие "мощности языка".

Там про это в FAQ джулии как раз говориться, проблема в том что numpile и numble это подмножества раз и используют LLVM JIT а не AOT два. Ну и соответственно это накладывает определенные ограничение как на портирование конкретного python кода так и на реальный буст по произвордительности

Что-то я не уловил, в чем же проблема. Питон же как раз язык выразительный! Зачем портировать все? Выбираем критический участок в программе и переписываем код на типизированном eDSL с использованием DSL-компилятора -- ну и далее см. мою ссылку выше. Благо в Питоне для таких дел есть модуль ast :)

Да что там LLVM! Я когда-то делал свой "дешевый и сердитый" JIT-компилятор для Питона следующим образом -- из программы на Питоне генерируется программа на Си и тут же, во время выполнения скрипта, результат вызывается через gcc. Сначала немного стеснялся такого решения, а потом выяснил, что Макаров для Ruby почти так же делал! :)

ну это костыли, отладка и профилирование будет в сях, супер неудобно

На самом деле это было довольно удобно. Не нужно было в комплекте с программным проектом держать исполняемые файлы в двоичном виде. Си-код с параметризацией через Питон получался эффективнее, чем просто Си-код. Естественно, профилирование проводилось, иначе зачем огород городить? А отладчик я последний раз запускал уже не помню когда, кажется, для какого-то МК на базе STM32...

история с виртуальной машиной очень хороша, библиотеки общие, легко перейти на другой язык

не понял, я про разработку на питоне, есть инструменты профилирования и отладки, тот же брейкпоинт, а тут получается этого всего не будет, кстати тесты на pytest такая штука сможет съесть?

Эх, но я же не просто про разработку, а про разработку компиляторов... Мда, казалось бы, тупик -- мы на данном этапе совершенно уже удалились от тематики канала, да? Но понаблюдайте, как я сейчас вырулю обратно! ;)

1. Не вижу причин любить pytest, который сделан по Java-лекалам. Есть же замечательный doctest! Вообще, использование для метапрограммирования docstring -- это в Питоне, насколько я помню, от лиспов.

2. Кстати говоря, "философский вопрос" -- является ли использование docstring для создания DSL с произвольным синтаксисом -- работой с внутренним DSL? Или это уже внешний DSL? :)

3. Среди компиляторщиков имя John Aycock достаточно известно. Он, в частности, придумал изумительно простой алгоритм построения формы SSA. А еще он для Питона разработал в конце 90-х систему конструирования компиляторов под названием Spark: http://pages.cpsc.ucalgary.ca/~aycock/spark/ Система эта довольно изящная, хотя и забытая. И как раз метаязыки там используются именно в docstring! В результате код простеньких компиляторов, созданных в Spark, выглядит вполне читаемо.

стандартный unittest там калька с джавы

pytest на джаву не сильно похож

О просто разработке тоже стоит говорить, чтоб создавать язык с её учётом.

1. pytest это вообще жуткая магия, его сложно любить, но он прикольный, а doctest всё таки очень узкое решение

Есть cython, органично совмещающий быстродействие python’а и удобство C.

Посмотрел doctest - отличная вещь!

cython уже компилятор, так что не торт

А есть системы контроля версий, которые не по строкам работают, а по AST конкретных языков?
правда сам не могу понять, что будет если diff будет считать два куска, отличающихся только пробелами и порядком литералов в сетах, одним и тем же

интересно бы такое увидеть. Но аст, мне кажется тоже не все проблемы решает. Например переименование не будет работать. По этому мне кажется надо как минимум граф а не дерево

возможно в UE4 такое есть, но это не точно