Re[4]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 21.01.09 11:35
Оценка: :)
E>>Откуда информация о том, что у большого количества императивных программистов несложная обработка преобразуется в плохочитаемому коду и т.д.?
VD>Из практики чтения чужого кода. Поверь, не малой практики.

Наша практика говорит об обратном. А у нас она, пожалуй, одна из самых крупных, и ФЯ почище некоторых.

Всё нормально у императивщиков при переходе на ФЯ.

VD>Скажу больше. Я сам бы очень хотел бы наткнуться на подобную статью году эдак в 2005-ом или 2006. А лучше еще раньше. Вместо этого я нарывался на трехколенные выпендрежи, понты и замуности которые мало что давали с точки зрения понимания принципов ФП. По сути только попытка разобраться с Немерле позволила мне понять принципы ФП. И, о чудо, все оказалось совсем просто. Оказывается проблемы были не в моем скудном уме, а в неумении других объяснять весьма простые вещи. Вот эта статья и есть попытка объяснить эти простые вещи для таких же простых парней как я.


Перевод этой сентенции на русский язык настолько ярок, "it can blind you by pure awesomness".

Если я его опубликую, то меня забанят, да.

Этот параграф очень, очень показателен.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[10]: "LINQ как шаг к ФП". Стиль изложения.
От: EvilChild Ниоткуда  
Дата: 21.01.09 11:39
Оценка:
Здравствуйте, thesz, Вы писали:

S>>>В принципе, комбинирование ИП и ДП — достаточно нормальная штука.

EC>>Это пожалуй единственный на данный момент реальный варинт применения ДП, если ты пишешь не на Haskell или Clean.

T>А если на Agda2 или Coq? Не пойдёт?

А на них разве пишут "обычные" программы?
now playing: Redshape — Slow Monday
Re[11]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 21.01.09 13:02
Оценка:
S>>>>В принципе, комбинирование ИП и ДП — достаточно нормальная штука.
EC>>>Это пожалуй единственный на данный момент реальный варинт применения ДП, если ты пишешь не на Haskell или Clean.
T>>А если на Agda2 или Coq? Не пойдёт?
EC>А на них разве пишут "обычные" программы?

define "обычные". Why should I ask in first place?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[12]: "LINQ как шаг к ФП". Стиль изложения.
От: EvilChild Ниоткуда  
Дата: 21.01.09 14:02
Оценка:
Здравствуйте, thesz, Вы писали:

EC>>А на них разве пишут "обычные" программы?

T>define "обычные". Why should I ask in first place?
Для более-менее конечного пользователя, а не для computer scienetist'ов.
Re[13]: "LINQ как шаг к ФП". Стиль изложения.
От: thesz Россия http://thesz.livejournal.com
Дата: 21.01.09 14:51
Оценка: :)
EC>>>А на них разве пишут "обычные" программы?
T>>define "обычные". Why should I ask in first place?
EC>Для более-менее конечного пользователя, а не для computer scienetist'ов.

CompCert подойдёт?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[14]: "LINQ как шаг к ФП". Стиль изложения.
От: EvilChild Ниоткуда  
Дата: 21.01.09 16:10
Оценка:
Здравствуйте, thesz, Вы писали:

EC>>>>А на них разве пишут "обычные" программы?

T>>>define "обычные". Why should I ask in first place?
EC>>Для более-менее конечного пользователя, а не для computer scienetist'ов.

T>CompCert подойдёт?

Вполне.
Этот компилятор используется для решения практических задач или это чисто исследовательский проект?
now playing: Gui Boratto & Anderson Noise — Triads
Re[14]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 21.01.09 17:57
Оценка:
Здравствуйте, Sinix, Вы писали:

S>Офтоп про декларативыность linq:


S>Как вы воспринимаете декларативность?


Как определение того "что делать", а не того "как делать".

S>Если как возможность отделить логику от алгоритма — то вон жаваисты вполне справляются одними интерфейсами. То, что фп мягко настаивает на подобном разделении не означает "недекларативность" императивных языков.


Интерфейсы и есть интерфейсы. Их нужно реализовывать. И тут в Яве есть только один путь. Императивно описать что нужно сделать при вызове каждого метода интерфейса.

