[Kopa 0]

Не умоляя достоинств С программирования, в очередной раз попалась ссылка

на применение Форта для решения задач автоматизации http://www.forth.org.ru/~st/

( j,jheljdfybz на хлебокомбинате.)

 

Хотелось бы услышать мнение по этому поводу:) почему так происходит.

 

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

 

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

Что и не мудрено. К тому же форт такой же процедурный язык, как и другие.

 

Для меня и не только, при кажущемся неудобстве и простоте синтаксиса, сравнимом

с ассемблером, Форт остается мощнейшим из созданных языков программирования

со своей парадигмой разработки программ.

Познакомится с языком можно по изданной литературе ( начав с рускоязычного ресурса forth.org.ru ).

C середины 90х годов в России литература по данному языку не издавалась.

 

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

средство автоматизации планировщика nncron ( nncron.ru) на PC . На нем также написан мультисервер

eserv ( eserv.ru). Частично, как скриптовый язык он один из реальных участников процессов

автоматизации производства.

 

Идеалогия данного языка строится на принципах открытости архитектуры языка и реализации.

Все внутренние механизмы реализации доступны программисту и могут изменяться по необходимости.

Основу языка составляет механизм саморасширения в нужную проблемную область.

( механизмы расширения языка разные от базовой конструкции определяющих слов,

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

ручному управлению поддержки компиляции и др. Упрвляющие конструкции могут вводится, при

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

В системе есть, как минимум два стека. Первый стек - данных, служит для места расположения

обрабатываемых параметров. Второй стек - управления, для хранения адресов вызова процедур

и при необходимости изменения потока управления. Оба стека программно доступны и имеют

некоторые слова по монипулированию параметрами на стеке. Переменные могут определяться

глобально. В стандарте 94г. ввели в описании процедуры возможность применения именованных

локальных переменных. Все слова в системе организуются в виде связанных списков слов.

при этом имеется возможность управлять контекстом поиска нужного слова при компиляции и

куда его помещать.

 

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

Стандартным компонентом языка для передачи параметров является стек. Стек также

является вычислительным устройством языка. ( Например типичное сложение с участием

стека можно выразить так 5 4 + результат останется на стеке заменив числа 5 и 4 )

Введение скобочной записи не представляет сложности. Типов данных как таковых

в языке почти нет ( char , int , double int, float ). Типы данных никак не определяются.

Для Char и int при арифметических операциях выделяется одна ячейка стека ( в зависимости от разрядности системы) для double 2-e ячейки. Float заносится на свой стек данных.

Операции над числами одинарной или двойной длины отличаются добавочным признаком в слове.( т.е. в зависимости от требуемого действия выбирается соответствующее слово).

Слово никак не контролирует обрабатываемые параметры на стеке. Для безнакового сравнения есть свое слово. В языке отсутствуе механизм меток.

 

В двух словах примерно так, думаю основное для понимания представил.

Такое вот это чудо при первом рассмотрении. Находит как сторонников так и критиков.

Про стратегию управления не совсем понял.

Хочется адекватных возможностей в классических языках.

 

Фирма kaskod.ru в части своих изделий встраивает Форт в качестве стандартного

средства программирования. Есть процессоры и контроллеры с аппаратной поддержкой

стековой модели вычислений, есть смешанные. Много чего еще по данной тематике наработали.

Примеры тут приводить, пока, не имеет смысла. Многие специалисты даже и не знают

о существовании и возможностях данного языка. А часть может думать, что это сокращение

от Фортрана.:)

[Kopa 0]

Вот еще одна интересная ссылка по затронутой мной теме автоматизации

 

http://raps-technol.narod.ru/

 

АВТОМАТИЗАЦИЯ ПО-РУССКИ

Распределенная Аппаратно-Программная Среда ("РАПС") - новый подход к построению АСУ промышленного и бытового назначения.

[Владимир Е. Зюбин 0]

Сразу должен сказать, спасибо Вам, Andrew2000, за эти вопросы. Глубоко копнули.

