среда для clojure: emacs или vscode?

PyQt/PySide и есть непитоновские костыли

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

А на чем еще писать рич-графический интерфейс под десктоп на джаве что ли или на С++?

Под форточки еще на дотнете пишут весьма успешно.

Очевидно. Но не кросплатформенно, WPF не работает под линуксом.

Давай все-таки разберемся с определениями

Почитай определение интерпретатора, и необходимость в каких-либо разбирательствах отпадет сама собой.

Ты был полностью прав, когда говорил, что получится питон

Ну, спасибо что признал. Хотя не факт, что мы все равно с тобой имеем ввиду одно и то же, даже по этому поводу.

Это разительно отличается от Clojure, где set/setq/setf вообще отсутствуют в языке и все изменения выполняются в более функциональном стиле возвратом измененных значений вместо изменения объектов по месту

На то он и функциональный язык. def правда это такой же setf, только который можно применить один раз.

в функциональном стиле пишут и на других лиспах (и это считается хорошим стилем)

В кложуре, схеме, рекет - да. Но и там (везде) есть императивщина, ибо без нее неюзабельно совсем.

Точно так же и на питоне можно писать в более функциональном стиле

Можно, но писать неудобно. Нормальных лямбд нет, tco нет (и не будет), других атрибутов современного фп (вроде неизменяемых структур, ленивости, диспетчеризации разнообразной) тоже нет. И кругом торчит опп и императивщина, начиная со стандартной либы.

так что, еще раз повторю: лисп без макросов, действительно, примерно равен питону.

Я рад, что мы пришли к этому понимаю. Сори, если как-то агрессивно немного отвечал, просто выбешивают супер-помповые заявления без знания матчасти.

так что мои додумки по поводу макросов в рантайме CL/ранней Clojure были додумками. Правда, apply-macro в Clojure таки было, но опиралось на eval и в итоге его выкинули из библиотеки

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

На счет равенства питону надо обозначить, что это гипербола в самом утрированном смысле - но я рассматривал только аспекты даже не касающиеся реализаций. Преимущества у текущих (а не гипотетических) лиспов на уровне реализаций все еще значительны, по сравнению с такими языками как питон, руби - в первую очередь это repl, даже в первые три очереди. Далее - скорость (при этом легкость создания прототипов не теряется), рестарты, дженерики, clos, mop, возможность _нормально_ писать в фп-стиле (из-за префиксной нотации, нормальных лямбд и оптимизации хвостовых вызовов), в некоторых диалектах типа кложи есть немутабельные и ленивые структуры, в CL это тоже есть, но реализовано на уровне библиотек, а потому не столько удобно. Каждая из перечисленных особенностей - киллер фича. Сюда же разработка в образе. И это мы, напомню, выкинули макросы. С ними - еще целый ряд подобных фич. Наличие стандарта - тоже считаю преимуществом. И есть минимум 6 (шесть!) продакшн риди реализаций - CCL, SBCL, Allegro, Lispworks, ECL, Clasp etc.

Поясни. Имеется ввиду, что можно автоматическими средствами отформатировать исходник, как тебе нравится или о чем-то другом?

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

Но мега-лулзовый костыль \
   просто-напросто убог.

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

Я спрашиваю у своего собеседника.

на публичном форуме

Но мы говорили о принципиальных отличиях, черточки в именах - это не принципиально.

Мелочь, но когда глазеешь на такую мелочь днями напролет, то все эти NewVariable или hello_world начинают резать глаза, и понимаешь насколько бытсро привыкаешь к такой малой, но приятной возможности написания как new-x или with-accessors. И это становаится принципиально.

функциональное программирование (в пейтоне оно не поощрается) Ф-п на таком же уровне есть в руби и жс.

так мы про жс или руби? или питон? или pypy? или про хаскелль? а то в хаскелле еще круче фп. может за хаскелль поговорим?

Это все про реализацию, а не о принципиальных отличиях. Кроме того в питоне есть pypy.

Принципиального различия чего с чем? В питоне нет никакого pypy. Есть pypy, который определяет свой питон. Ну да ладно. Я конечно же знаю о чем ты. Не проблема, будем сравнивать текущий лисп с гипотетической реализацией питона из будущего, где все сделано как надо, все сомнительные решения вырезаны, все гениальные решения приняты, а волосы у программистов гладкие и шелковистые, да и вообще все за всех пишет ИИ на биологической основе Гвидона Вишневского Гвидо ван Россума и нет никаких программистов. Это очень удобная позиция в плане споров ни о чем на лоре, но не очень практичная ирл.

Но мы говорили о принципиальных отличиях

И да, я смотрю у тебя тоже калибр приравнивателя нехилый такой. Для меня все перечисленные вещи - довольно принципиальны. И префиксная нотация, и идентификаторы, и человеческий CLOS, и индентация, и компиляция, и многопоток, и скобочки, и ФП, и интерактивность. Даже если они могут появиться когда-либо в божественном питоне будущего (наверное, именно на том на котором сам Господь говнокодил нашу вселенную), то могу только сказать - пока не объяснено как эти фичи будут в него встроены, говорить особо не о чем, можно только фантазировать.

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

В питоне нет никакого pypy. Есть pypy, который определяет свой питон. Ну да ладно.

pypy это как раз-таки реализация совместимая с эталонным cpython, это не cython и подобные «свои питоны». В нем, например, нет GIL и скорость исполнения значительно выше, по понятным причинам (JIT).

Это очень удобная позиция в плане споров ни о чем на лоре, но не очень практичная ирл.

Изначальный разговор был о том, «что если» убрать из лиспа макросы, что там останется принципиально отличного от питона. Что останется я перечислил, даже отдельным сообщением.

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

Вместо питона можешь подставить js и рассказать, например, в чем там принципиальная сложность сделать репл. А ее нет, просто «там так не принято».

Ну прям как в старые добрые времена… Хотя ослабление, конечно, налицо, но во всяком случае можно вспомнить их.

Так я чуть выше как раз все и перечислил на эту тему.

Я те сообщения не принимал в расчет. Мне, что, когда ты вдруг постишь сообщения разъясняющие свою позицию, вдруг брать и переписывать свой собственный, филигранно-выточенный ответ, который я вот-вот закончу? Размечтался.

Что останется я перечислил, даже отдельным сообщением.

Я все же настаиваю что бы в этом списке была индентация.

Ну и да, ты конечно забыл самое главное - основанность на теоретических принципах.

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

