> Тут просто аудитория немного другая, не похапешная.

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

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

У нас уже есть к примеру GCC, занимающийся этим. Реализовывать часть его функциональности в любой из IDE это ошибка, кроющаяся внутри здравого смысла.

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

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

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

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

на готовых продуктах, собственного авторства?

Нет, не затруднит, вот скрин моего рабочего текущего проекта: http://archimag-dev.blogspot.com/2009/11/made-with-common-lisp.html

Ну и может ещё и http://lisper.ru/ сойдёт для демонстрации?

> Нет, не затруднит, вот скрин моего рабочего текущего проекта

угу - XUL, JS, SVG и (невероятно) лисп с гордой ролью расчета по «очень сложному алгоритму» для расстановки бутылок :))))))

Ну и может ещё и http://lisper.ru/ сойдёт для демонстрации?

«похапешная» аудитория очень долго бы смеялась увидев это поделие

это вообще п%ц:

http://lisper.ru/planet/

> угу - XUL, JS, SVG и (невероятно) лисп с гордой ролью расчета по

«очень сложному алгоритму» для расстановки бутылок :))))))

Самая дешёвая коммерческая система на эту тему стоит от 100 000$, какой-то алгоритм есть только в одной, за которую просили несколько миллионов американских денег.

«похапешная» аудитория очень долго бы смеялась увидев это поделие

это вообще п%ц:

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

> Самая дешёвая коммерческая система на эту тему стоит от 100 000$, какой-то алгоритм есть только в одной, за которую просили несколько миллионов американских денег.

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

Для «продемонстрировать практическую применимость лиспа» не годится? Хотелось бы узнать почему...

потому-что без лиспа это делается гораздо быстрее и гораздо лучше

> и тем не менее этим примером вы показали, что лисп неюзабелен и вам

пришлось использовать другие инструменты, оставив на долю любимого

лиспа лишь расчеты

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

потому-что без лиспа это делается гораздо быстрее и гораздо лучше

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

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

Хорошая IDE должна понимать семантику того языка, для которого предназначена, поэтому должна еще и семантический анализ делать.

У нас уже есть к примеру GCC, занимающийся этим. Реализовывать часть его функциональности в любой из IDE это ошибка, кроющаяся внутри здравого смысла.

GCC видит только translation units после препроцессинга для определенной конфигурации проекта. А IDE должна со всеми файлами проекта одновременно работать, желательно еще и c разными конфигурациями. А из GCC даже вытащить front-end для C++ в отдельном виде пока нормально не могут.

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

В Eclipse JDT инкрементальный Java компилятор как раз встроен в IDE. Самый правильный подход.

> Гы... Напрягите фантазию, представьте какая поддержка на стороне сервера необходима для того, что бы это работало

может на лиспе это и сложно, а на том же С++ - это примитив

Какие либо основания под вашими словами вообще есть?

http://lisper.ru/planet/

не осилили сделать листание по страницам?

> может на лиспе это и сложно, а на том же С++ - это примитив

Да при чём тут сложность? Вся серверная сторона реализована на Common Lisp, при чём, без Apache, ngigx и т.п., чистый Common Lisp. Там решаются различные проблемы, что-то сложнее, что-то проще. Это, как мне кажется, и соответствует «продемонстрировать практическую применимость лиспа».

И да, на каком-то этапе там действительно был C++. Я (да и не только я) как бы считаю себя достаточно неплохим специалистом по C++ (не претендую на величие, но в boost-e, как и в работах Александреску для меня загадок не осталось) и я гордился тем кодом. Но знаете, в итоге код на Common Lisp намного, намного проще, и размер его совсем не тот.

не осилили сделать листание по страницам?

Я как бы следую известным образцам, где листание по страницам не принято. Основной способ чтения данной ленты - через RSS-риадер.

> Вся серверная сторона реализована на Common Lisp, при чём, без Apache, ngigx и т.п., чистый Common Lisp. Там решаются различные проблемы, что-то сложнее, что-то проще

можно список «различных проблем», а то слишком размытое определение

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

о_О

> можно список «различных проблем», а то слишком размытое определение

XML REST сервис, сервис для работы с фотографиями товаров, генерация PDF с планограммами (в различных вариациях), там отчёты разные, это как бы не совсем маленькое приложение, что именно вы хотите понять?

о_О

