Современные технологии автоматизации» («СТА») —  журнал для квалифицированных специалистов по промышленной автоматизации Форум СТА — современные технологии автоматизации Домашняя страница
Домашняя страница форума CTA Домашняя страница форума CTA > II. АСУТП и SCADA > Архив
  Активные темы Активные темы
  FAQ FAQ  Искать в форуме   Зарегистрироваться Зарегистрироваться  Вход в систему Вход в систему

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

 Ответить Ответить Страница  <1 1213141516 53>
Автор
Сообщение
Доктор Q Смотреть выпадающим
Действительный член
Действительный член


Присоединился: 29 Сентябрь 2003
Категория: Isle Of Man
Online Status: Offline
Публикации: 119
Свойства публикации Свойства публикации   Ответить, цитируя автора - Доктор Q Ответить, цитируя автора -  ОтветитьОтвет Прямая ссылка на эту публикацию Тема сообщения: Средство для программирования контроллера: Си или МЭК 61131?
    Опубликовано: 29 Сентябрь 2003 17:03

Mike_K Давайте провозгласим лозуг

ПРОСТЫЕ ЗАДАЧИ ДЛЯ МЭК СЛОЖНЫЕ ДЛЯ С++!!!

Ну вот... Про амбиции - это ведь тоже Вы писали? Вот это:

Mike_K Весь спор только из амбиций программистов приверженцев МЭК, ни как не согласятся что МЭК для простых задач.

Удивительно, как Вы умудряетесь это сочетать ;-)

На С++ можно, конечно, писать и сложные задачи. Однако это язык _среднего_ уровня. Причем из алголоподобных - не самый лучший, имхо. МЭК вместо С предлагает ST, то есть язык типа Модулы-2. Это язык того же класса и уровня как С, только более логичный и естественный.

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

Если же говорить о небольших но _надежных_ применениях, то С тоже не на высоте. Старый добрый Форт даст ему десять очков форы.

Функциональные (по сути) языки LD, FBD и SFC - это языки более высокого уровня чем императивный С.

Наверх
Guests Смотреть выпадающим
Гость
Гость
Свойства публикации Свойства публикации   Ответить, цитируя автора - Guests Ответить, цитируя автора -  ОтветитьОтвет Прямая ссылка на эту публикацию Опубликовано: 29 Сентябрь 2003 17:08

При чем тут картинки? Я говорил о ЗАДАЧАХ.

Давайте распишем возможности языков, надеюсь тогда будем всем понятнее:

Типичное применение языков управления

Диаграммы функциональных блоков (ДФБ)

Контроль и тревожная сигнализация

Непрерывные вычисления

Аналоговое регулирование (давления, температуры,

Управление двигателями и клапанами

Диаграммы функциональных последовательностей

Загрузочные системы

Управление запуском-остановом

Управление периодическими процессами (наполнение,

смешивание, нагрев, разгрузка)

Структурированный текст (СТ)

Развитая математика

Сложные вычисления

Проверка условий блокировки

Проверка “Если-То-Иначе”

Битовые операции

 

Диаграммы функциональных блоков (ДФБ)

Диаграммы функциональных блоков используются 

для реализации непрерывно выполняемых вычислений,

контроля процесса и стратегий управления. Различные

блоки на диаграмме соединяются графическими

«проводами». По каждому «проводу» передается один или

несколько блоков данных. Весь обмен данными в системе

выполняется автоматически. Функциональные блоки

расширены и дополнены для

большей гибкости при разработке стратегий управления.

Совместимые со стандартом полевой шины

функциональные блоки позволяют вам реализовать

распределенное управление в полевых приборах.

 

Диаграммы функциональных последовательностей

(ДФП)

Этот язык позволяет вам конфигурировать независимые от

оператора действия, изменяющиеся во времени.

Диаграммы ДФП наилучшим образом подходит для

стратегий управления с несколькими состояниями. Они

могут использоваться для приложений с

последовательностью действий и для простых рецептур.

ДФП состоит из набора шагов и переходов. Каждый шаг

включает в себя набор действий, оказывающих воздействие

на процесс. Переходы определяют, когда обработка

переходит к следующему шагу. В ДФП поддерживаются как

последовательные, так и параллельные алгоритмы.

Структурированный текст (СТ)

С помощью структурированного текста вы можете писать

программы сложных расчетов, используя широкий набор

алгебраических и тригонометрических функций и

операторов. Кроме того, вы можете составлять сложные

логические выражения, используя условные и

итерационные структуры.

 

Наверх
Владимир Е. Зюбин Смотреть выпадающим
Действительный член
Действительный член


Присоединился: 09 Сентябрь 2003
Категория: Russian Federation
Online Status: Offline
Публикации: 247
Свойства публикации Свойства публикации   Ответить, цитируя автора - Владимир Е. Зюбин Ответить, цитируя автора -  ОтветитьОтвет Прямая ссылка на эту публикацию Опубликовано: 29 Сентябрь 2003 17:33
Доктор Q:
Я это готов воспринимать так. Вам не удалось найти
готовые функциональные блоки, которые решали бы Вашу
задачу. Вместо того чтобы написать такие блоки самим
и далее работать в рамках МЭКовских языков, Вы решили
вообще выбросить все, и начать с нуля... ;-)