…

Да «гипербола.» Да «выбросил из лиспа макросы - получил петон.» Да «вкусовщина же». Тьфу на вас всех.

Арэвуар, Аристоклий.

К прощанию, конечно же, присоединяются Доброжир и Аристарх. Все втроем плюем и ссым на вас.

В том-то и дело, что ничего интересного и нового тут не написано, к сожалению. А что там у тебя с сидром получилось все?

PyQt/PySide и есть непитоновские костыли

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

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

Почитай определение интерпретатора, и необходимость в каких-либо разбирательствах отпадет сама собой

Легко:

«In computer science, an interpreter is a computer program that directly executes instructions written in a programming or scripting language, without requiring them previously to have been compiled into a machine language program»

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

def правда это такой же setf, только который можно применить один раз

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

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

Ленивость есть на итераторах и генераторах. Неизменяемый встроенный контейнер тоже есть. С диспетчеризацией затык только.

Сюда же разработка в образе. И это мы, напомню, выкинули макросы

На макросах лиспа вы можете написать любой собственный язык, если этот язык — лисп. В питон так-то ввели работу с AST и хуки загрузки модулей. Мой главный посыл был: макросы не нужны, большинство задач можно выполнить без них, с сохранением той же ленивости.

pypy это как раз-таки реализация совместимая с эталонным cpython, это не cython и подобные «свои питоны». В нем, например, нет GIL и скорость исполнения значительно выше, по понятным причинам (JIT)

Еще раз повторяю тезис про то, что JIT — это далеко не серебрянная пуля. И в питоне, и в JS. Потому JIT-компилируются только отдельные часто вызываемые куски кода.

Изначальный разговор был о том, «что если» убрать из лиспа макросы, что там останется принципиально отличного от питона. Что останется я перечислил, даже отдельным сообщением

Я так понимаю, речь про вот это сообщение:
среда для clojure: emacs или vscode? (комментарий)

Я боюсь, что это уже мелкие детали реализации и там уже на вкус и цвет. Так-то разные варианты REPL есть и для питона, и для JS (при изменении сорцов в SPA перезагружаются измененные модули и обновляются затронутые компоненты).

На макросах лиспа вы можете написать любой собственный язык, если этот язык — лисп.

Нет, посмотри какие языки написаны на racket - даже те, которые представлены на офсайте. На CL тоже писали разные языки, с любыми синтаксисами. Не популярно это по другой причине - потому что не нужно, мы в таких языках лишаемся мощности хостового языка. А ради чего?

В питон так-то ввели работу с AST и хуки загрузки модулей.

И как это помогает ввести в питон новые синтаксические конструкции?

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

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

Еще раз повторяю тезис про то, что JIT — это далеко не серебрянная пуля. И в питоне, и в JS.

Речи не шло о серебрянных пулях. А о том, что современные python и js - компилируемые языки, в байткод, при этом иногда используется JIT компиляция. Что тоже компиляция, а не интерпретация.

Я боюсь, что это уже мелкие детали реализации и там уже на вкус и цвет.

Они не мелкие, и в сумме позволяют пользоваться всей мощностью, растущей с каждой фичей нелинейно.

Так-то разные варианты REPL есть и для питона

И для многих других языков, по сравнивать это с лисповым реплом можно только если последнего в глаза не видел.

На тебя ссым особенно злостно! (но и на других не перестаем!)

Это касается любых биндингов питона, которые нужны для любой задачи со скоростью, отличной от «очень медленно».

Большинство задач с гуи - не требуют никакой супер скорости.

А вот для жавы GUI либы, писанные на самой жаве, существуют.

Ну, отлично. Написали на низкоуровневом языке gui с системщиной. Но пользоваться можно из языков более высокого уровня.

Является ли байткод машинным кодом?

У тебя определение неверное. Java у тебя тоже интерпретатор? :)

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

Нет, не получается. Целевая платформа для python (и для java) - своя VM. Это компилятор.

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

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

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

Ленивость есть на итераторах и генераторах.

Этого мало.

Неизменяемый встроенный контейнер тоже есть. С диспетчеризацией затык только.

Какой неизменяемый контейнер есть в питоне?

Нет, посмотри какие языки написаны на racket - даже те, которые представлены на офсайте. На CL тоже писали разные языки, с любыми синтаксисами. Не популярно это по другой причине - потому что не нужно, мы в таких языках лишаемся мощности хостового языка

Можно написать любой препроцессор для питона или руби. Там мы уже потихоньку подходим и к вопросам фронтэндов LLVM. То есть, уже не легко, не быстро, не удобно. Однако же, речь про макросы, а макросы ограничены именно языком. А в языке есть более удобные конструкции, чем макросы. И советы применять лямбды/функции вместо макросов не лишены оснований, потому что функции можно применять и во время компиляции, и во время выполнения — необходимости делать этот выбор не было в более ранних лиспах. Когда в лиспе макросы уехали в compile-only, то смысл всей петрушки по большей части пропал. Вот, посмотри на макросы в схеме, например, где их порезали знатно.

И как это помогает ввести в питон новые синтаксические конструкции?

Введению новых синтаксических конструкций мешает необучаемость ЦА. А так — можно веселые штуки на AST делать:
Python at Scale: Strict Modules

Макросы - это не замена ф-ций, а их расширение для эффективной кодогенерации и создания eDSL, в первую очередь

К сожалению, в эффективной кодогенерации много чего зависит от того, как транслятор подружится с процессором. Для проявления инициативы со стороны кодера в каком-то там компиляторе CL для этого даже «ассемблерные вставки» придумали, но это очень трудоемко и непортируемо. Особенно этому «помогают» всякие создатели непортируемых SIMD инструкций (новый код не запустится на старом процессоре, новый процессор не дает никаких преимуществ для старого кода).

Или ты про генерацию исходного кода? В том же хаскеле функции полиморфны, принимают переменное число аргументов — что еще нужно для «эффективной генерации кода»?

Опять-таки, я не увидел смысла в макросах. Что можно сделать с макросами, что без них нельзя? Написать лисп на лиспе? Но для этого не нужны макросы. Работа с чужеродной AST, как я уже писал, лишает доступа к инструментам лиспа и намного сложнее — она есть в питоне, она есть в руби, причем, в питоне при этом нет макросов. Так зачем нужны макросы?

Так зачем нужны макросы?

