Мама, я очень болен.
Мама, нас лечат не те врачи.
Те, кто нас заразил этим, залечивают наши раны.
Вот почему я неизлечим.
Сергей «Чиж» Чиграков 
здесь и ниже кадры из фильма «И.
В.
Меняет профессию» Мне кажется, моменты и цитаты подобраны по смыслу.
Нет, в этом тексте не будет говориться о пандемии или даже политике.
Вернее, о большой отрасли компьютерной жизни, а именно о CAD-индустрии.
Наверное, такая статья была бы лучше, если бы она исходила от кого-то, кого хабро-сообщество уже знает. Однако такая тема предполагает либо чистый кликбейт, либо аналитику.
Не любят кликбейт на хабе, но и аналитику не любят. Аналитика по проблемам приходит только от авторов, которым вы доверяете.
Но так уж получилось, что пара моих попыток зайти на Хабр, которые я предпринимал с интервалом в три года, оказались безуспешными.
Определенности нет и сегодня, но надо быть последовательными и выйти наконец из режима «только чтение».
В общем, не знаю, смогу ли я залогиниться, получу ли аналитику или это чистый и «голый» кликбейт, который больше никогда не покинет песочницу.
Решать вам, дорогой читатель, а я подойду немного ближе к сути.
Если мой никнейм и слово «Сапробасны» вам ни о чем не говорят, то скажу, что я в индустрии довольно давно.
Настолько, что если бы в начале карьеры меня посадили за плохо реализованные проекты, я бы все равно вышел.
Это, конечно, не означает, что я обязательно что-то хоть как-то пойму, но все же трудно быть совсем не в теме на такой период времени.
В итоге все написанное ниже – не более чем мое личное мнение и личный взгляд. Можно даже сказать, личные тараканы.
Некоторые вещи немного преувеличены, чтобы было живее, но я старался не уходить от реальности.
Приятного (надеюсь) чтения.
Жду ваших мыслей, комментариев, дополнений.
Болезнь 0. Терминология.
Маркетинг Ну, на самом деле это не болезнь и, конечно, не совсем индустрия.
Но есть проблема.
Приведу пример из жизни.
Представьте себе этот диалог:
- Здравствуйте, мне нужно, чтобы вы помогли мне рассчитать прочность моей конструкции.
- Для этого мне нужна геометрия, свойства материала, условия нагрузки, условия эксплуатации.
- Вы не поняли, я уже купил программу, мне просто нужна ваша помощь.
- Программа хорошая, но сама по себе не работает, нужна информация о том, что происходит
- Наверное вы не специалист, продавцы мне другое сказали.
- Что ж, пусть они помогут вам посчитать!
- И они послали меня к вам.
Частично проблема отрасли связана с тем, что мы говорим CAD (автоматизированное проектирование), а не CAD/CAM/CAE/PDM/PLM (и около трехсот других двух-пятибуквенных сокращений).
И как-то так получилось, что раз «Дизайн» по-английски — «Дизайн», то CAD == CAD (компьютерное проектирование).
Хотя на самом деле проектирования в САПР практически нет (за исключением некоторых мастеров/волшебников для создания стандартных объектов типа болтов или шестеренок).
Казалось бы, оба Иваны Васильевичи, но такие разные.
Нравятся условия Да, с помощью программ, которые относятся к категории САПР, решаются задачи проектирования.
Но в основном только два из них — это описание геометрии и оформление чертежей (или документации вообще, если смотреть шире).
И это не все дизайнерские задачи.
Не все.
Да, есть еще некоторые проблемы, которые можно частично или полностью решить, анализируя построенную геометрию в САПР: найти массо-инерционные характеристики, проверить сборку, некоторые вопросы технологичности.
Но это скорее следствие наличия 3D-геометрии, чем конкретной САПР.
Более того, даже в этих вопросах обычно возникают проблемы, связанные с вопросами точности изготовления, с тем, что реальные объекты имеют конечную жесткость и многими другими нюансами, которые не всегда можно проверить в САПР.
И это при том, что в других – подобных – случаях вроде бы все работало.
Остальные вопросы проектирования решаются в других программах, относящихся к классам CAE, CAM, CAPP. к большому списку, как говорилось ранее.
Казалось бы, об этом факте говорилось и писалось во многих местах.
Но это не решает проблему.
И даже сами продавцы часто допускают подобную ошибку.
Приведу в пример «Руководство по цифровой трансформации производственных предприятий».
http://Autodesk.ru/digitalguide .
На самом деле подобные примеры можно найти практически у каждого.
Ситуация усугубляется еще и тем, что то же самое можно сказать и о других типах программ класса САПР.
CAE не оценивает прочность конструкций/изделий и не дает ответов по вопросам компьютерного проектирования.
CAM не решает проблемы автоматизированного производства самостоятельно.
Все решения принимаются людьми; программы лишь автоматизируют рутинный процесс работы, частично уменьшая его объем, частично заменяя другими действиями.
И хотя многие это знают и помнят (применительно к отрасли, в которой они работают), знают не все.
И даже те, кто знает, насколько сильно результат зависит от оператора программы (например, при работе в САМ).
Насмотревшись, прочитав и прослушав массу «рекламы», такой специалист приходит к выводу: решить проблемы, в которых он не разбирается, достаточно просто купить подходящее программное обеспечение.
Вот и получается, что произошла подмена понятий.
Изменения, к которым мы привыкли.
И этого уже почти никто не замечает, но это выгодно в основном тем, кто продаёт софт. Ведь когда ты в чем-то недостаточно разбираешься, а тебе предлагают софт, который все сделает за тебя.
и это звучит со всех сторон.
это подкупает. Но! Проблема в том, что CAD (ни в версии CAD, ни в версии CAD/CAM/CAE.) не занимается проектированием, это лишь инструмент в руках человека.
А эффективность человека, использующего САПР, — это продукт «человеческой компетентности» и «возможностей инструмента».
При этом компетенция включает в себя не только «владение инструментом», но и знание предметной области.
Почему написано «возможности инструмента», а не «возможности САПР»? Наверное потому, что грамотный человек многое может сделать и без САПР.
И некомпетентный человек тоже может что-то сделать с помощью САПР.
И зачастую это даже срабатывает. Но гарантировать этого никто не может, а в лицензионных соглашениях на ПО в этом случае обычно есть куча пунктов, которые «освобождают» программный продукт и его разработчиков от ответственности (как говорится, читайте текст мелким и очень мелким шрифтом на конец документа).
инструмент, позволяющий решать разные задачи в зависимости от компетенции оператора Хотя, может быть, я ошибаюсь?.
А ведь нет проблем ни с прочтением терминологии, ни с заявленной подменой понятий, ни с соответствием ожиданий реальности? Напишите свои мысли в комментариях.
На проблемах терминологии хотелось бы закончить, но есть еще пара моментов, о которых следует упомянуть.
Во-первых, я объясню, почему я отказываюсь от аббревиатуры, неправильно склоняю слова рядом с термином САПР, а дальше по тексту вообще буду писать чушь в стиле «САПР-системы», «САПР-программы».
Да, CAD — понятная, однозначная аббревиатура (хотя некоторые умудряются заморочиться с ее расшифровкой).
И, честно говоря, к нему следует относиться именно как к аббревиатуре.
Но в то же время этот термин уже давно вошел в жизнь тех, кто с ним связан, и из простой «аббревиатуры» по сути стал словом.
А раз можно «развернуть», «обмануть» и «обмануть», то почему и здесь нельзя действовать соответственно? Я долго спорил на эту тему с разными людьми, особенно старшего поколения.
Но тут я неожиданно нашел в этом споре авторитетного союзника: Дэвида Левина, редактора портала isicad.ru. К сожалению, оригинальную заметку мне найти не удалось, ну да ладно.
Другая проблема в том, что половина отрасли «построена» на хайпе и войне условий.
Как только кто-то придумывает что-то относительно новое, все остальные тут же начинают это доказывать:
- На самом деле это никому не нужно;
- у них все одинаково и уже давно.
И это может продолжаться довольно долго.
Что в перспективе хоть и приводит к «урегулированию» терминов, использованию «хайпа» и т. д., но порядка не добавляет. 
Да, это не из фильма.
Но аналога я не нашел.
Характеризует оправдания продавцов при копировании чужого.
Ну раз уж заговорили об хайпе и новинках, то перейдем к тому, что действительно можно считать болезнью.
Болезнь 1. Застой и застой
На всех CAD-конференциях поставщики и те, кто в них участвует, рассказывают о новых продуктах, улучшениях, новых подходах и продуктах.Регулярно возникают некоторые модные тенденции, призванные произвести революцию в индустрии дизайна.
И все же, если посмотреть на последние 20-30 лет САПР в перспективе, обещанные в свое время революции как-то не заметны.
ретроспективный подход обычно более точен Однако это проблема не только вендоров, но и того, что многие до сих пор используют САПР, как в юмористических роликах про не очень умных пользователей.
То есть, например, перфоратор используется для того, чтобы забить что-либо в стену, а тачка – для того, чтобы удобнее было переносить помещенные в нее вещи.
И было бы хорошо, если бы это были люди, которые 20-30 лет назад работали именно так, потому что других вариантов не было.
Но те, кто, казалось бы, должен в силу возраста быть более восприимчивым к технологиям, часто работают точно так же.
пользуйтесь тем, что есть под рукой.
и больше ничего не ищите (с) Филеас Фог В этом разделе мне бы вообще хотелось поговорить не о вечных слезах пользователей о том, что в их любимой САПР ничего не изменилось и только в интерфейсе кнопки перерисованы и поменяны местами.
Потому что если человек, уже привыкший к новой последней/предпоследней версии, вдруг переводится на что-то устаревшее на 3-5 лет, то вдруг оказывается, что нет маленьких, почти незаметных «приятностей», которые облегчили жизнь и добавили удобство в последних версиях.
Но на самом деле модернизация интерфейса — сложная задача.
Дело не только в том, что сейчас все САПР похожи друг на друга, как близнецы.
И да, если сравнить, как выглядели некоторые программы 20 лет назад и как они выглядят сейчас, разница будет очевидна.
Если суммировать изменения, то можно даже предположить, что где-то есть обязательный ГОСТ о том, как должны выглядеть и работать САПР, а тем более САПР.
Если вы выйдете за рамки CAD и распространите аналогичные сравнения на CAM и CAE, разница будет больше.
Но опять же: учитывая ближайших конкурентов и вектор развития интерфейсов, можно предположить, что вся индустрия ведет себя по школьному принципу «дайте я это спишу».
такие разные и такие одинаковые одновременно В противном случае, если вы посмотрите на форумы и «списки пожеланий» по любой САПР, там найдутся сотни вещей, которые не исправлялись десятилетиями, даже если вопрос касается многих и на первый взгляд не требует каких-то гигантских усилий.
Да, я знаю, что часто, казалось бы, незначительная проблема на самом деле имеет гораздо более глубокие корни.
Но я также знаю случаи, когда подобные проблемы устранялись отдельными пользователями, даже не имевшими доступа к коду и уж точно не являвшимися профессиональными разработчиками.
В качестве примера ситуации, описанной в последнем тезисе, можно привести случаи, когда сотрудники вендоров/дилеров втихомолку рекомендовали брать установки от господ корсаров, потому что они были более компактными, менее глючными и т.д. И, что характерно, за 20 лет Я слышал сотни таких историй и подтверждений им от «официальных» лиц.
Не скажу, что слышал такое про всех вендоров, но это не единичные случаи (с точки зрения применимости к вендорам).
во все времена были «посредники», которые помогали страждущим Знакомы ли вам такие истории? Или, быть может, «копеечные проблемы», которые не решаются годами или появляются от релиза к релизу, от сервис-пака к сервис-паку? А может быть, у вас есть история о «копеечной проблеме», которая на самом деле является верхушкой айсберга? Наверное, проблема «застоя» надумана, ведь «чужие дети растут быстрее своих».
В том смысле, что, наблюдая за заявлениями маркетинга в сфере нашей компетенции, мы имеем возможность критически оценивать изменения, тогда как в других мы имеем лишь красивую картину, которую дает маркетинг.
И именно поэтому нам кажется, что «где-то там трава зеленее» и развитие идет семимильными шагами, а здесь «стабильность».
И если бы мы поговорили с экспертами в других областях, которые нас так впечатлили, результат был бы тот же (если, конечно, этот эксперт не пытается нам что-то продать или просто является «оптимистом по жизни»).
Или нет и все объективно?
Болезнь 2. Обратная совместимость.
Совместимость.
Сотрудничество Слова, взятые в анамнез текущего заболевания, можно трактовать очень по-разному, но теперь они будут трактоваться в рамках работы программного обеспечения без учета вмешательства человека своими грязными руками.
старые файлы в новых программах Итак, обратная совместимость.
Эти термины означают возможность открытия результатов вашей работы в более ранних версиях программы.
Желательно без потерь или с минимальными потерями.
А в САПР это обычно очень плохо.
Возможность открытия проекта в «устаревших версиях» как у класса практически отсутствует. Возможность экспорта проекта в более старую версию — скорее исключение, чем правило.
Зачастую процесс и рекомендации такого экспорта (как и последствия) мало чем отличаются от экспорта в «нейтральный формат» для открытия в других САПР.
Думаю, не нужно объяснять, что при таком действии все данные превращаются в «тыкву».
И лишь весьма ограниченный список программ дает возможность совмещать работу в старых и новых версиях, пусть и с дополнительным геморроем в виде экспорта в старые версии, и при этом не теряя почти всего.
Обычно к таким программам относится программное обеспечение самого низкого уровня (не в плане самого «тупого» и ни на что не способного, а того, работа которого осуществляется, по сути, на уровне базовых объектов, и зачастую свободна от « история»).
И да, как человек, работавший во многих системах и следивший не только за изменениями в интерфейсе, но и в ядре или API, могу сказать: не всегда, когда с точки зрения обычного пользователя нет никакой разницы, действительно нет никакой разницы.
Да, визуально в интерфейсе ничего не изменилось, но из API видно, что неизмененный интерфейс теперь вызывает совершенно другие функции, которых раньше просто не было.
Ну или хотя бы их новые версии.
А анализ на более низком уровне позволяет сказать, что кое-где программа изменилась чуть более чем полностью.
И вполне естественно, что поскольку используются новые функции API, функции ядра, алгоритмы, настройки и т.д., которых просто не было в предыдущих выпусках, то обеспечить обратную совместимость сложно.
Потому что это не всегда адекватно работает в прямом направлении.
Особенно когда перескакиваешь несколько версий.
Вот и получается, что даже с прямой совместимостью, с которой проблем точно быть не должно, есть проблемы.
А на долгосрочных проектах они появляются гораздо чаще.
Иногда, чтобы открыть существующие данные по «старому проекту», нужно иметь целый набор промежуточных версий, в которых нужно постепенно обновлять проект. И, конечно, не забывайте молиться, чтобы как можно меньше «падало», даже если в проекте нет потерь.
Вот почему мне лично смешно слышать о PLM (управлении жизненным циклом продукта), о котором любят говорить большинство поставщиков САПР и многие другие.
Формально это принцип, идея, метод (здесь нет единого мнения), согласно которому весь проект должен выполняться в единой среде (не программе, а среде, системе, наборе программ, организованных в единую среду).
правильная цепочка) от идеи до реализации.
Ведь срок жизни большинства разработанных объектов составляет не менее десятилетий.
И хотя у нас есть «болезнь 1», в рамках которой мы считаем, что ничего не изменилось, следует отметить, что сменились целые поколения оборудования, ОС и программ.
Это делает идею PLM «тупо» неприменимой на реальной практике.
И все эти слова начинают выглядеть не как конкретный метод, не как подход, а просто как «добрые пожелания» или утопические идеи.
Несмотря на «лучшее в мире образование», связь поколений была потеряна.
То же самое и с PLM. И здесь мы можем поднять вопрос о сотрудничестве.
Более того, даже если «вынести человека за скобки» и рассмотреть просто вопрос совместной работы приложений, то мы получим боль.
хотя нет, скорее БОЛИ!!! 20 лет назад большинство производителей старались сделать так, чтобы пользователи работали только в их программах, а отсутствие совместимости с другим ПО было одним из инструментов связывания пользователей.
Ведь рынок был небольшой.
Дальнейшая история развития показала, что рынок на самом деле гораздо больше и попытка ограничить пользователя своей экосистемой фактически подтолкнет пользователя к системе, дающей большую свободу выбора.
Так зародилось вынужденное сотрудничество многих компаний.
И это, кроме всего прочего, еще одно проявление современных реалий бизнеса, в которых кто-то постоянно кого-то покупает и продает. Это делается для доступа к патентам, разработкам, людям, чтобы «съесть» конкурента.
вариантов много.
В результате практически невозможно «посадить» всю компанию на одно программное обеспечение, поскольку разные отделы имеют разные цели и задачи, и зачастую выбор программного обеспечения определяется не только историей, но и потребностями.
Есть и другие ситуации.
Да, руководство может поставить все отделы на одно программное обеспечение.
Но для некоторых ведомств экономически выгоднее выбрать что-то другое, гораздо дешевле.
Также бывают случаи, когда часть работ выполняется на аутсорсе, и не всегда можно там что-то потребовать, потому что это единственный аутсорсер, который решает подобные задачи, и он сотрудничает с разными компаниями, работающими в разном программном обеспечении.
Давление на данную компанию может привести не к тому, что вам станет удобнее работать, а к потере исполнителя и проигрышу конкурентам.
Все это опять-таки приправлено закупками, продажами и реорганизациями, что делает вопрос единого ПО столь же утопичным, как и PLM. Но даже среди разработчиков САПР часто возникают подобные ситуации, когда вчерашний конкурент может стать сегодняшним подчиненным, партнером или даже начальником.
А софт, который вы «избегали» как могли, вдруг становится дружественным, и вам нужно с ним интегрироваться.
И желательно глубоко – и быстро.
И здесь мы видим, что ПО от одного вендора иногда сочетается хуже, чем покупки от разных вендоров.
Получается, что программное обеспечение, которое должно образовывать единую экосистему, вообще не умеет работать вместе.
И, казалось бы, никаких препятствий для этого нет, поскольку они уже давно принадлежали одной компании, либо вообще разрабатывались в недрах одной компании изначально.
Никаких препятствий нет. Но возможностей для сотрудничества нет. Что уж говорить о совместимости разных программ одного или разных типов.
Да, надо учитывать разнообразие САПР, представленных на рынке – по названию, по направлениям и т.д. И то, что количество реализуемых на практике вариантов объединения разных САПР в единый или интегрированный бизнес-процесс и Процесс проектирования просто за гранью понимания и расчета.
А если сюда добавить еще направления и цели/задачи, которые нужно решить, то можно совсем сойти с ума.
Так что, учитывая все это, вопрос интеграции действительно сложен.
Никакого сарказма и иронии.
Но, к сожалению, это не облегчает боли и страданий.
Можно было бы подумать, что раз вендоры согласились сотрудничать, то все, проблема решена.
Но нет, ведь каждый старается больше получить себе, меньше отдать конкуренту и – главное! - не переутомляйтесь.
И определяющим здесь, как обычно, является последний пункт: как сделать, чтобы ничего не делать.
Логично.
Ясно.
Но это не облегчает боль.
Я повторяюсь? Да, повторяю.
Но думаю, причины ясны.
Ладно, продавцы не напрягаются, но есть проблема.
Что делается в этом случае? Правильно, стандарт принят. И они являются.
Более того, тот самый ШАГ, который все критикуют, на самом деле содержит возможность практически полного обмена конструкторской, технологической и расчетной информацией.
Вопрос: кто-нибудь вообще знает об этом? Судя по тому, что на смену ему пришел новый стандарт ISO JT, целью которого было создание возможности передачи не только геометрии, но и остальной проектной информации, особенно технологической и конструкторской информации - нет, он этого не делает. не знаю.
Да, STEP немного устарел, но зачем было создавать принципиально новый стандарт, а не «дополнять» требования к уже существующему? Почему Siemens, продвигавшая стандарт ITS, пошла на это, вполне понятно.
Почему такая слабая поддержка этого стандарта другими вендорами, тоже понятно; «Троянский конь» мало кому нужен.
Почему после принятия этого стандарта даже ПО от Siemens очень ограниченно поддерживало этот стандарт (по крайней мере, поначалу, сейчас не скажу, давно с ним не сталкивался) — понять сложнее.
Почему, если вы не хотите реализовывать JT, почему бы не «допилить» поддержку STEP, чтобы он хотя бы без проблем открывал геометрию? С ней нет проблем, с историей постройки, с ней нет проблем, с параметрикой.
Про вычислительные сетки я вообще молчу.
Но можно ли научиться передавать ГЕОМЕТРИЮ без потерь?! И вот есть ощущение, что лет через 5-10 начнется разработка нового стандарта, который решит проблему того, что ни один из предыдущих не поддерживается должным образом в отрасли.
Болезнь 3. Производительность.
Многопоточность Регулярно на форумах, в чатах, под видео люди ругаются, что купили мощный компьютер с кучей ядер, но «их» CAD (и CAM вообще, а иногда и CAE) тормозит хуже, чем на старом.
Когда таким людям говоришь, что не только «их» САПР, но и вообще практически любой другой не может работать параллельно и многопоточно, они спорят, обзываются и указывают на статьи о том, как здорово САПР работает на многоядерных процессорах (хотя я я из тех самых людей) статьи делают противоположные выводы).
Они указывают на статьи, в которых рассказывается, как видеокарты ускоряют математические вычисления вообще и САПР в частности (опять же, обычно мягкое путают с теплым, ну да ладно).
Показывает графики использования процессора и ядра.
При этом они доказывают, что, поскольку пики возникают на всех ядрах, общая загрузка системы не превышает процента в «полтора ядра».
А это значит, что тот, кто говорит о невозможности использования многих ядер, тот дебил и кабинетный эксперт. 
Вы представляете?.
и эти люди дерутся.
Я сейчас ничего не докажу.
Потому что я считаю, что лишь в некоторых операциях большинство САПР научились использовать более «полутора ядер».
Исключение составляют, по сути, только расчеты (ну там сила, газодинамика и.
рендеринг).
С параллельными рендерерами все отлично, с CAE с параллельным все очень хорошо (не всегда, но чаще всего), с CAM может быть вполне хорошо.
CAD дела идут плохо.
И да, я понимаю, что это не ленивые программисты, ведь если бы дело было только в лени, кто-то один давно бы все сделал и разбогател (или бы сразу подключились другие).
Но, увы, явно есть проблемы с параллелизмом многих алгоритмов.
И все же это БОЛЬ.
И здесь нам нужно сделать еще одно отвлечение.
Дело в том, что алгоритмы есть алгоритмы.
проблемы проблемы.
НО! Лично мне очень странно видеть, что каждый год вендоры бодро сообщают, что их САПР работают быстрее, эффективнее и менее ресурсоёмко.
Это странно, потому что я вижу, насколько изменилась производительность компьютера.
Это подтверждено испытаниями и многим другим.
И я, как человек, почти 20 лет назад работавший со сборками в 20 тысяч единиц и более, как человек, лично делавший сборку в 2 тысячи единиц, не могу серьезно отнестись к этим заверениям.
Особенно, когда я вижу, как люди бьются над сборкой 100 компонентов на современных компьютерах в современных САПР (и то и другое должно быть более продуктивно).
Да, иногда это исходит из модельной культуры.
Вернее, его отсутствие (по понятиям 20-летней давности).
Но это не единственная причина.
И мне сложно понять, как такое возможно.
Поэтому буду предполагать, что здесь что-то не так.
И хорошо бы это лечить.
И, что интересно, у меня есть некоторые объяснения.
Я видел две версии программы, работавшие до и после того, как она была куплена одним поставщиком.
Никаких отличий в программах не видно и не заявлено.
Единственное, что было сделано, это добавить в интерфейс программы фирменный «вью-куб» для навигации.
Нужно ли объяснять, что время запуска «обновлённой» программы увеличилось по секундомеру почти в 30 раз? Раз уж мы на хабе, то сразу скажу, что я не программист. Но когда ты в индустрии уже давно, чуть ли не со времен мамонтов (не динозавров, и это хорошо), без программирования обойтись сложно.
И я видел некоторые фрагменты кода отдельных приложений.
И мне пришлось заменить полторы тысячи строк чужого сломанного кода на 30 рабочих.
Да, я заменил фреймворки чистой математикой только потому, что я плохо разбираюсь в фреймворках, а, наоборот, кое-что понимаю в математике.
Да штука там выросла до полутора тысяч просто потому, что автор решал задачи поиском решений на stackoverflow. Но все равно.
Также мне пришлось заменить «случай» из 200+ проверок на линейное уравнение и сделать ряд других вещей.
Но, как вы понимаете, это сказалось на конечной скорости работы приложений.
Справедливости ради следует сказать, что мой хреновый код не раз переделывался и ускорялся настоящими программистами.
Потому что ничего более серьёзного, чем «доказательство концепции», я создать не могу.
Даже то, что я делаю, не всегда можно назвать «минимально работающим прототипом».
Но в «мире САПР» бытует ощущение, что за редким исключением вопросами скорости программ пренебрегают в ущерб скорости их написания.
И это.
да, я еще раз повторю про боль.
Болезнь 4. Цена
Я прекрасно понимаю, что цена САПР зависит от того, какую пользу она может принести (цитирую вендоров и дилеров).А программы, стоимость которых составляет сотни тысяч долларов за лицензию (а такие не редкость в мире САПР), более чем стоят своих денег, даже несмотря на наличие более дешевых аналогов.
Потому что это аналоги, но есть нюансы (с).
И нет, это не значит, что какой-то условный FreeCAD или OpenFOAM не может быть полезен, ведь они бесплатны.
Продолжая цитировать сапроселлеров, могу также напомнить: САПР — это высокоинтеллектуальный продукт, в который вложено много усилий (иногда сотни тысяч человеко-лет) очень крутых и дорогих специалистов (некоторые из которых уникальны в своем деле).
весь мир, а других специалистов такого класса и типа в мире буквально пару сотен человек), и это тоже влияет на цену.
И нет, это не значит, что какой-то обычный FreeCAD или OpenFOAM написали кривые дебилы на коленках за 5 минут. Еще можно вспомнить об ответственности, которая лежит на плечах САПР, но вместо условных упоминаний FreeCAD и OpenFOAM напомню: многие пользователи жалуются на стабильность лицензионных коммерческих САПР (причем довольно активно).
Также напомню, что согласно лицензионному соглашению разработчики ни за что не несут ответственности.
Интересный подход к ответственности, не правда ли?
Теги: #Программное обеспечение #Инженерные системы #проектирование #CAD #CAD #CAD/CAM #cae #CAM
-
Обширная Информация По Применению Xml
19 Oct, 24 -
Мобильные Браузеры Opera В России
19 Oct, 24 -
Opera Готовит Революцию В Интернете
19 Oct, 24 -
Китайцы Сделали Электронную Сигарету
19 Oct, 24