Насколько я понял, Вы на FBD намекаете...
Увы, но FBD весьма ограниченый язык и мою задачу
на нем в принципе решить нельзя... более-менее
адекватный набор средств имеет SFC+ST, но, увы,
и этот набор достаточно убог с точки зрения
возможностей.

И эта-а-а... по-видимому, Вы не читали архивы,
а я уже устал повторять, я не программирую
управляющие алгоритмы на Си...

Доктор Q на мое "Языков в МЭКе не один, а целых пять,
да еще в некоторых средствах (ISaGRAF, к примеру) и Си
отлично просматривается... по вполне понятным
причинам... ;-)":
В МЭКе сями и не пахнет. По вполне понятным
причинам (с) ;-)


По-моему, все было предельно четко сказано,
но могу и повторить:
В МЭК 61131-3 пять языков. Это LD, FBD, SFC, ST, IL.
А вот в ПО-средствах, ориентирующихся
на МЭК, часто имеется Си. Иногда в неявном виде (как
исходное средство программирования ПО-средства),
а иногда и в явном, например, как в ISaGRAF.


Доктор Q:
...готов согласиться. МЭК представляет универсальный
подход для решения типовых АСУ ТП задач.
И универсальную оболочку для изящной инкапсуляции
нетиповых задач. В конце концов, чем функциональный
блок хуже ++ в сях? Инкапсуляция - есть, наследование -
есть, полиморфизм - и тот можно сделать при желании.


Языки МЭК ориентированы на новичков и тривиальные
задачи. А утверждения о том, что язык FBD объектно-
ориентированный, пардон, смехотворны... С таким же
успехом можно утверждать, что ассемблер
объектно-ориентирован...

И еще раз: МЭК это не язык, а стандарт описывающий
пять языков, поэтому каждый раз требуется пояснять,
какой из языков Вы конкретно имеете ввиду...
Что Вы имеете ввиду говоря "МЭК представляет"?
Мне неясно... "ST представляет"? или "IL представляет"?
Уверяю Вас, Си представляет гораздо более универсальное
средство... Давайте все же почетче свои мысли пытаться
выражать... как и подобает настоящим докторам...

Доктор Q:
Более того, LD и FBD по сути своей - функциональные
языки. До такого уровня императивный по природе С++
недопрыгает никогда, имхо ;-)


Все ПО поддержки этих языков в подавляющем большинстве
случаев пишутся на Си++... не стоит об этом забывать.
Кроме того, ни LD ни FBD функциональными языками
не являются... если Вы понимаете, о чем я говорю... ;-)

http://www.InstantWeb.com/D/dictionary/foldoc.cgi?functional+programming
Кстати, это ссылка на хороший толковый словарь,
имеет смысл им чаще пользоваться...
чтобы реже впросак попадать.