А я предлагал тебе объяснить. Причем цена, если ее вообще можно так назвать, была весьма адекватна, она была, можно сказать, чисто символическая. Даже в порыве энтузиазма начертал небольший ответ. Но ты промолчал. Теперь поздно. Теперь ты попущен мною и моими друзьями и никто тебе ничего объяснять не будет.

современные python и js - компилируемые языки, в байткод

Ну тогда моя очередь посылать тебя читать определение компиляции. Байткод питона не является низкоуровневым языком, и не является продуктом сборки чего-то там. То есть, трансляция исходника в байткод — это не компиляция (хоть я сам и назвал ее так). Примерно как преобразование JS ES6 в JS ES5 не является компиляцией, а является трансляцией. Примерно как reader в лиспе не является компилятором.

Я боюсь, что это уже мелкие детали реализации и там уже на вкус и цвет

Они не мелкие, и в сумме позволяют пользоваться всей мощностью, растущей с каждой фичей нелинейно

Вот именно, ты не можешь выделить из этого списка что-то значимое. Это вроде жавистов, которые будут говорить «а еще у нас язык адаптирован под IDE». Скромно умалчивая, что без IDE языком просто нереально пользоваться в проекте значительного размера. Даже такой ужасный язык, как жава, выжил и интенсивно используется. И C++ используется, хотя ни разу не сахар. Потому что да, одной мелочи не хватает, другой не хватает, но в целом без всех этих плюшек можно спокойно прожить — и таки живут, и пишут на питоне, и не просят ввести макросы в питон, и не нужны им CLOS и MOP.

И для многих других языков, по сравнивать это с лисповым реплом можно только если последнего в глаза не видел

... и ты с легкостью назовешь киллер фичи лиспового REPL, которых нет в питоне? Функции, аналогичные read-eval в питоне есть, нет только печати, поскольку язык не гомоиконный.

Большинство задач с гуи - не требуют никакой супер скорости

Ты бы очень удивился, если бы узнал, насколько может быть медленным GUI на питоне. Очень отдаленное представление можно получить, если сравнить обычный питонью GUI на биндингах с обычным непитоновым GUI без бидингов. Там уже проблема не в том, насколько быстро оно отрабатывает, а в том, что «я кнопку нажал, не нажал, или это у меня программа зависла» — и так на каждом действии. Даже секретарше таким тяжело пользоваться.

Является ли байткод машинным кодом?

У тебя определение неверное. Java у тебя тоже интерпретатор?

Да. И QEMU VM тоже интерпретирует. К слову, не Java, а JVM. Интерпретатор с компилятором. Проблема непонимания этого находится на твоей стороне и заключается в том, что ты не догадываешься, насколько тормознутой может быть жаба — просто потому, что ее никто не запускает без помощи JIT или AOT компилятора. Вот в случае жавы JIT очень сильно решает, и это создало некий такой слух, что жава — чисто компилируемая штука. Но вот почему-то не получается толком AOT компилировать ее — это один из первых звоночков, который должен натолкнуть на мысли.

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

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

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

Неизменяемый встроенный контейнер тоже есть. С диспетчеризацией затык только.

Какой неизменяемый контейнер есть в питоне?

tuple же ж. Кортеж кортежей неизменяем. Да, можно в кортеж засунуть изменяемый список, но тут уже ССЗБ — список в кортеж прекрасно превращается. Примитивные типы, вроде чисел и строк, уже из коробки неизменяемы. Ассоиативные массивы из коробки изменяемы и поддержка неизменяемых из коробки отклонена, хоть отклонена и по причине простоты написания собственной реализации подобного контейнера.

современные python и js - компилируемые языки, в байткод

Ну тогда моя очередь посылать тебя читать определение компиляции

In computing, a compiler is a computer program that translates computer code written in one programming language (the source language) into another language (the target language). The name «compiler» is primarily used for programs that translate source code from a high-level programming language to a lower level language (e.g., assembly language, object code, or machine code) to create an executable prog.

Примерно как преобразование JS ES6 в JS ES5 не является компиляцией, а является трансляцией. Примерно как reader в лиспе не является компилятором.

У тебя смешались кони люди трансляция компиляция интерпретация. И компиляция, и интерпретация - это трансляция (внезапно). Основное отличие в том, что интерпретатор не создает промежуточное представление, а сразу преобразует, допустим, DSL -> AST и выполняет (или не выполняет), компилятор же создает объектный / машинный код, зачастую сразу с оптимизациями, в результате которых часть высокоуровневой информации может теряться, добавляться мета-информация и так далее, применяются различные методы оптимизации короче. Из откомпилированной программы затруднительно восстановить исходник (если он явно не хранится прицепом в уже скомпилированном коде, но такого почти нигде нет), в случае же интерпретатора - восстанавливать либо совсем нечего (построчное / пооператорное выполнение), либо восстановление непроблематично. ES6->ES5->ES6 это тривиальная трансляция, макросы лиспа тоже: вначале однозначно *интерпретируются* в хостовой язык, а уже затем выполняется компиляция полностью раскрытой программы в низкоуровневую хрень - машкод (sbcl, ccl, ...) либо в java bytecode (в случае clojure), или в байткод с последующим jit-ом для racket и прочих chez scheme. А ты все перепутал.

Они не мелкие, и в сумме позволяют пользоваться всей мощностью, растущей с каждой фичей нелинейно

Вот именно, ты не можешь выделить из этого списка что-то значимое

Все значимо, что я перечислил, тебе просто сложно это осознать.

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

Аналогию на тему сложности оценить преимущества зрения слепорожденным я уже приводил. Как можно хотеть macros, repl, clos, mop etc - если о них почти никто не знает что это? «А сегодня в завтрашний день не все могут смотреть. Вернее, смотреть могут не только лишь все. Мало, кто может это делать.» (с)

... и ты с легкостью назовешь киллер фичи лиспового REPL, которых нет в питоне?