А на хорошие вопросы всегда приятно отвечать.

 

В документации сказано:

1. "2.5.4 Адрес регистра в модуле IO может быть в диапазоне от 0 до 2;"

Какой в этом смысл, если

"2.5.5 Адрес модуля IO может быть в диапазоне от 0 до 0xFFFFF"

Большое спасибо за замечание! Это проблема документа, который писался в пакете и во взаимоувязке

с конкретной системой и конкретной библиотекой. На самом деле, это описывается интерпретация параметров для конкретной платформы (MicroPC+УСО UNIO): УСО типа UNIO просто сидят на XT магистрали и имеют три регистра, что относится к платформе, а не к транслятору языку.

Транслятор языка проверяет только то, что это число (числовая константа). Ну и подставляет эти числа как параметры при вызове функции считывания (записи) значений в IO-модули.

 

Разумеется, что функции считывания (записи), которые привязаны к платформе и описываемые отдельно при портировании, могут интерпретировать эти числа как угодно, например, как некий адрес в ОЗУ.

 

Спасибо за замечание. Это моя вина, надо было внимательно просмотреть описание, перед публикацией. Файл подкорректировал и обновил на сервере.

 

2. "2.6.8 Возможны процессы, использующие пересекающиеся множества входных и выходных переменных."

Кто последним установит выход, т.е. как определяется последовательность выпонения процессов?

Строго говоря, эта ситуация действительно неопределена - процессы параллельны, и, возможно, даже исполняются на разных процессорах.

 

Хотя конкретные реализации языка могут фиксировать последовательность выполнения, например, задаваемую порядком описания (что естественно). Т.е. в каждом конкретном цикле последовательность выполнения процессов определяется порядком их описания в программе.

 

Использовать эту информацию, строго говоря, некорректно. Мы, по крайней мере, не используем.

 

3. "2.7 - в состояниях нет возможности организации циклов и переходов"

Не совсем ясен смысл - 'for' и 'while' отсутствуют, или нет перехода сам в себя?

Да. Конструкции типа for и while в языке отсутствуют.

Вызвано это идеологическими причинами: в языке нет "естественной"

возможности глобально "завалить" программу.

 

Ну а если очень хочется, то конечно же, можно. И несколько вариантов, на выбор:

на двух состояниях, с помощью инлайн подстановки Си-кода, с помощью

выносной Си-функции. Первый вариант - самый безопасный. Последний - наименее

удобный.

 

4. "2.11.5 Описание программы начинается с резервированного слова "Прогр""

А как задается точка входа (типа 'main')? Или нет главного процесса - все процессы стартуют вместе?

Главный процесс - описанный первым. С него и начинается раскрутка алгоритма.

По включению питания (по запуску). Все процессы, кроме описанного первым, находятся в пассивном состоянии.

 

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

 

5. 'ТАКТ' един для всех процессов или каждому процессу можно назначить свой 'ТАКТ'?

В текущем варианте языка - ТАКТ один для всех. Проработан вариант изменения синтаксиса в этом направлении, но по реальной надобности пока не ощущается.

 

Кстати, даже и вариант реализаций проработан - очень простая и мощная идея распределения процессорной загрузки для реализаций типа round-robin, кооперативной многозадачности. Идея делителя базового такта для отдельных процессов.

 

Если интересно, то этот вопрос обсуждается тут:

Зюбин В.Е., Петухов А.Д. Распределение вычислительных ресурсов с многопоточной реализацией гиперавтомата // Труды III Международной конференции <Идентификация систем и задачи управления> SICPRO '04. Москва 28-30 января 2004 г. С. 446-463 (pdf 366Kb).

[Владимир Е. Зюбин 0]

попалась ссылка на применение Форта для решения задач автоматизации ...

Хотелось бы услышать мнение по этому поводу:) почему так происходит.

 

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

 

<...>Про стратегию управления не совсем понял.

 

Ну вот например, есть классическая задача из области автоматического управления:

