LINUX.ORG.RU

стоит ли изучать функциональные языки программирования?


0

0

Здравствуйте.

Вот, думаю, изучать функциональные языки программирования или нет? В данный момент умею программировать на C (в том числе и кернел-спейс). Кто чего скажет?

Кто может объяснить, чем они лучше/хуже императивных языков программирования?

anonymous
Ответ на: комментарий от swizard

>> Там ведь там руководствуются размером кода и понятностью, примеры же для новичков приводятся.

И обычно сопровождаются комментарием типа "почуствуйте мощь хаскеля". Я не против хаскеля, просто мне не всегда понятен PR вокруг него.

cathode
()
Ответ на: комментарий от stassats

> Как-то в наше время уже беспокоиться о производительности особо не приходится.

Ты не из тех. кто Висту писАл? :D

tailgunner ★★★★★
()
Ответ на: комментарий от cathode

> И обычно сопровождаются комментарием типа "почуствуйте мощь хаскеля".

Я что-то не пойму, ты предлагаешь сравнивать чистый хаскель как язык с другим языком + багаж библиотек :)

А ты на простых примерах сравни хаскель и чистый C++ (без STL, Boost и пр.), или хаскель и C# (без .NET вообще), или даже c C без libc =) Почувствуйте мощ хаскеля =)

swizard
()
Ответ на: комментарий от swizard

А практическая польза от сравнения "чистых" языков в чем? Давай тогда сравним не просто сортировку, а in-place сортировку массива (списка) - то в чем приемущество C и скажем что С круче. Честно говоря я не представляю себе код в две строчки на хаскеле в таком случае и без монад, а с ними особых отличий по совершаемым действиям не будет.

О чем это говорит? Что сравнения либо необъективны либо просто бестолку сравнивать читый вариант (читай синаксис). Мощь языка инересна в конкретном примере разработки конкретного софта, а не в программах типа Hello World. Для примера можно взять исходники того же GHC. Я бы не сказал, что они (исходники) прям таки так просты и элегантны.

cathode
()
Ответ на: комментарий от stassats

> Ты не из тех, которых называют троллями?

Это виднее со стороны.

А Висту писали люди, которые о быстродействии не заботились - как ты.

tailgunner ★★★★★
()
Ответ на: комментарий от cathode

> А практическая польза от сравнения "чистых" языков в чем?

Ну есть такие понятия, как "мощность", "лаконичность" и "выразительность" языка.

В качестве примера можешь посмотреть выше, как я переписал (define (inc-n n) (lambda (x) (+ x n))) на Си :) Никто же не скажет, что на Си нельзя вернуть замыкание (я ведь вернул). Но сравни лаконичность и универсальность обоих решений.

swizard
()
Ответ на: комментарий от swizard

Я не спорю, что лисп в таком примере выигрывает. Но опять же, чистый ФЯ сам по себе штука бесполезная хотя и интересная. Как только речь начинает идти о реальных программах, то без всяческих ухищрений типа монад уже не обойтись, а тут выгод нет никаких, а для многих разделов типа системного программирования ФП просто не нужно. Добавь к этому сложность отладки программ на ФЯ - это возможно одна из причин почему ФЯ так и остались в основном маловостребованы.

В итоге получаем, что лакончиность и выразительностья языка - это еще не все что нужно. И пожалуй ФЯ только в этом и выигрывают, проигрывая во всем (во многом) остальном. Я сознательно опустил "мощность" т.к. смысл термина можно трактовать слишком широко.

cathode
()
Ответ на: комментарий от cathode

> Как только речь начинает идти о реальных программах

Всегда интересно было, что люди вкладывают в это понятие :) Вот, например, есть товарищ Булат, который пишет архиваторы на хаскелле, изредка инжектя куски на Си в критичных местах: http://haskell.org/bz/. Это реальные программы? :)

> типа системного программирования ФП просто не нужно

Опять же, есть товарищ Сергей, который умудрился как-то аж эмулятор процессора сделать на хаскеле: http://thesz.livejournal.com/tag/%D0%BC%D0%BE%D0%B4%D0%B5%D0%BB%D0%B8%D1%80%D...

