[lisp] [work] [real] lisp'еры из последнего опроса - отзовитесь

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

> ну т.е. сферо-CL лучше сферо-схемы. Спасибо, кэп )

почему сферо-? вполне конкретный ANSI CL и вполне конкретная RnRS схема (думаю R6RS подразумевалась)

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

не буду, ECL не видел, а перенести Racket-овые батарейки на любую реализацию R6RS насколько легко?

ох ма, что-же это такое... Я _согласен_, что в _стандарте_ CL «батареек» больше, чем в любом стандарте схемы. Только пишут программы не на стандартах, а на реализациях (там где реализаций больше одной, причём разной степени «реализованности» этого самого стандарта). Да, есть либы с поддержкой нескольких реализаций - но мы же не про них (и не при их использование)? Мы про «батарейки» «искаропки». Так вот это - характеристика конкретной реализации, а не сферо-стандарта. Ну и как пример - реализация с наименьшим соответствием стандарту (может пальма первенства у ABCL - не знаю) CL и уже почти «не схема» с вагоном батареек.

засим прошу ветку считать закрытой, ибо тем, кто не понял, я помочь не могу. Хотя указания на ошибки принимаются :)

> Только пишут программы не на стандартах

Мы про «батарейки» «искаропки».

Ну не знаю. Из всего кода, что написан у меня на CL, прибит к SBCL (а пользуюсь я практически только им) только демон для restas. А всё остальное основано либо на стандарте, либо на «либах с поддержкой нескольких реализаций».

> Только пишут программы не на стандартах, а на реализациях

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

>Из всего кода, что написан у меня на CL, прибит к SBCL (а пользуюсь я практически только им) только демон для restas.

«Прибит к SBCL» - это одно.

А всё остальное основано либо на стандарте, либо на «либах с поддержкой нескольких реализаций».

Про библиотеки - не будем. А вот «основано ... на стандарте» - есть уверенность, что заработает на всех известных реализациях CL? Нет, и правильно - хз как они там все стандарт поддерживают (я уж молчу про всякие «зависит от реализации» в самом стандарте), пока не попробуешь - уверенности нет.

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

что мы и так имеем в мире CL - тот-же ffi, в результате появляются всякие костылики типа cffi/uffi

стоит нам захотеть использовать какую-то другую реализацию, как сразу облом. ну и какой толк тогда от этих «батареек»?

они есть и их можно использовать. И я не представляю себе, как можно было те-же «батарейки» в racket написать «для всех», если они явно выходят за пределы стандарта схемы и завязаны на «внутренности»? Да и к чему это было создателям?

> есть уверенность, что заработает на всех известных реализациях CL?

У меня тут недавно случилась ситуация, был в отпуске и под рукой была машина с виндой. Я уже много лет за виндой не сидел, но тут выбирать не приходилось. Мне нужно было запустить один мой софт (который я разрабатывал исключительно под SBCL), который зависел от нескольких моих библиотек и в частности от cl-libxml2. Больше всего меня беспокоила именно cl-libxml2, ибо она зависит от libxml2 и я никогда (!) ранее даже не пробовал запускать её не на linux. Я взял Clozure CL (который то и под linux запускаю раз в полгода), запихнул libxml2.dll (и ещё пару нужных dll) в systems32 и попробовал запустить свой софт. К моему глубокому изумлению он взял и заработал, сразу.

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

> в результате появляются всякие костылики типа cffi/uffi

В чём заключается костыльность CFFI?

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

Не спорю - классно! (пачка плюсов в копилку sbcl, ccl, CL в целом и конечно в твою собственную) Но ты же не дашь гарантию на все реализации CL? :)

>В чём заключается костыльность CFFI?

1. в необходимости собственного существования

2. ты мне скажи - CFFI на 100% «повторяет» всю функциональность ffi sbcl-а?

3. я не сказал, что это плохо - специально применил уменьшительную форму.

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

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

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

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

Пример чего? Ну архимаг взял и запустил нечто, написанное под одну реализацию, под другой реализацией. Но вопрос - ЗАЧЕМ это нужно?

>Но вопрос - ЗАЧЕМ это нужно?