S>Проблема с Linq2Objects в том, что _пока_ оно реализовано только для перебираемых последовательностей. Это некритично, пока стоимость запроса линейна, а объём невелик. Если у нас жойн, получаем O(n*m). Причём для любого, кто долго работал с SQL это абсолютно неинтуитивно, потому как он привык к оптимизатору, который достаточно умён, чтобы использовать индексы (если они есть) и сократить до O(max(n,m)) в идеальном и O(m*log(n)) в худшем случае.


Это и есть мышление императивного программиста. Мыслим не о том, "что делается", а о том "как". Меж тем реализация может быть весьма разно. Вот ты предположил, что Join сделать тупым перебором. Меж тем это не так. Он реализован на лукап-таблицах которые в свою очередь реализованы на хэш-таблицах. Таким образом скоростные характеристики Join близки к линейным. К тому же Join требуется только при обработке реляционных данных коих не много в программах.

S>Без похожего функционала Linq2Objects годится только для примитивных запросов, или ситуаций, где оптимизировать исходные структуры нельзя. То, что к таким ситуациям относится большинство типичных сценариев, ещё не говорит о революционном LINQ — убийце императивщиков


Я тебя возможно удивлю, но множество программ пишутся в функциональном стиле и даже на функциональных языках где единственной базовой "юзабельной" структурой данных является однонаправленный связанный список. И при этом такие программы за частую оказываются даже быстрее аналогов написанных на С++ и откомпилированных лучшими компиляторами.

S>Сам по себе LINQ не тру декларативен. Декларативность подразумевает произвольную реализацию алгоритма в зависимости от ситуации.


Декларативность вообще не подразумевает реализации. Декларативность — это способ описания потребностей без описания реализации. Вот это LINQ обеспечивает, так что он вполне себе декларативный.

В прочем размышления о произвольной реализации так же не верны. Скажем LINQ to SQL преобразует код полностью аналогичный тому что можно написать на LINQ to object в SQL, а LINQ to DataSet во вполне эффективные операции над DataSet-ами (так как в них поддерживаются индексы). При этом нет каких-то разных LINQ-ов. LINQ один. Вместо этого есть разные реализации так называемого LINQ Pattern, что как раз и является реализацией алгоритма в зависимости от ситуации. Ведь то какая библиотека используется определяется исключительно обрабатываемыми данными.

С некоторой натяжкой можно обозвать декларативным сам язык — эдакий DSL вокруг набора методов. Вы ж не будете обзывать декларативным это:
S>
S>new StringBuilder.Append("A").Append("B");
S>

S>А вот это — декларативный код?
S>
S>new int[] {1,2,3}.Where(i=>i>2).Select(i=>"#" + i.ToString());
S>

S>А вот это — уже похоже, да?
S>
S>from i in new int[] {1,2,3} where i>2 select "#" + i.ToString());
S>


S>Так вот, если понимать, что DSL в третьем шарпе лишь синтаксический сахар, что предикаты для LINQ2Objects будут выполняться именно в том порядке, как вы их зададите, и что вам по-прежнему нужно уделять внимание внутренней логике запроса, то язык не повернётся называть linq чисто декларативным. Да, идеи кое-какие позаимствованы, но внутри — императивщина-императивщиной.


ДСЛ-ем является уже сам LINQ Pattern. Синтаксис действительно всего лишь простая трансформация.

S>В принципе, о декларативных запросах к графам — неважно, объектным, XML, иерархическим БД — писал ещё Дейт начиная с 8 издания. Точной цитаты не приведу — книги на руках нет, быстрый поиск не помог, но суть там была такая, что из-за захардкоденной структуры возможность произвольного доступа невелика, различных путей выполнения не так уж и много, а использование этих путей в запросах в принципе лишает смысла использование оптимизатора. Посему те же XQuery/XSLT так и пребудут императивными во веки веков до скончания оных


Ты просто не понимаешь термин "императивный".

VD>>Нет в природе никаких анонимных делегатов. Если кто-то так называет анонимные методы, то он просто ошибается.


S>Может ты скушал не ту пилюлю, нео?


S>Не всё так просто. Если посмотреть что происходит в реальности:...


Есть терминология определяемая стандартом. Не надо ее пытаться корежить и выдумывать что-то свое.
Кстати, в МС обсуждалась идея ввести в дотнет именно анонимные делегаты. Под этим понималось то, что в ФЯ называется функциональным типом. Логика была проста. Функциональный тип — это делегат без имени, т.е. анонимный делегат.
И как мы дальше будем разговаривать если каждый будет понимать свое под конкретным термином?
Так что забудь "анонимный делегат". То о чем ты говоришь в дотнете называется анонимным методом.

