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

Напоследок, пару слов по поводу текстовых и графических языков программирования. Меня лично очень удивляет тупость "ученых" вроде Грина, которые не видят (или сознательно игнорируют?) очевидную вещь: текстовые языки - "одномерные", тогда как графические могут быть "двумерными".

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

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

Довольно много алгоритмов/описаний вполне удовлетворительно излагаются и воспринимаются в "одномерной форме", в виде текста. Это относится прежде всего к простым алгоритмам, с малым количеством связей между различными участками.

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

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

Применительно к языкам программирования, достойный пример: http://www.softcraft.ru/auto/switch/onemin/onemin.shtml Апологетам текстовых языков советую ознакомиться, прежде чем "кидаться какашками" или изобретать велосипед в виде самопального "автоматно-ориентированнного диалекта С".

Потенциал LD и FBD, по моему мнению, до конца еще не раскрыт. ST и IL, будучи текстовыми языками, таким потенциалом не обладают.

Что же касается С/С++, то использовать этот допотопный отстой в АСУ ТП приходится только и исключительно для "затыкания дыр", пока нормальные МЭКовские языки еще не покрыли все применения. 

To: Доктор Q.

Уважаемый Доктор, аргументы приводимые в обидной для оппонента форме не воспринимаются конструктивно. Это достаточно известный психологический факт. Если Вы хотите обсуждения по существу, старайтесь быть более позитивными в своих высказываниях. Владимир Зюбин стал существенно более сдержанным. Пример достойный подражания.

 

Что касается терминологических споров, то даже члены одного коллектива разработчиков зачастую понимают один и тот же термин по разному. Что же тогда говорить о представителях разных коллективов («школ») работающих к тому же в разных предметных областях. Нужно так же учитывать, что иностранные термины на российской почве часто мутируют в своем смысловом значении.

 

Наверное не важно как называть систему изначальных понятий, облегчающих понимание семаники различных языков – метафора, парадигма или еще как.  Понятно, что существуют разные способы записи (представления) алгоритмов и зачастую способ записи влияет на саму постановку задачи. Интересно – можно ли предложить что то, что улучшит возможности МЭКовских языков добавит им гибкости и т.п., и наоборот - может ли быть предложена какая нибудь стандартная библиотека (набор модулей, инфраструктура) для распространенного языка С, что бы приложения пользующиеся этой единой инфраструктурой могли быть переносимы и гибкость языка не приводила бы к проблемам надежности ПО? Или это утопия?

 

Может ли все это (и С и МЭК, да и другие языки) работать над некой единой платформой а-ля JVM или .NET? Кто нибудь смотрел эти технологии с точки зрения их скорости и детерминированности?

 

Тот же OPC - это ведь некоторая АСУ ТПшная нашлепка на Микрософтовский DCOM. Может аналогичную нашлепку можно сделать на .NET?

 

С Уважением,

 

Сергей Сорокин

Первоначально опубликовано Sergey Sorokin [...] Интересно – можно ли предложить что то, что улучшит возможности МЭКовских языков добавит им гибкости и т.п., и наоборот - может ли быть предложена какая нибудь стандартная библиотека (набор модулей, инфраструктура) для распространенного языка С, что бы приложения пользующиеся этой единой инфраструктурой могли быть переносимы и гибкость языка не приводила бы к проблемам надежности ПО? Или это утопия?

Такие библиотеки уже существуют...
и их, по-видимому, очень много.
Вот некоторые из известных мне:
- библиотеки FSM для С++ Concurrent Hierarchical State
Machine =   
http://homepage.mac.com/pauljlucas/software/chsm/
- в рамках т.н. SWITCH-технологии (подход А.А. Шалыто)
студенты постоянно пишут свои библиотеки
- в рамках т.н. КА-технологии (подход В.С. Любченко) -
dll-ка под Windows для Си++

Хотя мое личное мнение - требуется диалект Си, а не
библиотеки...

Первоначально опубликовано Sergey Sorokin Может ли все это (и С и МЭК, да и другие языки) работать над некой единой платформой а-ля JVM или .NET? Кто нибудь смотрел эти технологии с точки зрения их скорости и детерминированности? Тот же OPC - это ведь некоторая АСУ ТПшная нашлепка на Микрософтовский DCOM. Может аналогичную нашлепку можно сделать на .NET?

