Здравствуйте, INTP_mihoshi, Вы писали:
INT>Тут меня надо спросить, а почему же при всем при этом Ocaml не юзают все кому не лень.
Потому, что
— Есть куча уже написанного кода на С++/С#/Java, который надо развивать и поддерживать.
— Проще найти специалиста по С++/С#.
— Со стороны програмиста — знание OCaml (Haskell, whatever) не увеличивает его ценность на рынке труда. Он не чувствует необходимости тратить на него время.
— К тому-же, среда программирования не настолько "дружественна", как в коммерческих средствах разработки. Это отпугивает.
— Популярность языка обусловлена также количеством денег, потраченным на рекламу и продвижение. Mainstream — это бизнес, и его участники заинтересованы, чтобы все использовали С# и Java, потому, что в них вложены большие средства. Популярность же остальных "бесплатных языков" так или иначе связана с популярностью Linux.
— Существует набор предубеждений о ФЯ среди незнакомых с ними людей. У ФЯ есть слабые места. Но предубеждения обычно не имеют к ним отношения.
Заметно поправить ситуацию сможет только включение любого из современного ФЯ в учебную ВУЗовскую программу как одного их основных языков.
INT>Ответ, я кажется, почти понял, но налеюсь, что его скажет кто-нибудь, кто знает этот язык лучше. Возможно, одна из причин в том, что практическая польза языка не только в том, что он позволяет делать, но и в том, что он не позволяет А вот со вторым у OCaml явные напряги
О чем ты говоришь? . Никто даже и не догадывается, что OCaml позволяет делать, и, что характерно, не хочет знать. Все, что большинство о нем знает — что в нем есть страшная и неудобная рекурсия, что и обсуждается. Еще обсуждаются, в каком кривом формате (PDF) приведенные ссылки. "Цвет учебника" не нравится.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, AndreyFedotov, Вы писали:
AF>> Верно. Только для полноты картины вспомни о затратах ресурсов на переключение контекста.
AVK>Но тем не менее у нас получается в рамках одного проекта успешно применять C#, SQL, XSLT и собственный декларативный язык, причем зачастую один генерит программу на другом и наоборот, и что то переключение контекста особых проблем не вызывает.
Естественно. Потому, что у Вас оно — сбалансированно. Более того — редко найдёшь хоть сколько-нибудь заметный проект, где бы использовался только один язык.
Тебе известны проекты, где бы одновременно применялось 30-40 языков? Мне — нет. И догадываюсь почему...
Читал, что лет так 30 назад у Пентагона подобные проекты были — и неизменно проваливались. Авторы книги утверждали, что именно это побудило DARPA создать язык ADA и потребовать переход субподрядчиков Пентагона на него. Целью было — как раз уменьшить издержки на "переключение контекста" до приемлемого уровня.
Чуть в сторону. Как то видел подобное утверждение о естественных языках (за точность не ручаюсь): "Образованный человек должен знать минимум один иностранный язык. Если человек знает два иностранных языка, то он молодец и сделает успехи в карьере. Человек знает 6-7 иностранных языков — полиглот и пред ним открыт весь мир. Человек, который знает 15-20 языков — гений. Но тот кто знает больше 20 языков — опасный псих, ль которого следует охранять общество"
Re[6]: Занятная статистика "сравнение СССР и россии"
Здравствуйте, Gaperton, Вы писали:
G>Заметно поправить ситуацию сможет только включение любого из современного ФЯ в учебную ВУЗовскую программу как одного их основных языков.
Вроде-бы на родине OCaml, т.е. во Франции, так и сделали...
Re[15]: Почему никто не использует функциональные языки
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Gaperton, Вы писали:
AVK>>>А вот те самые ФЯ и то что они перевернут мир . G>>Как странно, ты уже не первый, кто видит в ней ней то, чего там нет. Вон, с Федотовым поабзацно "вслух" читали — все равно не понимает. Проповедники ему везде мерещатся. Простая вроде статья. Понятная.
AVK>А может ты не видишь? Когда один ошибается это еще ладно. А вот когда несколько человек воспринимают одинаково то закрадывается подозрение что не все так просто .
AVK>Собственно в самом начале мы видим такую фразу: AVK>
AVK>Эксперименты не всегда подтверждать, эту цифру — иногда они показывает улучшение только в четыре раза. Однако, не стоит пренебрегать кодом, который в четыре раза короче, в четыре раза быстрее писать, или в четыре раза проще поддерживать. Так почему же функциональные языки не используются более широко?
AVK>Оказывается существует способ в четыре раза быстрее писать и проще поддерживать, а его никто не использует.
Было бы преувеличением сказать, что никто не использует функциональные языки. Телефонные вызовы в Европейском парламенте коммутируются программами, написанными на функциональном языке Erlang фирмы Ericsson. Виртуальные компакт-диски распределяются по сети Cornell через систему Ensemble, написанную на CAML, реальные компакт-диски распространяются в Европе компанией Polygram с использованием Natural Expert от Software AG. Функциональные языки выбраны для создания программ автоматического доказательства теорем, таких как система HOL, которая помогла отладить линию многопроцессорных систем HP9000.
AVK> ВОт тебе и сенсация.
Способ такой есть, причем уже настолько давно, что сенсацией он являться не может даже с натяжкой. Ты можешь убедиться в этом сам, написав, например, реализацию AVL деревьев на Haskell. Чужой код не произведет такого впечатления, как свой собственный. А пока взгляни на это:
quicksort( [ H | T ] ) -> [ X || X <- T, X <= H ] ++ [ H ] ++ [ Y || Y <- T, Y > H ];
quicksort( [] ) -> [].
Выигрыш в том, что ты вообще свободен от управления памятью, что ты вынужден всегда делать в С#. Тебе надо думать только об алгоритме. Но за все надо платить, и платить в данном случае придется производительностью.
На С# программа будет гораздо длиннее, но зато ты сможешь применить алгоритм Хоара, который не требует дополнительных затрат памяти. Естественно, до такого управления памятью никакой умный компилятор додуматься не сможет (Хоар и то додумался не сразу). Вот и вся сенсация.
Здравствуйте, Gaperton, Вы писали:
AVK>> ВОт тебе и сенсация. G>Способ такой есть, причем уже настолько давно, что сенсацией он являться не может даже с натяжкой. Ты можешь убедиться в этом сам, написав, например, реализацию AVL деревьев на Haskell. Чужой код не произведет такого впечатления, как свой собственный. А пока взгляни на это: G>
G>quicksort( [ H | T ] ) -> [ X || X <- T, X <= H ] ++ [ H ] ++ [ Y || Y <- T, Y > H ];
G>quicksort( [] ) -> [].
G>
Кстати, это не совсем правильный quicksort. Элемент должен браться не первый, а, например случайный, иначе на уже отсортированном списке он будет далеко не quick. Можешь написать правильный?
Здравствуйте, ON, Вы писали:
ON>From: Курилка
>>Не совсем понятно что ты хочешь — мат. часть или исходники? (ну вещи ведь совсем разные по сути) Если по поводу мат. >части, то тут главенствуют вроде бы как лямбда-исчисления (знатоки меня поправят, если что)
ON>И то и другое. ON>- теорию, желательно по-русски. ON>- хотя бы примерно описание как работает то, что ФЯ-компиляторы выдают.
Ищи эту книгу.
А.Филд, П.Харрисон "функциональное программирование" М.Мир 1993
Там есть исчерпывающие ответы на эти вопросы.
Здравствуйте, INTP_mihoshi, Вы писали:
INT>Здравствуйте, Gaperton, Вы писали:
AVK>>> ВОт тебе и сенсация. G>>Способ такой есть, причем уже настолько давно, что сенсацией он являться не может даже с натяжкой. Ты можешь убедиться в этом сам, написав, например, реализацию AVL деревьев на Haskell. Чужой код не произведет такого впечатления, как свой собственный. А пока взгляни на это: G>>
G>>quicksort( [ H | T ] ) -> [ X || X <- T, X <= H ] ++ [ H ] ++ [ Y || Y <- T, Y > H ];
G>>quicksort( [] ) -> [].
G>>
INT>Кстати, это не совсем правильный quicksort. Элемент должен браться не первый, а, например случайный, иначе на уже отсортированном списке он будет далеко не quick. Можешь написать правильный?
Не соглашусь. Порядок элементов в списке вообще говоря случайный. С точки зрения теории вероятностей — совершенно неважно, беру я первый элемент, или какой-то другой. А то, что quick sort в любом случае не будет работать быстрее на сортированном массиве, как медиану не выбирай, — это известная особенность quicksort.
К тому же если брать случайный элемент, то списки лучше не использовать.
И вообще, что ты делаешь? Сейчас такими примерами всех здесь распугаем . Определим функцию, вычисляющую медиану, как ты говоришь. В на входе в рекурсию считаем длину списка, внизу генерируем случайное число, на выходе их рекурсии забираем нужный элемент. Осторожно, hardcore Erlang programming! Слабонервным не смотреть, код слегка оптимизирован для скорости.
median( L ) ->
{ _, Element } = median( L, 0 ),
Element.
median( [ H | T ], Count ) ->
case median( T, Count + 1 ) of
{ Count, nil } -> { Count, H };
%% применяем pattern matching для сравнения результата ф-и с Count.
%% если номер текущего элемента совпадает со случайным - возвращаем этот элемент.
Res -> Res; %% в противном случае - что получили - то вернули.
end.
median( [], Count ) -> { float_to_integer( rand() * ( Count - 1 ) + 0.5 ), nil }.
Примерно так.
Теперь код сортировки будет выглядеть так.
qsort( L ) -> quicksort( L, fun head );
rndqsort( L ) -> quicksort( L, fun median ).
quicksort( L, Median ) ->
M = Median( L ),
[ X || X <- L, X <= M ] ++ [ Y || Y <- L, Y > M ];
quicksort( [], _ ) -> [].
Re[8]: Почему никто не использует функциональные языки
Здравствуйте, Sinclair, Вы писали:
S>...в узких нишах ФЯ таки сумели прорваться — SQL применяется повсеместно. Как ни странно, оказалось, что императивная обработка данных не устраивает даже ярых противников ФЯ.
Я хоть и не ярый противник всего живого (включая ФП), но любители SQL (хотя есть менение, что он на ФЯ) это -.
Всегда не понимал, как приживаются эти бейсикообразные монстры
Здравствуйте, sardonyx, Вы писали:
S>Здравствуйте, Gaperton, Вы писали:
G>>Заметно поправить ситуацию сможет только включение любого из современного ФЯ в учебную ВУЗовскую программу как одного их основных языков.
S>ну вообще то lisp включён в учебные программы Университета да и prolog не забыт, кста вот о чем нада говорить, за ним будущее )
на форуме как-то говорили, что lisp — функциональный язык раннего типа (т.е. недоделка ), а пролог — не вляется ФЯ
так что вероятней было бы утверждать, что всё же не изучают
Здравствуйте, sardonyx, Вы писали:
S>ну вообще то lisp включён в учебные программы Университета да и prolog не забыт, кста вот о чем нада говорить, за ним будущее )
Пролог уже прошлое. Современность — это системы логики высшего порядка, написанные, разумеется, на диалектах ML.
Re[9]: Почему никто не использует функциональные языки
Здравствуйте, mister-AK, Вы писали: MA>Я хоть и не ярый противник всего живого (включая ФП), но любители SQL (хотя есть менение, что он на ФЯ) это -. MA>Всегда не понимал, как приживаются эти бейсикообразные монстры
Это ты про кого?
... << RSDN@Home 1.1.4 beta 1 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[16]: Почему никто не использует функциональные языки
на форуме как-то говорили, что lisp — функциональный язык раннего типа (т.е. недоделка ), а пролог — не вляется ФЯ MA>так что вероятней было бы утверждать, что всё же не изучают
Так можно про что угодно сказать, но тому же императивному (как тут говорится) обучают на примере дремучего Виртовского Паскаля, да и вообще машина Тьюринга рулит
А лисп он как паскаль, если можно так сказать , для обучения самое оно будет — ничего лишнего. Да и потом необходимо растить новое поколение пользователей самого мощного редактора не свете — emacs
а пролог, ах пролог... я и не говорил что это фунциональный язык, я просто думаю, что если б его преподавали/обучали в необходимом объёме, то это давало бы надежду что человек-инженер-программист не бросится сразу решать задачу в рамках одного императивного (читай basic/fortran что там ещё) подхода, а немного подумает. А так весь этот спор похож на спор кто круче бэтмен vs человек паук или windows vs linux...
Здравствуйте, Gaperton, Вы писали:
G>Что-то помутнение сознания случилость. Вот как надо. G>
G>median( L ) -> lists:nth( random:uniform( length( L ) ) - 1, L ).
G>
В Haskell за счет sinctactic sugar выглядело бы лучше, зато так понятнее для непривычных
let rec qsort pivot_fun comp_fun lst = match lst with
| [] -> [] (*Пустой список не сортируем*)
| _ -> let pivot = pivot_fun lst in
match List.partition (fun x -> pivot = x) lst with (*Отделяем элементы, равные pivot.*)
(lsteq, lstneq) ->
match List.partition (comp_fun pivot) lstneq with (*Из не равных отделяем элементы, большие pivot и меньшие.*)
(lst1, lst2) ->
(* Сортируем не равные и склеиваем *)
List.concat [qsort pivot_fun comp_fun lst1; lsteq; qsort pivot_fun comp_fun lst2]
let rnd_pivot_fun lst = List.nth lst (Random.int (List.length lst)) (*Рандомный pivot*)
let num_comp_fun a b = a > b (*Аримфметическое сравнение*)
let qsort_num_rnd = qsort rnd_pivot_fun num_comp_fun
Скомпилено и работает. Хотя на C# или С++, возможно, получился бы почти столь же краткий и понятный код
Кто-нибудь напишет?
Re: Почему никто не использует функциональные языки
Я в данный момент как раз решил серьезно ознакомиться с этим направлением в программировании, так что мне пока мало чего есть сказать — за скудностью знаний
Вместе с тем, считаю, что функциональное программирование имеет перспективы.
1. Итак, компьютеры стали быстрыми, производительность уже маловажна. Вместе с тем, индустрия склоняется в сторону многопроцессорных (многоядерных) конфигураций. Производители компиляторов и прочие заинтересованные лица тут же этим заинтересовались, что привело к появлению того же OpenMP.
Функциональный язык в самой своей основе лучше распараллеливается автоматически. Вообще без какого-либо OpenMP. Вообще, оптимизация для ФЯ видится значительно более действенной.
2. Императивная индустрия программирования научилась переносимости ((D)COM, CORBA, XML, Web-Services), а реальные проекты стали чаще использовать несколько языков одновременно. Выросли обземы жестких дисков, появились средства дистрибуции высокой емкости (CD, DVD), появился широкополосный доступ в Internet. Т.е. теперь никто не мешает включить в свой продукт модули, написанные на функциональных языках. Хоть 10 модулей, каждый — на новом языке, а к кажому языку — runtime мегабайт на 20!
3. Одновременно, судя по беглому обзору, функциональные языки стабилизировались и даже появились стандарты, что провоцирует накопление переносимых библиотек, появление специалистов по стандартным языкам и популярным библиотекам (специалиста по кустарной библиотеке и собственному диалекту ФЯ никто искать не будет — ибо таких естествено нет).
4. Постепенно облегчается создание компиляторов, например при переносе на другие платформы ms .net, код, сгенерированный на IL, будет работаь и на этих платформах, причем получит всю необходимую оптимизацию. Кроме того, так как компиляторы обычно пишут на компилируемом языке, поддерживать такой компилятор/IDE становится легче по вышеуказанным пунктам — язык стабилизировался, много разных библиотек.
5. Чтобы там ни говорили, а образование программистов во всем мире растет, так же как и количество программистов, т.е. растет потенциальная аудитория функциональных языков. Императивное программирование с каждым годом становится все более высокоуровневым, и поэтому рано или позно у ФЯ будут коммерческие пользователи в количестве, достаточном для появления рынка труда. Причем, так как на ФЯ будут поначалу программировать довольно квалифицированные программисты, в разных журналах IEEE будет появляться статистика типа "90% проектов на ФЯ оказываются успешны!!!".
*. Человеческий язык (естественный) оказывает сильнейшее влияние на образ и качество мышления. Похожая ситуация складывается и с языками программирования. Поэтому программисту полезно знать несколько языков, точно так же как врачи считают, что изучение иностранного языка стимулирует мозг. Программируя на функциональном языке, программист будет больше думать, вместе с тем, благодаря тренировке, останется производительным, но зато будет делать меньше ошибок. Это не может не радовать.
-. Современный программист пишет обыно не для себя, и не для атомного реактора, прогаммист пишет для людей. Пишет прикладные программы — с менюшками и диалогами, так как программы эти предназначены для людей, а не докторов наук, а потому правильный ФЯ должен позволять программировать эти диаложки с такой же легкостью и императивностью, как и Delphi & C#.
Здравствуйте, faulx, Вы писали:
F>На вас не угодишь. А так понятнее? F>
F>foreach func list
F>
Да не очень то. От обычного мировозрения это очень сильно отличается.
F>Выскажу парадоксальную мысль. Если в вашей программе на ФЯ встречается рекурсия, значит, почти наверняка вы делаете что-то неправильно.
Да рекурсия там постоянно. Просто она подразумевается. Я о другм. Я хочу декларативности не ограниченой правилами языка или парадигмой.
F>Дело в том, что с каждым ФЯ идет в поставке богатая библиотека и вся рекурсия спрятана в функциях этой библиотеки. Чтобы обработать список, никакой рекурсии не надо, вполне достаточно стандартных функций. В качестве аналога можно привести алгоритмы STL — при повсеместном их использовании количество циклов в программе на С++ резко сокращается.
Мышение все равно унжно менять на рекурсивное.
F> Вообще, STL — это такой маленький и уродливый аналог библиотеки ФЯ.
Уродливый он по другим причинам. Просток как всегда с помощью С++ пытаются сделать, то на что он не рассчитан.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: Почему никто не использует функциональные языки
G>quicksort( [ H | T ] ) -> [ X || X <- T, X <= H ] ++ [ H ] ++ [ Y || Y <- T, Y > H ];
G>quicksort( [] ) -> [].
G>
Ну, и много так можно выиграть? А читается именно как ассемблер. Вот тебе тоже самое на ИЯ:
static void QuickSort<T>(T[] item, int left, int right)
{
int i = left;
int j = right;
T center = item[(left + right) / 2];
while(i <= j)
{
while (item[i] < center)
i++;
while (item[j] > center)
j--;
if (i <= j)
{
T x = item[i];
item[i] = item[j];
item[j] = x;
i++;
j--;
}
}
if(left < j)
QuickSort(item, left, j);
if(right > i)
QuickSort(item, i, right);
}
Сделай у себя названия понятные и коментариев добавь и будет тоже самое. Зато можно оптимизировать как хочешь. А когда будешь приенять, то разницы вообще не будет.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
А вот со вторым у OCaml явные напряги
да и prolog не забыт, кста вот о чем нада говорить, за ним будущее 
)
), но любители SQL (хотя есть менение, что он на ФЯ