Я уже задавал вопрос в этом треде - расскажи конкретно, как ты пользуешься реплом в питоне. У тебя есть файл с данными, классами и ф-циями, данных, допустим много, к примеру тебе нужно найти аномалии в данных, некорректные данные и так далее. Все функции используют один и тот же набор данных, который может быть немного модифицирован для каждой из них, предобработан предыдущей ф-цией и все в таком духе. Как ты будешь последовательно (или параллельно) тестировать данные в питоне и тестировать ф-ции, которые с ними работают? Что будешь делать, когда окажется, что ф-ция работает некорректно, ее необходимо исправить и вновь прогнать по данным (напоминаю - при загрузке из файла данные предобрабатываются для последующей удобной манипуляции с ними). Таких ф-ций у тебя 50 штук, каждая из которых может выполняться значительное время. Но протестировать тебе нужно одну, или несколько. И ты можешь даже не знать какую изначально. Следующий вопрос - что будешь делать, если к середине обработки файла / фикстуры явно будет видно, что данные испорчены (и их можно поправить по месту) или там вообще результат деления одного столбца данных на другой - devision by zero, а до середины мы считали полчаса (или 2 месяца) и очень не хотим заниматься этим заново, надо только поправить в конкретном месте и продолжить. А еще попутно написать небольшой тест над рандомным кусочком из всего массива данных, протестировать, убедиться что все ok и выкинуть этот одноразовый код. Еще неплохо было бы на каком-то этапе сохранить все над чем ты экспериментировал, чтобы продолжить завтра или через год, или твоему коллеге.

В общем, слушаю тебя внимательно.

Большинство задач с гуи - не требуют никакой супер скорости

Ты бы очень удивился, если бы узнал, насколько может быть медленным GUI на питоне.

Еще раз - для большинства задач этой скорости более чем достаточно.

Очень отдаленное представление можно получить, если сравнить обычный питонью GUI на биндингах с обычным непитоновым GUI без бидингов.

Использую gui на PyQt почти каждый день - тормозов нет.

Там уже проблема не в том, насколько быстро оно отрабатывает, а в том, что «я кнопку нажал, не нажал, или это у меня программа зависла» — и так на каждом действии.

Возможно, ты просто пользуешься коряво написанным софтом.

Даже секретарше таким тяжело пользоваться.

Продемонстрируй - запиши демку того, как все тормозит на PyQt.

Является ли байткод машинным кодом?

У тебя определение неверное. Java у тебя тоже интерпретатор?

Да.

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

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

Никто тебя не торопит - прочти вдумчиво и ответь через неделю, но по делу, а не что попало в огороде бузина.

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

Зачем ты хочешь это обсуждать вообще?

Какой неизменяемый контейнер есть в питоне?

tuple же ж. Кортеж кортежей неизменяем. Да, можно в кортеж засунуть изменяемый список

Классная иммутабельность, ага.

список в кортеж прекрасно превращается.

А шо там с персистентными структурами в массивах и подобных превращениях в питоне, потормозим немножечко?

Примитивные типы, вроде чисел и строк, уже из коробки неизменяемы.

Какая красота! А то я обычно первым делом как открываю чужой код - сразу ищу как заменить единицу на ноль, true на false итд, но почти нигде так не получается. Ой, а в питоне можно, за что мы его и любим :) Если что, невозможность изменения примитивов - это не про иммутабельность.

Ассоиативные массивы из коробки изменяемы и поддержка неизменяемых из коробки отклонена

Естественно, отклонена. Потому что без эффективной реализации немутабельный структуры - неюзабельны на практике.

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

Если бы ты хотя бы сам читал по ссылкам которые кидаешь - то узнал бы, что причины отклонения совсем другие. Это «нинужна» потамушта «неасилели» и «надо будет полпитона переписать» и PyPy вдобавок. Зачем нам это, если нам даже оптимизация хвостовых вызовов нинужна. Зато GIL _нужен_. Дайте два.

vim же.

In computing, a compiler is a computer program that translates computer code written in one programming language (the source language) into another language (the target language). The name «compiler» is primarily used for programs that translate source code from a high-level programming language to a lower level language (e.g., assembly language, object code, or machine code) to create an executable prog

Это то, о чем я писал. Или ты мне предлагаешь ограничиться первым предложением. которое, например, включает в себя также декомпилятор, то есть, декомпилятор = компилятор. Оттуда же:

«An interpreter is computer software that transforms and then executes the indicated operations»

Transforms, и потом executes.

Основное отличие в том, что интерпретатор не создает промежуточное представление, а сразу преобразует, допустим, DSL -> AST и выполняет (или не выполняет), компилятор же создает объектный / машинный код, зачастую сразу с оптимизациями, в результате которых часть высокоуровневой информации может теряться, добавляться мета-информация и так далее, применяются различные методы оптимизации короче

Опять-таки, по твоим же критериям CPython получается интерпретатором. Потому что преобразует DSL->AST и выполняет его. Однако же, AST должно иметь какую-то форму представления. Если брать отладочный выхлоп GCC/LLVM, то они в разы больше исходников. Если бы в GCC/LLVM надумали сохранять именно AST, то они тоже были бы вынуждены создавать более компактное представление AST.

В питоне более компактным представлением AST и является байткод. В нем из исходного кода отсутствуют только комментарии, и то не все, строки документации сохраняются. Собственна, «оптимизация» этого «компилятора» и заключается в том, чтобы выкинуть docstring-и и assert-ы — в остальном это один к одному исходник.

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

Создаю модуль в IDLE, запускаю/перезапускаю его, по окончанию его работы получаю интерактивную консоль со всеми данными.

что будешь делать, если к середине обработки файла / фикстуры явно будет видно, что данные испорчены (и их можно поправить по месту) или там вообще результат деления одного столбца данных на другой - devision by zero, а до середины мы считали полчаса (или 2 месяца) и очень не хотим заниматься этим заново, надо только поправить в конкретном месте и продолжить

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

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

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

Еще неплохо было бы на каком-то этапе сохранить все над чем ты экспериментировал, чтобы продолжить завтра или через год, или твоему коллеге

IDLE умеет сохранять свою консольку.

Очень отдаленное представление можно получить, если сравнить обычный питонью GUI на биндингах с обычным непитоновым GUI без бидингов.

Продемонстрируй - запиши демку того, как все тормозит на PyQt

Еще раз: я вел речь не про дерганье функций на C/C++, а про то, чтобы, например, иметь главный цикл на питоне. В PyQt/PyGTK главный цикл на C/C++ написан так-то. В противном случае при каком-нгибудь изменении размера окна в твоем приложении на PyQt/PyGTK оказывается, что код на питоне вообще не выполняется, полностью всю работу по пересчету элементов и отрисовке их выполняет только сишный код. Примерно та же история с машинным обучением, где кодер только задает конфигурацию, а полностью все вычисления делаются на C/C++.

То есть, еще раз: питон оказывается дергалкой функций или конфигурялкой, на нем самом ничего не считается.

