О расширении LISP функционала при помощи .NET и ARX

[Андрей Бушман]

Если функционал, трудно реализуемый (или вообще не доступный) в LISP, будет представлен в виде LISP-функций, написанных на .NET или ARX, тем самым делая их зависимыми от версии AutoCAD, то станете ли вы использовать их в своём коде?

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

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

P.S. Я понимаю, что на форуме пользователей - всего полтора человека и в виду этого результат опроса может выглядеть несколько искажённо, но возможно, что со временем их наберётся человек 5-10 и все они проголосуют, в свете чего результаты опроса станут ближе к жизни.

Спасибо.

[Андрей Бушман]

2 Администраторам:
Я нажал на кнопку "редактировать голосование", поставил запятую в тексте вопроса (в графе, куда записывается вопрос):

Если функционал, трудно реализуемый (или вообще не доступный) в LISP, будет представлен в виде LISP-функций, написанных на .NET или ARX, тем самым делая их зависимыми от версии AutoCAD, то станете ли вы использовать их в своём коде?

Однако после этого текст вопроса исчез. И теперь не удаётся ничего туда записать.

P.S. Кроме того, хотелось бы видеть, кто за что голосовал, ибо одно дело, когда проголосовал А.Н. Ривилис, а другое, когда Вася Пупкин.

[Александр Ривилис]

Однако после этого текст вопроса исчез. И теперь не удаётся ничего туда записать.

Видимо слишком длинный вопрос. И движок форма его отбраковал.

P.S. Кроме того, хотелось бы видеть, кто за что голосовал, ибо одно дело, когда проголосовал А.Н. Ривилис, а другое, когда Вася Пупкин.

Этого в движке форума нет. И кроме того возможно не все захотят открыто заявлять своё мнение.
Что касается моего мнения, то оно не показательное. Правильным моим ответом на вопросы в такой формулировке было бы написать "Никогда не буду использовать такие функции", т.к. я практически никогда не пользуюсь чужими ARX/.NET функциями, кроме родных из состава AutoCAD и ARXDBG/MGDDBG, но они не в счет. Просто если мне нужна функция - я её пишу сам на ARX или .NET. Но ты задал вопрос в разделе AutoLisp/VisualLisp, т.е. вопрос относится к тем, кто в основном пишет на lisp, и написать самому её на ARX/.NET ему будет проблематично.

[Андрей Бушман]

Этого в движке форума нет.

Жаль

И кроме того возможно не все захотят открыто заявлять своё мнение.

Это было бы очень странно.

Что касается моего мнения, то оно не показательное.

Я для примера привёл. Понятное дело, что нет людей, знающих всё и ежели речь, к примеру, зайдёт о подшивках, то "котировка акций" резко изменится.

ты задал вопрос в разделе AutoLisp/VisualLisp, т.е. вопрос относится к тем, кто в основном пишет на lisp

Именно к ним.

вопрос относится к тем, кто в основном пишет на lisp, и написать самому её на ARX/.NET ему будет проблематично.

Поэтому и создан этот опрос. Я же не спрашиваю о том, будут ли они сами что-то писать на .NET, но спросил, будут ли они пользоваться такими решениями в случае их наличия.

[Андрей Бушман]

Шутки шутками, но как видим, про полтора человека я всё-таки не ошибся...

[Дмитрий Загорулькин]

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

[Александр Ривилис]

Отчасти я согласен. Но с другой стороны в интернете нет (или почти нет) хороших примеров исходников по работе с SheetSet на .NET (С# или VB.NET)
Так что то что сделает Андрей (в случае открытых исходников) может быть полезно далеко не только пишущим на lisp.

[Андрей Бушман]

в случае открытых исходников

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

[Владимир Северюхин]

1) Использовать расширения библиотеками .net - да так и делаю (это было сделано для ключей защиты, где на лиспе сделать было не возможно), правда это требует опр. навыков. Нужны исходники нужно перекомпилировать под разные версии и т.д. В тех случаях где сложно но можно обойтись лиспом, стараюсь им обходится, расширял раньше диалоги при помощи .net, но теперь использую Open DCL, т.е. тоже раширение библиотеками, но сделанными проф. программистами и не требующими от меня никаких знаний Си и т.д. Проект правда полностью опен-сорс, всвязи с чем постоянно находится на грани жизни и смерти.
2) В будущем где всем правит web-сервис технологии постараюсь расширять сверх-умный функционал, на Common lisp, т.е. выносить часть вычислений на сервер, это снимает много проблем и с монетизацией и с защитой, но и создает. Так что приоритет развития скромного проекта имеено на использования lisp, а не на войну с тонкостями .net, которые для неискушенного являются достаточно большой проблемой.

[ElpanovEvgeniy]

Проголосовал за "Буду использовать их (по мере необходимости) наравне с "родными" LISP функциями"...

[Дима_]

Я не голосовал т.к. трудно подобрать ответ из предложенных. Ради облегчения, "жизнепроцесса", когда это было возможным частенько "мешал мух с котлетами" - ибо так получаеться продуктивней всего, но если понимаю, что количество .Net'а переходит определенный порог - то тогда и мешать смысла нет. В последнее время, я сразу проговариваю заказчику, что есть два варианта можно на лиспе (тогда ....), а можно и не на лиспе (и тогда...) - выбирайте сами. У меня, лентяя, руки не доходят доделать хотя-бы до "бетки" расширение автолиспа для загрузки .Net сборок и работы с ними через REPL (хотя фактически я уже несколько раз его использовал в "сыром виде"). Не хочеться выкладывать в том убогом виде, как оно есть сейчас - сейчас это близкий аналог того как реализованн COM - есть функции для вызова методов и получения свойств + придуман метод взаимодействия лисп кода с событиями (кривой как моя жизнь, но "косяков" пока не выявленно) с "имитацией" замыканий функций обработчиков. Хочеться довести его до нормального вида. То есть дописать парсер который выражения типа

Код: [Выделить]

(MessageBox*Show "Привет медвед") - автоматически переводил в

Код: [Выделить]

(net-sm "MessageBox" "Show" "Привет медвед") - звездочку вместо точки использую т.к. в лиспе она зарезервированна под пару - но т.к. синтаксис на другие вещи (события в частности) "гораздо веселей" то и для перевода элементарного

Код: [Выделить]

(f*Resize '(net-sp tb*Size f*ClientSize) в

Код: [Выделить]

(net-event f "Resize" nil '(net-sp *tb "Size" (net-gp *f "ClientSize"))) - который на данном этапе рабочий - надо лезть в семантику,смотреть что сейчас "выполняеться", какие имена "замыкать" (то что на выходе помеченно звездочкой ) и куча чего еще - лень непобедимая, да еще и упирающиеся в косяки особенности автолиспа.
з.ы. если кому интересно поучаствовать в допиливании сего инструмента - с удовольствием поделюсь\посоветуюсь - а то честно говоря забросил уже давно, а сил и мотивации (не коммерческой, а в принципе) для "доделки" просто не хватает.
  Ушел от основного вопроса - сама идея наделать "основных нашлепок" под автолисп мне кажется утопична, да и не правильна по сути своей - какая сборка (класс) понадобится завтра предсказать невозможно, а если смотреть только на т.н. основные инструменты - без изысков - то они и так есть в штатном исполнении автолиспа.