LD и FBD - это основанные на метафоре низкоуровневые
языки четвертого поколения.
Поясню на всякий случай, упреждая возможное
неверное прочтение:
- "основаный на метафоре" означает, используются
привлеченные из других областей понятия,
- "низкоуровневый" - не представляет широких
структурирующих возможностей,
- "четвертого поколения" - проблемно-ориентированные.
Владимир Е. Зюбин
Язык Рефлекс -- Си-подобный язык программирования ПЛК
http://reflex-language.narod.ru/
Наверх
Guests Смотреть выпадающим
Гость
Гость
Свойства публикации Свойства публикации   Ответить, цитируя автора - Guests Ответить, цитируя автора -  ОтветитьОтвет Прямая ссылка на эту публикацию Опубликовано: 29 Сентябрь 2003 17:34
Первоначально опубликовано Mike_K

Давайте провозгласим лозуг

ПРОСТЫЕ ЗАДАЧИ ДЛЯ МЭК СЛОЖНЫЕ ДЛЯ С++!!!

И все станет на свои места, а крики, что на си писать долго рабираться плох это для тех кто его незнает. Тоже можно сказать и о МЭКовских языках.

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

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

Поэтому я Ваш лозунг переиначу: ЛЮБЫЕ ЗАДАЧИ ДЛЯ МЭК НЕ ЯВЛЯЮТСЯ ЛЮБЫМИ ЗАДАЧАМИ ДЛЯ С++

 

  

Наверх
Дмитрий Теркель Смотреть выпадающим
Новичок
Новичок


Присоединился: 26 Сентябрь 2003
Категория: Russian Federation
Online Status: Offline
Публикации: 22
Свойства публикации Свойства публикации   Ответить, цитируя автора - Дмитрий Теркель Ответить, цитируя автора -  ОтветитьОтвет Прямая ссылка на эту публикацию Опубликовано: 29 Сентябрь 2003 17:55
Первоначально опубликовано Максим Ананских

Первоначально опубликовано Дмитрий Теркель


Конечно, на C++ очень легко определить класс FunctionBlock, Task и т.д. Но каждый определит их по-разному, виртуальные функции назовет по-разному, и переносимости по исходным текстам не будет. Так, может быть, пора это как-то стандартизировать, в форма неких базовых классов или даже макросов?


И в результате мы получим нечто вроде "IEC-1131 для тех, кто пишет на C". А насколько это нужно?



Ну вот, Вы самой постановкой вопроса на него и ответили :) . Значительная часть систем пром. автоматизации пишется на Си - это медицинский факт, и данная дискуссия это подтверждает. Писать на Си есть свои резоны, как объективные, так и связанные с уровнем и квалификацией программистов. Переучить абсолютно всех на Мэк - это также нереально, как и переучить всех на Си. Речь идет о том, чтобы программист чувствовал себя комфортно в обоих случаях, при необходимости переходя с одного языка на другой и не теряя при этом соответствующей поддержки и соответствующих понятий. Кроме того, я слабо верю в абсолютную замкнутость "мира промышленной автоматизации", и связь с "большим миром" должна присутствовать.

Первоначально опубликовано Максим Ананских



Первоначально опубликовано Дмитрий Теркель



Теперь про мэковские языки. НА мой взгляд, они сильно неравноценны -некоторые из них, я согласен, просто пережиток (IL), некоторые - дань определенному историческому типу мышления (LD)



Скорее, LD - это дань наглядности и удобству отладки. Если нужно выполнить большое количество операций "И", "ИЛИ", "НЕ" - то на LD это получается удобнее всего. Хотя для других целей он, конечно, малопригоден, поэтому его необходимо использовать в комплексе с другими языками.




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

Первоначально опубликовано Максим Ананских



Первоначально опубликовано Дмитрий Теркель


а вот ФБД и Structured Textболее интересны. ST как будто самый гибкий из них, но.. трудно отделаться от вопроса: а зачем изобретать новый процедурный язык, когда есть масса хороших старых и новых - Си, Паскаль, Ада? Java и пр, и пр.



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




В некоторой степени с Вами согласен. Но мне все равно представляется, что изобретение нового языка только ради минимизации возможностей программиста совершать НЕКОТОРЫЕ виды ошибок ... Но, впрочем я не против существования ST как такового, просто, он как бы не добавляет ВЫРАЗИТЕЛЬНОСТИ по сравнению с другими языками. А интересен он лишь тем, что он наиболее универсальный язык в МЭКе. Так сказать, локальный интерес :)