Посмотрите, например, http://planet.gnome.org/ или http://planet.mozilla.org/. Вы вообще где-нибудь кроме ЛОР бываете?

Yi.

Если сомневаешься в нужности elisp'а, то вот тебе Yi — текстовый редактор на Haskell.

>что именно вы хотите понять?

Вы вообще где-нибудь кроме ЛОР бываете?

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

> XML REST сервис, сервис для работы с фотографиями товаров, генерация PDF с планограммами (в различных вариациях), там отчёты разные, это как бы не совсем маленькое приложение, что именно вы хотите понять?

просто в общих чертах хотел разобраться, для чего вы используете лисп( то что вы показывали - было XUL + JS без всяких отчетов, PDF и т.п. )

Посмотрите, например, http://planet.gnome.org/ или http://planet.mozilla.org/. Вы вообще где-нибудь кроме ЛОР бываете?

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

> и про емакс

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

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

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

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

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

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

Если бы тебе лисп был интересен, ты бы и так знал, кто что из местной аудитории делает.

>А из GCC даже вытащить front-end для C++ в отдельном виде пока нормально не могут.

Из GCC не могут вытащить даже бэкенд. И очень жаль, тогда на свалку отправились бы не нужные костыли типа LLVM.

archimag, спрашиваю здесь, ибо в гугловском блогспоте комментарии ни в Опере, ни в вебките не заработали.

Хотелось бы увидеть небольшой пример по RESTAS вроде недавнего Hello World, но с аплоадом файлов. Я писал небольшой сайтик (2 страницы, интерфейс к простой БД) на Scheme, но уже столкнулся с нехваткой документации.

Кстати, API plt-scheme'овского веб-сервера подозрительно напоминает RESTAS. :)

naryl, напиши на lisper.ru, но, вообще, это к restas особого отношения не имеет, ибо он работает поверх hunchentoot, соответственно, надо смотреть доку на hunchentoot.

Кстати, API plt-scheme'овского веб-сервера

подозрительно напоминает RESTAS. :)

Х.з. с plt-scheme не работал, тамошний веб-сервер не смотрел.

Прошу прощения за копипаст. Лень выдумывать новые слова для тех же мыслей.

http://lisper.ru/forum/thread/73

И пара замечаний по сайту:
1. При попытке залогиниться с неподтверждённым аккаунтом ничего не происходит. Лучше было бы показать сообщение об ошибке.
2. При добавлении комментария не помешал бы предпросмотр.

> И пара замечаний по сайту:

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

> Если бы тебе лисп был интересен, ты бы и так знал, кто что из местной аудитории делает.

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

П.С. приношу извинения archimag за резкий тон( хоть и уверен, что они ему не нужны ), после общения с Love5an и пр. не ожидал, что мне покажут серьезные разработки на лисп, а также стал необъективен, я был не прав

lester, Love5an - это отдельная тема. Всё, что он может сказать это «Лисп - круто, ибо скобочки». Не все лисперы такие. :)

http://love5an.livejournal.com/tag/ldx

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

Оно не тормозит. Тормозит, если кто читать не умеет, загрузка и компиляция, потому как макросы жирные.

я тебя лично спрашивал - ты сказал, что твоя работа не подлежит разглашению,

Что-то я такого не припоминаю ;)

> Тормозит, если кто читать не умеет, загрузка

значит тормозит.

Такая жирная штука, как Direct3D вообще-то и сама не особо быстро подгружается

Тормозит, если кто читать не умеет, загрузка

значит тормозит.

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

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

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

А что из этого не умеет gcc? После фронтэнда конкретного языка там же всё одинаковое? И PGO тоже есть.

про PGO я что-то пропустил, надо поиграться...

но вот генерация llvm байт-кода для своего DSL - это на gcc не сделать без долгих разборок с ним, а на llvm достаточно просто...

но вот генерация llvm байт-кода для своего DSL - это на gcc не сделать без долгих разборок с ним, а на llvm достаточно просто...

Вроде как после внедрения GIMPLE в gcc всё тоже просто.

надо посмотреть, я что-то отстал от gcc ;-)

>LLVM как раз таки очень перспективен

В middle-end у GCC > 4 находится примерно то же самое... Но вот заюзать GIMPLE и при этом не быть gcc-хакером крайне сложно, в отличие от того же LLVM.

Не слушай местных велосипедистов, учи Python+PyQT. Потом не придется страдать фигней из-за нехватки либ или упрямства мейнтейнеров Emacs.