У тебя компилятор - это только в машкод, что в корне неверно

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

tuple же ж. Кортеж кортежей неизменяем. Да, можно в кортеж засунуть изменяемый список

Классная иммутабельность, ага.

список в кортеж прекрасно превращается.

А шо там с персистентными структурами в массивах и подобных превращениях в питоне, потормозим немножечко?

Ну в CL тоже тормозить придется так-то.

А то я обычно первым делом как открываю чужой код - сразу ищу как заменить единицу на ноль, true на false итд, но почти нигде так не получается. Ой, а в питоне можно, за что мы его и любим :) Если что, невозможность изменения примитивов - это не про иммутабельность

Я про вот это:

>>> s1 = 'abc'
>>> s[1] = 'g'
Traceback (most recent call last):
  File "<pyshell#16>", line 1, in <module>
    s[1] = 'g'
TypeError: 'str' object does not support item assignment

В каком-нибудь Си можно без проблем изменить true на false, поскольку true/false не являются никакими объектами-контейнерами, а просто числовыми значениями, подставляемыми в код во время компиляции.

Это то, о чем я писал.

Ты сознательно игнорируешь фразу «assembly language, *_object_code_*, or machine code»?

Transforms, и потом executes.

Ну правильно, в AST хотя бы надо преобразовать, чтобы было что исполнять.

Опять-таки, по твоим же критериям CPython получается интерпретатором.

Нет, не получается. Вначале он _компилирует_ исходник в *байт-код* (а не другой ихсодник), а затем байткод выполняется. Принято считать, чисто терминологически и исторически, что интерпретатор транслирует и выполняет код пооператорно.

Однако же, AST должно иметь какую-то форму представления.

Чем недостаточно самого AST, зачем нужен байткод?

«оптимизация» этого «компилятора» и заключается в том, чтобы выкинуть docstring-и и assert-ы — в остальном это один к одному исходник.

Т.е. не проводится оптимизаций (в cpython) - при этом трансляция происходит из более высокоуровневого языка в низкоуровневый (байткод), а не в пределах одного языка CL->CL или языка одного уровня ES6->ES5 с *последующей* трансляцией в байткод. Короче, классическое понятие интерпретации оно про другое, вот как QBasic транслировался примерно это оно. Байткод же явно более низкоуровневая штука, чем сам язык (питон), то что там нет или почти нет оптимизаций - уже вопрос другой, и решение такое могло быть принято по причинам в широком спектре от «ниасилили» до «нам надо быстро компилировать» потому что скриптуха или «давайте оставим такой байткод, над которым уже потом если очень захочется можно проводить оптимизации вроде JIT».

«оптимизация» этого «компилятора» и заключается в том, чтобы выкинуть docstring-и и assert-ы — в остальном это один к одному исходник.

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

Подытожим. Интерпретация от компиляции отличается следующими признаками: 1) Обычно выполняется пооператорно, промежуточное представление нигде не сохраняется 2) Соответственно, не проводится предварительный анализ кода модуля на корректность 3) Не применяются оптимизации 4) Трансляция происходит в язык примерно того же уровня либо в AST - выполняется согласно первым трем пунктам. Вывод: python - примитивный, но компилятор, в баткод.

Продемонстрируй - запиши демку того, как все тормозит на PyQt

Еще раз: я вел речь не про дерганье функций на C/C++, а про то, чтобы, например, иметь главный цикл на питоне. В PyQt/PyGTK главный цикл на C/C++ написан так-то. В противном случае

Ну, то есть ничего не тормозит по факту, правильно я тебя понял?

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

Мне без разницы, что там происходит под капотом, если я пишу код на питоне. А PyQt - это именно что python и ничего более.

У тебя компилятор - это только в машкод, что в корне неверно

Или в низкоуровневое представление.

Приведи примеры других низкоуровневых представлений - кроме машкода.

Трансляция между языками близкого уровня — транспиляция.

Прекрасно, значит ES6->ES5 и макросы CL это транспиляция. Но что нам это дает в контексте обсуждения интерпретации vs компиляция?

Исходное значение слова «compile» — собирать/грабить, складывать выдержки вместе

В английском языке многие слова вообще не имеют однозначного значения, без контекста.

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

Т.е. python - транспилятор? :) Или нет? И какое это отношение имеет к интерпретации?

То есть, еще раз: питон оказывается дергалкой функций или конфигурялкой, на нем самом ничего не считается.

Мы как бы и так были в курсе, ты просто рассказывал что PyQt тормозит - я попросил продемонстрировать.

А шо там с персистентными структурами в массивах и подобных превращениях в питоне, потормозим немножечко?

Ну в CL тоже тормозить придется так-то.

Не придется. http://blog.thezerobit.com/2012/07/21/immutable-persistent-data-structures-in... и до кучи FSet, sycamore, Series, Taps итд.

Я про вот это: «>>> s1 = 'abc'; s[1] = 'g'»

Я понял, о чем ты. Но этого _очень_ мало.

В каком-нибудь Си можно без проблем изменить true на false, поскольку true/false не являются никакими объектами-контейнерами, а просто числовыми значениями, подставляемыми в код во время компиляции.

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

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

True является любым числом отличным от нуля.

тип bool в C тип bool в C

А вот False менять нельзя.

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

True является любым числом отличным от нуля.

И поэтому True = False имеет смысл в случае...? Каком?

True является любым числом отличным от нуля.

Впрочем лучше следовать логике программы и дурью не заниматься.

И поэтому True = False имеет смысл в случае…? Каком?

Речь о булевых операциях.
А у них целочисленное значение равное нулю - false.

Но вопрос вообще был в другом - какие средства иммутабельности обеспечивает python. И что это классный язык, в котором можно сделать True = False и радоваться жизни (в 3.х это если что исправили уже). И если засунуть в кортеж список - то вся иммутабельность поплывет, и что в нем нет persistent data structs.

«Нет программиста - нет проблем».

У меня reporting отвечает за формирование отчетов и non problem.
А писал бы их «вручную» обязательно были бы ошибки.
Абсолютно все ошибаются при разработке программ /в основном конечно в логике/.

И если засунуть в кортеж список - то вся иммутабельность поплывет, и что в нем нет persistent data structs.

Эх, только ли в Python?
C++ стал сложен тем, что на каждое «льзя» имеются десятки «нельзя».
И программист должен хорошо понимать все «льзя» и «нельзя».