Первоначально опубликовано Максим Ананских


Первоначально опубликовано Дмитрий Теркель


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


А какие преимущества для задач автоматизации даст ООП? Инкапсуляция? В принципе, ФБ и есть объект, обладающий своим собственным состоянием... Наследование и полиморфизм? А настолько ли они нужны при решении задач достаточно узкой тематики?



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

Первоначально опубликовано Максим Ананских


Первоначально опубликовано Дмитрий Теркель


Язык FBD, {...} Казалось бы, можно инкапсулировать один блок в другой, создав компактное описание на верхнем уровне системы. Но нельзя инкапсулировать много связей в одну "сложную" - а значит, из "крупного" блока будут тянуться сотни информационных связей, которые придется соединять руками, что и сведет на нет всю простоту "укрупненной картины".



Это не совсем так. Связи можно создать, ипользуя пользовательские типы данных. Если же этого сделать не удается - значит, неправильно само разбиение программы на функциональные блоки, или неправильно спроектированы информационные связи.



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

Первоначально опубликовано Максим Ананских



Первоначально опубликовано Дмитрий Теркель


Далее, этот язык не позволяет описывать массовые или повторяющиеся вычисления (здесь приводились примеры с обработкой массива сэмплов с какого-либо датчика) Я тоже считаю, что десятикратный Copy/Paste фрагмента диаграммы - это не метод программирования циклов :-).



Вот именно для этого и придуман ST. Вообще, в МЭКовском стандарте каждый язык проблемно-ориентирован и ни в коей мере не претендует на универсальность. Потому что изначально не ставилось такой задачи.




Я все-таки не совсем согласен с тем, что если какая-то проблема плохо решается на каком-то языке, то она автоматически исключается из его "проблемной ориентации". МНе не очень понятно, чем проблема обработки десяти сэмплов с датчика противоречит ИДЕЕ графического представления этой обработки с помощью блоков и информационных связей. Просто на конкретном языке ФБД это выглядит не очень изящно.
Первоначально опубликовано Максим Ананских



Первоначально опубликовано Дмитрий Теркель


Я ничего не говорю про ООП, то есть наследование, а также параметрический полиморфизм, которые также были бы уместны. Почему бы не унаследовать PID-регулятор от абстрактного регулятора, а адаптивный PID-регулятор от просто PID-регулятора? (я имею ввиду наследование ФБД-диаграмм?)


Поясните, пожалуйста, идею наследования диаграмм. Что-то я слабо себе это представляю... Или речь идет просто о вызове вложенного функционального блока?



В случае ФБД скорее речь идет о наследовании от "абстрактных" блоков, содержащих только входные и выходные переменные. Эта возможность даст существенный эффект только в паре с идеей "множественных связей". То есть, если у меня некий регулятор унаследован от абстрактного, где есть только измеренная величина,задание, и положение рабочего органа, то этот регулятор я могу соединить (одним взмахом мышки), например, с универсальным функциональным блоком, оценивающим качество регулирования (скажем, оповещающем, что регулятор "пошел в разнос"). Мне не придется отдельно соединять входы и выход моего регулятора с входами "контролёра", поскольку для абстрактного регулятора это уже объяснено (опять же просьба не пинать за подбор примера :).
Первоначально опубликовано Максим Ананских


Первоначально опубликовано Дмитрий Теркель


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



Разве эта задача не решается с помощью SFC? Или имеется в виду нечто другое?



[/QUOTE]
Да, согласен с Вами, это одно из решений. Я в какой-то мере спровоцировал этот вопрос, чтобы услышать мнения других участников дискуссии по этому поводу :).

С уважением,
Дмитрий Теркель
Наверх
Доктор Q Смотреть выпадающим
Действительный член
Действительный член


