На мой взгляд возможность хостинга движка PowerShell в AutoCAD, автоматом отправляет в ведро AutoLISP и Visual LISPТы как всегда не в меру категоричен. ;) А что делать с наработками на AutoLisp/VisualLisp за 25+ лет? Предлагаешь их все переписать или туда же в ведро?
При этом скрипты PowerShell работают в контексте приложения, а не в контексте документа (как это, к сожалению, обстоит у Лиспа от Автодеска)В этом я вижу скорее минус, чем плюс, так как это:
Скрипты PowerShell можно подписывать цифровой подписью.Лисп-приложения тоже можно подписывать цифровой подписью: https://knowledge.autodesk.com/search-result/caas/CloudHelp/cloudhelp/2016/ENU/AutoCAD-Customization/files/GUID-A63E8C40-6870-4874-BF7E-FD75E87268AA-htm.html
А что делать с наработками на AutoLisp/VisualLisp за 25+ лет? Предлагаешь их все переписать или туда же в ведро?Под "отправкой в ведро":) я подразумевал не "вырезать вовсе, как аппендицит", но подразумевал то, что возможности PowerShell полностью перекрывают существующие возможности AutoLisp/Visual Lisp, в виду чего дальнейшие наработки можно создавать на PowerShell вместо Lisp, т.е. переходить с Lisp на PowerShell. Понятное дело, что движок лиспа удалять не стоит (дабы можно было использовать наработанные годами Лиспы). Автодеск не развивает Лисп. Майкрософт постоянно развивает PowerShell.
Кстати, внутрь AutoCAD уже пытались всунуть и не один скриптовый язык. Это был и Python и еще ряд ...Shell. Вроде как не прижилось.Я не пытаюсь изобратеть велосипед. Вместо этого я всего лишь использую в AutoCAD то, что создано Майкрософтом и предлагается программистам для использования. Движок PowerShell разработан так, чтобы его можно было максимально просто использовать в любом Windows-приложении. Имеются успешные примеры его использования (например, тот же NuGet). Код внедрения движка занимает несколько строк, так что существенных затрат для этого не требуется.
В этом я вижу скорее минус, чем плюс, так как это:При желании можно использовать PowerShell и в контексте документа. А в необходимости блокировки документа я не вижу ничего страшного.
1) Требует блокировки документов для их модификации
2) Делает проблематичным (если не невозможным) синхронный запуск команд AutoCAD/сторонних приложений.
PowerShell - язык администрирования Windows, так что зная его, в Windows можно делать почти всё что угодно, не прибегая к помощи компилятора.Примерно в той-же мере, что и автолисп позволяет делать с автокадом - а если нужны "изыски" то можно программировать на чем-то посерьезней. Насчет, что автолисп в ведро - ихмо он еще вполне переживет PowerShell, как пережил VB, у того тоже возможностей было поболее. У автолиспа есть фишка - это "лисп основа" и ее не имеет смысла сравнивать с умением вызывать API. На автолиспе можно как начать писать через 10 минут, так и в "ясном виде" описать сложнейший алгоритм - с его сочетанием простоты и выразительности мало кто до сих пор может соревноваться.
Примерно в той-же мере, что и автолисп позволяет делать с автокадомВ той, да не в той. Например, насколько я помню, из акадовского лиспа невозможно работать с подшивками. Добраться к подшивкам, например, можно через AutoCAD .NET API, но лисп сам по себе туда [туда - это к AutoCAD .NET API] добраться не может. PowerShell может.
У автолиспа есть фишка - это "лисп основа" и ее не имеет смысла сравнивать с умением вызывать API.Если важен результат, то очень даже имеет, на мой взгляд.
На автолиспе можно как начать писать через 10 минут, так и в "ясном виде" описать сложнейший алгоритм - с его сочетанием простоты и выразительности мало кто до сих пор может соревноваться.Ну, через 10 минут, начав писать на лиспе, сложнейший алгоритм вряд ли можно качественно написать, т.к. необходимы некоторые навыки работы, опыт. Относительно сложные вещи - да, можно. Но это в равной степени относится и к PowerShell. Мне не интересно вести полемику вида "PowerShell vs AutoLISP". Меня интересуют подводные камни, которые могут встретиться в случае использования PowerShell (не важно, вместо лиспа, или же параллельно с лиспом).
с его сочетанием простоты и выразительностиВыразительность лиспа может превратиться в плохо читаемый код.
Я смотрю на PowerShell в том числе (но далеко не в первую очередь) и как на возможную альтернативу для AutoLISP\Visual LISPСобственно я за введение альтернативы LISP. Подход c Lisp очень хорош, если бы не сам язык Lisp.
Добраться к подшивкам, например, можно через AutoCAD .NET APIчерез COM
через COMЧто "через COM"? Я в курсе, что API подшивок реализовано посредством COM и имел в виду то, что с COM API подшивок можно работать из AutoCAD .NET API, в то время как из акадовского лиспа с этим возникнут проблемы. Из скриптов PowerShell можно работать с подшивками как напрямую (через COM), так и через .NET API (которое за кулисами будет дёргать всё тот же COM API).
Собственно я за введение альтернативы LISP.Сегодня займусь оформлением уже имеющегося примера, а так же хочу добавить в него пример того, как PowerShell может исполнять исходный код, написанный на C# (для VB.NET пример делать не буду). Результат выложу на Bitbucket (исходники, откомпилированную версию и описание). Так же напишу демонстрационное видео и закину на youtube. В блоге отпишусь об этом, как только сделаю.
Выразительность лиспа может превратиться в плохо читаемый код.Пробовал и не раз - "Вы просто не умеете их готовить".
Попробуйте описать математическую(физическую) формулу с корнями, дробями и т.д. и от выразительности не останется и следа. Всю выразительность съедят скобки и шифровка логики, когда операция над переменными предшествует переменным (+ a b). И это не естественно для большинства, т.к. со школы учат a + b. В итоге быстро проверить/дополнить формулу не получится.
Пробовал и не раз - "Вы просто не умеете их готовить"."Приготовь" и покажи это юзерам не имеющим твоего опыта программирования. Смогут прочесть и (в идеале) понять его? :) Интереса ради, можно показать им код на др. языках. Вряд ли код на лиспе будет им более понятен.
Собственно я за введение альтернативы LISP.Закинул в блог.
Пробовал и не раз - "Вы просто не умеете их готовить".Так вот о каком выразительном, декларативном языке был намек))))
подготовительные затраты и сам код реализации не может сравниться в трудозатратах с лиспом - даже если мы "зафиксим" подготовительную работу на большинство операций.Если на PS создать некоторую коллекцию общих функций, для последующего их использования (подобно тому, как это уже сделано Автодеском для Лиспа), то размер кода, использующего эти функции, будет сопоставим с аналогичным кодом на лиспе, т.к. используя эти функции можно создавать цепочки вызовов, когда результаты вызова одной функции передаётся в очередную посредством оператора "|" - это так называемый конвейр объектов в PS (при этом получаем отсутствие гигантского количества скобок, коими изобилует Лисп). Ведь и за кулисами лаконичности "стандартных" функций Лиспа стоИт их реализация, которая не факт что всегда будет короче кода PS.
Я не силен в API PS, но с выводом в psOutput там по моему какая-то "борода", я бы поискал асинхронный метод или создал его сам - но это больше придирки.В PS код легко можно запускать код как синхронно, так и асинхронно. Обозначенный мною пример написан так, чтобы максимально походить на .NET-код, дабы программисты, знакомые с .NET API могли без проблем понять его. Не знаю, насколько это у меня получилось.
Прикрутить туда еще кнопок для подстрочника или копирования из VSПомимо движка PS компания Майкрософт так же бесплатно предоставляет и набор готовых контролов, разработанных специально для создания GUI приложений, предназначенных для написания кода PS, его тестирования, отладки (насколько я понял - даже с подсветкой синтаксиса и прочими плюшками, возможно что даже с ИнтеллиСенсом). Но я пока с этим не разбирался, поэтому могу в чём-то и ошибаться.
это так называемый конвейр объектов в PSНу скажем так, в PS он позаимствован, конвейер и композиция функций - это элементы присутствующий во всех без исключения функциональных языках, для частичного замещения лисповских скобок - именно для "проведения" логики "от описания".
Ну скажем так, в PS он позаимствован, конвейер и композиция функций - это элементы присутствующий во всех без исключения функциональных языках, для частичного замещения лисповских скобок - именно для "проведения" логики "от описания"Заимствовано или нет - это не имеет значения. Важен результат. Заимствовать полезные вещи - это правильно. Кроме того, в отличие от большинства других "*Shell", в PowerShell по конвейру передаются полноценные .net-объекты, а не текстовые данные.
Вполне допускаю, что данный функционал реализован и в PSДа, в PS это есть. Можно принудительно указать, что передаваться должен текст, а не объекты (я уже видел такие примеры в книжках). Соответственно, при желании по конвейру (либо по конкретной его части) можно передавать в виде текста исходный код, который должен динамически компилироваться (как это я уже показывал во втором примере скриптов).
Скрипты на Powershell довольно медленно исполняются (ну по крайней мере так было 4 года назад, когда их писал). В сравнении с тем же VBScript.Я не сравнивал скорость и не использую VBScript.
Лично я предпочел написать плагин пакетной обработки, который выполняет задачи, написанные на C# :-)Я никого не заставляю использовать PowerShell - дал лишь информацию к размышлению. Всякий инструмент нужно применять к месту и в меру.
Распространена тенденция не проверять корректность параметров, полученных на входе, а так же результатов, готовых к отправке на выход. Однако это плохо.
Например, в твоём случае db может оказаться null. Вместо какого-то строкового значения одного (или более) из параметров может быть передан null.
На счет db - согласен. Но насколько велика такая вероятность?В новых версиях AutoCAD эта ситуация вполне вероятна, о чём предупреждалось в блогах ADN.
На счет строковых переменных - такая вероятность отсутствует, поскольку перед выполнением функции "движок" проверяет "правильность" параметров. В атрибуте параметра указывается может ли быть пустое значение и соответствует ли введенное значение списку возможных значений. Пока что с этим проблем не было.Выносить за пределы функции проверку параметров, передаваемых в эту функцию - плохой подход. Это нарушает инкапсуляцию, создаёт дополнительные зависимости (вызывающий функцию должен быть информирован о том, как она работает внутри) и порой раздувает код. Кроме того, создаётся предпосылка к тому, что порой проверка будет сделана либо некорректно, либо вовсе забыта.
(вызывающий функцию должен быть информирован о том, как она работает внутри
Поэтому нет смысла в двойной проверке. :)Я нигде не писал о двойной проверке. Инкапсуляция проверок в теле функции как раз устраняет необходимость выполнения таких избыточных проверок (или их некорректного очередного выполнения, или вовсе отсутствия) вне тела функции. Ты полагаешься на то, что те, кто будет использовать твой код, всегда будут "играть по правилам". Дело твоё.
Инкапсуляция проверок в теле функции как раз устраняет необходимость выполнения таких избыточных проверок (или их некорректного очередного выполнения, или вовсе отсутствия) вне тела функции.А если эта функция вызывает другие, которые так-же делают проверки? Я тем не менее не согласен с мнением нескольких именитых авторов, по поводу "тотальной" обработки ошибок. Проверка корректности данных может действительно занимать время большее чем сама функция (либо просто занимать ощутимое время). Да если клас (функция) позиционируется как "публичная", то обработку ошибок следует учесть в результате, даже если это занимает приличное время. Для сохранения производительности, в этом случае можно прибегуть, как пример, к созданию перегрузки метода который обрабатывает сразу последовательность данных - что при условии наличия у них "общих знаменателей", может давать возможность однократной проверки ко всей последовательности (или ее части). Так-же в таких случаях, нередко, хорошо могут помочь ленивые вычисления ну или простое кэширование. Но что функции которые подразумевают обязательную предварительную проверку результата имеют право на жизнь - лично для меня это неоспоримо. Для меня хороший тон обработки ошибок - это не "тотальная" проверка корректности в каждом возможном месте, а как раз наоборот - обработка исключений может быть только при работе с доступом к "внешним" данным - который может внезапно "сломатья". Все остальное должно быть либо проверенно до, либо учтено в выдаче результата и соответственно обработанно (опциональные типы и пр). Так-же для публичной публикации имеет смысл давать две перегрузки класса (функции) которые расчитанны на подготовленные и не проверенные данные - Int32.Parse, Int32.TryParse.
А если эта функция вызывает другие, которые так-же делают проверки?Что для программиста в приоритете (надёжность или скорость) - это уж каждый решает для себя сам. Я за надёжность кода, пусть даже и в ущерб скорости работы. Если твоя функция А принимает параметры, которые она (не используя) просто должна передать при вызове некой функции Б, то нет нужды проверять эти параметры в А, т.к. проверить их - это забота конечной функции - Б. Если же в коде функции А эти параметры так же используются - тогда их следует проверять и в коде функции А. Такой подход, помимо прочего, устраняет зависимость от внешних факторов (т.е. не нужно надеяться на то, что проверку выполнит внешний код, причём выполнит корректно).
Для меня хороший тон обработки ошибок - это не "тотальная" проверка корректности в каждом возможном месте, а как раз наоборот - обработка исключений может быть только при работе с доступом к "внешним" данным - который может внезапно "сломатья". Все остальное должно быть либо проверенно до, либо учтено в выдаче результата и соответственно обработанно (опциональные типы и пр).Б. Стровструп (создатель C++) в "Практике программирования" подробно рассматривает эту тему, приводя наглядные примеры различных вариантов кода, в т.ч. с разными вариантами проверок: вне функции или внутри функции. В конце раздела он задаёт вопрос, мол "так как же в результате лучше всего нам поступать?" и сам же отвечает на этот вопрос: "всегда проверять данные на входе и выходе в коде самой функции". Т.е. он делает выбор в пользу надёжности в ущерб скорости (предварительно сделав на этом акцент, чтобы читатели понимали, что это делается осознанно). Я с ним полностью солидарен в этом.