S>Если замыканий нет — компилятор создаёт приватный метод и приватную переменную — делегат, которую инициализирует при первом выполнении метода. Так что в каком-то смысле анонимный делегат существует.


"Приватный" (скрытый) не тоже самое что "анонимный" (безымянный). Плюс переменная — это всего лишь ссылка. Есть она или нет рояли не играет.

S>Читаем http://blogs.msdn.com/zifengh/archive/2008/01/21/from-c-to-clr-jitted-code-call-delegate.aspx. Не запутайтесь — там подряд идёт создание и вызов делегата. JIT работает так, как вы и хотели. Если можем предложить более оптимальный вариант — предлагаем. Нет — не холиварим или учим матчасть.


Улавливаешь разницу между понятиями "более оптимальный" и "оптимальный"?

В МС к настоящему моменту сделали не мало, чтобы разгнать делегаты. Но если бы они не валяли дурака в 1998-ом, то решение было бы простым, чистым и эффективным.

VD>>Я не понял зачем мне что-то доказывать. Делегаты и так не совместимы по сигнатуре между собой. А принципиально это было сделано или по недомыслию лично мне все равно.


S>Ну ёпть... сделали они так — ради той самой производительности, что вам не хватает Им ничего не мешает изменить правила приведения типов для делегатов. Принципиальная возможность есть. Так что не всё потеряно.


Уважаемый. За то что идет перед ... тут банят и на долго.

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

VD>>Раз нашлись двое людей которые не только не восприняли основной посыл написанного (что императивный программист использует цикл перемешивая логику), но еще и нашли обидные для себя моменты, то видимо прийдется действительно изменить этот кусок статьи. Хотя, лично для меня, подобные претензии выглядят как паранойя.


S>Придётся править. Реально вопринимается как наезд. Или предвзятость. Ибо "90% императивных программистов" пишет код аккуратней. Да! Я себя к императивщикам не отношу. Вообще ни к кому не отношу. Не люблю таскаться


Причем тут аккуратность?

VD>>В прочем, данное замечание отлично демонстриует мышление императивного программиста. Даже освоив приемы ФП ты рассуждаешь не о том что делает код, а о том как он это делает. Особенностью ФП как раз является то, что он описывает "что", а не "как". А вопрос "как" перекладывается на реализацию библиотеки. И чем более высокоуровневая функция используется тем больше простора для оптимизаций у создателя этой функции.


S>Свою точку зрения разжёвал выше. Почему "вопрос "как" перекладывается на реализацию библиотеки" — особенность ФП? Это принципиально невозможно в императивных языках?


Какой еще библиотеки?

VD>>Объяснять как это реализовано на низком уровне бессмысленно! Это ничего не даст людям для понимакния того как это использовать и как извлечь из этого выгоды.


S>Я ж говорю — несовпадение мировоззрений. Не будем.


Именно.


S>>>P.P.S. Кто хочет посмеяться — Почему "делегаты" отстой. Версия Сан. (чесслово — они первые взяли делегаты в кавычки). Судя по упоминанию JDK 1.1 и J++ — статья 2001-2002 гг.


VD>>Кстати, к вопросу о происхождении делегатов. Отсюда явно видно, что МС предлагал делегаты в первую очередь как базу для реализации событий.


S>Ну, если для вас маркетинг-отдел Сана достоверней Рихтера... Не могу найти точной цитаты, но делегаты как каллбэки в рантайме были заложены ещё до событий и собсно фреймворка — ещё когда было только "common object runtime". Отсюда и делегат/мультикаст делегат. Одно для калбэков, другое для событий. Потом пришло осознание, что в принципе сценарии пересекаются и вполне себе оптимизируются в рантайме. Но было уже поздно(с). Принципиально нет ограничений для кастинга делегатов по сигнатуре. Оно просто не реализовано. Если у вас есть идеи, какими должны быть делегаты — озвучьте


Я читал тоже самое в письме Хейльсберга и в других местах. К сожалению не думал, что мне понадобятся ссылки на все источники. Рихтер же писал постфактум о дотнте. А делегаты действительно были предложены в J++.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 21.01.09 18:30
Оценка:
Здравствуйте, Sinix, Вы писали:

K>>Совершенно верно. Join и GroupJoin используют System.Linq.Lookup<key, value>


S>Ага, спасибо. Не знал.


Ну, и что ты теперь скажешь о императивной природе?

