"Цель этой статьи максимально просто объяснить императивному программисту основы функционального программирования (далее ФП)."
-- императивный программист такой тупой, что ему нужно объяснять все максимально просто.
VD>Я тупым себя не считаю, но предпочитаю максимально простое и доходчивое изложение. Особенно это касается вещей которые затрагивают концептуальные вещи вроде парадигм программирования. В отличии от закоренелых фунциональщиков я еще прекрасно помню то недоумение и полное не понимание возникающее от формальный но на сквозь косноязычных объяснений которые я находил. Так что опять мимо кассы. Это не проблемы изложения или какой-то моей надменности, а проблемы твоей озлобленности.
Я тупой, мне подробно плиз.
Вообще такие популяризирующие предмет статьи надо писать:
— доходчиво и пространно (пусть лучше тот кто понял скипнет часть текста, чем тот кто не понял забьет читать дальше)
— живим язиком (что б не уснул читатель), шутки в тему приветствуются
Написанние так статьи читаются и воспринимаются намного бистрее тех, где сухо и мало буковок — приходится думать что автор имел ввиду.
Вобщем автору зачет. Прочитал статью на одном дихании.
В таком же духе надо и про Немерл и прочее ФП.
И для теста можно сначала давать читать статью слабо подготовленому читателю не в теме — ето ж для них пишется. Он и скажет — где непонятно.
Вообще же мало кто анализировал по каким причинам люди начинают читать и бросают. А жаль. Вот Влад молоток, вроде спрашивает у тех кто неосилил "на каком месте уснул?".
Здравствуйте, IO, Вы писали:
IO>Вообще такие популяризирующие предмет статьи надо писать: IO>- доходчиво и пространно (пусть лучше тот кто понял скипнет часть текста, чем тот кто не понял забьет читать дальше) IO>- живим язиком (что б не уснул читатель), шутки в тему приветствуются
IO>Написанние так статьи читаются и воспринимаются намного бистрее тех, где сухо и мало буковок — приходится думать что автор имел ввиду.
IO>Вобщем автору зачет. Прочитал статью на одном дихании.
Спасибо за поддержку. Просто огромной проблемой является то, что люди что-то уже знающие начинают воспринимать материалы созданные в расчете не на них как личное оскорбление. Все усугубляется если человек к тому же воспитан на строгом изложении.
Собственно, мне кажется, по этому ФП так плохо доходило до масс. Те кто питались рассказывать про ФП просто не могут рассказывать о нем доходчиво и просто. У них уже мозг перестроился так, что понять проблем других они не могут. Зато могут долго охать и ахать — почему же нас не понимают...
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Кажись eao197 подумал, что я тоже пытаюсь покритиковать Влада и наставил мне плюсов. Аж 21.
Eao! "Пустые понты достали уже..." относились больше к тебе. Теперь минусуй
Теперь чуть-чуть ответов.
S>>Изменение синтаксиса 3-м шарпе имхо стоит вынести в подраздел. VD>С какой целью? Чтобы было проще искать? Или чтобы ссылаться можно было?
Не угадал . Хорошо структурированную статью легче читать. Мозг автоматом учитывает переключение контекста.
S>>Статья получилась слегка раздутой из-за кучи вводной информации. Стоило либо разбить на несколько: делегаты и итераторы как они есть, замыкания, внутренняя реализация -> C# 3, заимствования из ФП, лямбды и т.п. -> идеология ФП -> LINQ и ФП. Или хотя бы поставить уровень отсечения — "идите читать матчасть, потом возвращяйтесь" и сосредоточиться на последних двух частях. VD>На то есть оглавление. Да и статья не такая большая чтобы ее резать. VD>Или речь об переупорядочивании разделов?
Да, смысл именно в том, чтобы структура отражала твой замысел и служила костяком. Типа так: Мы плавно подходим к теме А, но говорить о ней можно только после раскрытия тем Б,В, ну и чуть-чуть Г. Если вы в них сечёте — переходите дальше. Если нет — то можете кончно пролистать, но в любом случае вы ничего не поймёте. И по-хорошему идите учите матчасть.
Чтобы не было иллюзий. Оглавление, которое не висит постоянно перед глазами, не очень-то и помогает. Для меня быстрее прокрутить вниз, по ходу быстро сканируя текст, чем искать оглавление, искать в нём раздел и переходить туда. Для небольших статей, естественно.
S>>Ещё стоило бы завести подраздел про то, что любая технология — не панацея и привести ситуации, когда лучше применять конкретные подходы. Привести микротесты, рассказать что вызов _одиночного_ делегата (без списка вызываемых методов) по стоимости сопоставим с virtual call, и что в худшем случае падение производительности будет в 2-5 раз (и что с каждым сп к рантайму соотношение улучшается) в лучшем — будет незаметно из-за стоимости исполнения метода.
VD>Ну, это уже на отдельную статью тянет. Замечания по производительности конечно можно сделать. Но боюсь, что люди без опыта воспримут их не адекватно. Конкретные цифры тут ничего не покажут. Тут нужно понимать суть происходящего. Конечно замыкания и виртуальные вызовы не бесплатны, но предпочитать функциональному стилю императивный нужно очень взвешенно и акуратно иначе очень легко из-за своих фобий скатиться к повсеместному применению ИП просто на основании того, что оно быстрее.
Нуу... лично у меня долго было предубеждение, что попытка агрессивно использовать делегаты и итераторы приведёт к затыкам с производительностью. Но когда стал вопрорс "как делать будем" прокрутили микротесты и выяснилось что по накладным расходам делегаты и итераторы сопоставимы со стоимостью виртуального вызова. Поскольку такой перевес был некритичен — сляпали в ФП стиле с возможностью потом переписать, если припрёт. В другой ситуации мы вообще отказались от перебора и использовали словарик — как выяснилось там было очень критично время поиска, шёл агрессивный перебор и совать туда делегат было ну никак нельзя. Поэтому решилось созданием 4 перегрузок копи-пастом.
Ну и важны не попугаи, а соотношение в этих попугаях в каждом конкретном случае.
S>>Да! Если это серьёзная статья, постарайтесь обойтись без ехидства и левых наездов на быдлопрограммистов или на разработчиков типа "никто не знает почему". Научитесь уважать чужую работу. Особенно смешно выглядит, если читаешь блоги самих товарищей, где они подробно описывают дизайн языка и говорят что да, решение было не лучшим, но оно было оптимальным на тот момент. Вы ж не жёлтая пресса, чтобы стонать "ооо, как они неправы"
VD>1. Это не серьезная статья. Она так задумывалась. VD>2. Опять же больше конкретики.
1. Так бы и сказали
2. Конкретик хотите? Их есть у меня!
Про анонимные делегаты (кстати, мс и так и так их называет и в принципе раскрывает суть — создаётся делегат на метод; другого доступа к методу нет. Так что вполне нормальный термин):
Зачем их было называть методами, и почему им сделали столь неуклюжий синтаксис, остается загадкой.
...
Откровенно говоря, лямбда-выражения – это просто доведенные до ума анонимные методы.
...
очень часто можно было услышать, как анонимные методы называют «анонимными делегатами», хотя это в корне неверно
Вы уж придирайтесь предметно — то вам непонятно, почему называть методами, то называть делегатами в корне неверно. Почему без шапки?!!
Следующая цитата — вообще наезд на эмоциях:
При этом в Microsoft не придумали ровным счетом ничего нового. Примерно так выглядят лямбды почти во всех ФЯ. Так что совершенно непонятно, зачем было лепить в C# 2.0 этот безобразный, длинный и сбивающий с толку синтаксис. Понятно, что вывод типов был сделан только в C# 3.0, но, по крайней мере, все остальное-то точно можно было бы сделать сразу как в лямбда-выражениях!
После
Однако при проектировании .NET-делегатов был сделан ряд ошибок, которые сказались при развитии C# в сторону ФП.
...
Данное решение не создает особых проблем на практике, за исключением того, что вызов делегата медленнее, чем мог бы быть.
возникает желание предложить почитать Абрамса. Допустим, пост от февраля 2004 года. У Абрамса сотоварищи есть много статей, где описывается дизайн рантайма/BCL/шарпа. Перед дальнейшими наездами рекомендую ознакомиться. О производительности:
For those performance oriented among you, please note that if you have a MulticastDelegate that hasn’t been combined with any other delegates the CLR can optimizes for this case during dispatch and in how the JIT compiles the callsite….
Продолжаем.
Вторая ошибка дизайна создает куда больше проблем, нежели первая.
...
Так вот, делегаты не проектировались как функциональные типы, или хотя бы с мыслью об этом. Они проектировались как деталь реализации событий.
In the .NET Framework, callback functions are just as useful and as pervasive as they are in unmanaged programming for Windows®. However, the .NET Framework has the added bonus of providing a type-safe mechanism called delegates.
Делегаты проектировались как типизированая реализация callback-ов.
Если вы объясните, почему такая реализация приводит к принципиальной невозможности кастинга делегатов по сигнатуре — я принесу извенения и тихо удалюсь. Если нет — не наезжайте
Дальше.
Именно так обычно пишет код 90% императивных программистов. Причем чем больше нужно выполнить действий над элементами списка, тем больше и сложнее становится тело цикла (а так же его пролог и эпилог). Не мудрено, что в большинстве случаев такой код превращается в кашу.
Я шо-то не понимаю, вы привлекаете народ, объясняя что он — недоразвитое быдло? Тактичней надо, мяхше.
Да, "быдло" обычно использует StringBuilder. Не знаю прям почему...
Причём к остальной части статьи, где описывается собсно linq глазами ФП я придраться могу только совсем по мелочам. Оставили бы только её — вообщзе конфетка была бы. Продолжайте
VD>Вообще-то я пытался не описывать LINQ глазами функциональщика, а показать людям идеологию лежащую за LINQ-ом и подтолкнуть их к более глубокому изучению того что на первый взгляд выглядит как SQL. VD>Другими словами я пытался на пальцах, простыми словами показать людям которые еще не плавают в ФП как рыбы те приемы и подходы которые предлагает ФП.
Ну на самом деле внутри себя оно довольно-таки императивное. И объясняя, что здесь нет чёрной магии, а только все те же методы и делегаты, вы привлечёте куда больше императивщиков. И если честно, мне не совсем нравится попытка использования SQL-синтаксиса. Потому что SQL — декларативный язык. Там вольности частично компенсирует оптимизатор. В случае Linq2Objects — что напишешь, то и получишь. И если ты сам сделал жойн коллекциям из тысячи элементов и добавил туда гроуп да ещё и сортировку — сам себе грабли. Аккуратней надо. Особенно в рабочих проектах.
VD>В общем, задача статьи помочь людям поменять сознание. Это все что требуется для реального понимания ФП и получения выигрыша от его применения на практике. Именно по этому у статьи не академический (не серьезный) стиль и в ней часто говорится об императивных программистах. Уверен, что если человек поймет, что это не наезды, а попытка помочь, то статья ему поможет. По крайней мере я пытался это сделать.
Поддерживаю. Дерзай дальше
P.S. Только заметил:
string Function(int x, string y);
Можно описать как:
int * string -> string
или как:
int -> string -> string
Если я ничего не путаю, в нотации хаскелля/фшарпа первое — это функция, которая принимает тюпл int * string и возвращает string. Второе — carrying функция. Не стоит сразу смущать людей.
P.P.S. Кто хочет посмеяться — Почему "делегаты" отстой. Версия Сан. (чесслово — они первые взяли делегаты в кавычки). Судя по упоминанию JDK 1.1 и J++ — статья 2001-2002 гг.
"Я понимаю, что это очень непривычно и непонятно (на первый взгляд), но поверьте, что есть целая теория обосновывающая это (теория «лямбда-исчислений» Чёрча)."
-- почему лямбда-исчисления в кавычках (это типа сарказм или опечатка)? Почему читатель должен тебе верить? Если лямбда-исчисление Черча есть -- дай ссылку, но просить поверить тебе не нужно.
Читатель может и не верить, но может и должен независимо верифицировать, данную информацию.
Lisp is not dead. It’s just the URL that has changed: http://clojure.org
Здравствуйте, Sinclair, Вы писали:
E>>Откуда информация о том, о чем привык думать императивный программист?
S>Вообще-то — из определения "императивного программиста".
C++ программист использующий std::transform, std::accumulate etc является императивным?
Здравствуйте, Sinix, Вы писали:
S>In the .NET Framework, callback functions are just as useful and as pervasive as they are in unmanaged programming for Windows®. However, the .NET Framework has the added bonus of providing a type-safe mechanism called delegates.
Кто-нибудь может объяснить почему здесь противопоставление?
И чем они type-safe'нее C/C++'ных указателей на функции?
Здравствуйте, EvilChild, Вы писали:
EC>C++ программист использующий std::transform, std::accumulate etc является императивным?
Смотря как он их использует
Вообще, скорее всего — да.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
EC>>C++ программист использующий std::transform, std::accumulate etc является императивным? S>Смотря как он их использует
Ну, очевидно, он передаёт им исключительно чистые функции S>Вообще, скорее всего — да.
Здравствуйте, VladD2, Вы писали:
VD>А за указание на орфографические ошибки вообще баня положена. Читай внимательно правила.
Нет такого, прочёл. Там это относится к форуму, а не к статьям. Писать неграмотные статьи в журнале, это неуважение к читателям, тем более в век, когда проверить написание слова можно за 5 секунд.
Кстати, что там насчёт "ставить под сомнение профессиональную квалификацию" написано? А то любят некоторые про Блаба писать в обращении к другим программистам. Это типа у них обоснование такое своей правоты
Здравствуйте, EvilChild, Вы писали: EC>Ну, очевидно, он передаёт им исключительно чистые функции
Ну, тогда это шаг из плена императивных иллюзий.
В принципе, комбинирование ИП и ДП — достаточно нормальная штука. Точно так же, как совмещение автоматического вывода с аннотацией типов.
Чрезмерная "гибкость", имхо, может быть даже вредна. А так — вон, программисты БД-приложений уже много лет включают декларативный SQL в свои чисто императивные программы.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinix, Вы писали:
S>>>Изменение синтаксиса 3-м шарпе имхо стоит вынести в подраздел. VD>>С какой целью? Чтобы было проще искать? Или чтобы ссылаться можно было?
S>Не угадал . Хорошо структурированную статью легче читать. Мозг автоматом учитывает переключение контекста.
ОК, попробую.
S>>>Статья получилась слегка раздутой из-за кучи вводной информации. Стоило либо разбить на несколько: делегаты и итераторы как они есть, замыкания, внутренняя реализация -> C# 3, заимствования из ФП, лямбды и т.п. -> идеология ФП -> LINQ и ФП. Или хотя бы поставить уровень отсечения — "идите читать матчасть, потом возвращяйтесь" и сосредоточиться на последних двух частях. VD>>На то есть оглавление. Да и статья не такая большая чтобы ее резать. VD>>Или речь об переупорядочивании разделов?
S>Да, смысл именно в том, чтобы структура отражала твой замысел и служила костяком. Типа так: Мы плавно подходим к теме А, но говорить о ней можно только после раскрытия тем Б,В, ну и чуть-чуть Г. Если вы в них сечёте — переходите дальше. Если нет — то можете кончно пролистать, но в любом случае вы ничего не поймёте. И по-хорошему идите учите матчасть.
Разбивать статью никто не будет. Она уже опубликована. Переупорядочить конечно можно. Но вопрос что, зачем и ради чего переупорядочивть?
S>Чтобы не было иллюзий. Оглавление, которое не висит постоянно перед глазами, не очень-то и помогает. Для меня быстрее прокрутить вниз, по ходу быстро сканируя текст, чем искать оглавление, искать в нём раздел и переходить туда. Для небольших статей, естественно.
Вообще-то для доступа к оглавлению достаточно нажать Home. В прочем, это уже разговор не о том. Каждый делает так как ему удобно.
VD>>Ну, это уже на отдельную статью тянет. Замечания по производительности конечно можно сделать. Но боюсь, что люди без опыта воспримут их не адекватно. Конкретные цифры тут ничего не покажут. Тут нужно понимать суть происходящего. Конечно замыкания и виртуальные вызовы не бесплатны, но предпочитать функциональному стилю императивный нужно очень взвешенно и акуратно иначе очень легко из-за своих фобий скатиться к повсеместному применению ИП просто на основании того, что оно быстрее.
S>Нуу... лично у меня долго было предубеждение, что попытка агрессивно использовать делегаты и итераторы приведёт к затыкам с производительностью.
Ты только подтверждаешь мои слова. Разговор о производительности — это очень не простой и очень флэймовый вопрос. Если уж даже по такому, казалось бы сугубо частному вопросу, как стиль изложения начинается флэйм, то вопрос производительности очень флэймовый.
Кстати, вопрос производительности — это еще разговор об оптимизациях. LINQ to objects без проблем может быть оптимизирован буквально до циклов. Это не так сложно. Но и это сложная и большая тема по которой народ защищает дисеры.
S>Но когда стал вопрорс "как делать будем" прокрутили микротесты и выяснилось что по накладным расходам делегаты и итераторы сопоставимы со стоимостью виртуального вызова.
Микро-тесты никогда ничего не показывали. Тут надо рассуждать о двух вопросах.
1. Стоимость абстракции (лямбды и замыкания не бесплатны).
2. Критичность кода к скорости выполнения (далеко не весь код критичен, но выявить и заменить критичный код не просто).
В общем, я считаю, что моя статья не о том. Он о том как изменить мышление и взглянуть на мир по другому, а не об обосновании необходимости применения ФП.
S>1. Так бы и сказали S>2. Конкретик хотите? Их есть у меня!
S>Про анонимные делегаты (кстати, мс и так и так их называет и в принципе раскрывает суть — создаётся делегат на метод; другого доступа к методу нет. Так что вполне нормальный термин):
Нет в природе никаких анонимных делегатов. Если кто-то так называет анонимные метод, то он просто ошибается.
S>
S>Зачем их было называть методами, и почему им сделали столь неуклюжий синтаксис, остается загадкой.
S>...
S>Откровенно говоря, лямбда-выражения – это просто доведенные до ума анонимные методы.
S>...
S>очень часто можно было услышать, как анонимные методы называют «анонимными делегатами», хотя это в корне неверно
S>Вы уж придирайтесь предметно — то вам непонятно, почему называть методами, то называть делегатами в корне неверно.
Что значит придираюсь? Я выражаю свои мысли по этому поводу. Они рано или поздно придут ко многим. И очень полезно если в людей сразу будет ясность в этом вопросе.
S>Почему без шапки?!!
Что? Что значит "шапка"?
S>Следующая цитата — вообще наезд на эмоциях: S>
S>При этом в Microsoft не придумали ровным счетом ничего нового. Примерно так выглядят лямбды почти во всех ФЯ. Так что совершенно непонятно, зачем было лепить в C# 2.0 этот безобразный, длинный и сбивающий с толку синтаксис. Понятно, что вывод типов был сделан только в C# 3.0, но, по крайней мере, все остальное-то точно можно было бы сделать сразу как в лямбда-выражениях!
Это называется критика. Многим, кто уже понимает что-то в ФП как раз такие вещи в статье и интересны.
S>После S>
S>Однако при проектировании .NET-делегатов был сделан ряд ошибок, которые сказались при развитии C# в сторону ФП.
S>...
S>Данное решение не создает особых проблем на практике, за исключением того, что вызов делегата медленнее, чем мог бы быть.
S>возникает желание предложить почитать Абрамса. Допустим, пост от февраля 2004 года. У Абрамса сотоварищи есть много статей, где описывается дизайн рантайма/BCL/шарпа. Перед дальнейшими наездами рекомендую ознакомиться. О производительности: S>
S>For those performance oriented among you, please note that if you have a MulticastDelegate that hasn’t been combined with any other delegates the CLR can optimizes for this case during dispatch and in how the JIT compiles the callsite….
Ты сам-то внимательно прочем то, что написано в приведенной статье? Если отбросить громкие заявления о высокой производительности и поглядеть описание процесса вызова, то становится отчетливо видно, что вызов дико не оптимален. Перед ним делается масса проверок которые снижают производительность. Решение без ошибок дизайна привело бы к одному виртуальному вызову который в общем-то и виртуальным можно назвать с натяжкой, так как конкретные реализации могли бы быть sealed. В итоге во многих случаях JIT мог бы после устранения виртуальности устранять и сам вызов встраивая его по месту.
S>Продолжаем.
S>
S>Вторая ошибка дизайна создает куда больше проблем, нежели первая.
S>...
S>Так вот, делегаты не проектировались как функциональные типы, или хотя бы с мыслью об этом. Они проектировались как деталь реализации событий.
S>In the .NET Framework, callback functions are just as useful and as pervasive as they are in unmanaged programming for Windows®. However, the .NET Framework has the added bonus of providing a type-safe mechanism called delegates.
S>Делегаты проектировались как типизированая реализация callback-ов.
S>Если вы объясните, почему такая реализация приводит к принципиальной невозможности кастинга делегатов по сигнатуре — я принесу извенения и тихо удалюсь. Если нет — не наезжайте
Я не понял зачем мне что-то доказывать. Делегаты и так не совместимы по сигнатуре между собой. А принципиально это было сделано или по недомыслию лично мне все равно.
В общем, в статье по этому поводу все написано и разжевано. Кто хочет, тот понял. Можно конечно долго спорить о первопричинах и осмыслении следствий, но это уже сугубо субъективное.
S>Дальше. S>
S>Именно так обычно пишет код 90% императивных программистов. Причем чем больше нужно выполнить действий над элементами списка, тем больше и сложнее становится тело цикла (а так же его пролог и эпилог). Не мудрено, что в большинстве случаев такой код превращается в кашу.
S>Я шо-то не понимаю, вы привлекаете народ, объясняя что он — недоразвитое быдло? Тактичней надо, мяхше. S>Да, "быдло" обычно использует StringBuilder. Не знаю прям почему...
Раз нашлись двое людей которые не только не восприняли основной посыл написанного (что императивный программист использует цикл перемешивая логику), но еще и нашли обидные для себя моменты, то видимо прийдется действительно изменить этот кусок статьи. Хотя, лично для меня, подобные претензии выглядят как паранойя.
В прочем, данное замечание отлично демонстриует мышление императивного программиста. Даже освоив приемы ФП ты рассуждаешь не о том что делает код, а о том как он это делает. Особенностью ФП как раз является то, что он описывает "что", а не "как". А вопрос "как" перекладывается на реализацию библиотеки. И чем более высокоуровневая функция используется тем больше простора для оптимизаций у создателя этой функции.
С другой стороны это опять же разговор о производительности и стоимости абстракции.
S>Причём к остальной части статьи, где описывается собсно linq глазами ФП я придраться могу только совсем по мелочам. Оставили бы только её — вообщзе конфетка была бы. Продолжайте
У меня нет задачи заработать оценок. Мне интересно было создать статью которая подтолкнет к развитию и размышлениям. Ну, что же. Если она кого-то немного задела, то можно оно и к лучшему. Даже интересно будет послушать тех же людей через некоторое время. Уверен, что оценки изменятся.
VD>>Вообще-то я пытался не описывать LINQ глазами функциональщика, а показать людям идеологию лежащую за LINQ-ом и подтолкнуть их к более глубокому изучению того что на первый взгляд выглядит как SQL. VD>>Другими словами я пытался на пальцах, простыми словами показать людям которые еще не плавают в ФП как рыбы те приемы и подходы которые предлагает ФП.
S>Ну на самом деле внутри себя оно довольно-таки императивное.
Ты не верно понимаешь понятие "идеологию лежащую за". Я не говорю о реализации методов. Я говорю о идеологии.
Конечно можно было бы уподобиться многим авторам и толкнуть теорию ламбда-исчислений. Но это с вероятностью 100% не было бы воспринято целевой аудиторией.
S>И объясняя, что здесь нет чёрной магии, а только все те же методы и делегаты, вы привлечёте куда больше императивщиков.
Объяснять как это реализовано на низком уровне бессмысленно! Это ничего не даст людям для понимакния того как это использовать и как извлечь из этого выгоды.
Возможно аналогия с магией здесь как нельзя кстати. Но магия не в смысле акультных наук и колдовства, а магия в смысле фокусников. Как фокусник иллюзионист или престидижитатор производя некоторые манипуляции создает иллюзию магии. Точно так же казалось бы понятные всем примитивы складываясь вместе создают иллюзию магии ФП. Как и в фокусах используя ФП все занют, что все это реализуется весьма банальным образом, но результат заставляет удивляться.
S> И если честно, мне не совсем нравится попытка использования SQL-синтаксиса. Потому что SQL — декларативный язык. Там вольности частично компенсирует оптимизатор. В случае Linq2Objects — что напишешь, то и получишь. И если ты сам сделал жойн коллекциям из тысячи элементов и добавил туда гроуп да ещё и сортировку — сам себе грабли. Аккуратней надо. Особенно в рабочих проектах.
Ну, и что мне теперь в стать рассказать, что есть вот на свете Иванов, Петров и Сидров которые не согласны с подходом МС? Я сказал, что думаю по этому поводу в статье.
VD>>В общем, задача статьи помочь людям поменять сознание. Это все что требуется для реального понимания ФП и получения выигрыша от его применения на практике. Именно по этому у статьи не академический (не серьезный) стиль и в ней часто говорится об императивных программистах. Уверен, что если человек поймет, что это не наезды, а попытка помочь, то статья ему поможет. По крайней мере я пытался это сделать.
S>Поддерживаю. Дерзай дальше
S>P.P.S. Кто хочет посмеяться — Почему "делегаты" отстой. Версия Сан. (чесслово — они первые взяли делегаты в кавычки). Судя по упоминанию JDK 1.1 и J++ — статья 2001-2002 гг.
Кстати, к вопросу о происхождении делегатов. Отсюда явно видно, что МС предлагал делегаты в первую очередь как базу для реализации событий.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, EvilChild, Вы писали: EC>Кто-нибудь может объяснить почему здесь противопоставление? EC>И чем они type-safe'нее C/C++'ных указателей на функции?
Тем, что тебе не удастся закастить произвольный интегер к указателю на функцию и попробовать его выполнить, на радость злоумышленникам.
Type-safety в .NET контролируется строго.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>В принципе, комбинирование ИП и ДП — достаточно нормальная штука.
Это пожалуй единственный на данный момент реальный варинт применения ДП, если ты пишешь не на Haskell или Clean. S>Точно так же, как совмещение автоматического вывода с аннотацией типов. S>Чрезмерная "гибкость", имхо, может быть даже вредна.
Гибкость в чём? S>А так — вон, программисты БД-приложений уже много лет включают декларативный SQL в свои чисто императивные программы.
Программист БД-приложений — сушество не менее загадочное, чем иперативный программист .
now playing: Gui Boratto & Anderson Noise — Triads (Andre Sobota Remix)
Здравствуйте, Sinclair, Вы писали:
EC>>Кто-нибудь может объяснить почему здесь противопоставление? EC>>И чем они type-safe'нее C/C++'ных указателей на функции? S>Тем, что тебе не удастся закастить произвольный интегер к указателю на функцию и попробовать его выполнить, на радость злоумышленникам.
Это можно сделать только, если ты сознательно действуешь в обход системы типов языка. Случайно это сделать она не позволит. S>Type-safety в .NET контролируется строго.
В C++ можно при желании закастить что угодно к чему угодно.
Поэтому мне странно слышать когда указатели на функции и делегаты выделяют отдельно.
Не припомню, чтобы как-то акцентировали внимание на строготипизированности ссылок в .NET.
now playing: Gui Boratto & Anderson Noise — Triads (Andre Sobota Remix)
Здравствуйте, EvilChild, Вы писали:
S>>В принципе, комбинирование ИП и ДП — достаточно нормальная штука. EC>Это пожалуй единственный на данный момент реальный варинт применения ДП, если ты пишешь не на Haskell или Clean.
Т.е. вот это:
module Main (main) where-- Pink Floyd - Goodbye Cruel World
main :: IO()
main = do
putStrLn "Goodbye, cruel world,"
putStrLn "I'm leaving you today."
putStrLn "Goodbye, goodbye, goodbye."
putStrLn "Goodbye all you people,"
putStrLn "There's nothing you can say,"
putStrLn "To make me change my mind."
putStrLn "Goodbye."
по-вашему не императивная программа?
... << RSDN@Home 1.2.0 alpha 4 rev. 1110>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Klapaucius, Вы писали:
K>Т.е. вот это: K>
K>module Main (main) where
K>-- Pink Floyd - Goodbye Cruel World
K>main :: IO()
K>main = do
K> putStrLn "Goodbye, cruel world,"
K> putStrLn "I'm leaving you today."
K> putStrLn "Goodbye, goodbye, goodbye."
K> putStrLn "Goodbye all you people,"
K> putStrLn "There's nothing you can say,"
K> putStrLn "To make me change my mind."
K> putStrLn "Goodbye."
K>
K>по-вашему не императивная программа?
А что, здесь где-то ссылочная прозрачность нарушается или есть какие-то вещи противоречащие чистому ФП?
SELECT * FROM mytable это тоже императивщина?
Здравствуйте, EvilChild, Вы писали: EC>Это можно сделать только, если ты сознательно действуешь в обход системы типов языка. Случайно это сделать она не позволит.
Да ладно!
Из-за отсутствия стандарта бинарной совместимости, компоненты вынуждены общаться между собой при помощи даункастов. Стандартнейшая штука "выполнить данный метод в GUI-потоке" обрабатывается через передачу адреса в виде целых полей плоской структуры оконного сообшения Windows.
Все карты сообщений построены на даункастах. Добро пожаловать в реальный мир, за пределами hello world.
S>>Type-safety в .NET контролируется строго. EC>В C++ можно при желании закастить что угодно к чему угодно. EC>Поэтому мне странно слышать когда указатели на функции и делегаты выделяют отдельно.
И очень зря. Потому, что не так страшно реинтерпретировать строку во флоат, как начать исполнение неизвестного мусора под привилегиями текущего пользователя.
EC>Не припомню, чтобы как-то акцентировали внимание на строготипизированности ссылок в .NET.
Акцентируют, и еще как. Type-safety в дотнете вообще рассматривается с позиции именно строготипизированности любых ссылок. Просто конкретный пример обсуждал именно pointer to method.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
