Ответ на »сообщение 3435« (AVC)
___________________________
Не понял. Какое отношение имеет присваивание к отсутствию или наличию модульности ?

Чо касается SICP то вы опять путаете проблемы конкретной реализации с проблемами подхода.
SICP написан на схеме. А в схеме (как и в лиспе) специально убран ВООБЩЕ какой бы то ни было механизм модульности. Просто потому что лисп это прото-язык. И приваривать к нему намертво в стандарт такие ЧАСТНЫЕ механизмы как модульность (которая может быть реализована множеством разных способов) или ООП (которое тоже может быть совершенно разным от Smalltalk, до java и оберона) создатели языка считали (и правильно) ненужным.

В лиспе нет модульности, и поэтому в лиспе есть ЛЮБАЯ модульность которую вы сами реализуете.
Например я пользуюсь модульной системой asdf (наиболее популярная на сегодня).
В стандарт лиспа правда таки включили ОО (CLOS), но вот например в схеме ООП нет. Зато есть куча разных реализаций ООП, с теми или иными свойствами.
Вообще брать лисп (прото-язык) для какой либо аргументации по типу вот есть чего то или нет, неправомочно.
Берите обычный ФЯ, без магии метапрограммирования.
Например ocaml или хаскель.
Вот там и реализация стандартной модульная системы мощная. С ней и сравнивайте.

Ответ на »сообщение 3434« (Илья Ермаков)
___________________________

Ответ на »сообщение 3433« (Jack Of Shadows)
___________________________

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


Естественно. Вопрос в том - поменять в статике или поменять в динамике.

А так ли это естественно?
Когда в SICP вводится присваивание, речь идет вовсе не о динамике, а о недостаточной модульности чистого ФП (а что такое "нечистое" ФП? :) ) в общем.

Ответ на »сообщение 3433« (Jack Of Shadows)
___________________________

Ответ на »сообщение 3432« (Илья Ермаков)
___________________________
Это значит что любую функцию можно поменять на другую, без последствий для вызывающих функций, поскольку нет побочных эффектов.

Естественно. Вопрос в том - поменять в статике или поменять в динамике.
Для перестройки "на лету" у ФП есть только один (старый, добрый, весьма мощный) способ - метапрограммирование, самомодифицирующийся код. Но это вотчина LISP, а никак не Haskell. В Haskell путь один - динамически регенерировать исходный код и перезагружать его...
Беря "железные" аналогии, ФП сегодня - это схемотехника отдельных блоков, но пока не инженерия модульных систем... Никто не спорит, что модульность и ФП - вещи совместимые. Я про это несколько раз писал... Нужен всего лишь механизм динамической коммутации модулей, а он может быть и декларативным. Но это еще нужно сделать, а ФП-исты в большей части равнодушны к инженерии, все больше "высокой математикой" балуются :-) Одни сферические кони в вакууме... :-)

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

Ответ на »сообщение 3432« (Илья Ермаков)
___________________________
Таковы возможности модульных архитектур.
Ну вот видите, а сами катите бочку на хаскель. :))
Таковы возможности функциональных архитектур. Потому что чистые функции это те же модули, с жесткими интерфейсами, результат работы которых зависит только от входных параметров.
Это значит что любую функцию можно поменять на другую, без последствий для вызывающих функций, поскольку нет побочных эффектов.

Ответ на »сообщение 3431« (Jack Of Shadows)
___________________________

Ответ на »сообщение 3429« (Илья Ермаков)
А вот в оберон наоборот. Если вам вместо OlimpIn придется использовать более эффективный механизм чтения с файлов, то он просочится в вашу логику верхнего уровня.

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

Ответ на »сообщение 3429« (Илья Ермаков)
___________________________
Какие шаманства Илья ? GeniPro ошибся в своей оценке (может потому что не пробовал ByteSTring)
По интерфейсу он точно такой же как и обычный String, то есть программа не меняется совершенно.
Меняется только низкоуровневой код чтения с файла.

