Средство для программирования контроллера: Си или МЭК 61131?

http://burks.brighton.ac.uk/burks/pcinfo/progdocs/cppcrit/index.htm

Выдержки из 5. Conclusion

C++ is complex including too many constructs to overcome problems with itself and C, while lacking sophisticated mechanisms such as garbage collection, global analysis and automatic optimisations. C is thought of as being a simple language; but this is doubtful, as it has many operators, and a difficult precedence system. C's pointer style of programming is low level and difficult. Overall, C has many traps that lead to difficult to detect errors in software. Now C++ as a language is looking like the equivalent of computers of the 1950s, with large knobs, dials and patch panels; the C++ equivalents being pointers, structures, unions, #defines , etc., all of which have no place in a modern OO language, and are not in Java and Eiffel.

Compared to other OO languages, C++ looks more and more like an anachronism. C++ is now impeding the progress of the programming technology.

Это уже становится интересным... Как справедливо заметил тут один товарищ, я совсем не разбираюсь в языках, и с трудом себе представляю, как такую штуку реализовать на паскале, не пользуясь расширениями типа hi и lo. Но на Java... Вы не могли бы привести примерчик?

Приведенный мною "плохой пример", тем не менее, должен транслироваться на любой машине любым транслятором.

Именно. Это тактика моего оппонента - увести разговор в сторону от обсуждаемой темы, перевернув все с ног на голову. Как раз я говорил о том, что Си обеспечивает достаточный уровень переносимости. Но мне просто стало интересно, каков будет ответ. 

Я сам лично реализовывал подобные алгоритмы как в LD (несколько дольше и не так наглядно, но он-лайн можно контроллировать входа-выхода) и в FBD (просто и наглядно и в он-лайн все параметры видны).

И не только в РСУ, но и ПАЗ. И я могу привести десятки примеров, где на МЭКовских языках разрабатывались ОЧЕНЬ опасные объекты, такие как завод по уничтожению хим. оружия, такие суперкритические установки как синтезирование трициклогексанона, гидрогенизация, гидроформилирование, алкилационные установки, этерификация для химических производств, не говоря уже про попроще: изомеризацию, каталитический риформинг и пр...

Более того- в FBD я могу или взять готовый блок из библиотеки (это стандарный алгоритм в нашей системе) или, если не понравится- модифицировать библиотечный или накидать свой.

Что касатся этого- убедиться, что за заданное время он
закрылся, то в случае если позиционер интеллектуальный я могу вообще контроллировать реальное положение клапана, считать его "пробег", знать когда нужно заменить шток или отремонтировать (клапан сам "скажет"). И все это- в течение нескольких минут разработки.

Мало того- я могу иметь защищенный доступ к настройке клапана, вести его (и не только для клапанов) журнал (чертежи, описания, даты поверок, ремонтов, калибровок и кучу подобных вещей). Составлять прогнозы по обслуживанию, эксплуатации, смотреть графики отрабоки, в общем все то, что Вы на Си будуте реализовывать кучу времени.

Что это вам Си повсюду мерещится, как в страшном сне? Я говорил про самые обыкновенные операторы (арифметика, команды пересылки, преобразования типов и т.д.) и функциональные блоки, подразделяемые на стандартные (счетчики, таймеры, триггеры и прочее) и пользовательские, реализуемые на любом языке МЭК, в т.ч. и на самом LD. Прочтите, наконец, описание - я уже понял, что текста стандарта у Вас нет. А то получается "я Пастернака не читал, но глубоко осуждаю..."

Во-первых, стандарт хотя и допускает использование LD отдельно от остальных языков, но для эффективной работы предполагается использование адекватных задаче представлений. Во-вторых, операторы, функции и функциональные блоки, которые Вы называете инородными элементами, являются неотъемлемой частью языка. В-третьих, функции и функциональные блоки могут быть созданы и на LD, хотя для многих задач использовать его часто бывает неудобно. Концепция, заложенная в LD, действительно крайне проста - с этим не поспоришь.