Присоединился: 29 Сентябрь 2003
Категория: Isle Of Man
Online Status: Offline
Публикации: 119
Свойства публикации Свойства публикации   Ответить, цитируя автора - Доктор Q Ответить, цитируя автора -  ОтветитьОтвет Прямая ссылка на эту публикацию Опубликовано: 29 Сентябрь 2003 18:18


Владимир Е. Зюбин Доктор Q на мое "Языков в МЭКе не один, а целых пять, да еще в некоторых средствах (ISaGRAF, к примеру) и Си
отлично просматривается... по вполне понятным
причинам... ;-)":
В МЭКе сями и не пахнет. По вполне понятным
причинам (с) ;-)


По-моему, все было предельно четко сказано, но могу и повторить:
В МЭК 61131-3 пять языков. Это LD, FBD, SFC, ST, IL.

Чем повторять прописные вещи, возможно Вам столо бы перечитать мой _исходный_ постинг, чтобы увидеть, что речь там идет о конкретной реализации на ПЛК, а не о стандарте, посему используется единственное число вместо множественного: то, что уже сделано разработчиками ПЛК (которые занимаются этим не один год),  и дается в виде МЭКовского языка

Владимир Е. Зюбин А вот ПО-средствах, ориентирующихся  на МЭК, часто имеется Си. Иногда в неявном виде (как  исходное средство программирования ПО-средства),  а иногда и в явном, например, как в ISaGRAF.

Я и пишу: В МЭКе сями и не пахнет. Тут у нас полный консенсунс. Не понимаю, против чего Вы пытаетесь возразить.

Владимир Е. Зюбин Языки МЭК ориентированы на новичков и тривиальные задачи.

Аргументов нет? Хорошо, это Ваше личное мнение я учту.

Владимир Е. Зюбин А утверждения о том, что язык FBD объектно-
ориентированный, пардон, смехотворны... С таким же успехом можно утверждать, что ассемблер объектно-ориентирован...

Аргументов нет? Хорошо, эти Ваши эмоции я тоже учту.

Доктор Q:
Более того, LD и FBD по сути своей - функциональные
языки. До такого уровня императивный по природе С++
недопрыгает никогда, имхо ;-)


Владимир Е. Зюбин Все ПО поддержки этих языков в подавляющем большинстве случаев пишутся на Си++... не стоит об этом забывать.

И что? Прошу Вас, доведите свою мысль до конца.

Владимир Е. Зюбин Кроме того, ни LD ни FBD функциональными языками не являются... если Вы понимаете, о чем я говорю... ;-)

Нет, не понимаю. Цитирую книгу Роберт У. Себеста, "Основные концепции языков программирования":

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

С моей точки зрения, LD, FBD и SFC прекрасно укладываются в определение.

Владимир Е. Зюбин  www.InstantWeb.com/D/dictionary/foldoc.cgi?functional+programming  Кстати, это ссылка на хороший толковый словарь,  имеет смысл им чаще пользоваться...  чтобы реже впросак не попадать. 

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

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

Аргументов нет? Хорошо, это Ваше личное мнение я тоже учту.

Наверх
Дмитрий Теркель Смотреть выпадающим
Новичок
Новичок


Присоединился: 26 Сентябрь 2003
Категория: Russian Federation
Online Status: Offline
Публикации: 22
Свойства публикации Свойства публикации   Ответить, цитируя автора - Дмитрий Теркель Ответить, цитируя автора -  ОтветитьОтвет Прямая ссылка на эту публикацию Опубликовано: 29 Сентябрь 2003 19:33
Первоначально опубликовано Доктор Q


<SPAN class=bold>Владимир Е. Зюбин </span>А утверждения о том, что язык FBD объектно-
ориентированный, пардон, смехотворны... С таким же успехом можно утверждать, что ассемблер объектно-ориентирован...

Аргументов нет? Хорошо, эти Ваши эмоции я тоже учту.



У меня тоже нет аргументов. Это действительно очевидно, просто неудобно как-то аргументировать :)
Никакие они не объектно-ориентированные
(хотя это автоматически не значит, что они плохие :)
Первоначально опубликовано Доктор Q




Доктор Q:
Более того, LD и FBD по сути своей - функциональные
языки. До такого уровня императивный по природе С++
недопрыгает никогда, имхо ;-)


