Да не будет мир жить по-другому, это все гипотетические рассуждения.
А вот что точно есть — это то, что в большинстве своем люди не будут покупать музыку, которую скачали нахаляву. И все рассуждения о том, что, мол, если мне понравится, то я и так куплю — профанация. Да, может один диск или два купишь. Это же Битлз (металлика/бетховен/бах/бабах), оооо, это надо купить. А вся остальная будет бесплатно использоваться под одобрительное хрюканье MP3-плейера.
Аргументы подобного рода были известны еще древним расовым грекам, и получили название ad hominum tu quoque. Суть его заключается в том, что оппонент вместо того, чтобы рассуждать о предмете спора (нелегальное использование контента) переводит разговор на личность оппонента. Как вы понимаете, к истине это не приближает обоих ни на йоту.
Я с вами согласен. Вообще, по-моему, использование кодов возврата в эпоху освоения космоса и дешевого интернета — дичь. Естественно, под «кодом возврата» я подразумеваю неочевидные данные. Например, такая функция (довольно часто раньше я так писал):
bool login(username, password)…
Что нам говорит код возврата? «Логин не удался». Никакой конкретной информации. А уж конструкции вида if (! login())… еще сильней добавляют туману.
Другое дело, когда «код возврата» — суть некое смысловое значение (например, int getHttpError() ...).
Поэтому, с моей точки зрения, исключениям — быть. Единственное, что неудобно — это отсутствие в пыхе возможности спецификации исключений, наподобие ветки throw в C++:
void f() throw (exception1, exception2) {… }
Приходится спасаться тегами PHPDocumentor'а, что все-же не так удобно.
> в более сложных случаях, лучше использовать функции
вы немного неправильно поняли эту фразу. Я имел в виду, что в более сложных случаях лучше использовать функции map, filter и reduce вместо list comprehensions :) Почему — потому что LC имеют свойство «теряться» в синтаксисе; слишком уж незначительны для нашего програмистского взгляда квадратные скобочки.
> И к тому же, я часто слышал упреки в более плохой читаемости кода в случае частого использования map(), reduce()
это лишь значит, что люди неправильно писали эти конструкции. Предлагаемый мой способ:
x = \
# filter something out
filter(lambda a: ...,
# convert something to something else
map(lambda a: ...,
# filter other odd things
filter(someNamedFunction,
....
data_entries)))))
Насколько яснее может выглядеть программа? :) Отступы нам показывают вложенность, последовательность операций читается сразу же, разве нет? Вы начинаете с самой вложенной операции и поднимаетесь вверх — и видите весь алгоритм.
> насколько часто используются функциональная парадигма в реальных программах на питоне (а не примерах)?
Ну, насколько часто используется структурная парадигма в ваших программах? Сколько процентов занимает в них ООП? Нужно понимать, что это тоже инструмент, который можно применять совместно с другими подходами. Вы используете map, filter или reduce? Или list comprehensions? Или генераторы (которые по сути являются continuations)? Если да, то вы уже использовали кусочки того, что мы называем «функциональным подходом».
> в более сложных случаях, лучше использовать функции
Да, будет гораздо медленней. Этим примером я просто хотел показать, что результат reduce — не обязательно одно значение (т.к. reduce чаще всего применяется именно для свертки списка в одно значение тем или иным способом), но может быть и список, например.
по-моему, это как раз та ситуация, когда перевод только усугубляет :) Наверное, лучше не переводить вовсе, а использовать «приблизительный» термин — такой как вы придумали, «описание списков», мне кажется вполне нормальным.
Как я и написал, с чистым ФП я дела не имел. Здесь, как я вижу, есть любители Хаскелла, они могут рассказать подробней.
Я занимался с Lisp, а Lisp — это мультипарадигменный язык. Самое сложное и красивое, что мне удавалось реализовать при помощи функционального стиля и что я ни за что не стал бы делать в императивной форме (поскольку мне дорог мой мозг как память) — это задача о семи ферзях. Она очень изящно реализуется рекурсией на списках. Кода не просите, т.к. это было очень давно. Могу лишь подсказать, что это была задача из SICP.
А так — ну это ж как бы не обязывающий ни к чему стиль программирования. Т.е. это можно использовать наряду с ООП и структурным подходом, если оно к месту.
На мой взгляд, ООП больше пригодна для программирования сверху-вниз (top-down design, т.е. когда сначала реализуется общая структура системы, а затем уточняются ее детали, реализуются методы и т.п.), в то время как функциональный стиль больше способствует подходу снизу-вверх (bottom-up design, когда сначала пишутся маленькие кусочки будущей системы, а потом синтезируются все более сложные ее части).
Так что, как заключение, я могу сказать что ФП — такой же стиль программирования, доступный каждому продвинутому программисту. Чтобы развеить «мифы» о том, что функциональный стиль и Lisp — чистое теоретизирование, могу посоветовать почитать книгу P. Siebel. Practical Common Lisp, а также M. Pilgrim. Dive Into Python (последняя не конкретно про функциональный стиль, но автор очень умело его использует, на мой взгляд; крайне советую почитать).
… и это не может не радовать. Все больше языков перенимают эти возможности, которые доступны программистам на Lisp или Haskell. Наконец-то рекурсия начинает становиться не чем-то непозволительно дорогим, а вполне рядовым инструментом программиста. Некоторые рантайм-окружения уже даже поддерживают оптимизацию хвостовой рекурсии (тот же CLR, например). На мой взгляд, производительность современных компьютеров дошла до той точки, когда можно применять данные методы без сильной оглядки на производительность.
Увы, некоторые возможности не будут реализованы еще долго — например, те же макры из Lisp. Если такое встроить в какой-нибудь C#, то по производительности это будет хуже, чем рекурсия во времена четырехкилобайтного стека.
Да, вы правы, есть термин «функции высшего порядка» :) Исправил. «Функции первого порядка» — тоже вроде как нет такого понятия, поэтому я их изменил на «простые функции»
А вот что точно есть — это то, что в большинстве своем люди не будут покупать музыку, которую скачали нахаляву. И все рассуждения о том, что, мол, если мне понравится, то я и так куплю — профанация. Да, может один диск или два купишь. Это же Битлз (металлика/бетховен/бах/бабах), оооо, это надо купить. А вся остальная будет бесплатно использоваться под одобрительное хрюканье MP3-плейера.
bool login(username, password)…
Что нам говорит код возврата? «Логин не удался». Никакой конкретной информации. А уж конструкции вида if (! login())… еще сильней добавляют туману.
Другое дело, когда «код возврата» — суть некое смысловое значение (например, int getHttpError() ...).
Поэтому, с моей точки зрения, исключениям — быть. Единственное, что неудобно — это отсутствие в пыхе возможности спецификации исключений, наподобие ветки throw в C++:
void f() throw (exception1, exception2) {… }
Приходится спасаться тегами PHPDocumentor'а, что все-же не так удобно.
<generator object at 0xb7bff54c>
ничего себе, век живи век учись. Первый раз такую конструкцию вижу, спасибо.
> в более сложных случаях, лучше использовать функции
вы немного неправильно поняли эту фразу. Я имел в виду, что в более сложных случаях лучше использовать функции map, filter и reduce вместо list comprehensions :) Почему — потому что LC имеют свойство «теряться» в синтаксисе; слишком уж незначительны для нашего програмистского взгляда квадратные скобочки.
> И к тому же, я часто слышал упреки в более плохой читаемости кода в случае частого использования map(), reduce()
это лишь значит, что люди неправильно писали эти конструкции. Предлагаемый мой способ:
x = \ # filter something out filter(lambda a: ..., # convert something to something else map(lambda a: ..., # filter other odd things filter(someNamedFunction, .... data_entries)))))Насколько яснее может выглядеть программа? :) Отступы нам показывают вложенность, последовательность операций читается сразу же, разве нет? Вы начинаете с самой вложенной операции и поднимаетесь вверх — и видите весь алгоритм.
Ну, насколько часто используется структурная парадигма в ваших программах? Сколько процентов занимает в них ООП? Нужно понимать, что это тоже инструмент, который можно применять совместно с другими подходами. Вы используете map, filter или reduce? Или list comprehensions? Или генераторы (которые по сути являются continuations)? Если да, то вы уже использовали кусочки того, что мы называем «функциональным подходом».
> в более сложных случаях, лучше использовать функции
На практике я, конечно, просто сделаю x.reverse()
Я занимался с Lisp, а Lisp — это мультипарадигменный язык. Самое сложное и красивое, что мне удавалось реализовать при помощи функционального стиля и что я ни за что не стал бы делать в императивной форме (поскольку мне дорог мой мозг как память) — это задача о семи ферзях. Она очень изящно реализуется рекурсией на списках. Кода не просите, т.к. это было очень давно. Могу лишь подсказать, что это была задача из SICP.
А так — ну это ж как бы не обязывающий ни к чему стиль программирования. Т.е. это можно использовать наряду с ООП и структурным подходом, если оно к месту.
На мой взгляд, ООП больше пригодна для программирования сверху-вниз (top-down design, т.е. когда сначала реализуется общая структура системы, а затем уточняются ее детали, реализуются методы и т.п.), в то время как функциональный стиль больше способствует подходу снизу-вверх (bottom-up design, когда сначала пишутся маленькие кусочки будущей системы, а потом синтезируются все более сложные ее части).
Так что, как заключение, я могу сказать что ФП — такой же стиль программирования, доступный каждому продвинутому программисту. Чтобы развеить «мифы» о том, что функциональный стиль и Lisp — чистое теоретизирование, могу посоветовать почитать книгу P. Siebel. Practical Common Lisp, а также M. Pilgrim. Dive Into Python (последняя не конкретно про функциональный стиль, но автор очень умело его использует, на мой взгляд; крайне советую почитать).
Увы, некоторые возможности не будут реализованы еще долго — например, те же макры из Lisp. Если такое встроить в какой-нибудь C#, то по производительности это будет хуже, чем рекурсия во времена четырехкилобайтного стека.