російськомовний оригінал публікував на хабр 2021.07.22, але нові реалії. Переклад покищо автоматизований

Мама, я очень болен. Мама, нас лечат не те врачи. Те, кто нас заразил этим, – врачуют нам раны. Именно поэтому я неизлечим.

Сергей «Чиж» Чиграков

Ні, в цьому тексті йтиметься не про пандемію, і навіть не про політику. Скоріше про велику галузь комп’ютерної життєдіяльності, зокрема галузь САПР.

Напевно, така стаття краще зайшла б від когось, кого хабросообщество вже знає. Така тема передбачає або чистий клікбейт, або аналітику. Клікбейт на хабрі не люблять, а аналітику… Аналітика про проблеми добре заходить лише від авторів, яким довіряєш. Але так уже вийшло, що пара моїх спроб зайти на Хабр, які я здійснював з інтервалом року в три, не мали успіху. Немає впевненості і сьогодні, але ж треба бути послідовним і нарешті вийти з режиму 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. це нікому насправді не потрібне;
2. у них є все те саме і вже давно.

І вигадувати нові терміни/назви до своїх “аналогів”/”вбивцям конкурентів”, причому нерідко виконуючи всі три “рухи тіла” одночасно. І це може тривати досить довго. Що у довгостроковій перспективі хоч і призводить до “устаканивания” термінів, утилізації “хайпів” тощо, але порядку не додає.

Ну і раз ми заговорили про хайпи та новинки, перейдемо до того, що дійсно можна вважати хворобою

Хвороба 1. Застій та стагнація

На всіх конференціях САПР вендори та причетні до них розповідають про новинки, поліпшення, нові підходи, продукти. Регулярно виникають якісь модні тренди, покликані перевернути галузь проектування. Проте, якщо дивитися в перспективі на останні 20-30 років галузі САПР, то обіцяних свого часу революцій якось не помітно.

Втім, це проблема не тільки вендорів, а й того, що багато хто досі використовує САПР, як у гумористичних роликах про не дуже розумних користувачів. Тобто, наприклад, перфоратор використовується для забивання чогось у стіну, а тачку – для того, щоб було зручніше нести складені у неї речі. І добре, якби це були люди, які 20-30 років тому саме так працювали, бо інших варіантів не було. Але так само нерідко працюють і ті, хто, здавалося б, повинен через вік бути більш сприйнятливим до технологій.

У рамках цього розділу хотілося б, насправді, поговорити не про споконвічні сльози користувачів, що в їх улюбленому САПРі нічого не змінилося і тільки в інтерфейсі кнопки перефарбовують і місцями змінюють. Бо якщо людину, яка вже звикла до нової останньої/передостанньої версії, раптом пересадити на щось застаріле на 3-5 років, то раптом виявиться, що немає якихось дрібних практично непомітних “ніштяків”, які зробили життя легшим і додали зручності в останніх версіях . Адже насправді модернізація інтерфейсу – це складне завдання. Не просто так зараз всі CAD програми схожі один на одного, як близнюки. І так, якщо порівняти, як виглядали деякі програми 20 років тому і як вони виглядають зараз – різниця буде в наявності. Якщо узагальнити зміни, можна навіть припустити, що існує обов’язковий до виконання ГОСТ на те, як повинні виглядати і працювати САПР, і особливо CAD. Якщо вийти за межі CAD та поширити схожі порівняння на CAMи, CAE, то різниця буде більшою. Але знову ж таки: розглядаючи найближчих конкурентів та вектора розвитку інтерфейсів можна припустити, що вся галузь поводиться за шкільним принципом “дай списати”.

В іншому ж, якщо подивитися на форуми та “вішалісти” за будь-яким із САПР, там знайдуться сотні речей, які не виправляються десятиліттями, навіть якщо питання стосується багатьох, і на перший погляд не потребує якихось гігантських зусиль. Так, я знаю про те, що нерідко здається дрібною проблема насправді має набагато глибше коріння. Але також знаю і про випадки, коли такі проблеми виправлялися одиничними користувачами, які не мали навіть доступу до коду і точно не були професійними розробниками.

Як приклад ситуації, описаної в останній тезі, можна навести випадки, коли співробітники вендорів/дилерів нишком рекомендували брати інсталяції у панів корсарів, бо вони були компактнішими, менш глючними та ін. І, що характерно, за 20 років я чув сотні таких історій та підтверджень їм від “офіційних” осіб. Не говоритиму, що подібне я чув про всіх вендорів, але це не поодинокі випадки (з погляду застосування до вендорів).

А чи Вам знайомі такі історії? Чи, можливо, “копійчані проблеми”, які не вирішуються роками, або вилазять від релізу до релізу, від сервіспаку до сервіспаку? А може, Ви маєте історію про “копійкову проблему”, яка насправді є вершиною айсберга?

