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

Если Вы говорите о ОО-"задатках" мэковских языков, то есть о том, что их МОЖНО сделать таковыми, то я с вами соглашусь (но я действительно не понял, что Вы имели ввиду именно возможную перспективу, а не текущее состояние дел, и не один я не понял ;). То есть я вообще не считаю, что идеи, заложенные в этих языках, уж такие тупиковые, и считаю, что развивать их можно и нужно. Болое того, и в нынешнем виде они значительную представляют ценность, как тот "общий знаменатель", по которому удалось достигнуть согласия (это редко бывает, и это надо ценить). Но нужно признать, что кому-то хватает этого "общего знаменателя", а кому то нет, и этот последний не может ждать, сложа руки, пока мэк продвинет свои языки дальше.

Ну а насчет "функциональности" языков - мне кажется, все же не стоит переопределять устоявшиеся термины (а функциональным языкам как таковым, если я не ошибаюсь, уже лет тридцать будет, если не больше, так что термин уже устоявшийся и даже "отстоявшийся" :). В сущности, Вы имели вввиду скорее не функциональность, а ДЕКЛАРАТИВНОСТЬ мэковских языков (в противовес ПРОЦЕДУРНОСТИ Си), поскольку, если в случае с ФБД, слово "функциональность" еще может хотя бы интуитивно с этим языком проассоциироваться, то в случае с SFC - уж вообще никак. Действительно, бОльшая декларативность (по ср. с Си, например) "графических" мэковских языков является определенным преимуществом, в том числе и в плане надежности ПО.

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

Направление развития МЭКовских языков меня тоже интересует, потому и ввязался в разговор. Но пока что разговор не очень конструктивный. Критика МЭКовских языков пока что выглядит огульной (в частности - неконкретной), а предлагаемые рецепты (типа "даешь Си!") ненамного лучше, чем призывы вернуться в пещеры ;-)

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

Как это часто бывает, опять спор перешел на вопросы терминологии. В подтверждение своего понимания "функциональности" я не буду "тыкать пальцем в небо", как это любят делать флеймеры, а приведу цитату из статьи Хьюза http://www.softcraft.ru/paradigm/fp/whyfp.shtml

Функциональное программирование называется так, потому что программа полностью состоит из функций. Сама программа тоже является функцией, которая получает исходные данные в качестве аргумента, а выходные данные выдаёт как результат. Как правило, основная функция определена в терминах других функций, которые в свою очередь определены в терминах еще большего количества функций, вплоть до функций - примитивов языка на самом нижнем уровне. Эти функции очень похожи на обычные математические функции, и в этой статье будут определены обычными уравнениями.  [...]

Особенности и преимущества функционального программирования обычно излагаются следующим образом. Функциональные программы не содержат операторов присваивания, а  переменные, получив однажды значение, никогда не изменяются. Более того, функциональные программы вообще не имеют побочных эффектов. Обращение к функции не вызывает иного эффекта кроме вычисления  результата. Это устраняет главный источник ошибок, и делает порядок выполнения функций несущественным: так как побочные эффекты не могут изменять значение выражения, оно может быть вычислено в любое время. Программист освобождается от бремени описания потока управления. Поскольку  выражения могут быть вычислены в любое время, можно свободно заменять переменные их значениями и наоборот, то есть программы "прозрачны по ссылкам". Эта прозрачность ссылок делает функциональные программы более удобными для математической обработки, по сравнению с общепринятыми аналогами.

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

к Доктор Q:

Не надо цитат, просто на данном этапе примите, что
FBD не имеет к функциональному программированию
никакого отношения... также как и Си,
где тоже такая штука, как "функции", есть... :-)

