Каким образом парадигма языка влияет на возможность подмены рантайма? И не забываем про смолтолк.

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

Конечно, можно и на Си BDSM терпеть с ручным закатом солнца, но зачем?

А я если что-то говорю, то обычно проверяю.

А не было мысли, что проверять можно неправильно? Или недосконально, или знание матчасти не позволяет применить некоторые методы?

> А не было мысли, что проверять можно неправильно?

У меня постоянно такие мысли, поэтому я смотрю самые разные варианты.

Конечно, можно и на Си BDSM терпеть с ручным закатом солнца, но зачем?

Было высказано две мысли.

1. На питоне нельзя свободно менять рантайм.

2. Так как это безумно нужная вещь, то питонисты бы обязательно ее сделали, позволяй такое питон.

Результат:

1. Посредством дюже черезжопных усилий это возможно.

2. Так как это не нужно, то никто и не напрягается.

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

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

> Посредством дюже черезжопных усилий это возможно.

Результат будет дюже жопный

Так как это не нужно, то никто и не напрягается.

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

Боже упаси, размахивать флагом призывая использовать питон

для лисподобной разработки

На самом деле я не уловил в чём заключается разница между подходами к разработке в Python и CL, при том, что языки достаточно близкие ведь.

Простые в плане реализации в коде самой замены, но не использования.

> Хотелось бы знать, как соотносятся между собой Smalltalk и Lisp, в чем они схожи, в чем разница между ними.

В Smalltalk отсутствуют макры. Плюс одна из ведущих (если не ведущая) реализаций Smalltalk - VisualWorks Smalltalk от cincom до сих пор (в 2010-ом году !!!) имеет проблемы с юникодом на не Windows платформах.

А так, как по мне, стиль разработки и там и там очень похож. Только вот в smalltalk IDE на порядки удобнее.

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

Только вот в smalltalk IDE на порядки удобнее.

Удобней чем SLIME? Хотелось бы услышать за счёт чего.

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

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

Минуса тут нет. Сплошные плюсы.

Во-вторых, хотелось бы почитать, почему некоторые вещи объективно не должны быть в текстовом редакторе. Тетрис можно не упоминать.

> Удобней чем SLIME? Хотелось бы услышать за счёт чего.

Графический отладчик, workspace (аналог SLIME REPL) сохраняется в image, так что их можно для одного image держать хоть десяток. Для меня Code Browser со встроенным рефакторингом, встроенный Version Control с хранилищем в PostgreSQL, UI Builder, централизованное хранилище для внешних пакетов - похоже на asdf-install только удобнее и интегрированно с VC. Один image работает на _всех_ поддерживаемых платформах - меняется только исполняемый файл VM.

> Графический отладчик

Хм, а в SLIME он какой?

workspace (аналог SLIME REPL)

А зачем их надо много? Задумался... Впрочем, ведь в Smalltalk контекст вычислений это ведь отдельный объект? Так что наверное это имеет весьма определённый смысл для Smalltalk, но вряд ли для CL.

Code Browser

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

рефакторингом

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

встроенный Version Control с хранилищем в PostgreSQL

Я думаю, что это стоит всячески скрывать и не вводить человека в курс дела до тех пор, пока он не будет «готов» :)) Прогрессивное человечество как бы выбирает git (ну или Mercurial). Надеюсь от этой «фичи» можно отказаться?

UI Builder

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

централизованное хранилище для внешних пакетов -

похоже на asdf-install

Только не надо сравнивать с asdf-install, ибо это г... всегда плохо пахло и никогда толком не работало. Только я не понял какое это имеет отношение к IDE?

Один image работает на _всех_ поддерживаемых платформах

Опять, речь не об IDE. Но надеюсь JIT то там есть? А то ведь будет тормозить. SBCL то компилит сразу в машинный код, поэтому и переносить нельзя, но зато и JIT не нужен.


Т.е. по большей части речь идёт о том, что разница между IDE в CL и Smalltalk обусловленна в первую очередь языковыми, а также какими-то культурными отличиями.

Поскольку вряд ли можно говорить о возможности полноценной разработки что на CL, что на Smalltalk без хорошей IDE, то когда вы говорите, что