<SPAN class=bold>Владимир Е. Зюбин </span>Все ПО поддержки этих языков в подавляющем большинстве случаев пишутся на Си++... не стоит об этом забывать.


И что? Прошу Вас, доведите свою мысль до конца.


<SPAN class=bold>Владимир Е. Зюбин </span>Кроме того, ни LD ни FBD функциональными языками не являются... если Вы понимаете, о чем я говорю... ;-)


Нет, не понимаю. Цитирую книгу Роберт У. Себеста, "Основные концепции языков программирования":


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


С моей точки зрения, LD, FBD и SFC прекрасно укладываются в определение.


По традиции функциональными языками называют языки, в той или иной степени основанные на лямбда-исчислении Черча. Их отличает по крайней мере такие черты:
1) Передача в качестве аргументов функций других функций (где это в мэках?).
2) Отсутствие у функций побочных эффектов (вычисление функционального блока принципиально имеет побочные эффекты)
3) Широкое использование параметрического полиморфизма (темплейты C++ - отдаленный аналог)
4) Отсутствие какого-бы то ни было намека на понятие времени (в котором происходит выполнение программы) или на понятие состояние программы (значений переменных состояния). Впрочем, последнее иногда все-таки вводится, правда, весьма неорганичным для этих языков образом.

Наиболее известные из функциональных языков ML и Haskell.
Если Вы хоть раз видели программы, написанные на этих языках, вряд ли Вам пришла бы в голову хоть какая-нибудь аналогия с мэковскими (я опять же не утверждаю, что мэковские языки плохие, потому что не функциональные. Просто не функциональные они, и все тут)
С уважением,
Дмитрий Теркель
Наверх
Доктор Q Смотреть выпадающим
Действительный член
Действительный член


Присоединился: 29 Сентябрь 2003
Категория: Isle Of Man
Online Status: Offline
Публикации: 119
Свойства публикации Свойства публикации   Ответить, цитируя автора - Доктор Q Ответить, цитируя автора -  ОтветитьОтвет Прямая ссылка на эту публикацию Опубликовано: 30 Сентябрь 2003 01:33

Доктор Q В конце концов, чем функциональный блок хуже ++ в сях? Инкапсуляция - есть, наследование - есть,  полиморфизм - и тот можно сделать при желании

Владимир Е. Зюбин А утверждения о том, что язык FBD объектно-
ориентированный, пардон, смехотворны... С таким же успехом можно утверждать, что ассемблер объектно-ориентирован

Дмитрий Теркель У меня тоже нет аргументов. Это действительно очевидно, просто неудобно как-то аргументировать :) Никакие они не объектно-ориентированные (хотя это автоматически не значит, что они плохие :)

Это правильно, что нет аргументов. Поскольку нигде прямым текстом не говорилось, что они таковые. Так показалось В.Зюбину, но, судя по его ответам, он невнимательно читает, так что не стоит за ним повторять.

Говорилось что они не хуже чем ООП-средства, и что у них есть определенные задатки, чтобы сделать их таковыми при желании.

Дмитрий Теркель По традиции функциональными языками называют языки, в той или иной степени основанные на лямбда-исчислении Черча.

Является ли следование этой традиции принципиально необходимым условием для зачисления в класс функциональных?

Их отличает по крайней мере такие черты:
1) Передача в качестве аргументов функций других функций (где это в мэках?).

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

2) Отсутствие у функций побочных эффектов (вычисление функционального блока принципиально имеет побочные эффекты)

Здесь наши мнения расходятся. Я не вижу причин, по которым вычисление функц. блока обязано давать побочные эффекты. 

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

3) Широкое использование параметрического полиморфизма (темплейты C++ - отдаленный аналог)

Еще раз, насколько это необходимо, и есть ли принципиальные ограничения, не позволяющие этого сделать?

4) Отсутствие какого-бы то ни было намека на понятие времени (в котором происходит выполнение программы) или на понятие состояние программы (значений переменных состояния). Впрочем, последнее иногда все-таки вводится, правда, весьма неорганичным для этих языков образом.