>решения задачи я сначала написал для Emacs парсер и генератор SOAP.

И насколько они хуже доступных в Python? Сколько времени можно было бы сэкономить, воспользовавшись стандартными?

Пока весьма простые, достаточные для решения основной задачи (хотя данные о рейсах с Аэрофлота я получил без проблем). Emacs мне помогает отпарсить XML-сообщения и сформировать запросы в XML (require 'xml).

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

И насколько они хуже доступных в Python? Сколько времени можно было бы сэкономить, воспользовавшись стандартными?

В питоне есть что-то, работающее с Аэрофлотом o_O

>И насколько они хуже доступных в Python?

Хуже. Потому что я сначала решал конкретную задачу. Поэтому сериализатор/десериализатор написал пока для базовых типов. Иерархические тоже работают. Апачевский Map в хеш-таблицу десериализуется, массивы работают (либо в список, либо в массив отдаются), в принципе. Но этого мало, конечно.

Сколько времени можно было бы сэкономить, воспользовавшись стандартными?

А сколько времени я сэкономлю с Python для реализации интерфейса? А сколько времени я сэкономлю для реализации просмотра mbox, раскодирования почтовых сообщений, формирование ответов с цитированием, отправка этих этих сообщений? А вот если письмо с прикрепленным патчем? Я уж не знаю, сколько мне всего придется в Python делать, но в Emacs у меня все под рукой. Сейчас интерфейсная часть debian-bts-ui.el (внимание!) всего 256 строк. Как, по-твоему, я сэкономил время?

>Но этого мало, конечно.

Мало для общего случая применения, но для большого количества сервисов уже достаточно, так как с типами они не загоняются. Григорианские gYear и прочие такие всякие мало, кто пользует. А если сложный и неизвестный тип, то после парсинга мне мой парсер просто возвратит примерно такой списочек (element-a (element-b . «строчка) (element-c (float-a . 12345.43) (float-b . 2323.0) (integer-a . 34342) (name-b . „dfsdf“) (ur-array . [2232 „dfs“ 4534.45])). Имея описание сервиса, я это все могу нормально поиспользовать.

сделали бы как в VIM'е - возможность писать руби-код прямо в .el :D вот жизнь бы была.

А там разве нет возможности получить mbox сразу, не пользуясь SOAP?

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

Батарейки - есть. Интерфейс над ними пришлось бы писать самому. Или писать Python плагин к почтовику. Я так понимаю, для работы с почтой используется GNUS из Emacs?

>Батарейки - есть. Интерфейс над ними пришлось бы писать самому. Или писать Python плагин к почтовику. Я так понимаю, для работы с почтой используется GNUS из Emacs?

А я ранее написал, что для просмотра логов пока используется RMAIL. Это такой древний, простой почтовик, идущий с Emacs. Реликт. Нет, Gnus не используется. По задумке для отправки будет использоваться тот почтовик, который у пользователя. Но вот не в каждый внешний почтовик я, наверное, смогу вставить цитирование извне и прописать References в заголовок. У меня gnus, потому у меня письмо отправляется gnus'ом.

А вот для просмотра почтовых логов не RMAIL'ом уже проведены кое-какие эксперименты с библиотекой Emacs MIME (это батарейки в комплекте), которая умеет кучу разных RFC. (mm-desect-buffer t) — и у нас дерево, описывающее все части письма. Хоп, а там уже и буфера, хранящие разбитое письмо: вот тут у нас само письмо, вот тут у нас аттачмент, тут второй аттачмент, тут подпись. Все очищено от Content-Transfer-Encoding, перекодировано с учетом Content-Type. Красота. И с mailcap разговаривать умеет. И html рендерит (можно выбирать, чем). С этим всем позже возиться буду.

>А там разве нет возможности получить mbox сразу, не пользуясь SOAP?

Так я так пока и получаю лог, скачивая maintainer mbox с определенного адреса. SOAP я использую для получения списка багов по шаблону и запросу по каждому из них расширенной статусной информации. Логи там тоже есть через SOAP, которые по сути повторяют mbox, т. е. header, body и массив attachmants, который вообще пуст у них — я даже в исходник BTS залез, чтобы проверить, что это не у меня глюки. В финале хотелось бы все получать через SOAP, а скачку mbox оставить на случай, если у них что-нибудь навернется. Как альтернативу, тэкскэть.