Куда уж системнее? :)

> сложность отладки программ на ФЯ

Ну вот это уже совсем вызывающе неверная информация :) Hint: результат функции зависит только от ее параметров, так как глобальное состояние отсутствует. Ну и добавь к этому еще такую мощнейшую штуку, как REPL.

> И пожалуй ФЯ только в этом и выигрывают, проигрывая во всем (во многом) остальном.

А что еще надо глобального, кроме лаконичности и выразительности? Я честно не понимаю, почему люди кругом повально убеждены, что исходник Java или Python понятнее и безошибочней, чем какой-нибудь Perl. Так оно и есть для человека, не знающего ни Java, ни Perl. Но в реальной жизни они и не читают коды. Я вот утверждаю, что человек, хорошо знающий Perl, напишет большую программу на Perl быстрее, стабильней и с меньшим количеством ошибок, чем человек, хорошо знающий Java на Jav'e :) Как минимум, из-за того что руками писать придется в десять раз меньше.

swizard
()
Ответ на: комментарий от swizard

> Опять же, есть товарищ Сергей, который умудрился как-то аж эмулятор процессора сделать на хаскеле:

> Куда уж системнее? :)

При всем уважении к работе thesz - это не системное программирование ни разу.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

> это не системное программирование ни разу.

Да собственно, какая разница? Есть реальные доказательства, что работа с устройством на ФЯ вполне реальна и удобна. Если сделают быструю/надежную _реализацию_ компилятора / интерпретатора ФЯ, то будет иметь смысл отказаться от Си в этой области.

swizard
()
Ответ на: комментарий от swizard

>> Вот, например, есть товарищ Булат, который пишет архиваторы на хаскелле

Ну мало ли... Я его не знаю и не могу прокомментировать почему он написал свой FreeArc на хаскеле. Может его от этого просто прёт ;), btw он не только на хаскеле пишет, но и на плюсах (судя по ссылке), с чего бы? ;) Необъективно.

>> результат функции зависит только от ее параметров

Любый функции пишут люди. Что мне мешает ошибиться при написании функции на хаскелле?

>> А что еще надо глобального, кроме лаконичности и выразительности?

А что ты вкладываешь в понятие лаконичности и выразительности? По мне "язык" которым я программирую стиральную машину, выставляя режим стирки, тоже лаконичный и выразительный ;). ИМХО эти понятия относительны.

>> Сергей, который умудрился как-то аж эмулятор процессора сделать на хаскеле

>> Куда уж системнее? :)

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

cathode
()
Ответ на: комментарий от swizard

> Есть реальные доказательства, что работа с устройством на ФЯ вполне реальна и удобна.

Если они и есть, работа thesz к ним не относится. Он занимался _имитацией железа_, а не работой с ним.

> Если сделают быструю/надежную _реализацию_ компилятора / интерпретатора ФЯ, то будет иметь смысл отказаться от Си в этой области.

Вряд ли. Любой ФП сопровождается очень нетривиальным рантаймом, так что от Си если и откажутся, то не скоро. Это уже не говоря, что настоящих realtime сборшиков мусора пока что не существует.

tailgunner ★★★★★
()
Ответ на: комментарий от swizard

>> Я вот утверждаю, что человек, хорошо знающий Perl, напишет большую программу на Perl быстрее, стабильней и с меньшим количеством ошибок, чем человек, хорошо знающий Java на Jav'e :)

Ну я надеюсь ты не ждешь что я буду это опровергать или соглашаться? :)

cathode
()
Ответ на: комментарий от Laz

> можно, пожалуйста, пример функции высшего порядка на сях?

Можно. man 3 qsort

watashiwa_daredeska ★★★★
()
Ответ на: комментарий от cathode

> обычно сопровождаются комментарием типа "почуствуйте мощь хаскеля". Я не против хаскеля, просто мне не всегда понятен PR вокруг него.