ЗЫ

Верным будет только утверждать, что реализация LINQ to object не самая эффективная и может быть сделана более эффективной если на то появится необходимость. Вот только появится она вряд ли.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 21.01.09 18:35
Оценка:
Здравствуйте, thesz, Вы писали:

E>>>Откуда информация о том, что у большого количества императивных программистов несложная обработка преобразуется в плохочитаемому коду и т.д.?

VD>>Из практики чтения чужого кода. Поверь, не малой практики.

T>Наша практика говорит об обратном. А у нас она, пожалуй, одна из самых крупных, и ФЯ почище некоторых.


Сам себе противоречишь. Если у вас "ФЯ почище некоторых", то код уже не императивный.

T>Всё нормально у императивщиков при переходе на ФЯ.


У кого как. Но я еще не видел людей которым не пришлось бы перестраивать сознание и которые бы без изучения идей ФЯ сами бы писали функциональный код.

VD>>Скажу больше. Я сам бы очень хотел бы наткнуться на подобную статью году эдак в 2005-ом или 2006. А лучше еще раньше. Вместо этого я нарывался на трехколенные выпендрежи, понты и замуности которые мало что давали с точки зрения понимания принципов ФП. По сути только попытка разобраться с Немерле позволила мне понять принципы ФП. И, о чудо, все оказалось совсем просто. Оказывается проблемы были не в моем скудном уме, а в неумении других объяснять весьма простые вещи. Вот эта статья и есть попытка объяснить эти простые вещи для таких же простых парней как я.


T>Перевод этой сентенции на русский язык настолько ярок, "it can blind you by pure awesomness".


T>Если я его опубликую, то меня забанят, да.


T>Этот параграф очень, очень показателен.


Ничего не понял.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 21.01.09 18:49
Оценка: :))
Здравствуйте, thesz, Вы писали:

E>>>>

...уж совсем немногие действительно разобрались...

T>>>Вот выделенное шрифтом — это VladD2 написал? Да?
Y>>Да. С моей колокольни кажется, что он очень хорошо разобрался и что самое важное, без всяких перекосов в какую-либо из сторон. Не то, что некоторые, не будем показывать пальцами

T>Если палец указует на меня, то я открещусь — я не разбирался, и даже не пытался. Я просто использую Хаскель, по прямым моим обязанностям вот уже пятый год, а так — с конца 1998 года.


Молодец. Но прямо вот этими словами ты доказал, что можно зная русский язык не понимать что тебе на нем пишут.

Понимаешь ли в чем дело? Может ты и лучше разобрался "в теме", но при этом ты зазнался и напрочь перестал понимать тех кто еще "не в теме". Отсюда такую же статью ты написать в принципе не в силах. Ну, по крайней мере без чужой помощи.

ЗЫ

А вообще забавнешая ситуация получается. Когда я спорю с представителями разных лагерей, то все они моментально записывают меня в радикалов, маргиналов и т.п. Но вот что странно! Каждый раз меня записывают в другой лагерь. Говоришь с опупевшим императивщиком который всюду видит операции над битами и ты вдруг злостный функциональщик/декларативщик не понимающий ток в написании реально быстрых программ. Говоришь с фнункциональщиком и ты вдруг чудесным образом переносишся в другую сторону спектра. И те и другие называют меня фанатиком и т.п.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: "LINQ как шаг к ФП". Стиль изложения.
От: VoidEx  
Дата: 21.01.09 19:17
Оценка: 3 (1) +9 :))
Здравствуйте, VladD2, Вы писали:

VD>ЗЫ


VD>А вообще забавнешая ситуация получается. Когда я спорю с представителями разных лагерей, то все они моментально записывают меня в радикалов, маргиналов и т.п. Но вот что странно! Каждый раз меня записывают в другой лагерь. Говоришь с опупевшим императивщиком который всюду видит операции над битами и ты вдруг злостный функциональщик/декларативщик не понимающий ток в написании реально быстрых программ. Говоришь с фнункциональщиком и ты вдруг чудесным образом переносишся в другую сторону спектра. И те и другие называют меня фанатиком и т.п.


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