http://reflex-language.narod.ru/bottle/spec_bottle.htm . Для нее имеется целый ряд решений для разных языков. На сайте - решение для Рефлекса (грубо): выделяется пять процессов, запускатеся, так-то функционируют, приведен текст программы и описание. Известно как эта задача решается на всяких DECN-ах и т.п.

см. например, http://reflex.freebox.ru/pub/98glang.pdf.

Все по разному. А как это сделать на ФОРТе? Непонятно.

 

В этом и вопрос про стратегию.

[Kopa 0]

 

<...>Про стратегию управления не совсем понял.

 

Ну вот например, есть классическая задача из области автоматического управления:

http://reflex-language.narod.ru/bottle/spec_bottle.htm . Для нее имеется целый ряд решений для разных языков. На сайте - решение для Рефлекса (грубо): выделяется пять процессов, запускатеся, так-то функционируют, приведен текст программы и описание. Известно как эта задача решается на всяких DECN-ах и т.п.

см. например, http://reflex.freebox.ru/pub/98glang.pdf.

Все по разному. А как это сделать на ФОРТе? Непонятно.

 

В этом и вопрос про стратегию.

Сделать, на Форте можно , как я понял необходим планировщик параллельных процессов.

 

1. Также как пишутся ОС на Си с ассемблернными вставками.

2. Переопределив уровень управления рантайм средой на свои процедуры.

И создав необходимый уровень реализации, при этом и изменив синтаксис и семантику

наполнения. При этом программа может выглядеть, как на языке Рефлекс ( например).

В процессе компиляции будут создаваться требуемые структуры для работы программы.

 

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

коду придется прорабатывать отдельно ( поправьте если ошибаюсь.) для целевой

платформы.

Изменено 16 мая, 2006 пользователем Kopa

[Andrew2000 0]

Хотя конкретные реализации языка могут фиксировать последовательность выполнения, например, задаваемую порядком описания (что естественно). Т.е. в каждом конкретном цикле последовательность выполнения процессов определяется порядком их описания в программе.

Использовать эту информацию, строго говоря, некорректно. Мы, по крайней мере, не используем.

А ISaGRAF и CoDeSys, например, используют. Как раз "некорректно" будет, если я (пользователь) не знаю, что там внутри творится.

Запишем в минусы текущей реализации.

 

Да. Конструкции типа for и while в языке отсутствуют.

Вызвано это идеологическими причинами: в языке нет "естественной"

возможности глобально "завалить" программу.

Ну, на двух состояниях я ее также "завалю".

 

И еще забыл спросить - что выполняется за такт?

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

 

Спасибо за ответы

[Владимир Е. Зюбин 0]

 

<...>Про стратегию управления не совсем понял.

 

Ну вот например, есть классическая задача из области автоматического управления:

http://reflex-language.narod.ru/bottle/spec_bottle.htm . Для нее имеется целый ряд решений для разных языков. На сайте - решение для Рефлекса (грубо): выделяется пять процессов, запускатеся, так-то функционируют, приведен текст программы и описание. Известно как эта задача решается на всяких DECN-ах и т.п.

см. например, http://reflex.freebox.ru/pub/98glang.pdf.

Все по разному. А как это сделать на ФОРТе? Непонятно.

 

В этом и вопрос про стратегию.

Сделать, на Форте можно , как я понял необходим планировщик параллельных процессов.

 

1. Также как пишутся ОС на Си с ассемблернными вставками.

2. Переопределив уровень управления рантайм средой на свои процедуры.

И создав необходимый уровень реализации, при этом и изменив синтаксис и семантику

наполнения. При этом программа может выглядеть, как на языке Рефлекс ( например).

В процессе компиляции будут создаваться требуемые структуры для работы программы.

 

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

коду придется прорабатывать отдельно ( поправьте если ошибаюсь.) для целевой

платформы.

 

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

 

Проблемы тут видятся такие:

1. Дополнительный объем работы (нужно разработать стратегию управления)

