Pull to refresh

Comments 28

Есть хоть одна разумная причина делать всё это?

Есть хоть одна разумная причина НЕ делать всё это?
Есть. Lisp — это один из первых высокоуровневых языков. Пайтон — один из современных. По скорости исполнения они сопоставимы. Впрочем, сегодня Lisp всё чаще считают медленным. Синтаксис Python, в большей степени, проще, чем синтаксис Lisp. Код — более читаемый. Собственно, простота, удобство и скорость написания кода — главная фишка высокоуровневых языков. Lisp немного устарел в этом плане, хотя используется в прикладных задачах. Но, не думаю, что автор брался за замену Lisp кода Python'ом.
Итого: у нас есть два высокоуровневых языка с динамической типизацией, сопоставимых по скорости выполнения программ. Язык, который получается после трансляции, более прост и визуально понятен, чем язык, который используется для трансляции.
Вывод: делать такую трансляцию — неразумно.
Начнём с того что использованными диалект лиспа младше питона, и был написан не просто позже питона а на питоне. Скорость выполнения у них совершенно одинаковая, система типизации также. Мне незачем защищать сам принцип трансляции в питон — раз это было сделано, значит это кому-то нужно; мне, например пригодилось.
А вот «синтаксис питона проще» — чистая неправда
О том и речь: два медленных языка. Только Lisp с его диалектами выглядит в рамках задачи уж больно оверхедом.

мне, например пригодилось.

Значит, вы что-то делаете не так.
Я занялся этой задачей из практических соображений. Не хотелось писать много однотипных классов вручную.

Что мешает генерировать эти классы при помощи python?

Думаю, ничего. Вопрос в удобстве. Т.е. надо бы спросить «что помогает». В hy помогает синтаксис, принцип на котором построен язык и наличие готовых классов и функций под задачу.

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

Есть миксины. Есть магическая ф-ия type, которую можно использовать как фабрику классов.


Генерация python кода с помощью lisp может пригодиться… Никогда?

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

Нужно, для начала, рассмотреть вашу задачу. Почему я говорю, что вы что-то делаете не так: если речь идёт о генерации классов во время исполнения, то есть замечательная функция type(). Она позволяет создавать класс непосредственно в процессе выполнения кода. Т.е. вы пишете фабрики, которые, используя type, формируют классы с нужными методами. В input приходят аргументы, запускается генератор, возвращает вам класс и инстанс, с которым вы уже можете работать. Вот вам и DSL.

Однако, в большинстве случаев, создание такой фабрики не требуется, поскольку мы можем собрать любой сложный функционал, применив «Примеси» или Миксины. Миксины — это такие классы, которые применяются для множественного наследования. Каждый миксин может представлять собой реализацию одного-единственного метода, который будет использоваться в различных реализациях классов.

self.heavy.add_classes([Exorcist, Retributors, PenitentEngines])
self.troops.add_classes([BattleSisters])
self.transports.add_classes([ASRhino, Immolator])
self.hq.add_classes([Celestine, Canoness, Jacobus])
self.fast.add_classes([Dominions, Seraphims])
self.elite.add_classes([ArcoFlagellants, Assassins, Celestians, Dialogus, Hospitaller, Imagifier, Mistress, Priest, Repentia, PriestV2, Crusaders])


Вот это что за трёхколёсник? Не совсем понятно, что оно делает, но если бы мне нужно было собрать отряд, я бы начал вот с чего:

class PriestMixin(object):
    def heal_one(target):
        # do something
        pass
    
    def heal_many(targets):
        for target in targets:
            self.heal_one(target)

class WarriorMixin(object):
    def kick_ass(target):
        # kick ass
        pass

class KnightMixin(object):
    def protect(target):
        # protect target
        pass

class Patrol(object):
    def __init__(self, id, name, containments):
        self.id = id
        self.name = name
        self.unit_classes = [type(cont['name'], (*cont['mixins']), {}) for cont in containments]
        self.containment = [unit_class() for unit_class in unit_classes]

Patrol('SuicideSquad', 'Suicide Squad', [
    {'name': 'VasyaTheKnight', 'mixins': [PriestMixin, KnightMixin]},
    {'name': 'YouraMotherFucker', 'mixins': [WarriorMixin]}
    ])
