Выбор средств разработки.

При огромном выборе средств SCADA, в нашей разработке был
использован язык Visul Basic. У нас нет предубеждений против
использования, например, широко распространённой Трейс Моуд,
хотя, согласитесь, лицензионное соглашение, которое Адастра
предлагает принять, звучит несколько настораживающе.
Приведём здесь небольшой отрывок из этого соглашения.
Цитируем дословно:

"
...ПРОГРАММА, СОПРОВОДИТЕЛЬНАЯ ДОКУМЕНТАЦИЯ
И УСЛУГИ ПОСТАВЛЯЮТСЯ НА УСЛОВИЯХ "КАК ЕСТЬ"
БЕЗ КАКИХ ЛИБО ГАРАНТИЙ. ВЕСЬ РИСК, СВЯЗАННЫЙ
С ИСПОЛЬЗОВАНИЕМ ИЛИ НЕВОЗМОЖНОСТЬЮ ИСПОЛЬЗОВАНИЯ
ПРОГРАММЫ, СОПРОВОДИТЕЛЬНОЙ ДОКУМЕНТАЦИИ И
ТЕХНИЧЕСКОЙ ПОДДЕРЖКИ ЛИЦЕНЗИАТ (т.е. пользователь)
ПРИНИМАЕТ НА СЕБЯ. Максимальная ответственность
АДАСТРА по данному соглашению не может превышать
покупной стоимости ПРОГРАММЫ или замены носителя.
...
"

Судите сами, можно ли доверять такому программному продукту
управление ответственными технологическими процессами.
В результате программного сбоя может произойти самопроизвольное
включение, например, масляного выключателя, в результате чего
от подстанции останутся одни угли, а нам компенсируют стоимость
программы, которая на два и более порядков ниже стоимости
вышедшего из строя оборудования.
Внедряя наши разработки, мы понимаем, что ответственность
за последствия неправильного функционирования системы в
результате ошибок проекта ложится прежде всего на нас.
Естественно, что количество ошибок должно сводится к разумному
минимуму. Понятно, что если поискать, в любой программе
можно обнаружить недостатки. Но в случае программного
обеспечения системы телемеханики ни при каких ошибках
не должно, например, происходить самопроизвольного
переключения коммутационного аппарата.
Для себя мы сделали вывод, что использование систем SCADA
общепромышленного назначения и широкого применения в данном
случае нам не подходит.
Надо сказать, что мы были несколько ограничены в выборе
языка. На фоне вышеизложенных соображений понятно,
что на первый план при проектировании выходит надёжность.
Такой высоконадёжный язык как ADA был нам недоступен,
во всяком случае, его последние реализации.
Проектирование велось нами параллельно на Borland C++ Builder 6
и Visual Basic 6. Написанные прототипы программ были протестированы.
Выяснилось, что при длительной работе программа, написанная на С++
постепенно, понемногу, увеличивала занимаемый объём памяти.
Кроме этого загрузка процессора была около 70% по данным
Диспетчера задач.
В квалификации программистов не было сомнений, но, по-видимому,
реализованный ими принцип параллельных потоков был несовершенен.
Все попытки устранить дефект не дали результатов.
Мы думаем, что винить С++ программистов в данном случае было бы
некорректно. Язык С++ по надёжности намного уступает VB.
Это конечно наше мнение, но мы в своих взглядах не одиноки.
В старой книге "Программирование в среде Си для ПЭВМ ЕС" 1991 года издания:

"
...Однако из-за того, что язык разрешает практически всё, его нельзя считать
языком надёжного программирования, и вся ответственность за надёжность
создаваемой на языке Си программы лежит на программисте.
"
Сказано это было про С, но верно и для С++, несмотря на развитие IDE.
Про споры насчёт преимуществ того или иного языка метко выразился
Крис Касперски:

"
...Вокруг языков программирования давно разгораются битвы,
но все как-то мимо писсуара и совсем не в тему.
"


Дискуссий мы открывать не собираемся, излагая только факты,
а выбор каждый сделает сам.