На самом деле их никто не использует только потому, что в RSDN Mag до сих пор нет ни одной статьи на их тему. Я уверен, что как только выйдет хорошая статья с практическим примером того, как современная популярная прикладная задача на раз-два-три решается на функциональном языке, прикладники потянутся в эту сторону. Грамотный маркетинг — основа успеха.
... << RSDN@Home 1.1.4 beta 1 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, VladD2, Вы писали:
VD>Эти 20 строк читаются без проблем. А в твоем коде каждый симвло нужно анализировать как Шерлок Холмс. По хорошему их нужно так же в 20 расписать и коментариев добавить. А то ты вот сам не заметил, что ошибку сделал.
Он мделал две ошибки. Первая отловилась бы при компиляции, вторая состоит только в том, что он определил медиану слишком громоздко. Итого, программа работает без ошибок сразу после компиляции.
VD>А. Ну, да. Причем на шеснадцатиричные. Давай свои реальные приложения будем глядеть. И не надо мне то что я посмотреть не могу и узкоспециализированное вроде камутаторов. Ты мне покажи что-то что я смоку сказчать на свой писюк, скомпилировать и поглядеть. Ну, и чтобы аналоги были императивные.
На сайте caml.inria.fr есть примеры кода. Но ты ведб его смотреть не будешь? Там ведб, наверняка, и HTML плозхо сверстан, и кнопочки "Скомпилировать и сравнить с аналогами" нету...
VD>Ты себя в этом уже убедил. Но я вот себя никак побороть не могу. Для меня это филькина грамота. Причем недающая мне сдлать все так как хочу именно я. Или заставляющая для этого изварачиваться.
Да, ФЯ предполагает другой способ мыщления, чем ИЯ. И если "так как хочешь ты" — эьл обязательно как в ИЯ, то действительно, ФЯ тебе не нужны.
G>> Требуется минимум привычки, которая вырабатывается за несколько дней. VD>Видимо я дефективный. Вот уже 30 лет, а такой привычки выработать не могу. И вроде тот же STL могу использовать и вообще не идиот, но вот до сих пор меня нагромождение палочек убивает. Это ненаглядно и очень тяжело читается.
Поэтому я и предложил вариант "без палочек". Но к "палочкам", действительно, привыкнуть можно быстро.
VD>Напомню, что о времени оптимизации речи тут не идет. Речь идет о невозможности ее в принципе.
Ошибка. В библиотеке Ocaml реализована оптимизированная сортировка, использующая массивы.
G>> В OCaml ты тоже сможешь оптимизировать, как захочешь. VD>Переписав императивно? А нафиг мне тогда он упал? Ты вот изобрази такой же алгоритм пимперативно на Окамле и сравним с Шарпом. Почему то я уверен, что выглядеть это будет очень не важно.
Выглядеть будет как минимум не хуже.
G>>Потом, по показаниям. В Erlang, конечно, таких возможностей поменьше. VD>Erlang как не имеющий статической типизации меня вообще не волнует.
Ошибка. Erlang имеет статическую типизацию.
Вобщем, ты меня убедил. Тебе ФЯ не нужно. И ни в коем случае не читай этот жутко сверстанный HTML и дремучие pdfы.Ну а если вдруг по неосторожности почитаешь, тогда и продолжим разговор.
Здравствуйте, ON, Вы писали:
ON>From: INTP_mihoshi >>Скомпилено и работает. Хотя на C# или С++, возможно, получился бы почти столь же краткий и понятный код
ON>А вот так: Сортируем снизу-вверх. Сравниваем два первых значения, упорядочиваем, генерируем функцию сортировки остатка с учетом этих значений. Там будет три рекурсии — до минимума из этих первых двух значений, между, и после. Для последнего имеем такое дерево if-ов, значение по нему попадает в нужное место. Что-нибудь такое, это функциональный стиль?
Функциональный стиль — это...
Сортировка списка по делается следующим образом.
let rec qsort lst = match lst with
Если список пуст, то результатом будет тоже пустой список.
| [] -> []
Если нет, то берем случайный элемент.
| _ -> let pivot = List.nth lst (Random.int (List.length lst)) in
Разделяем все элементы на те, которые равны ему, и не равны.
match List.partition (fun x -> pivot = x) lst with (lsteq, lstneq) ->
Которые не равны — на те, что больше и те, что меньше.
match List.partition (fun x -> pivot > x) lstneq with (lst1, lst2) ->
Те, что больше, и те, что меньше, сортируем по отдельности таким же образом. Возвращаем эти три списка, склеенные в порялке "меньшие отсортированные; равные; большие отсортированные".
List.concat [qsort lst1; lsteq; qsort lst2]
(Для простоты даю версию сортировки со случайным "средним" элементом и арифметическим сравнением элементов. В другом посте была сотрировка с произволными фуекциями сравнения и выбора среднего)
Т.е. если на слух понятно, что алгоритм работает, то это — функциональный стиль
Здравствуйте, VladD2, Вы писали:
F>>На вас не угодишь. А так понятнее? F>>
F>>foreach func list
F>>
VD>Да не очень то. От обычного мировозрения это очень сильно отличается.
Что такое "обычное мировоззрение"? В какой строчке из нижеследующих начинается "обычное мировоззрение" и кончается "необычное"?
map func list
foreach func list
foreach(func, list)
foreach(list, func)
for_each(list, func)
for_each(list.begin, list.end, func)
for_each(list.begin(), list.end(), func)
Последнюю строчку, надеюсь, узнаете? Или STL — это тоже "необычное мировоззрение"?
VD>Да рекурсия там постоянно.
Рекурсия там редко.
VD>Просто она подразумевается.
А вам не все равно, что там подразумевается? Вас беспокоит эффективность? Не волнуйтесь, _на этом_ эффективность не теряется. Сила ФЯ не в рекурсии, а в функциях высшего порядка, таких как foreach, а рекурсия — всего лишь необязательная деталь реализации.
VD>Мышение все равно унжно менять на рекурсивное.
Нет, надо менять мышление на более высокоуровневое. Вместо "организовать цикл по элементам списка, пройтись по ним индексом i и вызвать фукнцию для каждого i-го элемента" думать "вызвать функцию для всех элементов списка". Именно то, к чему призывает STL.
F>> Вообще, STL — это такой маленький и уродливый аналог библиотеки ФЯ.
VD>Уродливый он по другим причинам. Просток как всегда с помощью С++ пытаются сделать, то на что он не рассчитан.
А я разве говорил о других причинах? Правильно, именно поэтому.
Re[2]: Почему никто не использует функциональные языки
S>На самом деле их никто не использует только потому, что в RSDN Mag до сих пор нет ни одной статьи на их тему. Я уверен, что как только выйдет хорошая статья с практическим примером того, как современная популярная прикладная задача на раз-два-три решается на функциональном языке, прикладники потянутся в эту сторону. Грамотный маркетинг — основа успеха.
Здравствуйте, faulx, Вы писали:
F>Именно Haskell и является языком со статической типизацией, остальные языки лишь более или менее приближаются к нему в этом отношении.
Haskell, Ocaml, SML, Clean имеют статическую типизацию. Erlang — динамическую.
According to this definition C, C++ or Java aren't StronglyTyped languages. In C and C++ there is pointer to void, Java has typing constrains 'leak' for arrays. ObjectiveCaml can be example of StronglyTyped language. In ObjectiveCaml compiler is able to check any type constraint at compile time.
Здравствуйте, ON, Вы писали:
ON>From: Курилка
>>Не совсем понятно что ты хочешь — мат. часть или исходники? (ну вещи ведь совсем разные по сути) Если по поводу мат. >части, то тут главенствуют вроде бы как лямбда-исчисления (знатоки меня поправят, если что)
ON>И то и другое. ON>- теорию, желательно по-русски. ON>- какой-нибудь ML-интерпретатор в исходниках. ON>- хотя бы примерно описание как работает то, что ФЯ-компиляторы выдают.
Есть нечто вроде перевода, сокращенного, переделанного с ML на Haskell, недоделанного, корявого, дополненного... Словом, переводил я. Лежит здесь:http://kchri.narod.ru/lecs.pdf
Здравствуйте, INTP_mihoshi, Вы писали:
INT>Здравствуйте, faulx, Вы писали:
F>>Именно Haskell и является языком со статической типизацией, остальные языки лишь более или менее приближаются к нему в этом отношении.
INT>Haskell, Ocaml, SML, Clean имеют статическую типизацию. Erlang — динамическую.
INT>здесь
INT>
INT>According to this definition C, C++ or Java aren't StronglyTyped languages. In C and C++ there is pointer to void, Java has typing constrains 'leak' for arrays. ObjectiveCaml can be example of StronglyTyped language. In ObjectiveCaml compiler is able to check any type constraint at compile time.
INT>
Так оно и есть. Однако если сравнивать системы типов в OCaml и Haskell, то в последнем есть классы типов, которые дают возможность управлять ad-hoc-полиморфизмом. Впрочем, это отдельный разговор.
А как же функции высших порядков? Это же самое интересное.
Или я рекламы обчитался, или ФЯ должен генерировать функции, т.е. выполнять чуть ли не всю работу программиста.
Или хотя бы помочь собрать из понятных кусочков нечто большое, что охватить невозможно. Все языки высокого уровня в основном для этого сделаны. Я так понял в ФЯ самомодифицирующиеся программы хакерством не считаются, поскольку программы вроде как и не программы, а декларации, а это очень мощный инструмент. Только ради таких возможностей и берут интерпретаторы. Ну еще удобство отладки, но с ФЯ это пока не прояснилось.
Здравствуйте, faulx, Вы писали:
VD>>Мышение все равно унжно менять на рекурсивное. F>Нет, надо менять мышление на более высокоуровневое. Вместо "организовать цикл по элементам списка, пройтись по ним индексом i и вызвать фукнцию для каждого i-го элемента" думать "вызвать функцию для всех элементов списка".
Уж если менять, тогда так "Для каждого элемента списка..."
Здравствуйте, ON, Вы писали:
ON>А как же функции высших порядков? Это же самое интересное. ON>Или я рекламы обчитался, или ФЯ должен генерировать функции, т.е. выполнять чуть ли не всю работу программиста. Тогда, получается, ИЯ должен генерировать данные за программиста?
Просто в типизированных ФЯ гораздо более мощный (с точки зрения языка, а не быстродействия) механизм работы с типами, чем в традиционных ЯП. В остальном все очень похоже на современный С++ с темплейтами, функторами и указателями на функции. Т.е. если выкинуть из С++ кошмарный синтаксис, сделать чуть построже работу с типами и научить компилятор выводить тип самостоятельно там, где можно, а также собирать мусор и оптимизировать то получиться нечто очень похожее на OCaml.
Интересно, кстати, что об этом думает Страуструп
ON>Или хотя бы помочь собрать из понятных кусочков нечто большое, что охватить невозможно. Все языки высокого уровня в основном для этого сделаны. Я так понял в ФЯ самомодифицирующиеся программы хакерством не считаются, поскольку программы вроде как и не программы, а декларации, а это очень мощный инструмент. Только ради таких возможностей и берут интерпретаторы. Ну еще удобство отладки, но с ФЯ это пока не прояснилось.
Самомодифицирующий код — очень растяжимое понятие. Программы на ФЯ, по существу не более самомодифицирующиеся, чем С++.
Удобство отладки состоит опять же в том, что компилятор не прикидывается идиотом И не требует объяснять, где хранить какие-либо значения и какого они типа. Работа ведется в основном с функциями и значениями. Значения эквивалентны функциям без аргументов, так что можно сказать, что только с функциями. Это позволяет писать максимально кратко, переносимо и осмысленно. Так как из кода исчезают бессмысленные частности, различные части кода меньше цепляются друг за друга, поэтому код можно разбить на очень мелкие независимые кусочки, большинство — по нескольку строк. И каждый кусочек можно отлаживать независимо. Вот тебе и удобство отладки.
Здравствуйте, INTP_mihoshi, Вы писали:
INT>Он мделал две ошибки. Первая отловилась бы при компиляции, вторая состоит только в том, что он определил медиану слишком громоздко. Итого, программа работает без ошибок сразу после компиляции.
Итого две ошибки. Меня тоже компилятор поправит если я совершу не логическую ошибку. А с логической не поправит ни какой компилятор, так как это просто другое поведение.
INT>На сайте caml.inria.fr есть примеры кода. Но ты ведб его смотреть не будешь? Там ведб, наверняка, и HTML плозхо сверстан, и кнопочки "Скомпилировать и сравнить с аналогами" нету...
Ты ссылки давай. А то там... есть...
INT>Да, ФЯ предполагает другой способ мыщления, чем ИЯ. И если "так как хочешь ты" — эьл обязательно как в ИЯ, то действительно, ФЯ тебе не нужны.
А почему фанкторы и делегаты не предпологают другого способа мышления? Может все же надо сам язык как-то поправить, чтобы он был удобнее и понятнее?
INT>Поэтому я и предложил вариант "без палочек". Но к "палочкам", действительно, привыкнуть можно быстро.
Это как привычка к регексам. Понятнее они от этого не становятся. И без коментария они просто опасны.
VD>>Напомню, что о времени оптимизации речи тут не идет. Речь идет о невозможности ее в принципе.
INT>Ошибка. В библиотеке Ocaml реализована оптимизированная сортировка, использующая массивы.
Т.е. императивно? Изумительно!
INT>Выглядеть будет как минимум не хуже.
Точно хуже. Императивный синтаксис Окамла очень неудачен. Да и зачем тогда он мне нужен? Для шарпа у меня есть все. И красивый синтаксис, и отладчик, и среда разработки и море библиотек.
VD>>Erlang как не имеющий статической типизации меня вообще не волнует. INT>Ошибка. Erlang имеет статическую типизацию.
По-моему, у них на сайте написано обратное. Да, и у меня тут еще один сторонник по этому поводу есть
.
INT>Вобщем, ты меня убедил. Тебе ФЯ не нужно. И ни в коем случае не читай этот жутко сверстанный HTML и дремучие pdfы.Ну а если вдруг по неосторожности почитаешь, тогда и продолжим разговор.
Я уже прочитал. И давно. Свинячего восторга не ощутил, хотя разумные и интересные идея несомненно присутствуют. В таком виде мне они не нужны. А вот хорошие идеи следут перенять. Собственно тот же шарп и делался как набор проверенных хороших решений.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[20]: Почему никто не использует функциональные языки
Здравствуйте, faulx, Вы писали:
VD>>Во-во. Без пояснений тут никуда. А ведь импиративный вариант пояснять не нужно.
F>Его нужно пояснять для тех, кто не знает языка, на котором он написан.
К сожалению, его нужно пояснять в принципе. Запутаться в награмождении палочек не трудно. Это как регексы.
В общем — это называется плохой синтаксис. Вместо тех же регексов можно применять очень красивые и понятные выражения. Получается чуть длинее, но за-то в сто раз понятнее. Хорошим примерут тут является CocoR. У него грамор описывается очень приятным языком.
F>Именно Haskell и является языком со статической типизацией, остальные языки лишь более или менее приближаются к нему в этом отношении.
Видимо я его попутал с Erlang. Извиняюсь.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Цунцуяби, Вы писали:
Ц>Так какое исчисление ты хочешь предложить ?
Исчисления/вычисления в программировании занимают малый процент. Я бы скзал, что программирование в основном — это обработка данных и в частности вычисления.
Что касается декларативности, то возми к примеру XPath. Я моку без лишних навторотов описать запрос который найдет мне набор веток. Это чисто декларативный язык. Так вот хотелось бы иметь возможнось превращать подобные языки в императивный код эффективно решающий задачу. Другимы словами чтобы вводить какие-то высокоуровневые конструкции позволяющие описать предметную область, а потом иметь механизм превращения этой модели в готовый код который будет иметь все нужные рющечки. Таким образом я получаю возможность работать с простой в понимании моделью и сокращаю время на написание код (так как весь код строится алгоритмически).
Ц>А создавать язык ради языка — это для художников: кто-то любит крупные мазки, кто-то сангину...
Ну, художники тоже нужны. Хотя речь не об этом. R# задуманный мной — это попытка воплотить некоторые идеи в жизнь. С функциональными языками он пересекается идеей декларотивности. Но в ФЯ декларативность заложена однажды и может применяться только для решения конкретных задач. R# же должен обеспечить фрэймвор по созданию таких декларативных плагинов. Это позволит R#-у вводить новые удобные конструкции, реализовывать паттерны программирования и воплотить в жизнь идеии АОП (выносить аспектный код в отдельные модули).
Ц>P.S. Ц>Рекурсия тебе — не нравится — это тоже понятно, нормально.
Она мне не ненравится. Мне не наравится переводить свое мышление в рекурсивное и обратно. Если задача легко (для моего разума) описывается рекурсивно (например, тот же квиксорт), то я хочу описывать ее рекурсивно. Но если задача итеративна, то я не хочу переописывать ее для себя рекурсивно.
Ц>А как без нее работать с бесконечностями в замкнутой форме, чтобы доказательсва были покомпактнее.
А мне не нужна абстрактная математика. Мне нужно с БД работать, модели мира делать и т.п. Это, как я уже гворил, на 90% данные и работа с ними. А не вычислительная математкика. Вот если прийдется возиться с формулами, то функциональный стиль будет воспринят мной с радостью.
Ц> Как же в формальной логике и в теории доказательств без рекурсий.Хотя может и можно обойтись ? Может с помощью машины Тьюринга.
А зачем обходиться? Ненависть к рекурсии ты приписал мне только что сам. Я ее не испытываю. При работе с деревьями я с радостью применяю рекурсию. В общем, я уже об этом говорил.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[21]: Почему никто не использует функциональные языки
Вообще то конечно краткость до определённой степени хорошо, так как позволяет выделить и показать существенные детали и скрыть визуальный шум (отвлекающих или мешающие), но при такой черезмерной краткости, какую продемонстрировал Gaperton — это уже просто тёмный лес. И это действительно не читабельно — и соответсвенно — хуже для реального проекта. Конечно можно научиться понимать и такое, но вообще то написанное Gaperton'ом очень напоминает кусок формулы, выбранный наугад из докзательства какой-нибудь теоремы матанализа, страниц так на 30, без единого коментария.
Соответсвенно программа на ФЯ — будет представлять собой эту теорему целиком — если из неё выкинуть весь текст и оставить одни формулы. И разобраться в этом сможет только профессиональный математик. (Собственно именно математиками и была предложена идея функциональных языков — и идея сделать программу — доказательством неекоей теоремы).
Но математиков всегда было 0.0001% от населения или 0.01% от программистов — и больше их не станет никогда, т.к. для того, что бы стать математиком нужно иметь гораздо более высокий уровень абстрактного мышления, чем для того, что бы стать программистом.
Потому — в том виде в каком программу на ФЯ показал Gaperton — ФЯ однозначно обречены.
Другое дело — что многие идеи ФЯ — сохраняя свою суть, но видоизменяя форму — всё шире распространяются в обычных языках.
С моей точки зрения дело в том, как облечь идеи ФЯ в удобную и лёгкую для восприятия форму в рамках языка императивного — так, что бы можно было пользоваться на выбор действительно наиболее эффективным из этих двух подходов, в рамках одной программы.
Здравствуйте, AndreyFedotov, Вы писали:
AF> Но математиков всегда было 0.0001% от населения или 0.01% от программистов — и больше их не станет никогда, т.к. для того, что бы стать математиком нужно иметь гораздо более высокий уровень абстрактного мышления, чем для того, что бы стать программистом.
От программистов математиков — 100%. Если программист не умеет математически мыслить — то это кто угодно, но не программист.
Здравствуйте, INTP_mihoshi, Вы писали:
INT>Здравствуйте, AndreyFedotov, Вы писали:
AF>> Но математиков всегда было 0.0001% от населения или 0.01% от программистов — и больше их не станет никогда, т.к. для того, что бы стать математиком нужно иметь гораздо более высокий уровень абстрактного мышления, чем для того, что бы стать программистом.
INT>От программистов математиков — 100%. Если программист не умеет математически мыслить — то это кто угодно, но не программист.
Ну почему же? Для того что бы разрабатывать интерфейсы, поведение которых не выходит за рамки конечного автомата математического образования не надо
Грамотный маркетинг — основа успеха.
Может с помощью машины Тьюринга.