Только вот в smalltalk IDE на порядки удобнее.

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

> А реальные преимущества перед Java, C++, Python есть?

1. Интерактивная разработка
2. CLOS
3. Макросистема
4. Система условий и рестартов
5. Динамические переменные
6. И т.д.

1. С этим не поспоришь 2. Это костыль, а не преимущество 3. Если в рантайме не нужно код генерить (как правило - не нужно) то у Java, например, есть аналогичное - JET 4. WTF? 5. Ну и чем они так уж хороши эти динамические переменные? 6. Не аргумент

P.S. мну лисп нравится, но совать его в продакшен я не готов (в частности я пишу UI - круче Eclipse для этого пока ничего не видел).

> Это костыль, а не преимущество

Чего? Очевидно вы что-то путаете.

у Java, например, есть аналогичное - JET

Нет, если я правильно понял что такое JET, то это совсем не аналогичное. В java не может быть ничего аналогичного, ибо java не на символьных вычислениях основана.

4. WTF?

http://lisper.ru/articles/restarts

5. Ну и чем они так уж хороши эти динамические переменные?

http://lisper.ru/articles/cl-vars

6. Не аргумент

Согласен.

> Очевидно вы что-то путаете.

Common Lisp Object System: в лиспе нет классов и пакетов. А в Jave - это свойства языка. В этом смысле CLOS - это костыль эмулирующий классы, наследование и т.д.

ибо java не на символьных вычислениях основана.

При чём здесь символьные вычисления? Речь идёт о технологии написания и использования генераторов кода. Технологии замкнутой на тот же язык, код на котором и генерируется (JET = Java Emitter Templates).

4. restarts

Как я понял - это что-то типа механизма обработки исключений, не?

5.

Главное различие — область видимости. Лексическая переменная видна только в теле той формы, в которой она была объявлена (в теле функции в случае defun, в теле let в случае let, и т.д.). Динамическая переменная, даже если она была создана локально с помощью let, видна во всех вызываемых функциях пока действительно связывание с помощью let:

...

Интересным является то, что связывания динамических переменных, созданные с помощью let (а так же с другими формами, осуществляющими связывание, например with-open-file или defun и lambda, создающие связывания для своих аргументов) влияют на все вложенные вызовы функций (если они, конечно, не сами не связывают те же переменные). После выхода из let восстанавливается предыдущее связывание, если оно было.

Всё это тоже костыли областей видимости и весьма сомнительные. Зачем нам какие-то связывания, если можно по-честному передавать значения в функции в качестве параметров, конструировать экземпляр класс и в конструктор передать параметр, а внутри класса использовать в разных функциях? Хочется Замыканий? - Есть анонимные классы с заданным интерфейсом.

Не холивара ради, а понимания для.

Не холивара ради, а понимания для.

Ты недалекое ламо, начни с PCL. Вопросы будешь потом задавать.

Только не надо сравнивать с asdf-install, ибо это г... всегда плохо пахло и никогда толком не работало.

ЕМНИП quicklisp - попытка сделать asdf-install правильно и с версиями. Я понимаю, бета, но всё-же. Вчера ловил странные глюки. Через пол часа попыток отладки, смутно представляя проблему, сделал:

rm -rf ~/quicklisp; emerge hunchentoot rucksack cl-who

Помогло. Пока своего работающего менеджера пакетов у CL нет. Даже у D был более-менее удобный, пока автор его не забросил.

Кстати, могу я рассчитывать на добавление rucksack в archimag-lisp? :)

С JET не знаком, спорить не буду. А в остальном вы заблуждаетесь настолько, что проще действительно отправить rtfm'ить. PCL, например, если есть время и желание разобраться.

> Common Lisp Object System: в лиспе нет классов и пакетов.

Вы чего вообще? Кто вам такое сказал?

А в Jave - это свойства языка.

В Common Lisp тоже, угу.

В этом смысле CLOS - это костыль эмулирующий классы,

наследование и т.д.

Нет, CLOS это возможно наиболее мощная из существующих объектных систем (сравнение с Smalltalk, пожалуй, опустим). А костыли, при чём какие, это паттерны типа «визитор», которыми приходится пользоваться в Java.