Во-первых, про способ генерации я спрашивал не вас, а SirEdvin. Потому что о нём говорил он. Нужно было указать его имя с ником? Извините за неясность
Во-вторых, я прекрасно знаю про миксины и пользуюсь ими. Собственно, модель множественного наследования в питоне приводит меня в полное восхищение и щенячий восторг своей удобностью.
В-третьих, речь не шла о динамической генерации классов во время выполнения. В данном случае речь идёт об автоматической генерации кода который будет выполняться когда-то потом. Наличие сгенерированного кода позволяет в дальнейшем его ручную правку, применение к нему инструментов контроля версий — ну и проще в отладке чем динамически сгенерированные типы. Во всяком случае, этим руководствовался я.
Спасибо за совет касающийся приведённого мной примера
Ну, генерация кода программой — не новая фишка. Она прекрасно используется, в том числе, во вредоносном ПО. К сожалению, опять же, не совсем понятно для чего это делать. Если речь идёт об ИИ, который будет писать код, то это одно. Если нужно сделать червя, который будет самостоятельно дописывать код — другое. В первом случае, согласен, Lisp вполне может работать, как часть ИИ и использоваться для замены программистов (четвертовать бы вас за ваши исследования, или на кол посадить).

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

Это так же глупо, как компилировать CSS в scss. Ладно, с компиляцией lisp в js лет пять назад можно было согласиться. Но лисп в Пайтон?! Лисп менее лаконичен и по скорости выполнения может уступать python. К тому же, он хуже читается.

По старости выполнения этот лист пайтону уступить вряд ли сможет. Такова уж его природа что скорость выполнения будет всегда одинакова
Можно ли на считать этот лисп инструментом для создания разного рода DSL-ей для Python?
Да; это, пожалуй его самое лучшее применение.
Википедия говорит, что это основная область применения Hy. Однако, практическая сторона хромает. Например, Hy, по факту, весь код будет переводить в медленный python. Большинство полученных сниппетов будут примерно одинаковы по размеру в строках. С тем лишь исключением, что в Hy будет целая куча скобок.

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

Разумеется, можно использовать Hy для разработки DSL, рассчитанных на применение различными специалистами, которые не будут учить python. Только вот в чём проблема: Lisp в плане синтаксиса сложнее, чем python. Писать DSL для применения одним Lisp-гуру на всю компанию — экономически не выгодно. Создание же своего синтаксиса DSL проще реализовать на Python.

Да, посмотрел я в гитхабе репу этого Hylang:

Well. Python is awesome. So awesome, that we have so many tools to alter the language in a core way, but we never use them.

Why?

Well, I wrote Hy to help people realize one thing about Python:

It's really awesome.

Oh, and lisps are neat.


Иными словами, Lisp аккуратен, но Hylang был создан для того, чтобы показать, что пайтон лучше :-D Именно поэтому надо сперва читать README, а потом уже пилить обзоры.

Если бы эти языки имели разницу, смысл был бы. Например, если бы python генерировал c++. Это можно было использовать для увеличения производительности в отдельных вычислениях.


Либо, если нам нужно сгенерировать более сложный код с помощью более простого. Например, контроллер поддерживает golang. Но python — лаконичнее, и мы пишем код на python, который транслируется в go.


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

Смысл есть, «Hy» имеет распространенный диалект лиспа. Автор теперь может писать свой тормознутый высокоуровневый код и компилировать его в быстрый JVM байт-код (Clojure), js на фронте (ClojureScript), NodeJs (lumo), C++ (ferret-lang) и многое другое. Сложность синтаксиса вещь субъективная, после преодоления порога входа (да большой), писать на лиспах — быстро, просто и приятно. Читать чужие исходники на диалектах лиспа с иммутабельностью (Clojure), выходит еще проще чем документацию. Ну и бодрости к скорости разработки добавляет мощный REPL (если есть под диалект).
Хотелось бы если бы оно было так. Условно говоря иметь еще один таргет компиляции кложуры. Для всяких вспомогательных скриптов, как замена питону или перлу. (Очень уж медленно JVM стартует и обычная кложура не подходит для этих целей.) С хорошим интеропом со стандартной библиотекой питона и с вменяемой собственной библиотекой.

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

Скорее, наверное, lumo с нодой быстрее допилят и доведут до пристойного вида.
Вероятно можно было бы сделать на Hy прикольную кодогенерацию. Но возможно пример хромой, и галопом по европам тоже не помогает. Может вторая попытка?
Sign up to leave a comment.

Articles