Ну иногда бывает эта возможность «очень кстати»: у разных реализаций CL разные особенности, среди которых и поддерживаемые операционки - у кого-то их больше, у кого-то меньше. Попасть на какую-то «экзотику» (я не про пример архимага :), обнаружить там CL и запустить собственную прогу, которую писал не под этой реализацией и не под этой ОС - это очень не плохо. Это как максимум. Как минимум у тебя может просто не оказаться прав или возможностей поставить «здесь и сейчас» то, что нужно - приходится пользоваться тем что есть. (чёрт, граммарнаци - в последнем предложении запятая нужна перед обоими «что» или не нужна напрочь? мая нерусская...)

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

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

> Ну то есть надо просто брать реализацию, которая работает везде, где надо, и все.

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

> Попасть на какую-то «экзотику» (я не про пример архимага :), обнаружить там CL и запустить собственную прогу, которую писал не под этой реализацией и не под этой ОС - это очень не плохо. Это как максимум. Как минимум у тебя может просто не оказаться прав или возможностей поставить «здесь и сейчас» то, что нужно - приходится пользоваться тем что есть.

сомнительные какие-то возможности.

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

Хотя iolib — скорее всего исключение из правил, так как используются системные вызовы/АПИ напрямую. Но, опять же поддерживать все популярные реализации — пупок развяжется.

> Если писать что-то сложнее веба, придется лезть в потроха

_конкретной_ реализации и использовать их на всю катушку.

Для чего?

вопрос - ЗАЧЕМ это нужно?

Владимир Владимирович

НОРМАЛИЗОВАННАЯ ГАЙКА

1.  Подходи, рабочий!
Обсудим, дай-ка,
что это за вещь такая гайка?

2.  Что гайка?
Ерунда! Малость!

3.  А попробуй-ка
езжай, ежели сломалась.
Без этой вещи,
без гайки той —
ни взад, ни вперед.
Становись и стой!

4.  Наконец отыскали гайку эту...

5.  Прилаживают...
Никакой возможности нету!..

6.  Эта мала,
та велика, —
словом,
не приладишь ее никак.

7.  И пошли пешком,
как гуляки праздные.
Отчего?
Оттого, что гайки разные.


8.  А если гайки одинаковые ввесть,
сломалась —
новая сейчас же есть.

9.  И нечего долго разыскивать тут:
бери любую —
хоть эту, хоть ту!

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

11.  Если это
поймет
рабочего разум, —
к Коммуне
на паровозах
ринемся разом.

[1920, июль]
	

Роста № 172

> Для чего?

In short:

Если писать что-то сложнее веба

Например, пишу я распределенную систему для управления и мониторинга каких-нибудь ресурсов. Система использует треды, сокеты, интерфeйс с железом через FFI. На этапе прототипирования, лезть в потроха возможно не понадобится. Когда дойдет время для теста и профайлинга на реальной системе, придется лезть в профайлер и подкручивать гайки в конкретной реализации, например параметры GC и MP для более эффективной работы.

Все кроссплатформенные библиотеки сглаживающие разницу в различных ЦЛ, не имеют ручек (и никогда не будут иметь) для fine-tuning'а.

> Например, пишу я распределенную систему для управления

и мониторинга каких-нибудь ресурсов.

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

Вы что, действительно используете CL для систем, которые нужно писать на С?

Когда дойдет время для теста и профайлинга на реальной системе,

придется лезть в профайлер и подкручивать гайки в конкретной

реализации, например параметры GC и MP для более эффективной работы.

Может просто добавить пару серверов к распределённой то системе?

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

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

Говоря о вебе, имелся в виду только «веб интерфейс», например один из фронтендов, как GUI или CLI. А не то что, за ним. Бэкенд может быть сколь угодно сложным. И этот бэкенд придется тюнить под конкретную реализацию.

Вы что, действительно используете CL для систем, которые нужно писать на С?

С какой стати? Чья это идея? Я сам себе хозяин.

Может просто добавить пару серверов к распределённой то системе?

Не всегда это подходит.

> И этот бэкенд придется тюнить под конкретную реализацию.

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

Не всегда это подходит.

В случае с localhost, конечно, затруднительно.