Напевно, проблема “застою” є надуманою, тому що “чужі діти ростуть швидше за свої”. У тому плані, що, спостерігаючи за маркетинговими заявами в галузі нашої компетенції, ми маємо можливість критично оцінити зміни, а в інших у нас є лише гарна картинка, видана маркетингом. І саме тому нам здається, що “десь там трава зеленіша” і розвиток йде семимильними кроками, а у нас – “стабільність”. І якби ми поговорили з експертами в інших напрямках, які нас так вразили, то підсумок був би таким самим (якщо, звичайно, даний експерт не намагається нам щось упарити, або просто “оптиміст у житті”).

Чи ні, і все об’єктивно?

Хвороба 2. Зворотна сумісність. Сумісність. Сумісна робота

Слова, винесені в анамнез поточної хвороби, можна трактувати дуже по-різному, але зараз трактуватимуться у рамках роботи софту без урахування втручання людини своїми брудними руками.

Отже, зворотна сумісність. Під цим термінам розуміється можливість відкрити результати Вашої праці у попередніх версіях програми. Бажано без втрат або з мінімальними втратами. І ось із цим у САПР зазвичай дуже погано. Наявність можливості відкрити проект у застарілих версіях відсутня практично як клас. Можливість експорту проекту у старішу версію є скоріше винятком, ніж правилом. Нерідко процес та рекомендації щодо такого експорту (як і наслідки) не сильно відрізняються від експорту до “нейтрального формату” для відкриття в інших САПР. Про те, що при такій дії всі дані перетворюються на гарбуз -думаю, пояснювати не треба. І лише дуже обмежений список програм дає можливість поєднувати роботу у старих та нових версіях, хай і з додатковим гемороєм у вигляді експорту у старих версіях, і при цьому не втрачає майже все. Зазвичай до таких програм ставляться самий низькорівневий софт (не в плані “тупий” і нічого не вміє, а той, чия робота ведеться, по суті, на рівні базових об’єктів, і нерідко є вільними від “історії”).

І так, як людина, яка працювала в багатьох системах, і стежила не тільки за змінами інтерфейсу, але також ядра або АПІ, я можу сказати: не завжди, коли з точки зору звичайного користувача немає різниці, її дійсно немає. Так, візуально в інтерфейсі нічого не змінилося, зате по АПИ відомо, що постійний інтерфейс тепер викликає зовсім інші функції, яких раніше просто не було. Ну чи хоча б їх нові версії. А аналіз на нижчому рівні дозволяє сказати, що у окремих місцях програма змінилася трохи більше, ніж повністю.

І цілком природно, що якщо використовуються нові АПИ-функции, функції ядра, алгоритми, налаштування та інших., яких просто був у попередніх релізах, то складно забезпечити сумісність у зворотний бік. Бо це й у напрямі не завжди адекватно працює. Особливо при стрибках через кілька версій.

Ось і виходить – навіть із прямою сумісністю, з якою ну точно не повинно бути проблем, проблеми є. І на тривалих проектах вони виявляються набагато частіше. Іноді для відкриття наявних даних за “старим проектом” треба мати цілий комплект проміжних версій, в яких треба поступово оновлювати проект. Ну і, звичайно, не забувати молитися, щоб “посипалося” якнайменше, навіть якщо немає втрат у проекті.

Саме тому особисто мені дещо смішно чути про PLM (product life management), про яке так люблять говорити більшість вендорів CAD та багато інших. Формально це принцип, ідея, метод (тут немає єдиної думки) про те, що весь проект треба вести в єдиному середовищі (не програмі, а середовищі, системі, наборі програм збудованих у правильний ланцюжок) від ідеї та до утилізації. Адже термін життя більшості об’єктів, що розробляються, становить мінімум десятиліття. І хоч у нас є “хвороба 1”, в рамках якої ми вважаємо, що нічого не змінилося, слід зазначити – змінилися цілі покоління обладнання, ОС, програм. Це робить ідею 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 річної давності.

Поки що ця проблема вирішується “шаленим піратством”. Про нього всі знають, всі його нишком підтримують. Він навіть приносить гроші розробникам. Але все-таки все вдають, що борються з ним і пафосно розповідають про те, яку шкоду вони отримують від злісних корсарів. Імхо – це все теж схоже на дитячу хворобу. І я щиро сподіваюся, що все ж таки компанії світу САПР знайдуть варіанти цивілізованого лікування ситуації до більшого задоволення та користі всіх учасників процесу

(слово “все” – є гіперболою та оцінною характеристикою, яка не має бажання когось звинуватити у пособництві піратству).

Висновок
Текст вийшов досить об’ємним та сумбурним. Сподіваюся, що він був для Вас цікавим та корисним. Я навряд чи зміг висвітлити та розкрити всі болячки. Я лише торкнувся найважливіших хвороб та їх симптомів. Подальша розповідь, можливі шляхи лікування та ін. – упираються у питання наявності/відсутності інтересу до цієї проблематики.

Радий дізнатися Ваші думки, з чим Ви згодні/не згодні і взагалі що думаєте за запропонованим текстом.

Здоров’я всім нам (і мирного неба), нашим близьким та галузі в цілому.