Все, т.к. многое в статьях правильно представлено.
Но, к сожалению, и рецептов четких нет.
Зачем подмножество Паскаля, если есть Паскаль? Хочешь программируй и так и этак. На "истинно структурном" - только структурно. Ну и будете Вы самый чистый, но единственный в мире программист на специализированном (структурном) языке. "Шаг влево, шаг вправо - попытка к бегству" - так?
Зачем Рефлекс, если уже есть Си? На Си программируют даже школьники.
"Чистота" должна быть не в языке, а в мыслях и в выражении их. А просто, доступно, ясно и надежно можно "мыслить" и на Си. Думать только надо! Прежде всего об этом речь в указанных статьях...

Вступлюсь за Рефлекс... :-)

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

Насчет же структурного программирования и всяких GOTO, считаю, что любая абсолютизация вредна. И желание писать полностью в структурном стиле, и в объектном... Исключения из правил могут позволить упростить описание алгоритма. Это надо использовать с умом.

Подобных "расширений" Си- множество. При этом и язык новый изучать не нужно и возможность работы с процессами есть. К чему еще одно "расширение"? Старых мало?

Расширений Си действительно много:
Си++, Java, Java script, Си-шарп, php, в конце-концов... есть и менее распространенные, знаю, например, верифицирующие расширения Си...
Но диалект Си для класса задач управления один - это язык Рефлекс. ;-)

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

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

Если вы занимаетесь базами данных, или графикой, или WIMP-интерфейсами, или распознаванием образов, пишете трансляторы, занимаетесь созданием Веб-сайтов, работаете системным администратором, то изучать Рефлекс нет необходимости. Если Вы работатете в области пром. автоматизации, но алгоримты простенькие - то же... вас может вполне устроить один из языков МЭК 61131-3... можно и их поизучать (правда, их пять и они совсем непохожи на Си ;-).

"К чему еще одно "расширение"?" - да к тому, что Рефлекс преподносится публике не верно. Отсюда и вопросы такие. Никакое это не расширение С, а совсем другой язык, просто использующий синтаксис подобный С. Ноги растут не оттуда.
Владимир Е. Зюбин в начале ветки писал:
"В основу языка Рефлекс легли идеи, почерпнутые из языков ЯРУС, Си, QuickStep, СПАРМ. Да, до СПАРМ был проходной вариант ЯРУС-П (ЯРУС на Паскале, 1985-86), не оконченный."
И рассматривать Рефлекс надо как развитие этой ветки, и сравнивать его с языками IEC61131, а не С.


Ну, это Вы замахнулись. Есть еще, например, CLL - "Язык программирования алгоритмов логического управления". Это я откопал устаревшее описание, последний вариант использует язык С (асм, тоже никто не отменял).

Кстати, хотелось бы услышать Ваше мнение по CLL (в стиле "найдите 10 отличий")

Думается, все же не стоит ограничивать рассмотрение Рефлекса только сравнительным анализом с МЭК 61131-3, ЯРУС, ЯЛУС, QuickStep, СПАРМ и т.д. При рассмотрении Рефлекса как расширения Си, ортагонального Си++, весьма интересно. Приводит к весьма забавным мыслям и идеям относительно объектно-ориентированного программирования и его составляющих (наследование, инкапсуляция, полиморфизм).
Истина, она же в сравнении познается, не правда ль? ;-) Кстати, на эту тему, в конце прошлого года были публикации (по гиперавтомату), да и в этом уже появились, ну и, надеюсь, еще появятся.



Спасибо за ссылку. Интересно узнать были ли публикации по ЯЛУС, где и когда. И вообще, каким образом Вы на этот язык вышли. Очень интересно.

Что касается 10-ти отличий:
Первое впечатление очень хорошее, радует русскоязычный синтаксис, видно, что проделана очень большая и полезная работа, чувствуется влияние идей ЯРУСа (не только в названии).
Если заменить понятие "программа" на "процесс", а "ситуацию" на "состояние", то ЯЛУС-CLL (текстовая форма ЯЛУС) становится очень похож на СПАРМ.

Конкретнее ремарки по тексту (отличия CLL и Рефлекс, кроме уже упомянутых терминологических отличий):
1. стр. 4. В CLL есть таймерные переменные в Рефлексе их нет (работа со временными интервалами реализуется через оператор ТАЙМАУТ). В терминах переменных - таймерные переменные в Рефлексе описываются неявно и их очень много.