Первоначально опубликовано Доктор Q <SPAN class=bold>Владимир Е. Зюбин </SPAN>Не надо цитат, просто на данном этапе примите, что FBD не имеет к функциональному программированию никакого отношения... Вам не надо повторять Ваше личное мнение по многу раз, я его уже принял к сведению.  В противоположность Вам, я предпочел бы услышать цитаты или какие-либо технические доводы. Ссылки "невесть куда" просьба не давать. И еще к Вам пара просьб. В начале треда была ссылка на Вашу статью <SPAN style="FONT-FAMILY: 'Times New Roman Cyr'"><FONT face="Times New Roman Cyr" color=#800080>http<SPAN lang=RU style="mso-ansi-language: RU">://</SPAN>www<SPAN lang=RU style="mso-ansi-language: RU">.</SPAN>msclub<SPAN lang=RU style="mso-ansi-language: RU">.</SPAN>ce<SPAN lang=RU style="mso-ansi-language: RU">.</SPAN>cctpu<SPAN lang=RU style="mso-ansi-language: RU">.</SPAN>edu<SPAN lang=RU style="mso-ansi-language: RU">.</SPAN>ru<SPAN lang=RU style="mso-ansi-language: RU">/</SPAN>plc<SPAN lang=RU style="mso-ansi-language: RU">/</SPAN>iec<SPAN lang=RU style="mso-ansi-language: RU">1131.</SPAN>htm</SPAN><SPAN lang=RU style="FONT-FAMILY: 'Times New Roman Cyr'; mso-ansi-language: RU">  Я уже не раз пытаюсь ее прочитать, но то ли линк битый, то ли сайт безумно тормозной. Не могли бы Вы выложить ее в более доступное место?</SPAN> <SPAN lang=RU style="FONT-FAMILY: 'Times New Roman Cyr'; mso-ansi-language: RU">И еще, не могли бы Вы подробнее рассказать, что представляет собой Ваш язык СПАРМ? В Интернете информации по нему практически нет. Спрашиваю потому, что хотелось бы понять - какие _позитивные_ решения Вы предлагаете.</SPAN>

1. Уверяю Вас, функциональное программирование
основано на лямбда-исчислениях. Это не мое частное
мнение, а факт.

2. Черновой вариант статьи тут http://www.iae.nsk.su/~zyubin/iec1131.htm

3. По языку СПАРМ в Инете действительно немного,
но вполне достаточно публикаций в журналах ПСУ,
Автометрия, на международных конференциях по
специальности... СПАРМ - это русскоязычный
текстовый язык с Си-подобным синтаксисом, ориентированный
на описание сложных управляющих алгоритмов.
Базовая модель представления алгоритма -
гипер-автомат (совокупность z-автоматов, или,
если кому нравится, - процессов)... процесс можно
запустить и остановить из любого другого, включая
себя процесса. Все процессы полностью равноправны, что
позволяет организовывать алгоритм в виде произвольных
(в том числе иерархических) структур.
Его изучение, по-видимому, не требует никаких усилий...
По крайней мере, для знающих Си, которые, как я наблюдал,
спокойно и сразу текст на СПАРМ читают... Ну, и т.п.
(надежность, переносимость, выч. эффективность, гибкость,
расширяемость...)

Основной плюс, с моей точки зрения, представление
единого механизма организации управляющих алгоритмов
без затрат на изучение дополнительного (кроме
Си) языка... Типа "Си с процессами"... ;-)
(в альтернативу "Си с классами" :-)))

если Вы на sofcraft.ru захаживаете, то почитайте про
"switch-технологию", а потом представьте,
что существует язык, который от всей рутины
программирования на Си избавляет... это и
будет очень близкая штука к СПАРМ.

Владимир Е. Зюбин Черновой вариант статьи тут http://www.iae.nsk.su/~zyubin/iec1131.htm

Спасибо. Я, наконец, смог ознакомиться с этим документом. Комментировать его можно очень долго, поскольку в нем много спорных мест. Поэтому я попытаюсь ограничиться только указанием на вполне очевидные ошибки. Для начала я не буду разделять ошибки на крупные и мелкие, итоги будем подводить в конце.

Про ISaGRAF Вы пишите:

Набор средств разработки исполняется на компьютере проектировщика, например, компьютере типа IBM PC, и состоит из редактора, отладчика и препроцессора, который подготавливает описанный проектировщиком алгоритм к формату, "понятному" ядру-интерпретатору.

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

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