Ответ на »сообщение 2325« (Jack Of Shadows)
___________________________
Конечно, если писать код в стиле Фортрана или Бейсика, то жонглирование состоянием будет в каждой строке. Джек, Вы сами писали, что императивное программирование Вам не нравилось, следовательно, Вы им не занимались серьезно и не занимаетесь.
Нет в современном ИП никакого жонглирования. Есть строгое абстрагирование, построение блоков системы и объединение их по строго определенным интерфейсам и шинам. При этом композиция этих блоков содержит обычно очень мало присваиваний и много функциональных вызовов. Только работаем в технических, а не математических терминах - вот и вся разница.

Ответ на »сообщение 2316« (Сергей Перовский)
___________________________
Отсюда новая постановка вопроса о классификации: как отличить ФЗ и ИЗ?
Я уже потерял всякую надежду что вы поймете Сергей что нет никаких функциональных и императивных задач.
Любая функциональная задача рано или поздно должна что то куда то выводить, то есть в ней есть императивная составляющая. И любая задача содержит в себе алгоритмитескую, вычислительную часть (то есть функциональную)
Можно и ту и другую части делать императивным образом. Хреново, но работает. Главное легко в плане обучения, пятиклашкам в самый раз.
Нельзя и ту и другую часть делать в функциональным образом. Таким образом у вас складывается впечатление что раз нельзя все делать одним образом то и нет смысла вообще об этом говорить.
Но оптимальный вариант как раз и заключается в том чтобы дать вам инструмент в котором вы можете ЯВНО выбрать каким образом какие части вашей задачи вы пишите.
Таким инструментом и являются ФЯ. Вы выбираете Сергей.
В ИЯ у вас такого выбора нет. Там хочеь не хочешь а приходится жонглировать состоянием чуть ли не в каждой строчке.
В ФЯ у вас выбор есть. Никто не отнимает у вас возможность писать императивный код.
Просто добавляется возможность ЯВНО указывать какая часть кода императивна а какая функциональна.

Это оптимум для инженера, и конечно же кошмар для пятиклашек :))

Ответ на »сообщение 2323« (Geniepro)
___________________________

Real Programmers Don't Use Pascal
:o))
Старая басня :-)

Real Programmers Don't Use Pascal
:o))

Ответ на »сообщение 2313« (AVC)

Как мне поступить: добиваться соответствия стандарту Си с помощью компилятора и ценой потери эффективности, или опираться на существующую аппаратуру?


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

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

Реферат про Oberon - http://www.referat.ru/pub/item/22985 + http://www.studik.ru/database/50613

Ответ на »сообщение 2313«
Вы поступили в полном соответствии со стандартом. Размер типа char в С должен равняться 1 байту, а размер байта является машинно-зависимым. Так, во многих компиляторах С для DSP размер char 16 бит.
Однако при этом возникнут проблемы с переносимостью, так как большинство программистов, пишущих "переносимые" программы на "стандартном С", стандарта из 800 страниц не читали, а переносимость в С сама-собой не возникает.
Причем для проверки переносимости программы нужно протестировать ее на всех поддерживаемых платформах.
С другой стороны, в обероне модуль не импортирующий system должен быть гарантировано переносимым. Жаль только, что реализаций оберона для платформ, отличных от PC мало. Вот и приходится ковыряться в сишных "крючках", так как для встроенных систем переносимость ПО с одной платформы на другую жизненно необходима.

Ответ на »сообщение 2317« (info21)
___________________________

Ну почему же. Есть (в ББ) замечательная функция Math.Eps() -- помогает.

Хорошо бы еще пользоваться Math.Eps() (машинный эпсилон, DBL_EPSILON в Си) не на основе туманных предположений.
К примеру, на одном микропроцессоре функция вычисления квадратного корня не сходится, и разница между значениями, полученными на двух соседних итерациях, в этом случае всегда превышает машинный эпсилон.
В цитированной мной раньше книге по астрономическим вычислениям немецкие астрономы неизменно выбирали значение эпсилон = 100 * Math.Eps() (если перевести с Си++ на КП).
Почему именно 100?
Почему "Ы"? (c)

Ответ на »сообщение 2311« (Lisp Hobbyist)
___________________________

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

Ну почему же. Есть (в ББ) замечательная функция Math.Eps() -- помогает.
Вспомните (или выучите) математику.
Пишите неравенства.
Никакой мистики.

Точное знание деталей любого стандарта IEEE для формата с плав. точкой поможет мало.
А вот умение писать неравенства -- поможет сильно.