Владимир 123

Из твоего ответа очевидно, какое представление о репле имеется в других языках (не-лиспах) аля питон. Мне, чтобы тебе что-то продемонстрировать опять нужно копипастить весь предыдущий ответ? Ведь ты оттуда упустил самую суть, вообще всю то есть. Пишешь мне о каких-то перезапускаемых модулях (но в условиях задачи каждая ф-ция тяжеловесная, как и фикстура), рассказываешь о том, что это какие-то специфические задачи (но IRL это самый типичный процесс исследования данных), потом у тебя испорченные данные почему-то исправить нельзя (хотя в 99% случаев можно), но смысл не в их исправлении - а в том, чтобы продолжить вычисления дальше, не потеряв предыдущие, чтобы иметь возможность их откорректировать не теряя времени программиста и вычислительных ресурсов. Пишешь о каких-то одноразовых ф-циях в репле, хотя нас интересует в первую очередь запуск небольших ф-ций прямо из исходника, или части этих ф-ций, короче любой формы. IDLE сохраняет какую-то там консольку (историю команд?) - а я тебе говорю о сохранении образа. И при чем тут idle вообще, а если я веду разработку в eclipse? Смотри, обычно лисперы на тему репла говорят «вам не понять», я же нарушил это негласное правило тайного лисперского сообщества - попробовал объяснить, по сути совершил акт отступничества. Но ты просто даже не читаешь, что я пишу. За что? )

Кстати, вот это мы еще забыли дообсудить.

Да, потому что Clojure — это такой язык скриптования встроенной базы данных для жавы. Отсюда и такие средние зряплаты. Как лисп оно совсем никому не интересно.

Кложа интересна именно как лисп и ничего более. При чем функциональный лисп. Мне, и много кому еще. Языков «скриптования» до нее было много - scala, groovy, jruby, juthon. Но они действительно не популярны и маргинез.

Меня больше всего удивляет то, что находятся фанаты ClojureScript, которое в мире JS вообще ни к селу ни к городу

Расскажи почему, очень интересно.

, потому в мире JS нет спроса на многопоточную логику, а в остальном CS — это достаточно тонкая и ненужная надстройка над базовым языком.

Шта?

Если бы это был какой-нить ML (привет F#),

Привет, Scala.

то без скобочек это было бы менее и более востребовано. Но, как грица, дареному коню в зубы не смотрят.

Дареных коней было много - они не взлетели в отличии от лиспа over jvm.

Ты сознательно игнорируешь фразу «assembly language, *_object_code_*, or machine code»?

«Object code is a portion of machine code that has not yet been linked into a complete program»

Transforms, и потом executes.

Ну правильно, в AST хотя бы надо преобразовать, чтобы было что исполнять

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

Принято считать, чисто терминологически и исторически, что интерпретатор транслирует и выполняет код пооператорно

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

Чем недостаточно самого AST, зачем нужен байткод?

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

И далеко не всегда получится сделать обратную трансляцию (как и в случае компиляции в ассемблер, хоть и значительно больше таких обратных преобразований возможны)

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

2) Соответственно, не проводится предварительный анализ кода модуля на корректность
3) Не применяются оптимизации

Под питон подходит.

Ну, то есть ничего не тормозит по факту, правильно я тебя понял?

Да, потому что оно писано не на питоне. Точно так же, как если ты напишешь в питоне «subprocess.run('pg_ctl start -l logfile')», то это не «я написал сервер СУБД на питоне», а работу будет выполнять вызванная программа. Питон здесь — это запускалка-конфигурялка. То есть, при создании гуя на PyQt роль *.ui файлов примерно такая же, как у питона. Большую же часть работы выполняет Qt, и кто его знает, сколько в нем багов.

А PyQt - это именно что python и ничего более

Прям ничего-ничего? А не пробовал смотреть, сколько левых бинарников подключает твое приложение? Это тоже всё питон?

Приведи примеры других низкоуровневых представлений - кроме машкода

Питон->Си. Полученный код кроссплатформенный, но превращение необратимо и часть возможностей питона (вроде exec/eval и разной рефлексии) теряется. Еще превращение высокоуровневых ЯП в какой-нибудь IR LLVM, поскольку типы данных и инструкции намного проще исходных, большое кол-во исходных описаний потеряно, а часть превращены в результате оптимизаций до неузнаваемости.

Но что нам это дает в контексте обсуждения интерпретации vs компиляция?

То, что питон производит транспиляцию своего кода. Причем, при любом режиме выполнения, даже при построчной интерпретации.

python - транспилятор? :) Или нет? И какое это отношение имеет к интерпретации

В составе CPython есть и транспилятор, и интерпретатор. Они вместе потому, что байткод от одной версии питона нельзя интерпретировать на другом питоне.

Не придется. http://blog.thezerobit.com/2012/07/21/immutable-persistent-data-structures-in...

Это просто набор техник, которые не решают проблему неэффективности.

и до кучи FSet, sycamore, Series, Taps итд

https://github.com/tobgu/pyrsistent

Так-то смысл в этом всем появляется только когда другие библиотеки адаптированы под такой стиль.

Сможешь привести хотя бы один юзкейс, где такое может понадобится? Ну, кроме как запортачить программу

Могу:

static bool a = false;
void func(void)
{
    a = true;
}

у тебя испорченные данные почему-то исправить нельзя (хотя в 99% случаев можно), но смысл не в их исправлении - а в том, чтобы продолжить вычисления дальше, не потеряв предыдущие, чтобы иметь возможность их откорректировать не теряя времени программиста и вычислительных ресурсов

Отладка/интерпретация, как правило, значительно медленее, чем исполнение скомпилированной программы, потому история про экономию времени — очень прохладная. То, что ты описываешь, больше похоже на работу отладчика, когда программист по какой-то точке останова или исключению попадает в интерактивный режим с возможностью читать и писать переменные. И такой отладочный режим есть и в питоне, и даже в C# и прочих CLR-based, где можно не только менять переменные, но даже функции в работающей программе без перезагрузки. Впрочем, безопасность таких действий под вопросом и в питоне, и в CLR, и я сомневаюсь, что лисп дает в этом плане какие-то гарантии корректности.

IDLE сохраняет какую-то там консольку (историю команд?) - а я тебе говорю о сохранении образа

И TCP-соединения оно тоже сохраняет? И содержимое диска на исходной машине? И пиксели на дисплее?