При чём здесь символьные вычисления?

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

технологии написания и использования генераторов кода. Технологии

замкнутой на тот же язык, код на котором и генерируется

Макросистема в CL основана на лежащих в основе языка возможностях символьных вычислений и именно благодаря этому обладает такой силой.

Как я понял - это что-то типа механизма обработки исключений, не?

Механизм обработки исключений в традиционных языках это довольно сильно урезанный вариант системы «условий и рестартов».

Всё это тоже костыли областей видимости и весьма сомнительные.

Есть такая вещь как глобальные переменные. Раньше ими пользовались довольно широко, поскольку они часто очень удобны. Но с ними связан целый ряд очень серьзёных проблем, которые привели к порицанию подобной практики. Так вот, динамические переменные обладают всеми преимуществами глобальных переменных (в традиционных языках), но при этом лишены их недостатков.

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

значения в функции в качестве параметров,

Хочется Замыканий? - Есть анонимные классы с заданным интерфейсом.

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

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

Только вот здесь я сразу вижу в каком пакете клас, что это (контейнер/исключение/модель/описание интерфейса), какие методы предков перекрыты, какие перекрываются в потомках. Тут же проверка на ошибки типа селектор не определён и кучу остальных. Плюс указание на то что определённые селекторы _переопределяют_ селекторы из других класов - например будет чётко видно что данный пакет расширяет каким-либо образом поведение базовых контейнеров.

> Я думаю, что это стоит всячески скрывать и не вводить человека в курс дела до тех пор, пока он не будет «готов» :))

Это ещё с каких веников ?

Прогрессивное человечество как бы выбирает git (ну или Mercurial). Надеюсь от этой «фичи» можно отказаться?

Можно. Но это «через гланды» - местная VC достаточно наворочена и прекрасно встроена в кучу мест в IDE.

> Но надеюсь JIT то там есть? А то ведь будет тормозить.

JIT есть и засчёт PIC'а очень быстрый.

Не спорь. Переносимость образов - это однозначный вин. :)

> Только вот здесь я сразу вижу в каком пакете класc

Я понял, только такое имеет мало смысла для CL. CLOS устроен по другому. В его основе лежат не классы, а методы, это очень существенный сдвиг парадигмы.

Это ещё с каких веников ?

Но это «через гланды» - местная VC достаточно наворочена и

прекрасно встроена в кучу мест в IDE.

Я ничего не хочу сказать про «местную VC», пусть она будет самой распрекрасной, как и не хочу сказать, что git является лучшей. Дело ведь в другом. Речь о системе контроля версий как о неком социальном явлении. git безусловно упрощает распространение кода и взаимодействие с другими людьми. Я могу использовать github и это действительно здорово. А невозможность (или большие сложности) пользоваться git и github это очень, очень печально.

Не спорь. Переносимость образов - это однозначный вин. :)

Я не спорю, просто хотел уточнить на счёт JIT.

> Кстати, могу я рассчитывать на добавление rucksack в archimag-lisp? :)

Ну ты нашёл где спрашивать ) Вообще надо пост на эту тему написать.

> В его основе лежат не классы, а методы, это очень существенный сдвиг парадигмы.

Это я знаю. Но вот возможность быстро находить всякие :before, :after или более узкие специализации, думаю, никому не помешала бы.

> Речь о системе контроля версий как о неком социальном явлении. git безусловно упрощает распространение кода и взаимодействие с другими людьми.

Что касается VisualWorks Smalltalk, то все более менее приличные открытые проекты или расширения централизовано хостятся в Cincom Public Repository (более 6000 пакетов), к которому я подключиться в два клика мышью, просмотреть что есть, какие версии, историю коммитов и т.д. и т.п. Плюс всё это дёргается прямо из рабочего образа и я вполне могу выполнить в workspace или из кода:

"Find all the packages that define the method #yourself. Note this can be slow on a large database." 
session read: StorePackage where: [:each |
	each methods anySatisfy: [:eachMethod | 
		eachMethod definition name = 'yourself']].

"Find all the packages that define the class Object. Note this can be slow on a large database." 
session read: StorePackage where: [:each |
	each classDefinitions anySatisfy: [:eachClass | 
		eachClass definition name = 'Object']].