На мой взгляд, завязываться на производитель-
ориентированную технологию (каковой является дот-нет)
нецелесообразно.

Первоначально опубликовано Доктор Q http://forum.cta.ru/forum_posts.asp?TID=109&PN=1&TPN=19 <SPAN class=bold>Дмитрий Теркель </span>Так все-таки есть higher order functions, которые просто вводятся нетрадиционным образом. То есть одни функции манипулируют над другими, представленными в форме "quotations". Без этих особенностей не решились бы назвать язык "функциональным". То есть тот факт, что некоторый язык позволяет просто задавать функции с помощью комбинирования других функций в композиции, еще недостаточен для того, чтобы назвать язык "функциональным". Необходима по крайней мере возможность манипуляции одних функций над другими. Иначе пришлось бы зачислить в "функциональные" почти все языки Интересный комментарий на эту тему есть в http://www.holobloc.com/stds/iec/sc65bwg7tf3/html/faq.htm Can function block instances be passed as inputs to other blocks? Yes if function block FB1 is passed as an input to a second function block FB2, it is possible to invoke the function block FB1 within the body of FB2. Any input parameters of FB1 not defined in the invocation call within FB2 will take values defined by earlier invocations of FB1 made outside of FB2. Function block instances should be passed as VAR_IN_OUT parameters otherwise the values produced within the internal invocation will not be preserved.

Да, стандарт действительно разрешает передавать блоки как параметры, только здесь есть несколько "отягчающих обстоятельств". Я, правда, не совсем уверен, но, кажется, это обычно невозможно собственно в FBD (то есть можно только в ST), то есть я не плохо себе представляю, как это изображается графически. Во вторых, переменные типа inout вообще не очень хороши, поскольку имеют побочный эффект и, соответственно, результат вычисления диаграммы начинает зависеть от порядка вычислений (то есть теряется одна из самых приятных черт ФБД). Ну и , даже если все хорошо вызвалось, это не слишком отличается от передачи в Си функций по указателю...
А вот Ваша идея насчет ленивых вычислений (я, может быть, повторюсь) мне кажется довольно продуктивной. ТО есть так действительно можно было бы решить вопрос if - then -else
в ФБД естественным для него способом, то есть без всяких en-eno и тем более прыжков. Др. словами, вычисляться должен только тот фрагмент диаграммы, котрый нужен для вычисления выходов. Вычисление начинается с конца (то есть с блоков, непосредственно выдающих выходы). Когда программа, реализующая блок, доходит первый раз до чтения к-л входа, выполнение приостанавливается, и начинает выполняться блок, вычисляющий этот вход. Так "волна запросов" на вычисления пробегает "справа-налево", в результате требуемое значение получено, и исходный блок продолжает работу. Если переменная или блок уже вычислялись, повторного вычисления, конечно, не происходит - просто возвращается значение. Решение, в общем, в духе функциональных языков, фактически переменные ФБД, при традиционной трактовке пассивные, трактуются здесь как функции вычисления своих значений (они и передаются из блока в блок, а уж сам блок решает, вычислять ли свои входы или некоторые не вычислять).
Конуептуально в этом подходе (я не имею ввиду вычислительный overhead) мне пока не ясно, как по возможности выразительно продекларировать те входы, которые могут не быть задействованы (по усмотрению блока) и каковы допустимые варианты комбинации входов. Если такой декларации не предусмотреть, программа не будет структурной (при взгляде на диаграмму, не углубляясь в блоки, трудно будет понять, какие части диаграммы "опциональны" и в каких случаях). А в целом, мне кажется,
в этом случае - лень - двигатель прогресса :)

http://www.flownet.com/gat/papers/lisp-java.pdf

Lisp as an Alternative to Java

Our results show that Lisp’s performance is comparable to or better than C++ in execution speed; it also has significantly lower variability, which translates into reduced project risk. Furthermore, development time is significantly lower and less variable than either C++ or Java.

Lisp provides nearly all of the advantages that make Java attractive, including automatic memory management, dynamic object-oriented programming,and portability. Our results suggest thatLisp is superior to Java and comparable to C++ in runtime, and it is superior to both in programming effort and variability of results. This last item is particularly significant because it translates directly into reduced risk for software development.