В общем-то в спорах это удобно — гипертрофировать слова оппонента, так как крайности проще опровергаются, а ответная реакция людей — либо каждый раз пояснять, что ты не то опровергаешь, либо ответить тебе взаимностью и гипертрофировать твои слова, посему все для тебя фанатики, а ты — фанатик для всех. Более мирный путь (пояснить, что ты не о том) к сожалению менее результативен в споре, ощущение, что оппонент оправдывается и потому неправ, поэтому чаще всего ответная реакция взаимна. Так что в таких спорах не истина рождается, а срач, что мы регулярно и наблюдаем.
Re[6]: "LINQ как шаг к ФП". Стиль изложения.
От: yumi  
Дата: 22.01.09 00:41
Оценка: +1
Здравствуйте, VoidEx, Вы писали:

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


Слушай, я смотрел эту тему. Там Влад писал, что задачки слишком простые, чтобы продемонстировать пользу ФП и что эти задачки можно решить и императивно. Явного выигрыша использования ФП в которых не видно. Все. Это основная его мысль была, насколько я этого понял. Но пришел один товарищ, не будем показывать пальцем и начал прикапываться к деталям. Видимо тут просто какая-то личная неприязнь Постоянно наблюдаю.
Lisp is not dead. It’s just the URL that has changed:
http://clojure.org
Re[7]: "LINQ как шаг к ФП". Стиль изложения.
От: VoidEx  
Дата: 22.01.09 00:58
Оценка:
Здравствуйте, yumi, Вы писали:

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


Личная неприязнь одного человека не провоцирует все срачи, особенно те, в которых он даже не участвует. А если ты хочешь объяснить это личной неприязнью целой массы участников, то она уже неспроста
Ну и давай не будем обсуждать частности и оффтопить. Возможно, данный пример был не совсем удачен, но всё же разговор об императивности и непанацейности ФП завязался именно с его приходом.
Re[19]: "LINQ как шаг к ФП". Стиль изложения.
От: Sinix  
Дата: 22.01.09 02:48
Оценка:
Да шо ж ко мне вы так пристали, Sinclair? Я ж не это ж, чтоб вот так вот, как оно есть, а оно совсем не так, да!

Чтобы не наводнять форум постами с километром оверквотинга:

Я не говорил и не собирался говорить, и совсем даже не имел в виду и не намекал и не подмигивал даже на тему "linq как таковой — декларативный отстой".

Все комменты относились к конкретным сценариям с linq2objects, когда товарищ может сам себе отстрелить ногу из-за того, что не понимает каким образом будут исполняться запросы, но их алгоритм выполнения определяется именно тем, что и как он написал. Другими словами: планы выполнения теоретически идентичных запросов для Linq2objects будет существенно отличаться. Последнее слегка неожиданно, если воспринимать linq как полноценную чёрную магию из коробки. Для товарищей, которые уже наигрались с предыдущим шарпом это не страшно. Для новичков это может привести к жестоким обломам и разочарованию в декларативном программировании вообще. Во! Наконец понял, что хотел сказать

Если коротко, то linq слегка нарушает тот самый принцип наименьшей неожиданности, о котором пафосно рассказывал Баллмер, после прыжков по сцене и "Developers, developers, developers!".
Re[18]: "LINQ как шаг к ФП". Стиль изложения.
От: Sinix  
Дата: 22.01.09 03:07
Оценка:
Влад! У нас не получается нормального разговора. Вы как-то неадекватно воспринимаете любые мои слова. Я всего лишь запостил комменты на вашу статью. Не ради того, чтобы как-то наехать на вас. Я написал, что конкретно мне в конкретной статье не понравилось. Процесс выяснения того, _почему_ мне что-то не понравилось перешёл в пустую свару. Давайте так. Я извиняюсь за намеренные и ненамеренные наезды в сторону Влада и остальных товарищей и прекращаю портить праздник в отдельно взятой ветке.

Щастья вам всем

ЗЫ Я никуда не ушёл. Просто молчу. Пока
Re[9]: "LINQ как шаг к ФП". Стиль изложения.
От: Трурль  
Дата: 22.01.09 07:02
Оценка: :))) :)
Здравствуйте, eao197, Вы писали:

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


Ну нельзя же выдвигать одинаковые требования к "Успехам Теологических Наук" и "Московскому богомольцу".
Re[19]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 22.01.09 07:52
Оценка:
Здравствуйте, Sinix, Вы писали:

S>Влад! У нас не получается нормального разговора. Вы как-то неадекватно воспринимаете любые мои слова.


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

S>Процесс выяснения того, _почему_ мне что-то не понравилось перешёл в пустую свару. Давайте так. Я извиняюсь за намеренные и ненамеренные наезды в сторону Влада и остальных товарищей и прекращаю портить праздник в отдельно взятой ветке.


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