Плюс, VC жопой может смотреть и в PostgreSQL, и в Oracle, и в DB2. Да хоть в MSSQL.

> Но вот возможность быстро находить всякие :before, :after или

более узкие специализации, думаю, никому не помешала бы

А она есть, когда просишь открыть определение метода он показывает все имеющиеся специализации.

все более менее приличные открытые проекты или расширения

централизовано хостятся в Cincom Public Repository

(более 6000 пакетов)

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

Плюс, VC жопой может смотреть и в PostgreSQL, и в Oracle, и в DB2.

Да хоть в MSSQL.

Лучше бы ей смотреть на файловую систему.

Написал на github'е.

Тот ecls можно закрывать. Он уже в основном дереве есть, slowpoke. :P

> Получается что социальная проблема вдруг перенесена на уровень языка.

Не языка а среды. Smalltalk изначально создавался как «образ системы», и вне image не живёт - см. тот же Squeak (всякие GNU smalltalk не считаем). А внутри своей экосистемы вс прекрасно - нафига мне заморачиваться с файлами ? Я пишу код, а как он хранится - проблемы IDE. Надо будет - экспортну проект в текстовые файлы, только вопрос - нафига ? Для smalltalk'a само понятие IDE как-то криво звучит - это экосистема, которая не мешает мне запустить внутри одного образа хоть десяток приложений.

> Лучше бы ей смотреть на файловую систему.

На кой ?

> Для smalltalk'a само понятие IDE как-то криво звучит

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

На кой ?

Что бы не таскать с собой Oracle на флэшке.

> Что бы не таскать с собой Oracle на флэшке.

Таскай image. Если с сырцами - это три файла - бинарный образ, сырцы базового образа (~15Mb, необязательны, но крайне полезны), сырцы твоих изменений. Фаршированный по самое «немогу» образ для разработки с сырцами занимает ~100Mb. Базовый - 23Mb. Нужно будет VC - всегда можно подключиться к удалённому серверу.

> В java не может быть ничего аналогичного, ибо java не на символьных вычислениях основана.

да и не нужно это в ней абсолютно. под JVM есть Clojure, отличный лисп

linux

http://prisheynet.ru/ хороший вариант

>В java не может быть ничего аналогичного, ибо java не на символьных вычислениях основана.

Хватить тут разводить FUD и невежество.

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

http://en.wikipedia.org/wiki/Symbolic_computation

> Символьными вычислениями называется, и всегда называлась,

только одна вещь

Угу, мы это здесь уже обсуждали. Ну тупи. Как предлагаешь перевести на русский название книги «COMMON LISP: A Gentle Introduction to Symbolic Computation»? - про математические формулы там вообще ничего нет. В литературе по Common Lisp термин «символьные вычисления» используется достаточно часто в контексте операций над «symbolic expression», а не над формулами. Как вообще должны по твоему называть вычисления над «symbolic expression»?

Что будет, если вот так (я этот код не запускал, но смысл должен быть ясен).

/tmp$ cat module.py
def innerFunc():
    return "I am module.innerFunc"

def func():
    return innerFunc()

/tmp$ cat app.py
from module import func

def innerFunc():
    return "I am innerFunc of app"

def main():
    print func()

>>> import app
>>> app.main()
I am module.innerFunc
>>> from module import func
>>> def new_func():
...     return innerFunc()
...     
... 
>>> func.func_code = new_func.func_code
>>> app.main()
????? 
>>>

Чего-то он у меня переполняет стек во время компиляции совершенно безобидной функции из named-readtables. Пока что предполагаю, что дело в clocc, нужно локализовывать более точно. В lispworks 4.4.6 всё то же самое работало совершенно без проблем.

JS вроде по скорости сливает лиспу на порядок, или я отстал от жизни? Тормознутость языка накладывает принципиальные и неустранимые ограничения на приложения, которые имеет смысл писать на языке, в отличие от всего остального. Кроме того, JS - «безопасный» (с урезанными правами) язык для конкретного применения. Чтобы писать на нём вещи общего назначения, к нему нужно ещё что-то прикручивать, не?

В общем, сделал баг репорт.