Смотри, обычно лисперы на тему репла говорят «вам не понять», я же нарушил это негласное правило тайного лисперского сообщества - попробовал объяснить, по сути совершил акт отступничества

Лисперам точно так же не понять, что все их фишки уже давно повторены. Осталось лишь одно укрытие для элитарности — «повторено не так».

Да, потому что Clojure — это такой язык скриптования встроенной базы данных для жавы. Отсюда и такие средние зряплаты. Как лисп оно совсем никому не интересно

Кложа интересна именно как лисп и ничего более

А по факту при приеме на работу по Clojure первым вопросом стоит знание Java. И CL никого не колышет.

Мне, и много кому еще

Вот тебе может и да. Прими денчика на работу.

Языков «скриптования» до нее было много - scala, groovy, jruby, juthon. Но они действительно не популярны и маргинез

Давай разберем сказанное по частям:

 — Scala. Вполне себе активно применяется в коммерческом программировании;  — Groovy. Да, сдох;  — JRuby, Jython. Это, прежде всего, интерпретаторы ненужных implementation-defined языков. При всем моем неуважении к лиспу — этот язык все-таки проделал большой путь и имеет стандарты.

Меня больше всего удивляет то, что находятся фанаты ClojureScript, которое в мире JS вообще ни к селу ни к городу

Расскажи почему, очень интересно

потому в мире JS нет спроса на многопоточную логику, а в остальном CS — это достаточно тонкая и ненужная надстройка над базовым языком.

Шта?

Тебя смущает то, что многоверсионные данные не нужны в JS, или то, что CS в роли прослойки бесполезно? Многие JS либы сделаны на обычных ассоциативных массивах, и в итоге ты получаешь всё ту же императивщину, но к ней в довесок два языка в проекте и бесконечные вызовы между этими двумя языками. А вопрос на stackoverflow про «что полезного в Clojure можно сделать на макросах» так и остался неотвеченным.

Если бы это был какой-нить ML (привет F#),

Привет, Scala

Скала там тоже на первых позициях по средней ЗП.

то без скобочек это было бы менее и более востребовано. Но, как грица, дареному коню в зубы не смотрят.

Дареных коней было много - они не взлетели в отличии от лиспа over jvm

По-твоему диалектов лиспа было мало? Они точно так же не взлетели. Просто этот сделан более-менее грамотно. Индустрия, конечно тупая, но совсем уже очевидные сравнения может провести.

Лисперам точно так же не понять, что все их фишки уже давно повторены. Осталось лишь одно укрытие для элитарности — «повторено не так».

Я понял почему не взлетел лисп. У меня свершилось озарение. Просто луч божий сошел на меня и все встало на свои места: лисп не взлетел из-за всезнающих балаболов вроде вот этого вот, которые говорят много, но понимают мало. Лисп не взлетел НЕ из-за (немного) завышенного порога в сравнении с другими языками которые тогда появлялись. Не из-за скобок. Не из-за зимы, которая просто все ускорила. Не из-за того что он появился не в то время. Нет. Нет. Нет. Его падение было неизбежно. И оно было неизбежно, знаете из-за чего? Из-за самоуверенности блаб-программистов, у которых в блабе (или блабах) все есть и им всего хватает, а если нету сегодня - то завтра так точно будет. Из-за вот этой вот самоуверенности. Заметьте: я не называю их неосиляторами. Они скорее всего могли понять лисп, если бы захотели. Но тем не менее, именно из-за этих людей, которые делали все что бы защитить свое мировоззрение: навязывали его другим, делали новый блаб, писали статьи в бложиках где обсирали gc, закапывали старый блаб, экстраполировали всевозможноые кривые из одно точки, создавали бесконечные грабли для свое текущего любимого блаба, говнокодили свои никчемные проекты, и всем чем угодно они занимались, но только не потратили неделю на изучение лиспа. А потом самоуверенно шли и как ни в чем не бывало орали «лисп ненужне» «я на <блаб-name> всьо напесал, оно роботает! посоны закапываем лисп коккоок ко пок пок!». Я не сильно виню всех этих людей, возможно у них не было недели, или им было трудно принять в осознание всю реальную ущербность их бытия, или же им может попросту нассали в уши другие такие же балаболы. Но тем не менее, и тем не менее же, я ссу всем этим людям в рот. Лично. Они заслужили. Мы ссым всем эти людям в рот. И все лисп сообщество. Да и не нужны вы нам. Продолжайте жрать кактус, именно его вы и достойны.

Отец Аристоклий.

Ну прям как в старые добрые времена… Хотя ослабление, конечно, налицо,

Ага, ослабление ему «налицо», ссу я тебе на лицо! Ты почему в стороне стоишь и наблюдаешь? Тебе совсем нечего сказать? Вот лично из-за тебя тоже лисп и не взлетел!

всем чем угодно они занимались, но только не потратили неделю на изучение лиспа

Ты не поверишь, но я потратил пару дней на Clojure, читал доки, писал хело ворлды. Вывел для себя «интересный язык, надо как-нибудь слабать на нем проектик, заодно посмотреть как оно работает». Но вот так индустрия работает, что на бэке нужен PHP и Python — никто не хочет видеть твой лисп, даже с Clojure не особенно охотно связываются, а только под соусом жавы.

Вот посмотри на http://news.ycombinator.com. Это типичный такой проект на лиспе, написанный в одно рыло — еще более убогий по фичам, чем LOR, который, если я не ошибаюсь, тоже писан в одно рыло. С таким же успехом такой сайт можно было написать в одиночку и на питоне, и на PHP. С большой разницей: на Java/PHP/Python можно было бы найти кодера, который бы за еду доработал тебе сайт до какого-то более менее адекватного состояния. Потому что вести обсуждение на news.ycombinator.com крайне неудобно, в результате чего обсуждений там почти нет, а есть только одиночные ответы от случайных мимопроходящих людей. Поиска тоже можно считать нет. Отбор сообщений по тематике? А вот напиши в начале сообщения в квадратных скобочках волшебное слово — и твое сообщение попадет в один из пяти гвоздями прибитых разделов в шапке. То есть, такое ощущение, будто сайт писал школьник за неделю, и получил за эту работу ящик пива.

Я убил лисп, что ли? У меня даже компа не было, когда он уже умер. Он весьма быстро перешел из разряда «еще не нужен» в «уже не нужен». Я в эти годы читал книги по MS DOS и бейсику, и программировал на бумажке. Васик, который еще более убог, чем питон — и тот был востребован. Ты думаешь, что я работаю с питоном, потому что это такой замечательный язык? Нет, просто он нынче есть в каждом чайнике, а если я смогу при помощи магии сделать из говна конфетку, то убью сразу двух зайцев: потешу свое ЧСВ, и пропишу железобетонное доказательство способностей архитектора в резюме.

«Object code is a portion of machine code that has not yet been linked into a complete program»

«In computing, object code or object module is the product of a compiler.[1] In a general sense object code is a sequence of statements or instructions in a computer language,[2] usually a machine code language (i.e., binary) or an intermediate language such as register transfer language (RTL)».

Что тут непонятно? gcc RTL посмотри на что похоже вообще.

В питоне результат трансляции сохраняется на диск для ускорения последующей трансляции — это каким-то образом внезапно стало компиляцией?

А какой это был вид трансляции? Правильно, это компиляция и была.

Я тебе даже больше скажу: питон никак не защищен от атаки со стороны генерированного байткода.

Какое это имеет отношение к обсуждаемой теме?

То есть, еще раз: байткод является внутренним представлением отпарсенных сорцов. Его нельзя перенести даже между минорными версиями интерпретатора.

Если это так, это чисто проблемы питона, джавовские бинари вполне себе переносятся - но у тебя и джава интерпретатор.

Почему интерпретатор не должен транслировать целиком весь исходник-команду?

По определению.

Чем недостаточно самого AST, зачем нужен байткод?

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

Но ведь интерпретатору для построчного выполнения или пооператорного ничего никуда сохранять не надо.

В случае питона восстанавливается исходник с частью комментариев.

В полном виде зачастую не восстанавливается, но мы это уже обсуждали в предыдущих сериях.

Потому байткод находится на том же уровне абстракций, что и текстовый исходник, просто имеет не человекочитаемую, а машиночитаемую форму.

Даже не знаю, что на это ответить... вот серьезно, ты каждый раз выходишь на какой-то новый шизофренический уровень утверждений. «тот же уровень абстракции, но не человекочитаемый».

2) Соответственно, не проводится предварительный анализ кода модуля на корректность