2. Неустойчивость решения (разработанная стратегия находится вне языка, а, значит, нужна некая

дисциплина разработки, культура, квалификация)

3. Возможны проблемы с надежностью (пониженная надежность), т.к. разработанная стратегия

наверняка будет иметь и свою семантику, которую невозможно будет проконтролировать на уровне

базового транслятора. Не знаю, насколько это понятно... Попробую пример привести.

Скажем есть т.н. switch-технология, которая базируется на известной реализации автомата на Си, когда состояния автомата кодируются числами (0, 1, 2, 3...), которые хранятся в выделенной ячейке памяти - глобальной переменной: z1 (для автомата №1), z2 (для автомата №2), и т.д. Так вот. Скажем, кодируемый автомат #4 имеет три состояния. И чтобы перевести этот автомат в третье состояние надо на Си просто написать

z4 = 3;

куда казалось бы проще, да только транслятору Си никак не пояснить, что значение z4 не может быть больше трех. И с таким же успехом можно написать и

z=125;

Можно придумывать всякие ухищрения, но все они будут далеки от оптимального решения - проверки на уровне семантики, автоматической и проводимой до этапа исполнения. Надо просто подсчитать число состояний в автомате №4 и контролирвоать. Но в Си нет такого понятия как "состояние". Это трагедия.

Не знаю, насколько расширяем в этом смысле ФОРТ.

 

Если и можно привести ФОРТ к уровню семантики Рефлекса (реально, гиперавтомата) то это было бы здорово, но это дополнительная работа, которую кто-то должен проделать (ведь людям надо программировать алгоритмы, а не модифицировать ФОРТ). Ну и результат будет неустойчив.

 

====

 

Что касается уровня "рантайма" Рефлекса:

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

 

Так вот. В доступной на сегодняшний день реализации, действительно, настройка на конкретную платформу осуществляется отдельно, возможно, производителем контроллера или даже пользователем.

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

 

Эта работа по портированию проводится в любом варианте, для любого средства, просто обычно это делается разработчиком программного средства или OEM-ом, нужно покупать всякие Development Kit-ы и т.д. и т.п., а обсуждаемой реализации языка Рефлекс все максимально открыто - и адаптацию к платформе может сделать любой пользователь. И это очень удобно для производителей, выпускающих небольшие партии контроллеров, вплоть до единичных экземпляров.

 

Это ни в коем случае не исключает появление других подходов на базе языка Рефлекс.

[Kopa 0]

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

 

Проблемы тут видятся такие:

1. Дополнительный объем работы (нужно разработать стратегию управления)

2. Неустойчивость решения (разработанная стратегия находится вне языка, а, значит, нужна некая

дисциплина разработки, культура, квалификация)

3. Возможны проблемы с надежностью (пониженная надежность), т.к. разработанная стратегия

наверняка будет иметь и свою семантику, которую невозможно будет проконтролировать на уровне

базового транслятора. Не знаю, насколько это понятно... Не знаю, насколько расширяем в этом смысле ФОРТ.

 

Если и можно привести ФОРТ к уровню семантики Рефлекса (реально, гиперавтомата) то это было бы здорово, но это дополнительная работа, которую кто-то должен проделать (ведь людям надо программировать алгоритмы, а не модифицировать ФОРТ). Ну и результат будет неустойчив.

 

====

 

Разрабатывать стратегию управления придется, если не брать стандартные решения.

Решение будет находится в рамках Форт языка.

Автоматы на Форт языке пишутся легче, чем с использованием других языков ( Примеры тоже есть)

В плане понимания возможносей языка полезно прочитать "Thing Forth" Броуди

( неизданная в печатном виде книга, полезна всем кто занимается разработкой программ)

есть русский перевод Дмитриева.

 

Разработаны включения синтаксиса Си языка в Форт систему. ( в виде приинклюдивания

файла с расширением ).

 

 

Недостатки Си языка в приложении к контроллерам мне хорошо видны, т.к. приходится

его использовать. Рефлекс в этом плане закрывает некоторый пробел.