>> Зато в CL мегакрутые макросы. После лиспа сишные дефайны кажутся унылым говном

Сложно найти что-то, по сравнению с чем сишные дефаны не кажутся >унылым говном.

Ну, возьмём другие очень популярные языки:
Java - никакого препроцессора вообще
Python - никакого препроцессора вообще
Хватит или ещё назвать?

>>> Зато в CL мегакрутые макросы. После лиспа сишные дефайны кажутся унылым говном

Сложно найти что-то, по сравнению с чем сишные дефаны не кажутся унылым говном.

Ну, возьмём другие очень популярные языки:

Java - никакого препроцессора вообще

Python - никакого препроцессора вообще

Хватит или ещё назвать?

Конечно хватит. Здесь Вы делаете неявное предположение, что лучше с препроцессором, чем без. Я с этим не согласен. Фича, что делает язык хуже - говно. Лучше без нее. Дефайны в C это ужас, т.к. они работают на уровне сырого текста. Какой-то умник напишет в библиотеке

#define out 1

и потом разбирайся, почему у тебя в коде есть logout(reason), а компилятор тебе ругается на отсутствие функции log1.

> #define out 1

и потом разбирайся, почему у тебя в коде есть logout(reason), а компилятор тебе ругается на отсутствие функции log1.

Ну вот на так cpp обижать не надо :)

(500) darkman@sl500:~/tmp> gcc 1.c
(501) darkman@sl500:~/tmp> ./a.out
aaa
(502) darkman@sl500:~/tmp> cat 1.c 
#include <stdio.h>

#define pr 1

int main ()
{
        printf ("aaa\n");
        return 0;
}

> Здесь Вы делаете неявное предположение, что лучше с препроцессором,

чем без

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

Во-вторых, и это нужно освещать отдельно, макросистема Common Lisp не имеет никакого отношение к препроцессору. В этой связи, сравнивать макросы в C с макросами в CL вообще нельзя - они имеют лишь очень поверхностное сходство, в основном в слове «макросы».

Я с этим не согласен. Фича, что делает язык хуже - говно. Лучше без

нее. Дефайны в C это ужас, т.к. они работают на уровне сырого текста.

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

> Python - никакого препроцессора вообще

Python сам себе препроцессор. Что подтверждает его позиция в RPython в этом качестве.

ну и звиздец http://www.lispworks.com/images/lw-ide-windows.png они хоть бы посмотрели как в студии сплит делается, ну или на худой конец в емаксе

Ой! Я посмотрел на скриншот и вспомнил шестой вижуал бейсик, которым баловался классе в пятом. Даже не знаю от чего именно такая ассоциация возникла...

>Здесь Вы делаете неявное предположение, что лучше с препроцессором, >чем без. Я с этим не согласен. Фича, что делает язык хуже - говно. >Лучше без нее. Дефайны в C это ужас, т.к. они работают на уровне >сырого текста.
Ущербная логика. У Вас есть плохой пример препроцессора (даже, я бы сказал, плохой пример использования препроцессора), и Вы из него заключаете, что препроцессор - это вообще плохо.

и потом разбирайся, почему у тебя в коде есть logout(reason), а компилятор тебе ругается на отсутствие функции log1

Кроме того, конкретно в этой ситуации можно посмотреть на выхлоп cpp (как Вам уже посоветовали).

> В этой связи, сравнивать макросы в C с макросами в CL вообще нельзя - они имеют лишь очень поверхностное сходство, в основном в слове «макросы»

Контрпример.
(defmacro max (x y) `(if ,(> x y) ,x ,y))
- ровно то же самое, что и в С, не считая оформления.
А также
(define-symbol-macro out 1)

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

Нда, и кстати, действительно, это - гон. В этом случае logout(reason) не раскроется.

> Но вот возможность быстро находить всякие :before, :after или более узкие специализации, думаю, никому не помешала бы

Как раз в лиспворксе есть generic function browser или что-то в этом роде. Я, правда, никогда не пользовался (вообще редко пользуюсь CLOS).

Препроцессор C работает с лексемами, а не с символами(character), как уше выше заметили.

> (defmacro max (x y) `(if ,(> x y) ,x ,y))'

Это совсем не то же самое, не считая конечного результата.