S>Щастья вам всем


Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 22.01.09 08:08
Оценка:
Здравствуйте, VoidEx, Вы писали:

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


В "мастер-классе ФП" я высказал две мысли:
1. Что утверждение:

я часто сталкиваюсь с двумя точками зрения — первая "я знаком с ФП, но оно никакой выгоды в программировании не даёт", и вторая "я знаком с ФП, но так и не научился использовать его для повышения эффективности программирования".

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

2. Примеры в этом "мастер-классе ФП" слишком примитивные.

Как из этого можно было вывести искажения чьих то слов и бросания в крайности я не понимаю.

В прочем, в некоторых случаях может быть так и происходит. Вот только не думаю, что в этом только моя вина. Крайности как раз присущи приверженцам одной "true мысли".
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: "LINQ как шаг к ФП". Стиль изложения.
От: VladD2 Российская Империя www.nemerle.org
Дата: 22.01.09 08:15
Оценка:
Здравствуйте, VoidEx, Вы писали:

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

VE>Ну и давай не будем обсуждать частности и оффтопить. Возможно, данный пример был не совсем удачен, но всё же разговор об императивности и непанацейности ФП завязался именно с его приходом.

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

Что до массы участников, то она несомненно есть. Вот только она весьма мала. Возьмем скажем minorlogic (или как там его) который бегает и расставляет минусы на большую часть моих сообщений. Или того же eao197 который не может пройти мимо любого моего сообщения, чтобы не покритиковать меня и сообщение, а не мысль в нем высказанную.
Тут ничего не поделаешь. Есть люди с разными взглядами и с разной степенью неприятия чужих мыслей.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: "LINQ как шаг к ФП". Стиль изложения.
От: kochetkov.vladimir Россия https://kochetkov.github.io
Дата: 22.01.09 08:42
Оценка: 43 (1)
Здравствуйте, eao197, Вы писали:

VD>>Будешь писать сам — выклинишь.

E>Обязательно.

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

Судя по объемам ваших с Владом перепалок (в т.ч. и этой), если бы ты вместо них сел и написал перевод статьи Влада, то:

1. Сэкономил бы себе кучу времени
2. Наглядно показал всем как круто выглядит нормально написанная техническая статья.

VD>>А это моя статья, мой стиль и мой подход к изложению.

E>Стиль, значит. А со стороны выглядит так, что твои статьи просто никто не рецензирует, включая и себя самого.

Стиль. Статья написана легким в восприятии, разговорным языком. Как если бы Влад выступал с докладом, или на встрече участников RSDN, например.

E> -- снобизм и попытка закосить под элитарность.


Скорее, суровая правда жизни.

E>-- императивный программист такой тупой, что ему нужно объяснять все максимально просто.


Ипмеративный программист скорее рационален (как и любой другой). И предпочтет простое объяснение сложному.

E>Почему читатель должен тебе верить? Если лямбда-исчисление Черча есть -- дай ссылку, но просить поверить тебе не нужно.


См. выше про доклад и встречу участников.

E>-- выше и ниже где? Обычно пишут "об этом речь пойдет ниже" или "об этом было сказано выше". А когда "выше и ниже", это как?


Вполне уместный вопрос, в принципе

E>Лень было дать нумерацию разделов и указать пару нужных номеров?


И тут же наезд и личные домыслы

E>меня, как читателя статьи не волнуют проблемы твоего времени, затраченного на написание этой статьи. Либо реализация важна и должна быть приведена в тексте, либо не важна и об этом нужно прямо сказать. А отмазки вроде "много времени" могут пройти на форуме, но не в печатной статье.

E>Далее:

"Кстати, используя расширение синтаксиса, в конце запроса обязательно нужно писать ключевое слово select. Как говорилось в одном анекдоте – «Объясныт это нэлза! Это можьно толко запомныт!!!»."

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


См. выше про доклад и встречу участников. Статья легко читается, понятна, интересна и была востребована. Это следует хотя бы из проставленных участниками оценок. Это — важно. А все о чем говоришь ты, хоть местами и справедливо, но второстепенно. Если ты можешь осветить тему статьи лучше/понятнее/короче чем Влад, то просто сделай это. Тут думаю, будут только рады

P.S: Да, да — это тоже трындеж

[Интервью] .NET Security — это просто
Автор: kochetkov.vladimir
Дата: 07.11.17
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.