Комментарии 50
Спасибо, достойный перевод, статья и правда наделала много шума какое то время назад ))! Кстати так же отличный тест на наличие ч.ю.
Статья забавная. Но, думаю, зачастую проблема в не в том, что «я не хочу», а в том, что в ентерпрайзе не так просто перейти на функциональный язык в проекте, которому 5+ лет.
Я считаю в этом нет смысла вообще. Тот же LINQ сводит все преимущества ФП на нет.
Я большой любитель linq-а, и с вами частично согласен. Но, все-таки, он один не спасает от излишней многословности. Или, например, методы-расширения, которые также должны бы были привнести преимущества функциональщины, по факту не так хорошо работают из-за внушительного синтаксического шума.
Но, в конечном счете, вопрос действительно сводится к тому, кому нравятся скобочки, а кому — нет.
Но, в конечном счете, вопрос действительно сводится к тому, кому нравятся скобочки, а кому — нет.
LINQ вообще-то очень функциональная штука, гуглите «functional reactive programming». Пчелы против мёда прям.
А как же ADT?
Сомневаюсь что именно «все». Но многие. Скорее это напоминает другой потенциально холиваристый тезис «что только не придумают, чтоб не заставлять людей изучать ФП»;-).
В том же LINQ не хватает очень многих вещей по сравнению с модулем Seq из F#. Seq.pairwise, Seq.scan, Seq.windowed, например.
Это все можно достаточно легко добавить самому, но отсутствие их из коробки удручает.
Это все можно достаточно легко добавить самому, но отсутствие их из коробки удручает.
Спасибо, порадовало
А я прочитал первые две причины и сразу же возмутился, собрался уже было писать комментарий с критикой статьи. Потом перестал тупить и ещё раз перечитал предисловие =D
Пункт 2 убил.
Пункт 3 тоже неплох, тот ещё холивар ведь.
Пункт 3 тоже неплох, тот ещё холивар ведь.
Прямо захотелось взять и продолжить ударными темпами изучение Хаскеля!
Конечно, это достаточное время для геолога, но в эпоху интернета, 7 лет — это просто мгновение ока.
Этот абзац весьма спорный в оригинале, а автор перевода еще и усугубил эффект спорности, выбросив слово «возможно» после слова «конечно».
Пофиксил, здесь какое-то жёсткое преувеличение, но видимо в этом суть их юмора.
Я сейчас всё тщательно обдумал, и решил, что предложение вполне в духе общего сарказма статьи, но без слова «возможно» — явный перегиб палки.
В российской прессе цитировали несколько лет назад одного американского образовательного чиновника, что «Если английский был хорош для господа нашего Иисуса Христа, то он хорош и для меня, и для наших детей», так что поэтому в его (образовательном) раёне иностранные языки не изучаются. Думаю, они такого «воинствующего самоуверенного озарплаченного незнания» (типа кого волнует, что функциональный язык на самом деле LISP появился в 1958 году?) в исполнении своих соотечественников наблюдают раз в 100 больше и стёб и юмор над таким «озарплаченным незнанием» (в стиле «за что платят деньги — то и есть истина») давно стал частью их культуры.
А я вот думаю, что фигурные скобки всё же лучше, чем структурирование отступами. В отечественной печати мне доводилось видеть листинги кода на языке с «отступным структурированием», которые немало пострадали от того, что верстальщики книги не имели понятия о значимости количества начальных пробелов. Имели эти листинги такой вид, что впечатлительный читатель мог бы, вероятно, при виде их тотчас же уткнуть лицо в ладони и разрыдаться в голос. (Правда, впечатлительным людям в программировании вообще бывает тяжко.)
А ещё я вот думаю, чтокод «ss=: +/ @: *:» выглядит довольно страшно. Авторы его наверняка вдохновлялися брэйнфаковскою записью кода.
А ещё я вот думаю, что
Не страшно, а слишком абстрактно.
Ну, это выглядит почти как регулярка, а регулярки, они это — страшные..
Под термином «страшно» следует понимать «не читабельно».
Под термином «страшно» следует понимать «не читабельно».
Регулярные выражения вынужденно имеют такую форму: для них главным достоинством является предельная (и даже запредельная) компактность, потому что их поневоле приходится засовывать между буквами и другими частями обыкновеннейших строковых данных.
А вот когда проектанты языков программирования стремятся и остальным операторам придавать запредельно краткую форму, то получаются у них только очередные брэйнфаки, не более.
А вот когда проектанты языков программирования стремятся и остальным операторам придавать запредельно краткую форму, то получаются у них только очередные брэйнфаки, не более.
Что в регулярках добивает, так это отсутствие переменных или других каких-нибудь путей повторного использования;-)…
Обратные ссылки, не?
Ничто не мешает разбить регулярку на куски в виде переменных, дать этим кускам имена, и «повторно использовать» их конкатенацией. Не хватает только рекурсии.
Рекурсия есть, но не везде. Я знаю только о perl и PCRE. Учтите, что рекурсия в регулярных выражениях невозможна по определению (если не ошибаюсь, то использование ссылок (
(a*)\1 для нахождения вхождения чётного количества a в строке), также невозможно). Только регулярные выражения в большинстве движков уже давно не регулярные.Я имел в виду — нет возможности организовать рекурсию между этими кусками, во всяком случае, простым образом. Т.е. чтоб кусок регулярки под именем «a» мог сматчить «b», а тот в свою очередь снова «a».
Есть:
(zyx-desktop:zyx:~) 3 % echo 'abbabaa' | perl -p -i -e 's/(a(?2)*)(b(?1)*)/1($1)2($2)/'
1(abba)2(baa)Если что, то их можно также именовать:
(zyx-desktop:zyx:~) 3 % echo 'abbabaa' | perl -p -i -e 's/(?<fst>a(?&snd)*)(?<snd>b(?&fst)*)/1($1)2($2)/'
1(abba)2(baa)(zyx-desktop:zyx:~) 3 % echo 'abbabaa' | perl -p -i -e 's/(a(?+1)*)(b(?-2)*)/1($1)2($2)/'
1(abba)2(baa)-2 потому, что считаются открывающие скобки, соответствующие захватывающим группам, в заданном направлении.В perl и PCRE можно использовать рекурсивные регулярные выражения: простейший пример:
В perl также можно вставлять в регулярное выражение куски кода, которые будут выполнены во время сравнения регулярного выражения со строкой (
echo '((((()))))' | grep --color=always --perl-regexp '\((?R)?\)' подсветит вам все скобки (при условии, что grep собран с поддержкой PCRE). Можно ссылаться как на всё регулярное выражение (как в моём примере), так и на конкретную именованную или нумерованную группу.В perl также можно вставлять в регулярное выражение куски кода, которые будут выполнены во время сравнения регулярного выражения со строкой (
(?{code}) и (??{code})), но использование этой возможности не является хорошей идеей (в perldoc perlre в первом абзаце описания даже стоит предупреждение).
У меня основная проблема не в абстракции или длине. Как вот эту вот кракозяблину назвать? А как назвать <*>, <**> и >>? Что прекажете делать на ревью, вообще в любом техническом разговоре?
Ещё часто автары разнообразных вдохновляющих статеек даже не эти безымянные операторы используют а их типографские прототипы, лишая скромного читателя возможности их гениальный код собственно запустить. Вот и думаешь оно для программирования сделано или для повышения ЧСВ?..
Ещё часто автары разнообразных вдохновляющих статеек даже не эти безымянные операторы используют а их типографские прототипы, лишая скромного читателя возможности их гениальный код собственно запустить. Вот и думаешь оно для программирования сделано или для повышения ЧСВ?..
По той же причине не понимаю, как питонщики читают код длиной более одного экрана
Ага, бьют на подподподпроцедурки. Так и приходилось делать
А что насчёт шаблонов для веб-сайтов? Как понимаете, разметка для удобства чтения выравнена по тегам HTML, без скобок будет сложно
Решение — использовать шаблонизаторы
Ага, бьют на подподподпроцедурки. Так и приходилось делать
А что насчёт шаблонов для веб-сайтов? Как понимаете, разметка для удобства чтения выравнена по тегам HTML, без скобок будет сложно
Решение — использовать шаблонизаторы
Я бы поспорил насчет подразумеваемого факта, что «подподподпроцедурки» — это плохо. И уж тем более что процедуры более одного экрана — это хорошо.
есть еще отличное решение — экран побольше ) Но вообще никаких проблем не имею, хотя не могу сказать что приходилось на питоне писать что то достаточно объемное. Ну и свертка кода помогает в запущенных случаях.
Если метод или функция занимает больше экрана (85 строк в моем случае), то уже и скобочки не помогут. С другой стороны, в нормальных редакторах блоки дополнительно выделяются либо в области номеров строк, либо прямо по отступу блока.
Поэтому проблема сильно преувеличена.
Поэтому проблема сильно преувеличена.
А ещё я вот думаю, что код «ss=: +/ @: *:» выглядит довольно страшно. Авторы его наверняка вдохновлялися брэйнфаковскою записью кода.На самом деле, философский вопрос — что лучше: компактность или читаемость. По мне, лучше IDE с хорошим парсингом и хорошей подсветкой синтаксиса;-) (т.е. компактность и правильность в сочетании со средствами искусственного повышения способности читать;-) ) Не знаком глубоко с J и K, но, подозреваю, пропустить один оператор так, что компилятор не посчитает это ошибкой, и потом нудно отлавливать баг при отладке — в таких языках ситуация реальная. Если же язык стековый, где фактически вся программа — один сплошной оператор и скобок нет, то всё становится ещё веселее.
А в F# «отступное структурирование»? В исходном OCaml его не было.
Так-так-так. Значит мы тут пропагандой функциональщины и оскорблением чувств императивщиков занимаемся?
Только прочитав первую причину, попытавшись потом прочитать оригинал и ухватив глазами «Reason 2: I get paid by the line», я понял, что это ирония…
7-я причина не такая уж и смешная. Прототипы на Haskell-е писать не так удобно, как, к примеру, на том же Ruby.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Десять причин не использовать статически типизированный функциональный язык программирования