Чем болеет отрасль САПР
Мама, я очень болен. Мама, нас лечат не те врачи. Те, кто нас заразил этим, — врачуют нам раны. Именно поэтому я неизлечим.
Сергей «Чиж» Чиграков
здесь и далее кадры из «И.В. меняет профессию» мне кажется что моменты и цитаты подобраны по смыслу.
Нет, в данном тексте пойдет речь не про пандемию, и даже не про политику. Скорее про большую отрасль компьютерной жизнедеятельности, а именно про отрасль САПР.
Наверное, такая статья лучше бы зашла от кого-то, кого хабросообщество уже знает. Все-таки такая тема предполагает либо чистый кликбейт, либо аналитику. Кликбейт на хабре не любят, а аналитику… Аналитика о проблемах хорошо заходит только от авторов, которым доверяешь. Но так уж вышло, что пара моих попыток зайти на Хабр, которые я осуществлял с интервалом года в три, не увенчались успехом. Нет уверенности и сегодня, но надо же быть последовательным и наконец выйти из режима read-only.
В общем, не знаю, получится ли зайти, получится аналитика или все же чистый и «голимый» кликбейт, который снова не покинет пределов песочницы. Тут уж Вам решать, уважаемый читатель, а я перейду чуть ближе к сути.
Если мой ник и слово «Сапробасни» Вам ни о чем не говорит, то скажу, что я достаточно давно в отрасли. Настолько, что если бы в начале моей карьеры меня посадили за плохо выполненные проекты, то я бы уже по любому вышел. Это, конечно, не говорит о том, что я обязательно в чем-то хоть как-то разбираюсь, но все же за такой срок быть совсем не в теме сложно.
Как следствие, все написанное ниже — это не более чем мое личное мнение и личный взгляд. Можно даже сказать, персональные тараканы. Некоторые вещи немного гиперболизированы для более ярких впечатлений, но я старался не уходить при этом от реальности. Приятного (надеюсь) чтения. Жду Ваших мыслей, комментариев, дополнений.
Болезнь 0. Терминология. Маркетинг
Ну это не совсем болезнь, и уж тем более не совсем отрасли. Но проблема есть.
Обозначу примером из жизни. Представьте себе такой диалог:
Здравствуйте, мне нужно, чтобы Вы помогли рассчитать мою конструкцию на прочность.
Для этого мне нужна геометрия, свойства материалов, условия нагружения, условия работы…
Вы не поняли, я уже купил программу, мне нужно, чтобы Вы просто помогли.
Программа — это хорошо, но она сама по себе не работает, нужна информация о том, что происходит
Походу, Вы не специалист, мне продавцы другое рассказывали…
Ну так пусть они Вам помогут посчитать!
Так они меня к Вам и послали…
А теперь чуть более развернуто.
Частично проблема всей отрасли идет от того, что мы говорим слово САПР (системы автоматизированного проектирования), а не CAD/CAM/CAE/PDM/PLM (и еще где-то триста сокращений от двух до пяти букв). И как-то так вышло, что раз «Проектирование» по английски «Design», то САПР==CAD (computer aided design). Хотя, по сути, в CAD практически нет проектирования (за исключением некоторых мастеров/визардов для создания типовых объектов типа болтов или шестеренок).
Казалось бы оба Ивана Васильевича, но такие разные. Как и термины
Да, с помощью программ, которые относят к классу CAD, решаются задачи, связанные с проектированием. Но преимущественно только две из них — описание геометрии и оформление чертежей (ну или документации в целом, если смотреть более широко). А это не все задачи проектирования… Отнюдь не все. Да, есть еще часть задач, которые можно частично или полностью решить, анализируя в CAD построенную геометрию: масс-инерционные характеристики найти, проверить собираемость, некоторые вопросы технологичности. Но это скорее следствие наличия 3D геометрии, чем конкретного CAD. Более того, даже в этих вопросах обычно есть проблемы, которые идут от вопросов точности изготовления, от того, что реальные объекты имеют конечную жесткость и много других нюансов, которые не всегда проверишь в CAD. И это несмотря на то, что в других — похожих — случаях все вроде работало.
Остальные вопросы проектирования решаются в других программах, относящихся к классам CAE, CAM, CAPP… к большому списку, как уже говорилось ранее. Казалось бы, об этом факте сказано и написано много где. Но от этого проблема не решена. И даже сами вендоры часто делают подобную ошибку. Приведу как пример «Руководство по цифровой трансформации производственных предприятий» http://Autodesk.ru/digitalguide. На самом деле подобные примеры можно найти практически у всех.
Усугубляется ситуация еще и тем, что и про остальные типы программ класса САПР тоже можно сказать подобное. CAE не оценивают прочность конструкций/изделий и не дают ответов о работоспособности (computer aided engineering). CAM — не решают сами по себе проблем производства (computer aided manufacturing). Все решения принимаются людьми, программы лишь автоматизируют рутинный процесс работы, частично уменьшая ее объем, частично заменяя другими действиями. И хоть многие об этом знают и помнят (применительно к той отрасли, в которой они работают) — знают не все. И даже те, кому известно, насколько от оператора программы зависит итог (например, при работе в CAM)… Насмотревшись, начитавшись и наслушавшись «рекламы», такой специалист приходит к выводу: для решения задач, в которых он не разбирается, достаточно просто купить правильный софт.
Вот и получается, что произошла подмена понятий. Подмена, к которой привыкли. И уже практически никто ее не замечает, но она выгодна по большей части тем, кто продает софт. Ведь когда ты в чем-то недостаточно разбираешься, а тебе предлагают софт, который сам за тебя все сделает… и это звучит со всех сторон… это подкупает.
Но! Проблема в том, что САПР (ни в варианте CAD, ни в варианте CAD/CAM/CAE…) не проектирует, он лишь инструмент в руках человека. И КПД человека с САПР — это произведение «компетенции человека» на «возможности инструмента». При этом в компетенцию входит не только «владение инструментом», но и знание предметной области. Почему написано «возможности инструмента» вместо «возможности САПР»? Наверное, потому, что компетентный человек и без САПРа может многое сделать. И некомпетентный за счет САПРов тоже может что-то сделать. И оно нередко даже будет работать. Но гарантировать это не может никто, и в лицензионных соглашениях ПО обычно на этот случай есть куча оговорок, «отмазывающих» программный продукт и его разработчиков от ответственности (как говорится, читайте текст, набранный мелким и очень мелким шрифтом в конце документа).
инструмент, который позволяет решать разные задачи в зависимости от компетенции оператора
Хотя, может, я не прав?… И на самом деле нет ни проблем с чтением терминологии, ни с заявленной подменой понятий, ни с соответствием ожидания реальности? Напишите свои мысли в комментариях.
Хотелось бы закончить с проблемами терминологии, но надо упомянуть еще пару моментов.
Во первых, объяснить с какого почему я склоняю аббревиатуру, неправильно склоняю слова рядом с термином САПР, а далее по тексту вообще буду писать ахинею в стиле «САПР системы», «программы САПР». Да, САПР — это четкая однозначная аббревиатура (хотя и с ее расшифровкой некоторые умудряются начудить). И по хорошему, с ней надо поступать именно как с аббревиатурой. Но в то же время данный термин уже давно вошел в жизнь тех, кто с ним связан, что из простого «сокращения» превратился по сути в слово. И раз уж можно «задеплоить», «отманажить» и «имхнуть», то почему нельзя и тут поступить соответственно? Я долго спорил на эту тему с разными людьми, особенно старшего поколения. Но потом неожиданно нашел авторитетного союзника в данном споре: Давид Левин, редактор портала isicad.ru. К сожалению оригинальную заметку не нашел, ну да ладно.
Еще одной проблемой является то, что половина индустрии «построена» на хайпах и войне терминов. Стоит кому-то придумать что-то относительно новое, как все остальные тут же начинают доказывать, что:
это никому на самом деле не нужно;
у них есть все тоже самое и уже давно.
И придумывать новые термины/названия к своим «аналогам»/«убийцам конкурентов», причем нередко выполняя все три «телодвижения» одновременно. И это может продолжаться достаточно долго. Что в длительной перспективе хоть и приводит к «устаканиванию» терминов, утилизации «хайпов» и пр., но порядка не добавляет.
да, это не из кинофильма. Но аналог не подобрал. Характеризует отмазки вендоров при копировании чужого
Ну и раз мы заговорили о хайпах и новинках, перейдем к тому что действительно можно считать болезнью
Болезнь 1. Застой и стагнация
На всех конференциях САПР вендоры и причастные к ним рассказывают о новинках, улучшениях, новых подходах, продуктах. Регулярно возникают какие-то модные тренды призванные перевернуть отрасль проектирования. И тем не менее, если смотреть в перспективе на последние 20–30 лет отрасли САПР, то обещанных в свое время революций как-то не заметно.
взгляд в ретроспективе обычно более точен
Впрочем, это проблема не только вендоров, но и того, что многие до сих пор используют САПР, как в юмористических роликах про не очень умных пользователей. Т.е., например, перфоратор используется для забивания чего-то в стену, а тачку — для того, чтобы было удобнее нести сложенные в нее вещи. И ладно, бы если бы это были люди, которые 20–30 лет назад именно так работали, потому что других вариантов не было. Но точно так же нередко работают и те, кто, казалось бы, должен в силу возраста быть более восприимчив к технологиям.
используй то, что под рукою… и не ищи себе другое © Филеас Фог
В рамках данного раздела хотелось бы, на самом деле, поговорить не про извечные слезы пользователей, что в их любимом САПРе ничего не поменялось и только в интерфейсе кнопки перекрашивают да местами меняют. Ибо если человека, уже привыкшего к новой последней/предпоследней версии, вдруг пересадить на нечто устаревшее на 3–5 лет, то вдруг окажется, что нет каких-то мелких практически незаметных «ништяков», которые сделали жизнь легче и добавили удобства в последних версиях. А ведь на самом деле модернизация интерфейса — это сложная задача. Не просто ж так сейчас все CAD программы похожи друг на друга, как близнецы. И да, если сравнить, как выглядели некоторые программы 20 лет назад и как они выглядят сейчас — разница будет налицо. Если обобщить изменения, можно даже предположить, что где-то существует обязательный к исполнению ГОСТ на то, как должны выглядеть и работать САПР, и особенно CAD. Если выйти за пределы CAD и распространить похожие сравнения на CAMы, CAE, то разница будет больше. Но опять же: рассматривая ближайших конкурентов и вектора развития интерфейсов можно предположить, что вся отрасль ведет себя по школьному принципу «дай списать».
такие разные и такие одинаковые, одновременно
В остальном же, если посмотреть на форумы и «вишлисты» по любому из САПР, там найдутся сотни вещей, которые не исправляются десятилетиями, даже если вопрос касается многих, и на первый взгляд не требует каких-то гигантских усилий. Да, я знаю про то, что нередко кажущаяся мелкой проблема на самом деле имеет гораздо более глубокие корни. Но также знаю и о случаях, когда такие проблемы исправлялись единичными пользователями, которые не имели даже доступа к коду и уж точно не были профессиональными разработчиками.
Как пример ситуации, описанной в последнем тезисе, можно привести случаи, когда сотрудники вендоров/дилеров втихаря рекомендовали брать инсталляции у господ корсаров, ибо они были более компактными, менее глючными и пр. И, что характерно, за 20 лет я слышал сотни таких историй и подтверждений им от «официальных» лиц. Не буду говорить, что подобное я слышал про всех вендоров, но это не единичные случаи (с точки зрения применимости к вендорам).
во все времена были «посредники» помогавшие страждущим
А Вам знакомы такие истории? Или, может быть, «копеечные проблемы», которые не решаются годами, или вылезаютт от релиза к релизу, от сервиспака к сервиспаку? А может, у Вас есть история про «копеечную проблему», которая на самом деле является вершиной айсберга?
Наверное, проблема «застоя» является надуманной, потому что «чужие дети растут быстрее своих». В том плане, что, наблюдая за маркетинговыми заявлениями в области нашей компетенции, у нас есть возможность критически оценить изменения, а в других у нас есть только красивая картинка, выданная маркетингом. И именно поэтому нам кажется, что «где-то там трава зеленее» и развитие идет семимильными шагами, а у нас — «стабильность». И если бы мы поговорили с экспертами в других направлениях, которые нас так впечатлили, то итог был бы таким же (если конечно данный эксперт не пытается нам что-то впарить, или просто «оптимист по жизни»).
Или нет и все объективно?
Болезнь 2. Обратная совместимость. Совместимость. Совместная работа
Слова, вынесенные в анамнез текущей болезни, можно трактовать очень по-разному, но сейчас они будут трактоваться в рамках работы софта без учета вмешательства человека своими грязными руками.
старые файлы в новых программах
Итак, обратная совместимость. Под этим терминам понимается возможность открыть результаты Вашего труда в более ранних версиях программы. Желательно без потерь или с минимальными потерями. И вот с этим в САПР обычно очень плохо. Наличие возможности открыть проект в «устаревших версиях» отсутствует практически как класс. Возможность экспорта проекта в более старую версию является скорее исключением, чем правилом. Нередко процесс и рекомендации по такому экспорту (как и последствия) не сильно отличаются от экспорта в «нейтральный формат» для открытия в других САПР. Про то, что при таком действии все данные превращаются «в тыкву» -думаю, объяснять не надо. И лишь очень ограниченный список программ дает возможность совмещать работу в старых и новых версиях, пусть и с дополнительным геморроем в виде экспорта в старых версиях, и при этом не теряет почти все. Обычно к таким программам относятся самый низкоуровневый софт (не в плане самый «тупой» и ничего не умеющий, а тот, чья работа ведется, по сути, на уровне базовых объектов, и нередко является свободными от «истории»).
И да, как человек который, работал во многих системах, и следил не только за изменениями интерфейса, но также ядра или АПИ, я могу сказать: не всегда, когда с точки зрения обычного пользователя нет разницы, ее действительно нет. Да, визуально в интерфейсе ничего не поменялось, зато по АПИ понятно, что неизменный интерфейс теперь вызывает совсем другие функции, которых ранее просто не было. Ну или хотя бы их новые версии. А анализ на более низком уровне позволяет сказать, что в отдельных местах программа поменялась чуть больше, чем полностью.
И вполне естественно, что раз используются новые АПИ-функции, функции ядра, алгоритмы, настройки и пр., которых просто не было в предыдущих релизах, то сложно обеспечить совместимость в обратную сторону. Ибо это и в прямом направлении не всегда адекватно работает. Особенно при скачках через несколько версий.
Вот и получается — даже с прямой совместимостью, с которой ну уж точно не должно быть проблем, проблемы есть. И на длительных проектах они проявляются гораздо чаще. Иногда для открытия имеющихся данных по «старому проекту» надо иметь целый комплект промежуточных версий, в которых надо постепенно обновлять проект. Ну и, конечно, не забывать молиться, чтобы «посыпалось» как можно меньше, даже если нет потерь в проекте.
Именно поэтому лично мне несколько смешно слышать про PLM (product life management), о котором так любят говорить большинство вендоров CAD и много других. Формально это принцип, идея, метод (тут нет единого мнения) о том, что весь проект надо вести в единой среде (не программе, а среде, системе, наборе программ выстроенных в правильную цепочку) от идеи и до утилизации. Ведь срок жизни большинства разрабатываемых объектов составляет минимум десятилетия. И хоть у нас есть «болезнь 1», в рамках которой мы считаем, что ничего не поменялось, следует отметить — сменились целые поколения оборудования, ОС, программ. Это делает идею PLM «тупо» не применимой в реальной практике. И все эти слова начинают выглядеть не как конкретный метод, не как подход, а просто как «благие пожелания» или утопические идеи.
Несмотря на «лучшее в мире образование», связь поколений была утеряна. С PLM все тоже самое
И вот тут можно поднять вопрос совместной работы. Причем даже если «вывести за скобки» человека, а рассматривать просто вопрос совместной работы приложений, то мы получим боль… хотя нет, скорее БОЛЬ!!!
20 лет назад большинство вендоров пыталось сделать так, чтобы пользователи работали только в их программах, и отсутствие совместимости с другими ПО — было одним из инструментов привязки пользователей. Ведь рынок был небольшим. Дальнейшая история развития показала, что рынок на самом деле гораздо больше и попытка ограничить пользователя своей экосистемой на самом деле оттолкнет пользователя в сторону системы, которая дает большую свободу выбора. Так родилось вынужденное сотрудничество многих компаний. И это, кроме прочего, является еще одним проявлением современных реалий бизнеса, в рамках которых кто-то кого-то постоянно покупает и продает. Это делается для доступа к патентам, разработкам, людям, чтобы «съесть» конкурента… вариантов множество. Итог — «посадить» всю компанию на один софт практически невозможно, потому что у разных подразделений разные цели и задачи, и нередко выбор софта обусловлен не только историей, но и потребностями. Бывают и другие ситуации. Да, руководство может посадить все подразделения на один софт. Но экономически выгоднее для некоторых подразделений выбрать что-то другое, существенно дешевле. Еще бывают случаи, когда часть работы выполняется на аутсорсе, и там не всегда можно что-то требовать, потому что это единственный аутсорсер, который решает такие задачи, а он сотрудничает с разными компаниями, работающими в разном же софте. Давление на данную компанию может привести не к тому, что тебе станет удобнее работать, а к потере исполнителя и проигрышу конкурентам. Все это сдабривается опять же покупками, продажами и реорганизациями, что делает вопрос единого софта такой же утопией, как и PLM.
Но и в среде разработчиков САПР нередко возникают аналогичные ситуации, когда вчерашний конкурент может стать сегодняшним подчиненным, партнером или даже начальником. И софт, от которого ты «откараскивался» как мог, вдруг становится дружественным, и с ним надо делать интеграцию. Причем желательно глубокую — и быстро.
И вот тут мы видим, что софт от одного вендора иногда «стыкуется» между собой хуже, чем покупки у разных вендоров. Оказывается, что софт, который должен составлять единую экосистему, вообще не умеет работать совместно. И, казалось бы, этому нет препятствий, так как они уже давно принадлежат одной компании, или вообще разработаны в недрах одной компании изначально. Препятствий нет. Но нет и возможностей совместной работы.
Что уж говорить о совместимости разных программ одного или разного типа.
Да, надо учитывать разнообразие САПР, которое есть на рынке — по именам, по направлениям и пр. И то, что количество реализованных на практике вариантов совмещения разных САПР в единый или объединенный бизнес-процесс и процесс проектирования просто не поддается осмыслению и вычислению. А если сюда добавить еще направления и решаемые цели/задачи, то можно вообще свихнуться. Так вот с учетом всего этого вопрос интеграции действительно сложен. Без сарказма или иронии.
Но от боли и страдания это, к сожалению не избавляет. Можно было бы подумать, что раз вендоры договорились сотрудничать — то все, проблема решена. Но нет, ибо каждый старается выгадать побольше для себя, дать поменьше конкуренту и — главное! — не перетрудиться. И определяющим тут, как обычно, является последний пункт: как бы сделать, чтобы ничего не делать. Логично. Понятно. Но от боли это не избавляет.
Я повторяюсь? Да, повторяюсь. Но, думаю, причины понятны.
Окей, вендоры не напрягаются, а проблема есть. Что в этом случае делается? Правильно, принимается стандарт. И они есть. Более того, тот самый STEP, который все ругают, на самом деле содержит в себе возможности практически к полному обмену конструкторской, технологической, расчетной информацией. Вопрос:, а кто-то об этом вообще знает? Судя по тому, что ему на смену приняли новый ISO стандарт JT, целями создания которого и заявили возможность передавать не только геометрию, но и остальную проектную информацию, особенно технологическую и расчетную — нет, не знает.
Да, STEP немного устарел, но зачем было делать принципиально новый стандарт, а не «допиливать» требования к существующему? Зачем это компании Siemens, которая продвигала СВОЙ стандарт — вполне понятно. Почему такая слабая поддержка данного стандарта другими вендорами — тоже понятно, «троянский конь» мало кому нужен. Почему после принятия данного стандарта даже софт от Siemens очень ограниченно поддерживал данный стандарт (по крайней мере первое время, сейчас не скажу, давно не сталкивался) — уже понять сложнее. Почему, если не хочется внедрять JT, не «допилить» поддержку STEPа так, чтобы он хотя бы геометрию открывал без проблем? Фиг с ней, с историей построения, фиг с ней, с параметрикой. Про расчетные сетки я вообще молчу. Но ГЕОМЕТРИЮ без потерь можно научиться передавать?!
А так есть ощущение, что лет через 5–10 будет дан старт разработке нового стандарта, который будет решать проблему того, что ни один предыдущий не поддерживается отраслью нормально.
Болезнь 3. Производительность. Многопоточность
Регулярно на форумах, в чатах, под видео народ ругается, что купил мощный комп с кучей ядер, а «их» CAD (да в целом и CAM, а иногда и CAE) тормозит хуже чем на старом. Когда таким людям говоришь, что не только «ихний» кад, но и вообще практически любой не умеет работать параллельно и многопоточно, они спорят, обзываются и тыкают в статьи о том, как классно САПР работает на многоядерных процах (правда, я из этих же статей делаю обратные выводы). Тыкают в статьи, где рассказано, как видеокарты ускоряют математические расчеты вообще и САПР в частности (опять же обычно путается мягкое с теплым, ну да ладно). Показывают графики использования процессора и ядер. При этом доказывают, что раз пики идут на всех ядрах, то общая загрузка системы не превышает процента «полутора ядер». И, значит, тот, кто говорит про неумение использовать много ядер — дебил и диванный эксперт.
Вы представляете?… и эти люди борются…
Я не буду сейчас ничего доказывать. Ибо верю в то, что только на некоторых операциях большая часть САПРов научилась задействовать больше чем «полтора ядра». Исключение составляют, по сути, только расчеты (ну там прочность, газодинамика и… рендер). У рендеров с параллельностью все супер, у CAE с параллельностью все очень неплохо (не всегда, но чаще всего), у CAM бывает неплохо. У CAD — все плохо.
И да, я понимаю, что это не ленивые рукожопы программисты, ибо если бы дело было только в лени, кто-то один бы давно все сделал и озолотился бы (ну или тут же подтянулись другие). Но, увы — с параллельностью многих алгоритмов явно есть проблемы.
И все же это БОЛЬ.
И вот тут надо сделать еще одно отвлечение. Дело в том что алгоритмы алгоритмами. проблемы проблемами… НО! Лично мне очень странно видеть, что каждый год вендоры бодро рапортуют о том, что их САПРы работают быстрее, эффективнее, менее ресурсоемко. Странно потому, что насколько поменялась производительность компьютеров — я вижу. Она подтверждается тестами и много чем еще. И я как человек, который почти 20 лет назад работал со сборками 20 тыс. единиц и более, как человек, лично делавший сборку в 2 тыщи единиц, не могу серьезно воспринимать эти заверения. Особенно когда вижу, как у людей тормозит сборка из 100 компонентов на современных компьютерах в современных CAD (а оба должны быть производительнее). Да, иногда это идет от культуры моделирования. А точнее — ее отсутствия (по понятиям 20 летней давности). Но ведь не только от этого.
И понять, как это возможно — мне трудно. Посему я буду считать, что что-то тут не так. И это неплохо бы полечить.
И, что интересно, у меня есть некоторые объяснения. Я видел, как запускаются две версии программы до ее покупки одним вендором и после. Никаких отличий в программах не видно и не заявлялось. Единственное, что было сделано — это в интерфейс программы был добавлен фирменный «видовой куб» для навигации. Надо ли объяснять, что время запуска «обновленной» программы увеличилось, если верить секундомеру, почти в 30 раз?
Так как мы на хабре, то я сразу скажу — я не программист. Но когда ты в отрасли давно, почти со времен мамонтов (не динозавров, и то хорошо), то без программирования обойтись сложно. И я видел некоторые куски кода отдельных приложений. И мне приходилось заменять полторы тысячи строк чужого неработающего кода на 30 работающего. Да, я заменил фреймворки на чистую математику, только потому что плохо разбираюсь в фреймворках, а в математике, наоборот, что-то понимаю. Да, там кусок разросся до полутора тысяч просто потому, что автор решал проблемы методом поиска решений на stackoverflow. И все же.
Также мне приходилось заменять «case» на 200+ проверок линейным уравнением и делать ряд других вещей. Но, как вы понимаете, это отразилось на итоговой скорости приложений. Справедливости ради следует сказать, что и мой говнокод не раз подвергался переработке и ускорению со стороны настоящих программистов. Ибо я ничего более серьезного чем «пруф оф концепт» сотворить не могу. Даже на «минимал воркинг прототип» то, что я делаю, не всегда тянет.
Но в «мире САПР» создается ощущение, что за редким исключением вопросами скорости работы программ пренебрегают в ущерб скорости их написания. И это… да, я снова повторюсь про боль.
Болезнь 4. Цена
Я прекрасно понимаю, что цена на САПР идет от того, сколько пользы он может принести (цитирую вендоров и дилеров). И программы со стоимостью сотни тысяч долларов за одну лицензию (а такие в мире САПР не редкость) более чем стоят своих денег, даже не смотря на наличие более дешевых аналогов. Потому что аналоги-то они аналоги, но есть ньюансы ©. И нет, это не значит, что какой нибудь условный FreeCAD или OpenFOAM не могут принести пользы, ибо бесплатны.
Продолжая цитировать сапропродавцев, я также могу напомнить: САПР — это высокоинтеллектуальный продукт, в который вложено куча сил (иногда это сотни тысяч человеколет) очень крутых и дорогостоящих специалистов (некоторые из которых являются уникальными во всем мире, а других спецов такого класса и типа в мире буквально пара сотен человек), и это также влияет на цену. И нет, это не значит, что какой нибудь условный FreeCAD или OpenFOAM написаны криворукими дебилами на коленке за 5 минут.
Также можно вспомнить про ответственность, которая лежит на плечах САПР, но вместо упоминаний условных FreeCAD и OpenFOAM, я напомню: очень многие пользователи ругаются на устойчивость лицензионных коммерческих САПР (и достаточно активно). Напомню и то, что, согласно лицензионному соглашению, разработчики ни за что ответственности не несут. Интересный подход к ответственности, не правда ли?
вендоры лучше знают где хранить деньги, и сколько что должно стоить. Но иногда…
Более того, в той же «программерской» отрасли еще не так давно нас всех тоже убеждали, что инструменты разработки не могут стоить дешево. И так было и со средами разработки, и с игровыми движками, и базами данных, и с… да со всем так было. И ряд продуктов до сих пор стоит очень существенные деньги. И в то же время у них есть «урезанные версии», которые стоят вполне адекватные даже для частного лица деньги. Про количество бесплатных, или условно бесплатных (для личного пользования, для небольшой коммерции и пр.) вариантов я тоже промолчу. Промолчу, но их много. И мне кажется такое поведение — здоровым. Я искренне надеюсь что и САПР отрасль лишится этой «детской болячки».
И да, я вкурсе про существование бесплатных и opensource решений в мире САПР. Но для широкой аудитории они пока часто неприемлемы ввиду отсутствия адекватного интерфейса на уровне коммерческого софта хотя бы 5–10 летней давности.
Пока что эта проблема решается «оголтелым пиратством». О нем все знают, все его втихаря поддерживают. Он даже приносит деньги разработчикам. Но все же все делают вид что борются с ним и пафосно рассказывают о том, какой вред они получают от злобных корсаров. Имхо — это все тоже похоже на детскую болезнь. И я искренне надеюсь, что все же компании мира САПР найдут варианты цивилизованного лечения ситуации к вящему удовольствию и пользе всех участников процесса
(слово «все» — является гиперболой и оценочной характеристикой, не имеющей желания кого-то обвинить в пособничестве пиратству).
Заключение
Текст вышел достаточно объемным и сумбурным. Надеюсь, что он был для Вас интересным и полезным. Я вряд ли смог осветить и раскрыть все болячки. Я лишь затронул наиболее важные болезни и их симптомы. Дальнейшее повествование, возможные пути лечения и пр. — упираются в вопрос наличия/отсутствия интереса к данной проблематике.
Буду рад узнать Ваши мысли, с чем Вы согласны/не согласны и вообще что думаете по предложенному тексту.
и меня… вылечат…
Здоровья всем нам, нашим близким и отрасли в целом.