Это как раз показывает насколько ФП позволяет абстрагироваться от низкоуровневых проблем и решить их на месте, не загрязняя верхние уровни абстракции.

А вот в оберон наоборот. Если вам вместо OlimpIn придется использовать более эффективный механизм чтения с файлов, то он просочится в вашу логику верхнего уровня.

Ответ на »сообщение 3427« (Сергей Перовский)
___________________________
Это такой прикол или у Вас материалы есть?
В Альтаир 8800 не 8086 стоял...
А так я вам все адреса, пароли и явки и дал! :о)

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


При этом программа на КП заняла около четверти гигабайта оперативной памяти, тогда как хаскеллевская - в сто раз меньше. Очевидно, программа Ильи полностью зачитала входной файл в память, что приводит к весьма плохим последствиям при обработке файла с размером, раза в два меньшим объёма ОЗУ копьютера, - начинается ужаснейшая подкачка виртуальной памяти операционной системы, что снижает скорость работы программы в сотни, если не тысячи раз. Тогда как программа на Хаскелле преспокойно обрабатывает файл любого размера, заняв всего 3 мегабайта в ОЗУ...

Это особенность OlimpIn... Его я использовал для большей простоты/наглядности. Этот модуль при открытии файла целиком поднимает его в память. Если читать через Files/Stores, то такого не будет.

{Quote]Если переделать программы с использованием типа ByteString, то скорость её работы должна будет подняться в несколько раз и она догонит по быстродействию программу на КП. Правда, при этом мы рискуем усложнить программу, сделать её менее наглядной...
В том-то и беда - у меня есть простор для оптимизации без серьезного усложнения кода, у
Вас - нет... ФП - это как машина с автоматической коробкой скоростей. На гладкой трассе все нормально, на сложных дорогах начинаются пробуксовки... При этом Вы не имеете возможности явно взять управление в руки, у Вас есть только набор "шаманств", которыми вы можете намекнуть автоматике выполнять процесс так или иначе... Надеясь, что автоматика верно поймет намек...
При этом, подчеркну - что Оберон в сравнении с ФП - это не ручная коробка передач (не Фортаны с Сями и иже там с ними), а дорогая, профессиональная коробка, которая позволяет как отдать управление автоматике в гладкие моменты, так и принять его на себя в трудных ситуациях... Но принять на достаточно высоком уровне, не опускаясь до перещелкивания каждой шестеренки, как в тех же цях...

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

... как, ВСЕГДА проигрывая на всех ОФИЦИАЛЬНЫХ конкурсах и тендерах, МС удавалось оказываться с заказами (от той же IBM)...

Ну известно же, что менеджер IBM, подписавший *тот самый* контракт с МС, прежде чем поставить подпись, спросил: "А! Так это сын Мелинды Гейтс?" которая имела какое-то сотрудничество с IBM по юридической линии.

Ответ на »сообщение 3424« (Н)
___________________________
>>>Билли со товарищи подрядилсь интерпретатор писать, а бабки проели.
Это такой прикол или у Вас материалы есть?
При всей нелюбви к политике и продуктам MS, придется признать что Basic4K для 8086 написан лично БГ с помощью эмулятора, написанного Аленом. Ведь у них было только описание команд - самого процессора они в глаза не видели. Соответственно и ассемблера не было.
Это к дискуссии об американской тупости.
Вопрос не в способностях, а в целевых установках. Европейская наука начиналась как хобби состоятельных людей. И никоим образом не рассматривалась как источник дохода. Это был способ увековечить имя, а это требывало тщательности и ответственности. Не дай бог сделаться посмешищем. Мы еще несем в себе эту культуру: научный результат и доброе имя важнее прибыли.
Я не хочу делить по географическому признаку, в США безусловно есть представители старой научной школы.
Просто именно в США больше всего комерциализированной науки и технологии, где качество легко приносится в жертву необходимости первыми успеть на рынок.