Не думали вместо Си использовать Javу?

[Владимир Е. Зюбин 0]

Хотя конкретные реализации языка могут фиксировать последовательность выполнения, например, задаваемую порядком описания (что естественно). Т.е. в каждом конкретном цикле последовательность выполнения процессов определяется порядком их описания в программе.

Использовать эту информацию, строго говоря, некорректно. Мы, по крайней мере, не используем.

А ISaGRAF и CoDeSys, например, используют. Как раз "некорректно" будет, если я (пользователь) не знаю, что там внутри твориться.

Запишем в минусы текущей реализации.

 

Ну, наверное, все же не ISaGRAF использует, а пользователи ISaGRAF-а. И тут видится нехороший момент: в стандарте МЭК-61131-3, насколько я знаю, это не прописано. Также и документации на ISaGRAF я этих вещей не припомню. Хотя, действительно, порядок определен. Но использование этой информации - это область трюков, усложняющих программу.

 

К примеру, Вы написали работающую программу на FBD, а завтра кто-нибудь просто

переформатирует программу, для лучшего эстетического восприятия, и она перестанет работать.

 

В связи с этим повторюсь:

При программировании на Рефлексе тоже можно использовать информацию о реализации. Но приводит к усложнению сопровождения программы (снижение читаемости, понимаемости, модифицируемости и т.д.) и снижение ее надежности. Поэтому конкретно мы, сами не используем такие трюки, ну и другим не советуем. Но информация о реализации доступна: можно, что уровень Си-посмотреть, что так могу сказать: последовательность исполнения определена порядком описания.

 

Да. Конструкции типа for и while в языке отсутствуют.

Вызвано это идеологическими причинами: в языке нет "естественной"

возможности глобально "завалить" программу.

Ну, на двух состояниях я ее также "завалю".

 

Ну, вроде как, не получается. "Завалить" программу локальными операциями языка Рефлекс невозможно (вроде б). Можно либо выходя в Си, либо глобальными операциями типа

остановить все процессы, а потом остановить и себя.

 

И еще забыл спросить - что выполняется за такт?

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

 

За такт выполняется стандартный набор действий "ввод-обработка-вывод".

Насчет операторов перехода - вопрос глубокий и серьезный. Прям в точку.

Если честно, то ситуация у нас получилась такая: алгоритм обработки может настроить пользователь, через библиотеки. Такая вот петрушка.

 

Ну а вообще. Исторически, в одной из первых реализаций для платформы х86+VME, была реализован

алгоритм такой: операторы смены состояния вступали в действие только по окончанию такта.

А потом поработали с этим, поработали, да и отказались. Смысла нуль. Так что в текущих системных библиотеках оператор смены состояния вступает в действие сразу. Как встретился, так и отработал.

 

Ну, а если привязывать этот вопрос к предыдущему Вашему вопросу о порядке исполнения, то в типовом варианте оператор смены состояния вступает в силу:

а) для уже обработанных (и текущего) процессов только на следующем такте,

б) для еще необработанных - уже на этом.

 

Ну а в общем, дело вкуса.

[Владимир Е. Зюбин 0]

 

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

 

Проблемы тут видятся такие:

1. Дополнительный объем работы (нужно разработать стратегию управления)

2. Неустойчивость решения (разработанная стратегия находится вне языка, а, значит, нужна некая

дисциплина разработки, культура, квалификация)

3. Возможны проблемы с надежностью (пониженная надежность), т.к. разработанная стратегия

наверняка будет иметь и свою семантику, которую невозможно будет проконтролировать на уровне

базового транслятора. Не знаю, насколько это понятно... Не знаю, насколько расширяем в этом смысле ФОРТ.

 

Если и можно привести ФОРТ к уровню семантики Рефлекса (реально, гиперавтомата) то это было бы здорово, но это дополнительная работа, которую кто-то должен проделать (ведь людям надо программировать алгоритмы, а не модифицировать ФОРТ). Ну и результат будет неустойчив.

 

====

 

