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


Вот тогда императивщикам придется туго. Надо будет переучиваться :))

у "императивщиков" для решения проблем, в частности, параллельного программирования и свой арсенал есть. Увы, мейнстрим не поднимается в абстрагировании выше уровня семафоров/критических секций/потоков - но это уже проблемы мейнстрима...
В паскалевском семействе та же Ada еще в 80-м предоставила превосходные, встроенные в язык средства параллельного программирования, и большинству языков в этом аспекте до нее семь верст сами знаете чем еще плыть :-)

А по поводу "переучиваться" - у меня такое острое очучение, что в ФП побегут в первую очередь цеплюсисты - ибо им, как всегда, собственных проблем решаемой задачи не хватает, нужно еще повоевать с "ветряными мельницами" наворотов языка :-) Ну, или наворотов, измысленных математиками-теоретиками в минуту праздного безделья :-)

Ответ на »сообщение 2179« (Булат Зиганшин)
___________________________

>>>ну пусть не все языки, но многие :)

Точнее сказать -- некоторые.
Такие языки называются модульными. :)

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

IBM делает процессоры cells для Playstation 3, в которых работают несколько асинхронных ядер.
Это в корне отличается от обычной SMP архитектуры.


асинхронные - это как? может, асимметричные? в xbox 3-ядерный powerPC. в ps3 1нормальное ppc ядро, и ещё 8 упрощённых, чисто вычислительных, с 128к локальной памяти каждое. какие-нибуль научные расчёты на них пускать - самое милое дело. помните, как ps2 щапретили ввозить в россию, поскольку его мозность, 5.6 гфлопс, попала в диапазон, описывающий суперкмопьюетры? :)

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

Вы говорите о независимой (independent) компиляции, а Руслан Богатырев -- о раздельной (separate).
Основное (но не единственное) различие -- в межмодульном контроле типов.
Кроме того, раздельная компиляция позволяет избегать перекомпиляции клиентов модуля (при условии сохранения или даже расширения интерфейса).
А отсюда один шаг до компонентного подхода.

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

Ответ на »сообщение 2175« (Булат Зиганшин)
___________________________

Ответ на »сообщение 144« (Руслан Богатырев)
___________________________

Какие языки ФП имеют концепцию модуля как средства для инкапсуляции программных сущностей и инструмента поддержки раздельной компиляции (separate compilation) -- отчуждение интерфейса модуля от его реализации и автономную компиляцию модуля на основе одних интерфейсов при отсутствии доступа к реализации импортируемых им модулей?

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

Вы говорите о независимой (independent) компиляции, а Руслан Богатырев -- о раздельной (separate).
Основное (но не единственное) различие -- в межмодульном контроле типов.
Кроме того, раздельная компиляция позволяет избегать перекомпиляции клиентов модуля (при условии сохранения или даже расширения интерфейса).
А отсюда один шаг до компонентного подхода.

Ответ на »сообщение 156« (info21)
___________________________
А возращать локальные функции -- в гробу хочется видеть такие штуки. Жизнь-то одна, и хочется че-нить реальное совершать, а не примеры для конкурса Obfuscated Lisp генерить.

а ведь объект - это как раз и есть данные вместе с привязанными к ним функциями :)

я на http://haskell.org/haskellwiki/IO_inside приводил несколько примеров возрастающей сложности, как вместо класса, реализующего ту или иную функциональность в ООП-овской парадигме, в хаскеле возвращаются просто те самые несколько функций, которые составляют функционал этого класса. чем это лучше? меньше писанины. чем хуже? нет наследования. т.е. фактически это АТД, а не ООП

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

Булат переключился на начало списка :))
Если он продолжит в том же духе, нас ждет масса интересных коментариев.

Кстати по поводу нестандартной архитектуры компьютеров.
IBM делает процессоры cells для Playstation 3, в которых работают несколько асинхронных ядер.
Это в корне отличается от обычной SMP архитектуры.
И эти машины уже у нас дома. PS3 по моему продан уже в обьеме нескольких миллионов экземпляров.
Я думаю не за горами тот день когда мы увидми персоналки с асинхронными ядрами.
Вот тогда императивщикам придется туго. Надо будет переучиваться :))

Ответ на »сообщение 144« (Руслан Богатырев)
___________________________

Какие языки ФП имеют концепцию модуля как средства для инкапсуляции программных сущностей и инструмента поддержки раздельной компиляции (separate compilation) -- отчуждение интерфейса модуля от его реализации и автономную компиляцию модуля на основе одних интерфейсов при отсутствии доступа к реализации импортируемых им модулей?

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

Ответ на »сообщение 31« (Q. Werty)
___________________________

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

в свою очередь фон-неймановская архитектура была придумана отгадайте для чего?... для того, чтобы упростить программирование! :)  один из первых компьютеров, созданный под руководстовм Тьюринга, имел возможность программировать все исполнительные устройства параллельно и независимо, а данными управлять так, чтобы они приходили на исполнительные устройства just-in-time. в результате чего он работал в 6 раз быстрее (по сравнению с самим собой, работающим в "фон-неймановском" режиме), но его программирование превращалось в настоящий вызов для программистов :))

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

современные же компьютеры имеют отнюдь не фон-неймановскую микро-архитектуру. они *супер-скалярны* и только из-за проблем совместимости вынуждены эмулировать фон-неймановскую архитектуру, которая тянется как минимум со времён 8080. была подвижка с vliw-процессором itanium, но её благополучно закатала под асфальт amd :))

тем не менее, экспериментальные процессоры, управляемые данными, существовали. представь себе - есть куча исполнительных блоков. есть очередь заданий на вычисление - скажем вычислить x+y и поместить результат в z, затем a+b->c и z*c->t. задания из этой очереди расхватываются исполняемыми устройствами и выполняются в порядке, опредлеляемом их зависимостями *по данным*. в остальном же выполнение порграммы идёт асинхронно. фактически именно так сейчас и исполняются МОПыб в которые превращаются внутри процессора старые добрые x86 инструкции

добавь к эому параллелизм на уровне ядер (число которых intel обещает к концу десятилетия довести до 80 и вообще говорит, что теперь закон Мура будет работать в отношении числа ядер). не забудь ещё hyperthreading, хотя он наверно останется в основном для серверных процов; кстати уже продающийся sun t1 имеет не то 8 ядер по 4 треда, не то наоборот

или скажем CUDA - это когда на обычной nvidia-евской видеокарте запускают мат. вычисления. используя до 128 "ядер", которые там имеются.

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

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

Ответ на »сообщение 2172« (Jack Of Shadows)
_________________________
Кстати, почему delphikingdom ? Насколько я понял ты к дельфям никакого отношения не имеешь.


geniepro в жж ссылку кинул на задачку ACM. а к дельфи я действительно отношения никакого не имею, кроме того, что с 98-го его на хлеб намазываю :)))