Под питон подходит.

Вообще-то перед запуском модуль проверяется на синтаксические ошибки. Хотя до места некорректной инструкции (в самом конце модуля) может происходит много вычислений, вполне себе корректных, но они даже не будут запускаться до полной проверки модуля на синтаксическую корректность. Уже только это говорит о том, что cpython не интерпретатор. А, как и говорилось ранее, примитивненький компилятор в байткод без оптимизаций.

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

Ну, то есть ничего не тормозит по факту, правильно я тебя понял?

Да, потому что оно писано не на питоне.

Приложение PyQt написано на питоне, как биндинге к С++ gui-фреймворку Qt. Я могу писать графическое приложение на PyQt и ни разу за годы не увидеть кода С++, кроме как в примерах соответствующей доки. Харе бредить.

Питон здесь — это запускалка-конфигурялка.

В той же степени то любой другой язык в случае биндинга. Что сводит твое утверждение к абсурду.

То есть, при создании гуя на PyQt роль *.ui файлов примерно такая же, как у питона. Большую же часть работы выполняет Qt

Конечно Qt, это же памят^W биндинг! При этом С++ я в глаза не вижу, когда рисую формочки.

, и кто его знает, сколько в нем багов.

Понял, «власти скрывают».

А PyQt - это именно что python и ничего более

Прям ничего-ничего?

Именно так.

А не пробовал смотреть, сколько левых бинарников подключает твое приложение? Это тоже всё питон?

Нисколько, есть разные варианты деплоя - можно и в один бинарник все упаковать.

Приведи примеры других низкоуровневых представлений - кроме машкода

Питон->Си.

Т.е. в С это компилятор, а в байткод нет.

Полученный код кроссплатформенный, но превращение необратимо

С его вдруг необратимо?

и часть возможностей питона (вроде exec/eval и разной рефлексии) теряется. Еще превращение высокоуровневых ЯП в какой-нибудь IR LLVM, поскольку типы данных и инструкции намного проще исходных

В байткоде тоже инструкции проще.

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

Это всего лишь вопрос оптимизаций.

Но что нам это дает в контексте обсуждения интерпретации vs компиляция?

То, что питон производит транспиляцию своего кода.

Т.е. ничего нам не дает твое утверждение, понятно.

Это просто набор техник, которые не решают проблему неэффективности.

Я уже понял, что у тебя проблемы с чтением.

и до кучи FSet, sycamore, Series, Taps итд

https://github.com/tobgu/pyrsistent

Тормозит же, в чем сами авторы признаются. И вообще стараются подсунуть С-версию везде, где возможно.

Так-то смысл в этом всем появляется только когда другие библиотеки адаптированы под такой стиль.

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

Сможешь привести хотя бы один юзкейс, где такое может понадобится? Ну, кроме как запортачить программу

Могу:

<и привел опять иррелевантный код>

На счет репла я сдался, похоже тебе не дано понять (по крайней мере на текущий момент), приходи позже.

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

Не к спору.
Можно.

Sorry /1С на форуме не в почете/.

1С к примеру это псевдо дерево, которое связано в целое ссылками и в run-time и на диске оно таким и является.
Просто в ram используются указатели, а на диске смещения.

Владимир 123

Я убил лисп, что ли? У меня даже компа не было, когда он уже умер. Он весьма быстро перешел из разряда «еще не нужен» в «уже не нужен».

Ситаксис Lisp в какой-то мере похож на тэговое представление /например xml. html/.
В результате он легко парсится, … Обратная сторона медали в том, что тэговое текстовое представление readable лишь для маленьких и простых текстов.

Пока необходимости в использовании Lisp нет, потому что те удобства, которые он предоставляет можно достичь даже на Си /конечно лишь через специально разработанное API/.

PS: НЕ НУЖНО хоронить языки программирования.

Владимир 123

Я понял почему не взлетел лисп.

Присоединяюсь к данной группе анонимов! Хоть и сходил в туалет. но готов верующих пацанчиков поддержать.

Особенно доставляют ответы товарища - любой пыхер доделает, Куд-кудах! Ррааз - и готово! Рыночек порешал! И любимое - Haskel (ЯП не PHP/Python, огрызки неучей в JS) - НЕ НУЖЕН, Ко-ко-Кудах!