2. стр. 4 В CLL программы могут быть установлены извне в произвольную ситуацию (пустую), включены и выключены, в Рефлексе "пустые" ситуации жестко специфицированы, это два пассивных состояния: состояние нормального останова (СТОП) и состояние останова по ошибке (ОШИБКА), и, соотвественно, извне процесс может быть либо запущен (переведен в начальное состояние оператором СТАРТ), либо остановлен - т.е. переведен либо в состояние СТОП, либо ОШИБКА (операторы СТОП/ОШИБКА). Если кратко - в Рефлексе реализован некий аналог структурного программирования.

3. стр. 5. Похоже, что в CLL предполагается, что параллелизм обеспечивается на уровне ОС, или некоего ядра-супервизора - разделение по времени (отсюда рассуждения о семафорах и т.д., стр.23...), Рефлекс не исключает такой реализации, однако больше ориентирован на кооперативную многопоточность в стиле round-robin (нет проблем с конфликтами доступа).

4. стр. 6. В CLL автоматическая привязка к модулям УСО специфицируется одним числом, в Рефлексе - двумя (исторически это база+смещение). Не принципиально, но может привести к проблемам. В CLL - для привязки переменной следует указывать бит в порту, в Рефлексе - автоматически, по мере перечисления. В некоторых случаях, способ CLL удобнее.

5. В CLL - выход на ассемблер, в Рефлексе выход на Си (ассемблер, только если он предусмотрен целевым транслятором)

6. стр. 6. Про блок-схему я не понял. Сначала говорится, что графика - это одна из версий модели ЯЛУС, при чем тут CLL?

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

8. стр. 7. В CLL встречаются следы Паскаля: оператор "конец". В Рефлексе - Си-шный стиль - тела процессов и сотсояний обрамляются фигурными скобками - {}.

9. в CLL имеются особые операторы (вкл, откл, считать) для работы с переменными, в Рефлексе сохранен "сишный" стиль - операторы =, !=, == и т.д. Небольшое исключение - операторы работы с процессами (СТАРТ/СТОП/ОШИБКА).

10. Похоже, что в CLL отсутствует конструкции типа ЕСЛИ-ТО-ИНАЧЕ, без ИНАЧЕ - тяжело. В СПАРМЕ его не было. Мучались. Кроме этого в Рефлексе и оператор ВЫБОР есть (аналог switch). ну и вообще, в Рефлексе - сишный стиль ЕСЛИ-ИНАЧЕ... скобки, произвольная вложенность и т.д.

11. стр. 8 В CLL переменные глобальные, "видимы из всех программ"... а в Рефлексе - переменные имеют степень доступа и видимости. Можно использовать переменные с одними и теми же именами.

12. стр. 9. В CLL начальное состояние программ специфицируется "вручную" (операторы вкл, выкл), в Рефлексе состояние процессов по запуску специфицировано жестко - активен только начальный процесс, все остальные - пассивны.

13. стр.9-10. В CLL - есть механизм меток, в чем-то альтернативный ситуациям. В Рефлексе этого механизма нет, более того, как уже говорилось, воздействия извне ограничены тремя командами (СТАРТ/СТОП/ОШИБКА).

14. стр. 12, стр. 14 упоминается о кодах времени, спецификации интервалов времени n.m (сек.мс), и длительности цикла. спецификация интервалов - это достаточно удобная вещь, в Рефлексе ее нет (только планируется), а вот о спецификации длительности цикла я ничего не нашел. В Рефлексе - тактируемая цикличность исполнения описывается прямо - оператором спецификации такта - ТАКТ.

15. Не встретилось в описании CLL (может пропустил) упоминание об арифметических операциях типа умножение, деление. По-видимому, ориентация языка CLL в основном на логическое управление, Рефлекс не ограничивает использование Си-операторов, и позволяет описывать те же ПИД-регуляторы, делать другие математические расчеты.

16. Вообще по тексту примеров несколько озадачило присутствие идентификаторов типа _001, _086 (стр.17), и малоинформативных имен программ/ситуаций. Но это скорее по стилистике.

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

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


Можно вставлять любые инструкции С и асм - типа __asm{ .... }


Задается в файле проекта при компоновке.


стр. 6 - "В языке CLL отсутствуют операции с вещественными числами, а также операции с целыми числами, время выполнения которых зависит от значения операндов (например, умножения и деления)." Но, если время выполнения не страшно - можно делать С-шные вставки.


Ну, это просто пример. Так технолог написал - у него так провода на схеме называются ...

В проекте СПАРМ был прокол в идеалогической части, глупая идея отразить смешанный (Мили/Мура) автомат в его классическом виде. В результате - оператор ИНАЧЕ(else) отсутствовал как класс. В сложных проектах при использовании СПАРМ нам постоянно приходилось пользоваться Си-шными вставками. Это ужасно напрягало (хотя была целочисленная арифметика). А в CLL получается, например, что описываются чисто логические алгоритмы, и использовать ПИД-регулятор уже не удается.

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

