Здравствуйте, mishaa, Вы писали:
P>>>Если уж зашел об этом разговор... Какие есть более-менее качественные (минимум — с поддержкой отладки) некоммерческие IDE для Common Lisp? Желательно, чтобы работали под Windows.
P>>>P.S. Из IDE для Scheme — я нашел DrScheme, и он мне понравился. По крайней мере, для обучения он хорош (вроде для этого и предназначен). Под Windows работает (как и под Linux). Какие-то возможности отладки есть. А Project Management я там не нашел .
К>>Если от emacs сильно не тошнит, то глянь сюда К>>Лично мне показалось юзабельным.
M>Ну а если тошнит то вот сюда http://jabberwocky.sourceforge.net/
Здравствуйте, pvgoran, Вы писали:
P>Здравствуйте, pvgoran, Вы писали:
P>>Если уж зашел об этом разговор... Какие есть более-менее качественные (минимум — с поддержкой отладки) некоммерческие IDE для Common Lisp? Желательно, чтобы работали под Windows.
P>Будем считать, что про Emacs+SLIME я ответ уже получил
C>Во-первых, писать программу в виде чистого AST — неудобно.
Посмотри на возможности макроса loop — ну где здесь чистый AST? Как ни странно благодоря макросам лисп оказывается самым сладким языком.
C>Во-вторых, писать нетривиальные преобразования AST — весьма непросто, C>причем тестировать их тоже не легко.
Нетривиальные веши — не просты — это факт
Тестировать, а точнее писать,компилировать,править, шаблоны на С++ IMHO на порядок сложнее.
C>В-третьих, для обычных языков типа Java/C# уже существуют системы для C>редактирования AST. Только называется это Aspect Oriented Programming. А C>для C# у нас еще и R# есть
Не есть — а недавно появилось... Что еше раз потверждает выше сказанную мысль о том что все языки медленно двигаются в сторону Лиспа.
Меня собственно и подвигло на серьезноге изучение Лиспа, так это то что в CLOS кажись заложенно и AOP .
Кстати все навороты на лиспе выглядят как лисп — ни чуть не хуже .
IMHO спорить безполезно. Надо пробовать.
-- Главное про деструктор копирования не забыть --
mishaa wrote:
> C>Во-первых, писать программу в виде чистого AST — неудобно. > Посмотри на возможности макроса loop — ну где здесь чистый AST? Как ни > странно благодоря макросам лисп оказывается самым сладким языком.
Согласен — чуть украшеный AST.
> C>Во-вторых, писать нетривиальные преобразования AST — весьма непросто, > C>причем тестировать их тоже не легко. > Нетривиальные веши — не просты — это факт > Тестировать, а точнее писать,компилировать,править, шаблоны на С++ > IMHO на порядок сложнее.
Но оно правится и тестируется во время компиляции — а это большой плюс.
Еще у шаблонов есть преимущество — они локальны (почти), то есть один
шаблон не оказывает влияния на другие. Так что отлаживать их вполне
нормально.
> C>В-третьих, для обычных языков типа Java/C# уже существуют системы для > C>редактирования AST. Только называется это Aspect Oriented > Programming. А > C>для C# у нас еще и R# есть > Не есть — а недавно появилось...
AspectJ появился в 99 (если не ошибаюсь), до этого были исследования на
эту тему в PARC'е.
> Что еше раз потверждает выше сказанную мысль о том что все языки > медленно двигаются в сторону Лиспа. > Меня собственно и подвигло на серьезноге изучение Лиспа, так это то > что в CLOS кажись заложенно и AOP .
Кстати, после нескольких лет увлечения AOP сейчас интерес к нему
угасает. Оказалось, что применять манипуляции к коду напрямую — не
так-то уж и нужно, а скорее даже вредно — так как обычно это служит для
заплаток ошибок в дизайне.
Поэтому AOP стал использоваться для предоставления сравнительно
высокоуровневых сервисов, "перпендикулярных" самой логике кода:
1. Прозрачное распределенное кэширование объектов http://www.jboss.org/products/jbosscache
2. Транзакции на графах объектов: http://www.jboss.org/products/jbossas
3. Прозрачные политики безопасности и т.п.
> IMHO спорить безполезно. Надо пробовать.
Здравствуйте, mishaa, Вы писали:
К>>Если от emacs сильно не тошнит, то глянь сюда К>>Лично мне показалось юзабельным.
M>Ну а если тошнит то вот сюда http://jabberwocky.sourceforge.net/
Thanks.
P.S. Emacs — скажем так, напрягает, но, похоже, рано или поздно придется приспосабливаться...
Здравствуйте, Mishka, Вы писали:
M>Я со всем согласен, но есть два вопроса:
M>1. Как найти работу программистом на Lisp?
а) Скорее всего, никак — во всяком случае, в нашей стране, если только
очень повезёт. Говорят, серьёзные товарищи на #lisp в основном бабки
зашибают удалённо — но это уж совсем повезти должно.
б) self-employment
M>2. Как получать больше денег программируя на Lisp, чем, например, на C# или VBA?
а) Научившись программировать на Lisp'е, можно стать асом C#/Java/C++/etc.
Программировать на мейнстриме будете с отвращением, но качественно. И смысл разных
design patterns и пр. хрени станет яснее, чем для авторов этих концепций Ещё подход —
использование Лиспа для прототипизирования. Написать программу или некий её
фрагмент на Лиспе (или иногда хотя бы представить ), а затем переписать
на том же шарпе (раз того хочет народ/заказчик/менеджер/хозяин ) зачастую
позволяет получить результат быстрее & качественнее.
Требуется сгенерировать код на C# примерно такого вида:
public class Obj1
{
public Obj1(int prop1, string prop2)
{
_prop1 = prop1;
_prop2 = prop2;
}
private int _prop1;
public int Prop1
{
get { return _prop1; }
}
private string _prop2;
public string Prop2
{
get { return _prop2; }
}
}
F>а) Научившись программировать на Lisp'е, можно стать асом C#/Java/C++/etc.
Конечно можно стать асом, а можно и не стать, лисп тут ни причем, да и вместо Lisp'а сюда можно много что подставить.
F>Программировать на мейнстриме будете с отвращением, но качественно. И смысл разных F>design patterns и пр. хрени станет яснее, чем для авторов этих концепций
Угу солнце наверно тоже всходит и заходит только благодоря лиспу.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, fionbio, Вы писали:
AVK>А можно увидеть на лиспе решение следующей задачи: AVK>Имеем некое текстовое описание модели каких либо объектов. Пусть это будет xml. Например: AVK>
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, AndrewVK, Вы писали:
E>Как мне кажется, первое, что в духе Лиспа нужно будет сделать, так это написать описание на самом Лиспе: E>
Если оставлять условие, то XML распарсить должно не ставить проблем E>А потом окажется, что с помощью defmacro сам objects является кодом по генерации C# кода.
когда кажется — надо креститься
для defmacro нужен код макроса, который будет "развёртку" выполнять, лисп — не система ИИ, которая сама должна догадаться что надо сделать, как в любом ЯП ей надо это указать, просто это "указание" имхо должно быть проще. На работе лисп отсутствует как класс , так что, к сожалению задачку сейчас решать не возьмусь, надеюсь более продвинутые лисперы подмогут
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, eao197, Вы писали:
E>>Здравствуйте, AndrewVK, Вы писали:
E>>Как мне кажется, первое, что в духе Лиспа нужно будет сделать, так это написать описание на самом Лиспе: E>>
К>Если оставлять условие, то XML распарсить должно не ставить проблем E>>А потом окажется, что с помощью defmacro сам objects является кодом по генерации C# кода.
К>когда кажется — надо креститься
Кстати, напрасно прикалываешься. Почитай вот это http://martinfowler.com/articles/languageWorkbench.html
Там как раз говорится про external и internal DSL. Так вот по отношению к Lisp создание external DSL (пример AndrewVK на XML) может быть не нужным и избыточным шагом (если конечно этот XML не используется для интероперопа с другими приложениями).
Так же нормальный internal DSL вполне можно строить и на более популярных языках, скажем на Ruby:
objects do
object do
property do
name "prop1"
type "int"
end
property do
name "prop1"
type "string"
end
end
end
причем do-end можно заменить на фигурные скобки.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Курилка, Вы писали:
К>>Здравствуйте, eao197, Вы писали:
E>>>Здравствуйте, AndrewVK, Вы писали:
E>>>Как мне кажется, первое, что в духе Лиспа нужно будет сделать, так это написать описание на самом Лиспе: E>>>
К>>Если оставлять условие, то XML распарсить должно не ставить проблем E>>>А потом окажется, что с помощью defmacro сам objects является кодом по генерации C# кода.
К>>когда кажется — надо креститься
E>Кстати, напрасно прикалываешься.
См. о чём я ниже
E>Почитай вот это http://martinfowler.com/articles/languageWorkbench.html E>Там как раз говорится про external и internal DSL. Так вот по отношению к Lisp создание external DSL (пример AndrewVK на XML) может быть не нужным и избыточным шагом (если конечно этот XML не используется для интероперопа с другими приложениями). E>Так же нормальный internal DSL вполне можно строить и на более популярных языках, скажем на Ruby:
<skipped>
Вопрос — а DSL ты откуда взял? Т.е. описание его не включается в решение?
К>>>Если оставлять условие, то XML распарсить должно не ставить проблем E>>>>А потом окажется, что с помощью defmacro сам objects является кодом по генерации C# кода.
К>Вопрос — а DSL ты откуда взял? Т.е. описание его не включается в решение?
Ну, будь я Lisp-программистом, то привел бы полное решение. Просто прочитав столько отзывов о Lisp-е я пришел к мнению, что основная фича Lisp-а -- это возможность простого построения DSL для конкретной задачи. Т.е., вместо решения чего-нибудь в лоб (как зачастую делается с помощью гор кода на императивных языках), на Lisp-е делается DSL, в котором решение конкретной задачи записывается всего несколькими строчками.
Собственно в том, что построение конкретного DSL выполняется средствами самого языка, и в результате получается тот же Lisp -- и есть, имхо, главное преимущество над C++. Т.е. в C++ так же можно подобные фокусы делать, но навороты на шаблонах могут быть сильно сложными и, все-таки, ограниченными, а применение внешних инструментов типа Yacc/Lex для создания DSL -- то еще удовольствие. И главное, получается несколько разных языков, тогда как в Lisp-е язык один.
Но только в этой области у Lisp-е есть конкуретны. Тот же Ruby позволяет строить вполне нормальные DSL оставаясь в рамках Ruby-синтаксиса.
Да и такая гибкость Lisp-а, как указывал, кажется, Cyberax, оборачивается его главным недостатком. Лишком легко создать свой DSL, который кроме тебя никому не нравится и в котором другим разработчикам сложно ориентироваться.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Трурль, Вы писали:
Т>Здравствуйте, AndrewVK, Вы писали:
AVK>>Интересует решение именно в духе лиспа. Т>В духе лиспа будет генерировать код лиспе, а не на C#
А если еще и исходное описание на Lisp-е сделать, то вообще ничего генерировать не нужно будет.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Курилка, Вы писали:
К>>Вопрос — а DSL ты откуда взял? Т.е. описание его не включается в решение?
E>Ну, будь я Lisp-программистом, то привел бы полное решение. Просто прочитав столько отзывов о Lisp-е я пришел к мнению, что основная фича Lisp-а -- это возможность простого построения DSL для конкретной задачи. Т.е., вместо решения чего-нибудь в лоб (как зачастую делается с помощью гор кода на императивных языках), на Lisp-е делается DSL, в котором решение конкретной задачи записывается всего несколькими строчками.
E>Собственно в том, что построение конкретного DSL выполняется средствами самого языка, и в результате получается тот же Lisp -- и есть, имхо, главное преимущество над C++. Т.е. в C++ так же можно подобные фокусы делать, но навороты на шаблонах могут быть сильно сложными и, все-таки, ограниченными, а применение внешних инструментов типа Yacc/Lex для создания DSL -- то еще удовольствие. И главное, получается несколько разных языков, тогда как в Lisp-е язык один.
Не могу не согласиться.
E>Но только в этой области у Lisp-е есть конкуретны. Тот же Ruby позволяет строить вполне нормальные DSL оставаясь в рамках Ruby-синтаксиса.
С руби даже не игрался, так что сравнить не могу, к сожалению
Недостаточно компетентен
E>Да и такая гибкость Lisp-а, как указывал, кажется, Cyberax, оборачивается его главным недостатком. Лишком легко создать свой DSL, который кроме тебя никому не нравится и в котором другим разработчикам сложно ориентироваться.
На любом достаточно мощном языке можно сделать нечто (архитектуру, DSl и проч.), что никому не будет нравиться — и что? Язык не есть лекарство от неправильных решений, язык должне разрешать выражать мысли, а не запрещать
Или из-за некоторой корявости MFC мы и C++ будем признавать убогим языком? Отделяй, плиз, мухи от котлет.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Трурль, Вы писали:
Т>>Здравствуйте, AndrewVK, Вы писали:
AVK>>>Интересует решение именно в духе лиспа. Т>>В духе лиспа будет генерировать код лиспе, а не на C#
E>А если еще и исходное описание на Lisp-е сделать, то вообще ничего генерировать не нужно будет.
Здравствуйте, eao197, Вы писали:
E>Как мне кажется, первое, что в духе Лиспа нужно будет сделать, так это написать описание на самом Лиспе:
Я так и знал. Мне не нужно генерить код на Лиспе, мне нужно генерить код на шарпе. Ну, предположим, у меня есть большой проект на дотнете, который никто под лисп переписывать не будет никогда. И для него нужно написать вот такую штуку.
E>А потом окажется, что с помощью defmacro сам objects является кодом по генерации C# кода.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, eao197, Вы писали:
E>>Как мне кажется, первое, что в духе Лиспа нужно будет сделать, так это написать описание на самом Лиспе:
AVK>Я так и знал. Мне не нужно генерить код на Лиспе, мне нужно генерить код на шарпе. Ну, предположим, у меня есть большой проект на дотнете, который никто под лисп переписывать не будет никогда. И для него нужно написать вот такую штуку.
А нельзя разве XSLT преобразовать XML в Lisp-подобный формат, а затем скормить Lisp-овской программе?
E>>А потом окажется, что с помощью defmacro сам objects является кодом по генерации C# кода.
AVK>Вот еще бы не на словах, а в реальном коде.
Андрей, я полностью с тобой согласен. Более того, я здесь выступаю противником Lisp-а и мне самому хотелось бы реальный код увидеть.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
eao197 wrote:
> AVK>Я так и знал. Мне не нужно генерить код на Лиспе, мне нужно > генерить код на шарпе. Ну, предположим, у меня есть большой проект на > дотнете, который никто под лисп переписывать не будет никогда. И для > него нужно написать вот такую штуку. > А нельзя разве XSLT преобразовать XML в Lisp-подобный формат, а затем > скормить Lisp-овской программе?
А может тогда проще — сразу в C# преобразовать XSLем?
.
. 
Ещё подход —
, так что, к сожалению задачку сейчас решать не возьмусь, надеюсь более продвинутые лисперы подмогут 