Под FFI SBCL имеется ввиду SB-ALIEN? Так это нахрен не надо, вообще то есть. CFFI основывается на более низкоуровневом интерфейсе, то есть на SB-SYS, и аналогах в других реализациях. И является, соответственно, более низкоуровневой штукой. В то же время, CFFI мощнее SB-ALIEN, потому что последнее жестко фиксировано, а cffi - расширяемо. Это никакой не «костыль», это просто нормальное расширяемое FFI, которого нет даже в самом SBCL. В CFFI нет аналога sb-sys::alien-lambda, но это вообще очень спорная фича, в том плане что пока в SBCL не допилят чтобы она не сжирала static-space, ее использовать некомильфо.

lovesan

> В случае с localhost, конечно, затруднительно.

Вам виднее.

>Под FFI SBCL имеется ввиду SB-ALIEN? Так это нахрен не надо, вообще то есть. CFFI основывается на более низкоуровневом интерфейсе, то есть на SB-SYS, и аналогах в других реализациях.

Хорошо, что здесь за мат могут забанить - единственное что сдерживает. Скажу проще - ты в своём уме? SB-ALIEN не нужен? «CFFI основывается на более низкоуровневом интерфейсе, то есть на SB-SYS»?

Ты заставил меня скачать CFFI и глянуть. И что я вижу? Да, я вижу SB-SYS - «адресная арифметика» и pinned-objects. Тыпы? вызовы? «калбэки»? Всё это «нахрен не надо»? Это я к тому, что всё это из SB-ALIEN. Да ты болен!

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

>Ну то есть надо просто брать реализацию, которая работает везде, где надо, и все.

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

>Поэтому кросплатформенно никогда не получится.

У меня уже условный рефлекс выработался, на грани нервного тика: как только за словами начинает маячить ∀ - сразу руки зудят дать не то канделябром по голове, не то шашкой по тупой и наглой харе 8Е

>Тыпы? вызовы? «калбэки»? Всё это «нахрен не надо»? Это я к тому, что всё это из SB-ALIEN.

Не используются там типы SB-ALIEN, там своя система трансляторов над sb-sys, (за исключением вызовов функций, да, но в них используются только примитивы, и весь этот функционал по идее должен быть в sb-sys). Мой Virgil, например, это такого же рода же обертка, но над примитивами CFFI.

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

Для нормальной реализации FFI, типа CFFI, от реализации CL нужен самый минимум - аналоги sap-ref-*, то есть аксессоры для примитивов, и вызовы функций и коллбеки с примитивами.

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

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

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

это не Россия - это СНГ.
К примеру из Украины чаще всего попадаются вменяемые заказчики из России, тут еще хуже все.

Использую на работе для model based testing. Свой универсальный для этой цели фреймворк (на cl). Более детально не могу рассказать)) Много работал до этого с джавой - Cl мне больше нравится как инструмент.

даже отрасль в общих чертах?

enterprise, субд

и в опросе я не участвовал)

zZ> когда делали genera ос, использовали свой GUI фреймворк, с интересным подходом, для создания компонентов, потом когда lisp рынок рухнул, на это тоже забили.Думал как-то поискать, и все-таки написать простенький тулкит.

antares0> Будешь писать CLIM кинь мысли на lisper.ru. Я тоже по близкой к работе надобности этим занимаюсь, можеть быть две головы будет лучше

Если нравится McCLIM, можно допилить DUIM (OpenDylan Interface Manager) — DUIM это порт McCLIM на Dylan (Win32 native, и GTK в разработке), а CL-DUIM — бекпорт с Dylan обратно на Common Lisp

http://cl-duim.blogspot.com/

http://3.bp.blogspot.com/_2N_ytL74ba0/Sew91JlkoiI/AAAAAAAAAAM/8hYME9IMabY/s32...

см DUIM и cl-duim http://cl-duim.blogspot.com/

http://3.bp.blogspot.com/_2N_ytL74ba0/Sew91JlkoiI/AAAAAAAAAAM/8hYME9IMabY/s16...

> можно допилить DUIM (OpenDylan Interface Manager) — DUIM это порт McCLIM на Dylan

Судя по library reference этого DUIM в процессе портирования потерялись output record-ы, Incremental Redisplay, Вся машинерия на основе presentation: спец-методы, типы, трасляторы и.т.д и прочие фенечки. Или это порт ну очень доисторической версии McCLIM. В обоих случаях, есть ли смысл с этим возится?

CL-DUIM — бекпорт с Dylan обратно на Common Lisp

А исходники этого где брать?