Ну а насчет времени выполнения - то тут такой аргумент: если уж по алгоритму надо сложить два
целых числа, то от этого не уйти. Все равно надо складывать. А по опыту делать это надо часто. Так что переключения с языка на язык - не очень удобно.

Вопрос такой: где Вы публиковали результаты по CLL? Язык очень интересный, его невозможно игнорировать, и хотелось бы иметь ссылку на статьи по языку. Ну и по ЯЛУС.

Так в документе так и сказано - стр. 6: "Поскольку язык прежде всего, предназначен для программирования алгоритмов логического типа с _фиксированной длительностью цикла_".
В каждой отрасли свои традиции, т.к. тут ПИД-регулятор никому не нужен, про него никто и не думал. CLL создавался для конкретных применений - стр. 1: "СLL (Control Logic Language) был разработан для стендовых систем управления испытаниями ракетно-космической техники".


В CLL такая же фигня - С-шными вставками не пользуются, когда применяют его по-назначению
Тогда получается - одна команда CLL - одна команда процессора (выход на asm, например, для Infineon SAB).


Складывать и вычитать, как раз можно, делить и умножать нельзя.


Во-первых, публиковал не я, т.к. не автор. Во-вторых, наверное, не публиковали. Все, что есть - выложил в этой ветке.

Попалась интересная статья по генерации нативного
кода из байтового представления.
Адрес ссылки для ознакомления
http://www.softcraft.ru/translat/etc/rubst/rubberstack.pdf

P.S. к вопросу способа промежуточного представления программы.

Понятно. А что значит, "с фиксированной длительностью цикла" и почему это несовместимо с операциям умножения?



Вот это-то и вызывает вопросы... Почему?



Очень жаль, очень жаль... результаты действительно инетересные... непонятно, каким образом авторы планируют защищать свои приоритеты? Вернее, непонятно, почему они их не защищают стандартным способом - через публикации? Это что, ноу-хау, или ограничения со стороны первого отдела?
Вроде б под запрет не попадает. Блин! - а других слов нет. Придет какой-нибудь CLL от Сименс, вот и будут потом волосы рвать.

"Публикуйся, а то проиграешь!"
"Работу форсируй, результаты - фиксируй!"

Блин! нужны какие-то очень веские аргументы, чтобы добровольно выключить себя из научного процесса. Я их не вижу... Увы.

Та версия, описание которой я выложил ориентирована на проц. Infineon SAB. У него операции сложения и вычитания - один такт, а умножать и делить он может тока за несколько тактов.
Получается - одна команда CLL - одна машинная команда. Т.о. в среде разработки можно посчитать время выполнения куска кода по командам CLL.


От кого защищаться-то? Плохо помню историю, но, кажется язык создавался в 198х для испытаний двигателей БУРАН-а. И по сей день применяется для испытаний ракетных двигателей. Есть несколько дисеров.

не очень понятно... время операции - такт, а время выборки из ОЗУ/ПЗУ? и почему нельзя посчитать количество тактов на умножение/деление? они же тоже известны.

Но самое главное, непонятно, зачем эти такты считать вообще. Там что, тамера нет?



Защищаться нужно не от кого, а что - приоритеты, авторство. Ну и для научного сообщества польза - не нужно изобретать вилосипед, а можно использовать наработки для продвижения вперед...
вот бы все теорему Пифагора доказывать стали... или теорему Котельникова... где б мы все были?

Информационное сообщение:

Среди статей по языку Рефлекс появилась небольшая статья по математической
модели гиперавтомата, которая лежит в основе языка Рефлекс.
Небольшая критика модели конечного автомата, всякие слова
про процессы, событийный полиморфизм, и т.п.

http://reflex-language.narod.ru/articles/articles.htm

Также по материалам этой ветки форума на сайте был введен раздел с часто-задаваемыми вопросами.
Спасибо Andrew2000, locas, Kopa и всем остальным за вопросы и ценные ремарки.

Вот встретилась информация для размышления.
Автор предлагает некоторый пересмотр технологии создания ПО и вводит парадигму
получившую название языково-ориентированное программирование.

http://www.rsdn.ru/article/philosophy/LOP.xml

P.S. Форт язык всегда был ориентирован на данный подход.
Жаль, что некоторые вещи переоткрываются только сейчас.
По принципу "Новое - это хорошо забытое старое"
Хотя про Форт этого не скажешь