Значит ты не понял мощь Хаскеля и не застал те светлые времена, когда в книжках по C писали "почувствуйте мощь C" (в сравнении с asm, PL/1, whatever). А в книжках по C++ так и вообще только-только перестали писать эту фразу, кивая на C.

watashiwa_daredeska ★★★★
()
Ответ на: комментарий от watashiwa_daredeska

> в книжках по C писали "почувствуйте мощь C" (в сравнении с asm, PL/1, whatever)

Не надо гнать, не было такого :D Не говоря уже о том, что PL/1 - язык гораздо более мощный, чем Си.

tailgunner ★★★★★
()
Ответ на: комментарий от watashiwa_daredeska

Застал, почему же нет. Я бы удивился если бы в книжках по Си писали почувствуйте мощь Хаскеля. Или если бы в рекламе кока-колы рекламировали фанту. А в результате оказывается, что не все йогурты одинаково полезны :)

cathode
()
Ответ на: комментарий от tailgunner

>> Не говоря уже о том, что PL/1 - язык гораздо более мощный, чем Си.

Вот именно, что "не говоря". Помолчим... :)

cathode
()

Товарищи, не путайте парадигмы. Кроме того, очень важно какой вид ФП "чистый" или "смешанный" используются. Вообще, это разные измерения. Сравнивать декларативный "чистый" ФП хаскель и императивным процедурным С просто некорректно.

Преимущества у хаскеля есть, но чтобы их оценить по достоинству нужно забираться в дебри математики, которые даже _сами_ _математики_ (!) называют абстрактными, что для простого смертного означает абстрактные-в-квадрате. К сожалению, необходимые занния можно получить исключительно на матфаке и вообще, обладать определенным складом ума.

Мало того, еще нужно привыкнуть к тому что в хаскеле нет разделения на функции и данные. Но поскольку мы живем в реальном мире, и обычно работаем с данными в _их физическом представлении_ (память, файлы, сеть, базы данных), то необходимо их привести наиболее просто и эффективно к такому логическому представлению, которое не будет конфликтовать с "чистым" ФП. И методы с наработками, применяемые в императивном мире тут не работают. Нужно постигать все практически и нуля. В данный момент для меня это самое большое препятствие в повсеместном использовании хаскеля, нужно время все обдумать.

Теперь давайте посмотрим правде в глаза. Вы умеете работать с рекурсивными структурами данных? Вы понимаете понятие "комбинатор"? Вы можете свободно думать в point-free-style?

Так что не надо разудвать топик, сравнивая несравниваемое и определять крутость языка по возможности его использования в системном программировании.

Macil ★★★★★
()
Ответ на: комментарий от Macil

> Вы умеете работать с рекурсивными структурами данных?

Деревья подойдут? Тогда умеем.

> Вы понимаете понятие "комбинатор"? Вы можете свободно думать в point-free-style?

Мы думаем, что это эффектные выражения, скрывающие простые вещи.

tailgunner ★★★★★
()
Ответ на: комментарий от Macil

Macil, ты не прав.

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

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

Не знаю как кажется другим, но понятия комбинатор (в дргой интерпретации оператор) и понятие рекурсии относительно к способу представления данных или работы с ними ИМХО элементарны.

И как еще определить крутость языка, кроме как по его широкопрофильности? Хотя бы в первом приближении?

cathode
()
Ответ на: комментарий от cathode

> как еще определить крутость языка

А ее надо определять?

> по его широкопрофильности?

Как определен термин "широкопрофильность"?

watashiwa_daredeska ★★★★
()
Ответ на: комментарий от cathode

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

anonymous
()
Ответ на: комментарий от anonymous

Я добиваюсь объективности оценки возможностей тех или иных средств разработки, в частности пытаюсь донести мысль, что ФП в _среднем_ не дает никаких приемуществ перед ИП при реализации некой абстрактной программы, непнятно что и как делающей. К сожалению объективностью оценок не страдают даже книги. У ФП своя ниша, где его наиболее выгодно испоьлзовать, и не понимать этого - значит не знать зачем вообще создаются те или иные парадигмы и языки (не просто ж так, чисто по приколу, а?). У хаскеля есть свои сильные и слабые стороны, у Си есть, у кобола есть, у перла есть, у смалтолка есть, у всех есть - это понятно надеюсь? Хотя многие языки и позиционируются как языки общего назначения, это не значит что ими можно все дырки заткнуть, это значит что ими можно заткнуть дырок больше, чем узкоспециализированными языками и хаскель в этом не исключение.