Из практических соображений они там  в той или иной мере присутствуют. Для простоты можно считать, что в FBD и LD они присутствуют из тех же соображений.

Наверх
Владимир Е. Зюбин Смотреть выпадающим
Действительный член
Действительный член


Присоединился: 09 Сентябрь 2003
Категория: Russian Federation
Online Status: Offline
Публикации: 247
Свойства публикации Свойства публикации   Ответить, цитируя автора - Владимир Е. Зюбин Ответить, цитируя автора -  ОтветитьОтвет Прямая ссылка на эту публикацию Опубликовано: 30 Сентябрь 2003 09:16
Первоначально опубликовано Доктор Q

Доктор Q: В конце концов, чем функциональный блок хуже ++ в сях? Инкапсуляция - есть, наследование - есть,  полиморфизм - и тот можно сделать при желании


Владимир Е. Зюбин: А утверждения о том, что язык FBD объектно- ориентированный, пардон, смехотворны... С таким же успехом можно утверждать, что ассемблер объектно-ориентирован


Дмитрий Теркель: У меня тоже нет аргументов. Это действительно очевидно, просто неудобно как-то аргументировать :) Никакие они не объектно-ориентированные (хотя это автоматически не значит, что они плохие :)


Доктор Q: Это правильно, что нет аргументов. Поскольку нигде прямым текстом не говорилось, что они таковые. Так показалось В.Зюбину, но, судя по его ответам, он невнимательно читает, так что не стоит за ним повторять. <...>




Ув. Доктор Q, инкапсуляция, наследование и полиморфизм
- это три кита, на которых стоят языки ООП... и если
язык обладает этими тремя свойствами, то он
автоматически объектно-ориентированый... Другое дело,
95% "программистов" не понимают, что стоит за этими
словами и просто повторяют их как заклинания... В приличном обществе
не стоит уподобляться этим "программистам"... засмеют.

Кстати, очень хорошо об этом написано в ОС, "Объектная
философия и футурология"... статья, по-моему,
так называется... Почитайте, весьма полезно. Что касается
наших баранов, то язык FBD не связан ни
с инкапсуляцией, ни с наследованием, ни с
полиморфизмом в их общепринятом понимании...
Это утверждение не нуждается в аргументации, достаточно
понимать, что этими словами обозначается.

Первоначально опубликовано Доктор Q


Дмитрий Теркель: По традиции функциональными языками называют языки, в той или иной степени основанные на лямбда-исчислении Черча.


Является ли следование этой традиции принципиально необходимым условием для зачисления в класс функциональных? <...>




Да.

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

...а тут, в форуме, Вы этим ставите и себя, и окружающих
в неловкое положение.
Владимир Е. Зюбин
Язык Рефлекс -- Си-подобный язык программирования ПЛК
http://reflex-language.narod.ru/
Наверх
Mike_K Смотреть выпадающим
Действительный член
Действительный член


Присоединился: 29 Июль 2003
Категория: Russian Federation
Online Status: Offline
Публикации: 140
Свойства публикации Свойства публикации   Ответить, цитируя автора - Mike_K Ответить, цитируя автора -  ОтветитьОтвет Прямая ссылка на эту публикацию Опубликовано: 30 Сентябрь 2003 11:16
Дмитрий Милосер

При чем тут картинки? Я говорил о ЗАДАЧАХ.

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

Ничего из этого не видно что за задачи и как..., и это даже не интересно, как вы говорите что у вас отклик с дачиков более 200ms. Вагон времени для счета рисования и других обработок, тут нечего практически оптимизировать по части управления. Все очень просто МЭК вам подойдет.

Никто не хочет слышать и соглашаться, а пытается доказать свою исключительность, порою как видно из конфы, не представляя предмет спора, а просто отстаивает то что сам знает не зная или мало представляя задачи, средства апанента.

Давайте жить дружно!

www.sinat.ru
Наверх
 Ответить Ответить Страница  <1 1213141516 53>

Переход на форум Права доступа на форуме Смотреть выпадающим

Bulletin Board Software by Web Wiz Forums® version 9.64
Powered by Web Wiz Forums Free Express Edition
Copyright ©2001-2009 Web Wiz