| Функциональное программирование |
Функциональное программирование всегда привлекало меня в противопоставлении к императивному.
Я очень часто обсуждаю различные аспекты функционального программирования на различных ветках на Базарной площади.
Но хотелось бы собрать всех заинтересованный этой темой в одной ветке.
Я думаю что настало время открыть такую тему. И вот почему.
Исторически функциональное программирование появилось практически вместе с императивным.
Вторым языком после фортрана был лисп.
Но увы, функциональное программирование надолго было уделом исследовательских институтов или специализированных приложений (Искусственный Интеллект)
Конечно не надо считать весь мир дураками из за того что развитие пошло по пути языков Алгол семейства.
Для этого были вполне обьективные причины. Функциональные языки слишком близки к человеку и слишком далеки от машины.
Они сьедают в десятки раз больше рессурсов чем императивные языки.
Вспомните претензии, предявляемые к java - первому императивному языку с виртуальной машиной и сборщиком мусора, толкаемому большими корпорациями в mainstream.
Жутко тормозит, и жрет всю память какая есть. А ведь функциональные языки (далее ФЯ) все без иключения имеют сборщик мусора, виртуальную машину.
Многие из них (семейство лисп) еще и динамические, что только усугубляет положение.
Вполне естественно что появившись более полусотни лет назад они надолго опередилли свое время.
Для широкого распространения ФЯ нужны гигабайты дешевой памяти и гигагерцы дешевых процессоров.
Прошло более 50 лет, прежде чем такие требования к железу стали реальностью.
Это время наступило. СЕЙЧАС.
Добро пожаловать в новую эру программирования.
Jack Of Shadows
Всего в теме 5502 сообщения
Добавить свое сообщение
Отслеживать это обсуждение 
- Средства разработки. Языки программирования.
- Delphi 4 or Delphi 5
- Что приобрести в качестве средства разработки?
- Delphi6
- Delphi vs PowerBuilder
- Сравнение компиляторов
- Вот и вышла Delphi 7... Вы рады?
| № 1372 30-10-2006 14:06 |   |
Ответ на »сообщение 1371« (Geniepro)
___________________________
Офтопик.
Старайтесь воздерживаться от обсуждения вопросов к теме не относящихся.
А то так доберемся до обсуждения приемов катания на лыжах только потому что кто то из функциональных программистов еще и на лыжах катается :))
| № 1371 30-10-2006 13:17 | |
Простите, что снова возвращаюсь к Роману Душкину... ;-)
Я тут как-то подписался на RSS-ку с его живого журнала, и мельком читая всё это, вдруг понял, что фактически он со своими единомышленниками (не в плане программирования) готовится к самой настоящей Политической Революции! (об этом, видимо, и упоминал Артём...)
Да-да, именно так и никак иначе! Проект "Россия для русских"! В программе проекта - смена власти в России и реорганизация Федерации, в смысле передел территорий.
В принципе, так как я живу не в России, то мне как бы всё равно, да и скорее всего - проект распадётся, так ничего и не предприняв, но...
Предположим, что будет такая попытка. Естественно, она окончится неудачей. Что будет дальше?
Вдруг обнаружится, что Душкин ещё и ярый пропагандист Функционального Программирования!
На программистов-функциональщиков (а может, и на всех программистов) повесят ярлык диверсантов-саботажников-реакционеров...
Не очень приятная перспектива... :-(
| № 1370 24-10-2006 03:20 | |
Ответ на »сообщение 1360« (Geniepro)
...
for (l = 0; l < fl; l++)
}
Есть подозрение, что тормозит fs.ReadByte(). Не из-за "чтения с диска", а из-за перехода в режим ядра и обратно для каждого прочитанного байта. Точно не знаю, как ввод-вывод устроен в .NET, но в Win32 функции WinAPI типа ReadFile() выполняются в режиме ядра. Переход между режимом пользователя и режимом ядра - дорогостоящая операция. Поэтому куда оптимальнее читать данные одним куском, а потом искать в памяти.
| № 1369 Удалено модератором | |
| № 1368 23-10-2006 17:48 | |
Ответ на »сообщение 1367« (CPP)
___________________________
Но вот с фанатизмом и идиотизмом пора уже завязывать - все уже сыты этим по горло.
Эт точно. Завязывайте :))
| № 1367 Удалено модератором | |
| № 1366 22-10-2006 22:59 | |
Для меня честно говоря все эти замеры не представляют никакого практического интереса.
Скорость хаскеля находится примерно в том же районе что и у таких признанных лидеров как си и с++
Я же работаю с динамическим языком, лиспом, который по определению чуть ли не в 10 раз должен отставать.
Если меня лисп устраивает, то чисто автоматически устраивает все что быстрее лиспа, в том числе и хаскель :))
Более того, меня даже Python с Ruby устравивают. А ведь они медленнее лиспа чуть ли не в 100 раз!!
| № 1365 22-10-2006 20:17 | |
А давайте возьмём простенькую задачку 1.2.25 из задачника А.Шеня "Программирование. Теоремы и задачи":
Дан двумерный целочисленный массив размерности n x m.
Известно, что существуют числа, которые присутствуют в каждой строке двумерного массива.
Необходимо найти эти числа.
Если вдуматься, то это прекрасный тест для SMP-оптимизации.
module Shen1225 where
main = print (findAll dat) -- Результат: [5,6,7,8,9]
findAll :: [[Int]] -> [Int]
findAll [ ] = error "Empty matrix!"
findAll (m:ms) = filter ((\v n -> and (map (elem n) v)) ms) m
dat :: [[Int]]
dat = [[ 1, 2, 3, 4, 5, 6, 7, 8, 9, 0],
[ 2, 3, 4, 5, 6, 7, 8, 9, 10, 11],
[ 3, 4, 5, 6, 7, 8, 9, 10, 11, 12],
[ 4, 5, 6, 7, 8, 9, 10, 11, 12, 13],
[ 5, 6, 7, 8, 9, 10, 11, 12, 13, 14]]
Конечно, для реального теста нужен массив данных размером побольше... :о)
Очень любопытно, будет ли здесь ускорение на многоядерном процессоре?
Главное, не забыть не только компилятору ключ SMP указать, но и самой программе указать, сколько потоков задействовать...
| № 1364 22-10-2006 19:10 | |
Я заметил такую вещь у Хаскелла - например, стоит задача обработать список размером, скажем, в миллион элементов, то гораздо быстрее получается, если обработка идёт одним куском в миллион элементов. Если разбить список на 10 кусков - получается раза в полтора медленнее, а если разбить на сто частей - то ещё медленнее. Начинается страшная сборка мусора (вплоть до своппинга), которая и тормозит программу...
| № 1363 22-10-2006 18:41 | |
Ответ на »сообщение 1362« (Jack Of Shadows)
___________________________
Да но ваш хаскелевский код грешит тем же самым.
В сишарп вы считываете с файла и затем манипулируете одним и тем же тпом данных.
В хаскеле же считываете один тип данных, после чего делаете 2 (!!!) преобразования, и только после этого работаете с данными. Конечно так будет в разы медленнее.
if B.head s == toEnum (fromEnum ',')
Вы имеете в виду toEnum (fromEnum ',') ? Я надеюсь, компилятор это оптимизировал, ведь это константное выражение.
Вообще-то количество преобразований, как мне кажется, совпадает.
Data.ByteString.head :: ByteString -> Word8 - то есть 8-битный символ преобразуется в 8-битное слово (байт). Преобразование элементарное, возможно даже компилятор его и не производит (скорее всего).
toEnum (fromEnum ',') - опять же, вероятно, компилятор не производит на самом деле этого преобразования - оно нужно лишь для соблюдения типизации, реальные типы данных совпадают...
Но вот, правда, нет гарантии, что эти оптимизации есть...
Хаскелл - очень сложный и громоздкий для реализации язык, сравнимый с монстрами типа Ада/С++/С#...
int c, num = 0;
while ((c = sr.Read()) != -1)
Вот тут уже явное указание на преобразования типов: sr.Read() считывает символьный файл и преобразует 8-битные символы из этого файла в 16-битные числа. Хотя очень умный компилятор может и это оптимизировать. Скорее даже не компилятор, а загрузчик .NET-машины. Хотя я замечал, иногда эта пара компилятор/загрузчик тупит, производит неоптимизированный код...
Добавить свое сообщение
Отслеживать это обсуждение
| Дополнительная навигация: |
|