Разрабатывать стратегию управления придется, если не брать стандартные решения.

Решение будет находится в рамках Форт языка.

Автоматы на Форт языке пишутся легче, чем с использованием других языков ( Примеры тоже есть)

 

Было бы интересно взглянуть на внятные примеры или статью на эту тему.

 

Недостатки Си языка в приложении к контроллерам мне хорошо видны, т.к. приходится

его использовать. Рефлекс в этом плане закрывает некоторый пробел.

Не думали вместо Си использовать Javу?

 

Мне все-таки думается, что Си-язык используют не из-за его недостатков, а из-за его достоинств:

а) распространен, известен

б) первый платформонезависимый язык, что появляется на новой платформе

в) эффективен

 

Наверное вместо Си можно использовать и Яву, минусы: Ява менее распространена и более ресурсоемка. Но в принципе, почему бы и нет. Если кому-то это нужно, можно даже и посодействовать.

[Kopa 0]

 

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

 

 

 

Разрабатывать стратегию управления придется, если не брать стандартные решения.

Решение будет находится в рамках Форт языка.

Автоматы на Форт языке пишутся легче, чем с использованием других языков ( Примеры тоже есть)

...

Было бы интересно взглянуть на внятные примеры или статью на эту тему.

 

 

Наугад загуглил Форт Автоматы состояний и вот первая из ссылок на странице:

 

http://is.ifmo.ru/books/switch/2

 

в Приложение 9. Использование языка "Форт" при реализации автоматов

 

или вот из обсуждения проги для генерации С кода для автомата состояний (http://fsme.sf.net )

...

Самая изящная реализация КА, которую я видел -- непосредственное исполнение Форт-системой таблицы состояний автомата. Описано в Computers in Physics где-то в начале 90-ых, ксерокопию статьи можно взять в ftp://gleb.iao.ru/archive/archive/Info/Ar...orth(CiPh).djvu

 

Дальше не стал приводить...

Если пошире поискать, то найдется еще.:)

Изменено 18 мая, 2006 пользователем Kopa

[Владимир Е. Зюбин 0]

Разрабатывать стратегию управления придется, если не брать стандартные решения.

Решение будет находится в рамках Форт языка.

Автоматы на Форт языке пишутся легче, чем с использованием других языков ( Примеры тоже есть)

...

Было бы интересно взглянуть на внятные примеры или статью на эту тему.

 

Наугад загуглил Форт Автоматы состояний и вот первая из ссылок на странице:

http://is.ifmo.ru/books/switch/2

в Приложение 9. Использование языка "Форт" при реализации автоматов

 

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

 

или вот из обсуждения проги для генерации С кода для автомата состояний (http://fsme.sf.net )

...

Самая изящная реализация КА, которую я видел -- непосредственное исполнение Форт-системой таблицы состояний автомата. Описано в Computers in Physics где-то в начале 90-ых, ксерокопию статьи можно взять в ftp://gleb.iao.ru/archive/archive/Info/Ar...orth(CiPh).djvu

 

Дальше не стал приводить...

Если пошире поискать, то найдется еще.:)

 

Я не сомневаюсь, что на форте реализация автомата может быть выполнена самым изящным образом, хотя статьи скачать не смог.

 

Но вопрос не в реализации, как мне это видится, а в представлении для программиста и удобстве программирования. Реализация тут все-таки вторична.

[Kopa 0]

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

 

Я не сомневаюсь, что на форте реализация автомата может быть выполнена самым изящным образом, хотя статьи скачать не смог.

 

Но вопрос не в реализации, как мне это видится, а в представлении для программиста и удобстве программирования. Реализация тут все-таки вторична.

 

Не вступая в полемику можно сказать следующее:

1. Чуждая семантика для тех, кто привык к одной форме выражения программы.

Гибкость синтаксиса языка напрямую зависит от фиксированности структуры языка.

Если структура минимально фиксированна, то выразительная гибкость возрастает.

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

возможности в языке, а не простым действием создав их. Соответственно диапазон