cathode
()
Ответ на: комментарий от watashiwa_daredeska

>> А ее надо определять?

Ну видимо кому-то надо, раз народ меряется факториалами ;)

>> Как определен термин "широкопрофильность"?

"Универсальность" - так понятнее?

cathode
()
Ответ на: комментарий от cathode

>"Универсальность" - так понятнее?

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

DonkeyHot ★★★★★
()
Ответ на: комментарий от watashiwa_daredeska

> Современные ЯП общего назначения являются тьюринг-полными, а значит универсальны

Если ты считаешь Тьюринг-полноту универсальностью, значит, ФП зохавало твой моск. Hint: brainfuck, INTERCAL.

anonymous
()
Ответ на: комментарий от swizard

> А ты на простых примерах сравни хаскель и чистый C++ (без STL, Boost и пр.), или хаскель и C# (без .NET вообще), или даже c C без libc =) Почувствуйте мощ хаскеля =)

STL является частью стандарта языка C++. Большая часть Boost -а не нужна.

А то давай сравним C++-без-STL-я-и-libc с Haskell-без-Prelude. Что-то мне подсказывает, что в обоих случаях все плохо. Причем Haskell-у хуже, потому что из плюсов можно дергать систему напрямую (для IO, хотя бы), а из Haskell - фигвам.

anonymous
()
Ответ на: комментарий от anonymous

> Если ты считаешь Тьюринг-полноту универсальностью, значит, ФП зохавало твой моск. Hint: brainfuck, INTERCAL.

Т.е. ты считаешь их специализированными языками? И для какой же узкой области они предназначены? ;)

По-моему, вполне универсальные языки - на них все делать одинаково сложно.

И ты забыл Malbolge ;-)

anonymous
()
Ответ на: комментарий от anonymous

>> Если ты считаешь Тьюринг-полноту универсальностью, значит, ФП зохавало твой моск. Hint: brainfuck, INTERCAL.

>Т.е. ты считаешь их специализированными языками?

O_O

Нет, я не считаю их универсальными. Я считаю, что отождествлять Тьюринг-полноту и универcальность - глупая идея, которую могут выдвигать только фоннатеги ФП в полемическом угаре.

> И ты забыл Malbolge ;-)

Да и ты много чего забыл :)

anonymous
()
Ответ на: комментарий от watashiwa_daredeska

>> Нет. Современные ЯП общего назначения являются тьюринг-полными, а значит универсальны.

Хорошо, термин "безгеморность" устроит отца советской демократии?

cathode
()

>Вот, думаю, изучать функциональные языки программирования или нет?

Конечно! Изучать однозначно!

Ведь изучив их ты сможешь целыми днями философствовать на тему "чем они лучше/хуже императивных языков программирования" в этом форуме.

KIV
()
Ответ на: комментарий от anonymous

> Если ты считаешь Тьюринг-полноту универсальностью

Отлично, продолжаем уточнять. Широкопрофильность = универсальность. Тогда что такое универсальность?

watashiwa_daredeska ★★★★
()
Ответ на: комментарий от cathode

> Хорошо, термин "безгеморность" устроит отца советской демократии?

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

watashiwa_daredeska ★★★★
()
Ответ на: комментарий от watashiwa_daredeska

>> Не видел ни одного безгеморного языка. Только геморрой у каждого свой и в разных случаях. Поэтому я стараюсь, по возможности, выбирать наиболее безгеморный язык в каждом случае.

ВОТ И Я ОБ ЭТОМ ТВЕРДЮ УЖЕ ВТОРОЙ ДЕНЬ!!!!

cathode
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.