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

Дмитрий Теркель То есть тот факт, что некоторый язык позволяет просто задавать функции с помощью комбинирования других функций в композиции, еще недостаточен для того, чтобы назвать язык "функциональным". Необходима по крайней мере возможность манипуляции одних функций над другими. Иначе пришлось бы зачислить в "функциональные" почти все языки

Я готов согласиться. Однако признайтесь, что сам факт существования языка Joy заставляет подправить расхожие представления о том, что является, а что не является функциональным языком. Хотя бы потому что Joy не использует лямбда-калькулус.

Если Вы обратили внимание, несмотря на упомянутую Вами "маргинальность", Joy имеет весьма солидного "союзника" в лице Бэкуса с его FP-системами. 

Переводя разговор в более практическое русло, что, на Ваш взгляд, необходимо было бы добавить в FBD, чтобы сделать его действительно функциональным языком?

Насчет понятий вполне можно согласиться, это было бы весьма удобно. Однако, трудность будет заключаться в том, что не удастся заставить программистов пользоваться этими абстракциями. Что же касается поддержки - она упирается, в основном, в средства разработки, то есть, в ту или иную реализацию стандарта. Чтобы предоставить поддержку сишным программистам на том же уровне, на котором её получают программисты на МЭК, потребуется либо новая система разработки на C, либо поддержка C в том или ином виде в рамках конкретной реализации МЭКовского языка.

При создании ST были, как раз, учтены те самые абстракции, которыми Вы предлагаете наделить C. И, соответственно, убраны элементы языка, которые позволили бы программисту действовать вне рамок этих абстракций. Тем не менее, конкретная реализация языка может, наоборот, добавить ему функциональности, тем самым внося свой вклад в несовместимость с другими реализациями.

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

Возможность же наследования, позиционируемая как способ повторного использования кода, на самом деле позволяет похоронить детали реализации тех или иных классов вместе с воспоминаниями о том, для чего они были нужны :)

Вообще, я не сторонник ООП в сишном его понимании, и всегда предпочитаю писать  my_method (&my_object) вместо my_object.my_method() :-) Даже несмотря на то, что в данном случае "чистый" C не позволяет контролировать правильность передаваемого указателя (в этом смысле Паскаль - более "безопасный" язык). Прошу понять меня правильно, я не считаю, что ООП бесполезно как таковое. Просто оно, на мой взгляд, не является нужным при решении задач управления технологическими процессами. Его область применения тоже достаточно специфична: базы данных, графические интерфейсы...

Если исходить из того, что графически выраженный "агрегат" представляет собой вектор X=(x1,x2,...xn), то для того, чтобы получить из него другой вектор Y, представляющий собой некоторую комбинацию элементов исходного вектора, то мы должны выполнить преобразование, например, y1=x2, y2 = x1 и т.п. Таким образом, чтобы получить из одного "агрегата" другой, мы должны создать некоторую подпрограмму (функцию или функциональный блок), реализующую это преобразование. Либо делать это преобразование в том блоке, которому этот "агрегат" предназначается. Разве есть другие возможности?

Если я правильно понял, это что-то наподобие механизма "дружественных классов" в C++. Да, такой механизм мог бы добавить описательности языку, но  способен также сильно запутать программу, приводя к трудноуловимым ошибкам. Представьте себе, если три функциональных блока связаны между собой такими двунаправленными связями, как будет определяться порядок вычислений?

Здесь нет никакого противоречия, можно даже привести пример достаточно распространенного графического языка, ориентированного на процедурное программирование. Просто в рамках конкретного FBD принято избегать циклов и ограничивать разветвленность алгоритма, решая большинство задач в рамках единого управляющего цикла контроллера. Такой подход имеет под собой веские основания, но в него плохо укладывается решение данной проблемы.