возможных решений сокращается из-за ограничений языка.

 

2. Надежность должна, в моем понимании, обеспечиваться системой тестов, а не

попыткой визуально верифицировать код. Технологические вещи не обязательно

должны привычно выглядеть, но всегда давать хорошее решение при минимальных

затратах.

 

Действительно со сложившимися стереотипами приходится считаться, но если

при развитии язык не вбирает лучшее из других языков, то зачем мне такой язык?!:)

 

P.S. Некоторые прописные истины не грех лишний раз повторить.

[Владимир Е. Зюбин 0]

 

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

 

Я не сомневаюсь, что на форте реализация автомата может быть выполнена самым изящным образом, хотя статьи скачать не смог.

 

Но вопрос не в реализации, как мне это видится, а в представлении для программиста и удобстве программирования. Реализация тут все-таки вторична.

 

Не вступая в полемику можно сказать следующее:

1. Чуждая семантика для тех, кто привык к одной форме выражения программы.

Гибкость синтаксиса языка напрямую зависит от фиксированности структуры языка.

Если структура минимально фиксированна, то выразительная гибкость возрастает.

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

возможности в языке, а не простым действием создав их. Соответственно диапазон

возможных решений сокращается из-за ограничений языка.

 

Про семантику я заговорил, имея ввиду возможность создания своей семантики.

например программируя на ассемблере, невозможно ввести концепты типа "структура", "выражение".

Программируя на Си невозможно создать концепт "класс", "объект". Их можно только реализовать, ручками, рутинно, с кучей ошибок. Также средствами Си++ невозможно создать концепт "процесс".

Можно только реализовать. Я об этом говорю.

 

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

 

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

Ассемблер - это абсолютная гибкость и эффективность, Си - это потеря эффективности, потеря связи с платформой, но и платформонезависимость, переносимость, Си++ - ориентация на WIMP-интерфейсы, Фортран - инженерные расчеты, Паскаль - обучение структурному программированию... Ada - надежность комплексных проектов, и т.д. и т.п.

 

2. Надежность должна, в моем понимании, обеспечиваться системой тестов, а не

попыткой визуально верифицировать код. Технологические вещи не обязательно

должны привычно выглядеть, но всегда давать хорошее решение при минимальных

затратах.

 

Тестирование - это действительно один из подходов, не самый плохой. Но и не без недостатков.

ЧТо плохого, если сам язык содействует созданию надежных программ? По моему, так это здорово.

 

Действительно со сложившимися стереотипами приходится считаться, но если

при развитии язык не вбирает лучшее из других языков, то зачем мне такой язык?!:)

 

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

 

А попытки собрать "лучшее" в одном языке были: это язык Алгол... Ау-у-у-у! Алгол, где ты?

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

[Kopa 0]

А попытки собрать "лучшее" в одном языке были: это язык Алгол... Ау-у-у-у! Алгол, где ты?

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

Немного информации.

 

http://www.chipinfo.ru/literature/chipnews/200303/7.html

 

В данной статье про ДССП высказано следующее мнение:

 

Кроме того, наше программное обеспечение построено на западных операционных системах (ОС) и языках программирования, не защищено от взлома, вскрытия, то есть не соблюдается элементарная информационная безопасность. Выход из тупика - в использовании отечественных технологий. Примером такой технологии является ДССП и язык РАЯ (МГУ, Брусенцов Н.П.). РАЯ — единственный в мире истинно структурированный язык: Паскаль позволяет писать структурированные программы, а РАЯ - не разрешает писать неструктурированные программы. Разработка ПО в ДССП ведётся снизу-вверх, что обеспечивает надёжную верификацию программного продукта. Сегодня переход на отечественные программные технологии нереален, но когда-то нужно опомниться

 

Дает почву для размышлений и следующий диспут.

 

http://www.arbinada.com/_resources/misc/sedov_dispute.html

 

P.S. Что в разработке программ не так:)

Изменено 24 мая, 2006 пользователем Kopa