Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Gaperton, Вы писали:
G>>Ты как в очередной раз споришь сам с собой, выдумывая что говорит собеседник.
VD>Недадо мне припысывать чужих заслуг.
G>>Никто не говорил про "нельзя". VD>Да? А это чьи слова: VD>
G>Итераторы были-бы ленивыми, если бы значение элемента контейнера вычислялось в момент доступа к нему по итератору, т. е. было отложенным до момента чтения. Ух, какие это жесткие грабли в ИЯ! Брр!
Я не вижу здесь слова "нельзя". Здесь идет речь об итераторах, как о способе доступа к контейнеру. И утверждается, что такие итераторы не ленивые.
G>> Речь о том, что ленивые вызовы опасны при наличии побочных эффектов. Может ты начнешь наконец тратить время на чтение сообщений?
VD>Речь о том, что кто-то поняв что был не прав начал выкручиваться и переключать контекст обсуждения.
Речь о том, что ты ничего не понял с самого начала. А повыделываться охота. Вот начало ветки. http://www.rsdn.ru/Forum/Message.aspx?mid=789032&only=1
Так что оставь эти песни для других.
VD>Что до опасности, то я уже как-то говорил (раз 30), что сотни тысяч прграммистов использующих Шарп и Яву как-то не замечают этих опасностей. Иными словми имеет место намеренное завышение опасности.
Ты можешь повторить это хоть 50 раз. Однако синклер и большинство остальных почему-то поняли сразу, о чем речь.
Re[6]: Сильные стороны функционального программирования
Здравствуйте, faulx, Вы писали:
F>Пересказываю часть статьи своими словами. Вот вспомните пример с алгоритмом альфа-бета эвристики. Если бы у нас не было в распоряжении ленивых вычислений (а точнее говоря — ленивых, потенциально бесконечных структур данных), то модуль генерации возможных позиций (дерева игры) и модуль выбора оптимального хода были бы тесно связаны между собой: либо они были бы одним модулем, либо пришлось бы вводить сущность вроде итератора, которая, опять же, тесно связана с модулем генерации дерева и т.п.
Ну а так модуль связан со средой языка. То, что язык предоставляет нетипизированные списки ничего не говорит толкового о модульности. Я могу на C# сделать зашибись модульную программу, в которой все функции принимают и возвращают object[].
F> С бесконечными структурами данных все просто — один модуль генерирует бесконечное дерево, другой модуль выбирает оптимальный ход с учетом этого дерева. Друг о друге эти модули ничего не знают, и не нужны им никакие итераторы — достаточно самой структуры данных.
В твоем случае модули обмениваются, не делая предположений друг о друге. Но они делают предположения о формате данных! Это просто ужасно! Ведь тогда получается, что формат данных документирован только в кодах обрабатывающих их функций. Ну, вероятно, для простых списков это не критично.
F>Аналогия (все аналогии ущербны, а эту я придумал только что, но все равно приведу ее). Из крана льет вода, если его открыть и не льет, если закрыть. Тебе все равно, откуда в этом кране вода, с какой именно водонапорной башни (или что там у них) она подведена к крану. А теперь представь, что для того, чтобы принять душ, тебе надо набирать телефон водонапорной башни (это аналог итератора) и звонить туда, заказывая нужное количество воды. Ну и в какой схеме выше модульность?
Здесь ключевое не "все равно", а количество операций. На самом деле вода в твоем кране конечно же зависит от того, где башня. Но знание этого не входит в твою компетенцию. Если бы набор телефона осуществлялся автомитически при повороте тобой крана, то не было бы проблем. ФЯ предоставляют тебе инфраструктуру, в которой многое делается без непосредственного кодинга. Однако. Мэйнстрим ратует не только за укорачивание кода, но также и за управляемость. Достаточно вспомнить сколько было шума из-за оператора new в C++ и сборщика мусора в .NET
Re[18]: Сильные стороны функционального программирования
Здравствуйте, VladD2, Вы писали:
VD>>>Рад за тебя. Вот только кроме тебя были и другие люди пишущие код. И у некоторых из них он таки работал. G>>Эта система успешно работает более 10 лет . Четыре фермы серверов, самая крупная — в Чикаго. VD>Зачем тогда приводеть ее в качестве негативного примера? Или есть такая же система написаная на чистом ФЯ работающая 10 лет и не имевшая никаких проблем при разработке?
Читай ниже. 4-й абзац.
G>>Я эксперт по С++ . VD>Скромно и очень доказательно.
"То что ты все время говоришь о плюсах и о своем неудачном опитые всего лишь говорит о том, что твои скилы на плюсах меньше чем нужно чтобы решить данную проблему." — Скромно и очень доказательно. Все кругом дураки, один ты умный. Я рад был бы тебе ответить: да, я на самом деле такой тупой, каким ты меня считаешь. Но не могу, это была-бы неправда.
G>> И ведущий специалист компании по архитектуре данного приложения, sardonix не даст соврать. VD>Я в общем то верю и так. Хоя ссылка на какого-то sardonix-а явно выглядит смешно.
Какой-то sardonix — мой коллега, который сидит на соседнем этаже. И если я скажу неправду, он напишет опровержение.
G>> Работает оно великолепно, Влад, для приложения такого объема написанного на С++. Опыт у нас исключительно положительный. VD>Тогда сейчас ты сильно себе противоречишь.
Заработать можно заставить все что угодно, вопрос в цене. Когда я говорю, что оно работает великолепно — это правда. Когда я говорю, что мне не нравится цена, которая за это заплачена — это тоже правда. Когда я вижу, как эту цену можно было-бы уменьшить — я не считаю это противоречием с двумя предыдущими пунктами.
G>> И за последние 5 лет накоплена большая статистика по дефектам production-а, чтобы можно было достоверно говорить о причинах этих дефектов. Через меня и мою группу их прошла примерно тысяча (часть которых была вызвана тем, что SQA запутались в требованиях) — точно посмотреть не могу, т. к. пишу из дома. VD>Откровенно говоря 1000 для стольк масштабного продукта — это очень не много.
Это дефекты, найденные тестерами на фазе интеграции. А не те мелочи, над которыми ты сидишь в отладчике по 5 минут. Продукту примерно лет 15. Его постоянно развивали в течении этих лет. Над ним в разное время одновременно работало несколько групп общим количеством до 50 человек. Моя группа (в разное время от 2 до 8 человек) занималась подсистемой обработки данных. Работаю я здесь 5 лет (статистика за период примерно 4 года). Считай, много это, или мало.
VD>Ну, да фиг с ним. Какое это отношение имеет к ФЯ? Еще раз спрашиваю, почему при столь "явных" приемуществах ФЯ вы не выкинули С++ к чертям собачим и не переписали все на том же Хаскле?
Потому, что ни один дурак не бросится переписывать работающую и приносящую деньги систему в несколько миллионов строк, в разработку которой вложены огромные деньги. Честно говоря надоело разжевывать тебе прописные истины.
G>>Не сложнее, чем на С#, VD>Тут кто-то говорил мне о том, что я рссуждаю о Хаскеле не зная его? Не ты ли это был? Тогда что же ты не укоришь себя в том же? Я то о технических вопросах все же не рассуждал. А вот в дмнном случае ты разговариваеш о том, в чем явно ничего не смыслишь.
Если тебе приятно так думать , то ради бога. Шарпы такая немеряно сложная штука, что программисту на С++ их так просто не понять. И лучше наверно молчать в тряпочку.
VD>Писать код, и особенно отлаживать приложения на Шарпе на порядки проще чем на С++.
Ты знаешь что такое "на порядки"? Это больше чем в 100 раз. Оставь эти песни для других.
Наша статистика не подтверждает ни такого увеличения производительности , ни такого увеличения качества.
VD>В языке и рантайме предпринято множество мер упрощающих отладку. Самое смешное, что практически те же фичи ускоряют и упрощают отладку и ФЯ. Фичи эти хорошо извесны: строгий контроль типов, отсуствие ручного управления памятью, контрль рантайма.
Что ты тут пропаганду разводишь? Не надо следить за освобождением памяти, вот и все. Экономит (чаще) от 5 до (в редких случаях) 25% времени разработки. Зато: нет множественного наследования и нельзя создавать объекты на стеке. Вот что замечает большинство людей в первую очередь, переходя с С++ на С#. И они от этого не в восторге.
Справедливости ради надо похвалить remouting, компонентную модель, и библиотеки. Удобно. Но к "отладке" это не относится.
G>> если конечно умеешь пользоваться языком. VD>Сдается мне, что мои знания С++ не меньше твоих. По крайней мере проработав на этом языке 10 лет я имею право рассуждать о его достоинствах и недостатках. Так что предлагаю избежать измерения пенисов.
Так не меряйся.
VD>В общем, слушать тебя смешно. С++ надежен, Шарп неимеет никаких приемуществ, а вот Хаскель... Полная фигня. Серверы все больше и больше пишутся на Шарпе. Причем в основном из-за того, что это проще и надежнее. Да и не серверы тоже. Даже клиент к этому сайту написан на Шарпе. А вот есть ли подобные сайты и клиенты написанные на Хаскеле?
Смешной ты человек. Не помнишь даже, к чему это я про С++. Напомню. Ты предположил, что наша аппликуха не работает. Я тебя поправил. Ты предположил, что это потому, что я не знаю С++ на достаточном уровне, чтобы такое писать. Я тебя поправил. Теперь ты говоришь, что слушать меня смешно, потому что я якобы говорю, что С++ супернадежный язык. Сам с собой ведешь беседу, вобщем. В автономный режим перешел.
G>>Поправлю. Не отладки, а сложность поддержки и цену внесения изменений. Не путай, это совсем разные вещи. VD>Ты говорил и конкретно об отладке. Не нужно перепрыгивать.
Ссылку где я это так конкретно говорил. Хватит врать. Задергался, гляди ка.
VD>Но даже если говорить о "цену внесения изменений" и поддержке, то тут тоже твой любимый Хаскель вряд ли сможет тягаться с Шарпом или Явой просто потому, что для них создан целый ворох приложений, утилит, и мощьнейших IDE которые делают эти процессы простыми как три копейки.
Понятно. Не понимаешь, что такое "цена внесения изменений". Утилиты и мощнейшие IDE, ее снижают, надо же .
VD>Хотя конечно без должного проектирования можно все превратить в кашу. Тебе как архитектору это должно быть известно. VD> И нет проблем превратить в кашу самый что не наесть функциональный код. Как говорится с дуру можно и ... сломать.
Это всем известно.
G>>Потому, что сидел над своим кодом, который тебе знаком. VD>Ошибашся. К сожалению мне приходилось сидеть и за чужим кодом. Но на Шарпе отладка настолько проста и код насктолько хорошо читается, что о дне отладки, а уж темболее о неделе или месяце говорить не приходится. Просто ты отстал от жизни. Сосредоточился на ФЯ, а кроме них и другие области вперед продвинулись. Да вот такой я отсталый. Не знаю прелестей отладки в седьмой студии, исскуственный интеллект которой находит ошибки за 5 минут вместо одной недели.
G>>Понятно. На поддержке никогда не сидел. Функционала в чужой старый код большого объема не добавлял. VD>Я тебе уже несколько раз говорил. Код пишишь только ты. И знаешь тоже только ты. VD>В общем, убрал бы ты свое самомнение. Изходи из того, что с тобой разговаривают не менее опытные люди чем ты сам. А то просто противно разговаривать. Сенсей, блин.
Ты чо это заграничными непонятными словами обзываешься? На себя посмотри, сам такой . Например, на абзац выше.
G>>Подобные проблемы имеют обыкновение выглядеть как сложные зависимости в алгоритмах. VD>А какая мне тогда нафиг разница какой я парадигмы придерживаюсь? Если есть логическая ошибка, то ее осмысление зависит только от степени гибкости мозга.
Тебе — без разницы. Пиши на ассемблере. Умища должно хватить.
G>> А вообще, при исправлении дефектов всегда сложность состоит в том, чтобы понять ситуацию. VD>Не всегда. Как раз на плюсах очень часто возникают ошибки которые не свзаны с ошибкой непосредственно.
Пардон?
VD> Возмем к приеру проход по памяти. Да если ты все понял и нашел тот участок что портит память, то все ОК. Но логически вычислить такую ошибку нельзя. Так как ошибка в одном месте порождает ошибку высшего порядка в других. Тут уже нужно мастерство и шаманство.
Ошибки такой природы (связанные с повреждением памяти) у нас в релиз попадают крайне редко, а потому проблемой не являются, и группой тестеров находятся редко. Это во первых. Во вторых, за немотивированный "проход по памяти" в плюсах — по рукам. Нехрен. Здесь вам не С.
VD>То что в народе называют скилами. Я как раз очень долго занимался тем, что отлавливал ошибки не буеручки сделанные другими (на плюсах). С некоторым чутьем и набором отладочного софта эти проблемы тоже решаем, хотя не так быстро. Так вот когда я начал программировать на Шарпе, то понял насколько проще отлаживаться когда принципиально нет подобных проблем. Код попросту не может содержать то, что не ненаписано в коде. Ошибок высшего порядка добиться очень сложно, а от того обычные ошибки вылавливаются быстро и просто.
Не верю ((с) Станиславский). Не нужно рассказывать сказки.
G>> И при неопределенном порядке вычислений и наличии побочных эффектов это очень сложно. VD>Еще раз повторю. Не нужно рассказывать сказки. 20 минут на самую сложную ошибку. При создании того же парсера для R#-а намного сложнее было создать верную граматику, нежели найти мелкие ошибки. При более-менее человеческом дизайне они отлавливаются в секунды.
Ты вместо того, чтобы повторять ерунду всякую, прочитал бы предложение, на которое отвечаешь. Где это ты в парсере видал неопределенный порядок вычислений? Парсеры вообще штука простая и прямолинейная. Если знать теорию. И особенно, если пользоваться генератором
G>> Часто приходится встраивать в программу trace, ждать несколько дней, когда ситуация повторится, а потом долго разбирать trace, сопоставляя с кодом (чаще всего чужим, и правленным несколькими людьми), и пытаясь сообразить, как такое могло получиться. VD>Твой плюсовый опыт уже начинает надоедать. Поверь есть люди живущие по другому. Именно по тому многие мнее опытные и выбирают Шарп, что в нем не нужно сидеть недели на пролем с трэйсом.
Ну-ну. Волшебные шарпы уменьшают цену исправления дефекта в 50 раз. Наверно, благодаря отсутствию адресной арифметики и операторов delete. Смешно.
G>> И ты знаешь, иногда (редко) понять не получается, и приходится применять симптоматическое лечение — клиенты ждать не хотят! VD>Назвал то как! "симптоматическое лечение"! По простому — это называется заплатки/замазки, или сопли. Понятно что если продукт уже у заказчика, то иной раз не обойтись. Но намного лучше просто не доводить до подобного. И опять же когда ошибка ищится за пять минут, то подобные проблемы встречаются намного реже. Умные все стали. "До такого лучше не доводить". Нет, мы специально берем и доводим до такого. Ну не хватает ума у нас за 5 минут найти ошибку, на которую спец по подсистеме (не по языку!) тратит день, а не спец — неделю как рыба об лед.
Но теперь я знаю, что если то же самое написать на C# или Java, то любой человек с улицы найдет любую ошибку за 5 минут.
G>>Кстати, может прекратим "меряться пиписьками"? А то ты меня провоцируешь. VD>Ты это затеял. Так что не нужно про "провокации". Я тебе всего лишь заметил, что проекция твоего плюсового опыта на все ИЯ несколько некореектна. Вернее совсем некорректна. Это ты начал гордые заявления об экспертности и годах (не спрасив об оных у абонента).
Абонент не отвечает, или временно не доступен. Ты мне всего-лишь заметил, что я плохо знаю плюсы, ничего не понимаю в итераторах, рассказываю сказки про дефекты, не понимаю по русски, итд. То есть ты перешел на личности. Нехорошо.
Re[13]: Сильные стороны функционального программирования
Здравствуйте, Poudy, Вы писали:
P>Ну а так модуль связан со средой языка.
Все модули, написанные на каком-либо языке, связаны со средой этого языка. Что в этом плохого?
P> То, что язык предоставляет нетипизированные списки ничего не говорит толкового о модульности. Я могу на C# сделать зашибись модульную программу, в которой все функции принимают и возвращают object[].
Кажется, тут какое-то недопонимание. При чем здесь нетипизированные списки?
P>В твоем случае модули обмениваются, не делая предположений друг о друге. Но они делают предположения о формате данных! Это просто ужасно! Ведь тогда получается, что формат данных документирован только в кодах обрабатывающих их функций. Ну, вероятно, для простых списков это не критично.
Просто здесь не делается различия между "форматом данных" и "интерфейсом итератора". Если мы используем итератор по дереву, мы тоже (возможно, неявно) предполагаем некоторую структуру за этим итератором. Где документирована эта структура?
Сформулирую еще раз. При ленивом подходе не нужна отдельная сущность "итератор". Сама структура данных служит передадочным звеном. Media is the message, так сказать
P>Здесь ключевое не "все равно", а количество операций. На самом деле вода в твоем кране конечно же зависит от того, где башня. Но знание этого не входит в твою компетенцию. Если бы набор телефона осуществлялся автомитически при повороте тобой крана, то не было бы проблем. ФЯ предоставляют тебе инфраструктуру, в которой многое делается без непосредственного кодинга. Однако. Мэйнстрим ратует не только за укорачивание кода, но также и за управляемость. Достаточно вспомнить сколько было шума из-за оператора new в C++ и сборщика мусора в .NET
Так что, C++ и .NET — это не мэйнстрим?
Re[10]: Сильные стороны функционального программирования
Здравствуйте, VladD2, Вы писали :
V> документа. Исходите из того посыла, что если текст покажется V> убедительным мне, то он будет убедительным и для 80% других V> императивщиков.
А если его пойму я, то можно будет начинать в школе преподавать.
Еще вопросы, кто-нибудь ответит?
Нечеткая логика в ФЯ. Если любая переменная может принимать сразу множество значений, а логика описывает только работу с одним значением, тогда нужно вычислять все ветви и получать многомерный результат. Для этого требуется расширять язык или можно сделать в рамках того же? Любую переменную можно заменить списком переменных, полиморфизма ФЯ хватит?
Более точно — требуется работать не с отдельными переменными, а с пакетами, в любое лямбда выражение подставляется только один пакет, однако содержащий много переменных. Переменные типизированы, поэтому при подстановке автоматически выбирается что куда подставить.
Совсем замечательно было бы, если бы лямбда, куда подставляем пакет, могла заказать у этого пакета переменную некоторого типа, то есть даем пакету тип и получаем такую переменную если там есть такая. Такое вообще, бывает? Какой-нибудь Call-by-callback?
Или как более частный случай — значения "по умолчанию", в ФЯ не предусмотрены? Т.е. если есть что подставлять, то считаем переменную свободной и подставляем, если нечего, то вычисляем со значением по умолчанию. Это не совсем подстановка, а скорее подмена. Это тоже можно сделать не расширяя язык? Наверно, можно это сделать с обертками вроде MayBe, но тут мне кажется принципиальыный вопрос, требуется нечто среднее между строгим языком т.к. обертку нужно разворачивать, и нестрогим т.к. с тем, что в обертке нужно работать уже в lazy режиме.
ON>Нечеткая логика в ФЯ. Если любая переменная может принимать сразу множество значений, а логика описывает только работу с одним значением, тогда нужно вычислять все ветви и получать многомерный результат. Для этого требуется расширять язык или можно сделать в рамках того же? Любую переменную можно заменить списком переменных, полиморфизма ФЯ хватит?
Не могу сказать в целом, но одновременное вычисление возможно в отдельных случаях. Например, монадный парсер из примеров к Haskell'ю вычисляет сразу несколько альтернатив. Монада-список очень похожа на то, что ты хочешь.
Ее тип [a] -> (a -> [b]) -> [b]. Т.е. для всех элементов a списка вычисляется результат список [b], а потом результаты объединяются.
ON>Более точно — требуется работать не с отдельными переменными, а с пакетами, в любое лямбда выражение подставляется только один пакет, однако содержащий много переменных. Переменные типизированы, поэтому при подстановке автоматически выбирается что куда подставить. ON>Совсем замечательно было бы, если бы лямбда, куда подставляем пакет, могла заказать у этого пакета переменную некоторого типа, то есть даем пакету тип и получаем такую переменную если там есть такая. Такое вообще, бывает? Какой-нибудь Call-by-callback?
Из-за строгой типизации не может быть функции, возвращающей разные типы. Можно только эмулировать бестиповость. Объявить тип типа
data NoType = Integer Int | Str String | MyType1 ... | ....
И работать с ним методом списка.
ON>Или как более частный случай — значения "по умолчанию", в ФЯ не предусмотрены? Т.е. если есть что подставлять, то считаем переменную свободной и подставляем, если нечего, то вычисляем со значением по умолчанию. Это не совсем подстановка, а скорее подмена. Это тоже можно сделать не расширяя язык? Наверно, можно это сделать с обертками вроде MayBe, но тут мне кажется принципиальыный вопрос, требуется нечто среднее между строгим языком т.к. обертку нужно разворачивать, и нестрогим т.к. с тем, что в обертке нужно работать уже в lazy режиме.
Значения по умолчанию есть в O'Caml. В Haskell'e придется объявлять дополнительные функции.
create_array num elem = ....
cerate_array_0 num = create_array num 0
На самом деле значения по умолчанию опасны в ФЯ по следующей причине
my_func x y = x + y
result = my_func 1
Если бы x или y имел значение по умолчанию, здесь возникла бы 3-ная неоднозначность. f _ 1, f 1 _, f 1 (как частичная функция)
Re[12]: Сильные стороны функционального программирования
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Gaperton, Вы писали:
G>>У меня предложение попроще, способное на порядок поднять культуру общения. Давайте Чистякоа перестанет хамить и переходить на личности.
VD>То что ты называешь хамством другие называют называть вещи своими именами. Или говорить правду. Что же до хамства, то не тебе об этом говорить. Кажется не я поднял вопрос о быдляцких манерах (или что там было быдляцкого?).
Ну, то что свое хамство ты считаешь "называнием вещей своими именами" и "говорением правды", я в курсе. И по моему ясно высказал свое мнение на эту тему. Блин. Ты русский язык понимаешь? (пример называния вещей своими именами) Судя по твоим сообщениям — нет. (а этот оборот, тоже из тебя — это я правду говорю.)
Что же до хамства и быдляцких манер, то сосчитай минусы, которых ты нахватал в той ветке, рассуждая на эту тему. Ллойда можешь вычесть, все равно неплохо останется. Так что может мне об этом и не говорить, а уж тебе то точно на эту тему молчать. Впрочем, это не твой метод .
Re[16]: Сильные стороны функционального программирования
Здравствуйте, VladD2, Вы писали:
L>>2VladD2: нет, это не конвульсии и не случайность. это адекватная реакция на твое хамское неуважение к аппонентам.
VD>Ну, предположим назовем мои слова "хамское неуважение к аппонентам" хотя звучит довольно смешно. "Хамское неуважение".
Ну извини, я не смог придумать слова более точно описывающего ситуацию, когда к человеку проявляют неуважение и при этом хамят. Возможно, есть вариант, который пнрвился бы тебе в большей степени.
VD>Но что такого хамского ты нашел, например, в этом: Re[12]: Сильные стороны функционального программирования
Ну во первых кнопочка с минусом называется "Не согласен". А что касается именно этого сообщения, то понимай это как "я не согласен, что без качественной затравки в виде статейки ..."
VD>И почему тогда ты ненашел ничего хамского в данном? Не кажется ли тебе, что свое явно предвзятое суждение о человеке ты выливашь в толпу минусов?
Ну откуда у меня может быть о тебе предвзятое суждение? Мое мнение о тебе могло сформировалось только исключительно по постам в те форумы, что я читаю. Ах да, забыл. Есть же еще профиль. Но и там вроде ничего преступного нет. Так что твое предположение неверно.
VD>И не наводит ли тебя на мысль, что тебя в большинстве случаев не поддерживат даже те кто спорит со мной?
Ну я бы не сказал, что совсем уж не поддерживают.
VD>Почему я не видел ни одного твоего минуса даже на окровенные оскарбления тем же Gaperton других участников форума?
Здравствуйте, VladD2, Вы писали:
VD>Явно какой-то заклинивший. Нечто вроде тика.
Дружок, не заклинивайся на себе. Если ты считаешь себе центром вселенной, то поверь мне, ты сильно ошибаешься.
VD>Да и дело модератора следить за нарушениями. А то как-то следит только за моими. Причем мерещатся они везде. Вроде даже голосование создал. Его все послали куда полдальше...
Ху из послал меня подальше? Администраторы — члены rsdn-team?
VD>Да мне даже забавно. Но итересны мотивы.
Повторяешься, просмотри мои ответы на твои посты. И ты увидишь мотивы.
... << RSDN@Home 1.1.4 @@subversion >>
Re[19]: Сильные стороны функционального программирования
Здравствуйте, Gaperton, Вы писали:
G>Смешной ты человек. Не помнишь даже, к чему это я про С++. Напомню. Ты предположил, что наша аппликуха не работает. Я тебя поправил. Ты предположил, что это потому, что я не знаю С++ на достаточном уровне, чтобы такое писать. Я тебя поправил. Теперь ты говоришь, что слушать меня смешно, потому что я якобы говорю, что С++ супернадежный язык. Сам с собой ведешь беседу, вобщем. В автономный режим перешел.
Не будь к нему так строг. Ему тоже не просто. 200 сообщений в неделю — думаю ты тоже многое бы забыл.
... << RSDN@Home 1.1.4 @@subversion >>
Re[21]: Сильные стороны функционального программирования
Здравствуйте, Gaperton, Вы писали:
G>>>Никто не говорил про "нельзя". VD>>Да? А это чьи слова: VD>>
G>Итераторы были-бы ленивыми, если бы значение элемента контейнера вычислялось в момент доступа к нему по итератору, т. е. было отложенным до момента чтения. Ух, какие это жесткие грабли в ИЯ! Брр!
G>Я не вижу здесь слова "нельзя". Здесь идет речь об итераторах, как о способе доступа к контейнеру. И утверждается, что такие итераторы не ленивые.
О! Снова какие-то выверты. Про контейнер ты все сам додумал. И слова "были-бы ленивыми" никак подругому интерпретировать нельзя. Были бы, значит не были. Зачем предпологать то что и так является фактом?
Итераторы — это абстракция доступа к спискам. Список не обязан быть контейнером. В общем, просто признай, что был не прав. Эти выкручивания выглядят просто несерьезно.
VD>>Речь о том, что кто-то поняв что был не прав начал выкручиваться и переключать контекст обсуждения. G>Речь о том, что ты ничего не понял с самого начала.
Да, забавная особенность. Даже сам понял, что был не прав, но продолжашь честно смотря в глаза чмырить других. Браво!
G>Ты можешь повторить это хоть 50 раз. Однако синклер и большинство остальных почему-то поняли сразу, о чем речь.
Спросим у Синклера? Или у большинства других? Особенно забавно про "большинствао" .
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[19]: Сильные стороны функционального программирования
Здравствуйте, Gaperton, Вы писали:
G>"То что ты все время говоришь о плюсах и о своем неудачном опитые всего лишь говорит о том, что твои скилы на плюсах меньше чем нужно чтобы решить данную проблему." — Скромно и очень доказательно. Все кругом дураки, один ты умный. Я рад был бы тебе ответить: да, я на самом деле такой тупой, каким ты меня считаешь. Но не могу, это была-бы неправда.
Ну, ты как нибудь определись все же.
G>Какой-то sardonix — мой коллега, который сидит на соседнем этаже. И если я скажу неправду, он напишет опровержение.
Ты уже тут заливал не однократно и что-то sardonix-ов видно при этом небыло. Да его просто не видно. Видимо ему твои тирады просто безразличны.
VD>>Тогда сейчас ты сильно себе противоречишь. G>Заработать можно заставить все что угодно, вопрос в цене.
Ну, ты все же определись. Так работало оно великолепно, или каке-как добились работоспособности. А то как-то то тсую, то туда.
G> Когда я говорю, что оно работает великолепно — это правда. Когда я говорю, что мне не нравится цена, которая за это заплачена — это тоже правда. Когда я вижу, как эту цену можно было-бы уменьшить — я не считаю это противоречием с двумя предыдущими пунктами.
Дык я тебя и спрашиваю. Вы когда писали все это ты про ФЯ знал? Что не применил то? Зачем силы тратили?
VD>>Откровенно говоря 1000 для стольк масштабного продукта — это очень не много. G>Это дефекты, найденные тестерами на фазе интеграции. А не те мелочи, над которыми ты сидишь в отладчике по 5 минут.
Ну, типа у нас ОШИБКИ, а у вас каки-то жалкие бажки.
G> Продукту примерно лет 15. Его постоянно развивали в течении этих лет. Над ним в разное время одновременно работало несколько групп общим количеством до 50 человек. Моя группа (в разное время от 2 до 8 человек) занималась подсистемой обработки данных. Работаю я здесь 5 лет (статистика за период примерно 4 года). Считай, много это, или мало.
А зачем мне считать? Бессмыслицей является вообще какие либо выводы о всех ИЯ на базе этого опыта. Ведь не факт что этот проект вообще заработал бы с приемлемой производительностью будь он написан на ФЯ. И не факт, что сложность не сократилась бы раз в 10 если бы вместо С++ был бы Шарп. Вернее факт, что сократилась бы.
VD>>Ну, да фиг с ним. Какое это отношение имеет к ФЯ? Еще раз спрашиваю, почему при столь "явных" приемуществах ФЯ вы не выкинули С++ к чертям собачим и не переписали все на том же Хаскле? G>Потому, что ни один дурак не бросится переписывать работающую и приносящую деньги систему в несколько миллионов строк, в разработку которой вложены огромные деньги. Честно говоря надоело разжевывать тебе прописные истины.
Ну, по твоим же словам увеличение только произодительности программиста минимум в 4 раза. А поддержку вообще сравнивать нельзя. Да при таких раскладах (если конечно все это не треп) брось вы С++ даже на половине готовности вы бы закончили быстрее бы и качество было бы куда выше. Тут у тебя вная не стыковочка.
G>>>Не сложнее, чем на С#, VD>>Тут кто-то говорил мне о том, что я рссуждаю о Хаскеле не зная его? Не ты ли это был? Тогда что же ты не укоришь себя в том же? Я то о технических вопросах все же не рассуждал. А вот в дмнном случае ты разговариваеш о том, в чем явно ничего не смыслишь.
G>Если тебе приятно так думать ,
А тут и думать нечего. Ты своим незнанием гордишся.
G> то ради бога. Шарпы такая немеряно сложная штука, что программисту на С++ их так просто не понять. И лучше наверно молчать в тряпочку.
Не пробовал, не знашь, но заявления делашь. Изумительно! Да что уж молчание в тряпочку, хотя бы малейшее сомнение с твоей стороны тут было бы куда уместнее. Но "ты же у нас всегда прав" (с).
VD>>Писать код, и особенно отлаживать приложения на Шарпе на порядки проще чем на С++. G>Ты знаешь что такое "на порядки"? Это больше чем в 100 раз. Оставь эти песни для других.
На порядки — это более чем в 10 раз. Или у тебя без ФЯ проблемы с вычислениями.
G>Наша статистика не подтверждает ни такого увеличения производительности , ни такого увеличения качества.
Ваша статистика не весомее ваших слов. Ты лучше привди эту статистику, а не расказывай о ней. Хотя как можно говорить, о статистике когда ты вообще не знашь, что это за язык и что он может.
VD>>В языке и рантайме предпринято множество мер упрощающих отладку. Самое смешное, что практически те же фичи ускоряют и упрощают отладку и ФЯ. Фичи эти хорошо извесны: строгий контроль типов, отсуствие ручного управления памятью, контрль рантайма. G>Что ты тут пропаганду разводишь?
Я? Ух ты. А я грешным делом на тебя подумал. Думаю, сидит травит байки про супер приемущества ФЯ всегда и во всем. А оказывается это был я.
G> Не надо следить за освобождением памяти, вот и все.
Мастер! Откуда у тебя такие познания то глубокие? За ночь что ли освоил все. Так я тебя огорчу. Ты 90% возможностей проглядел. GC конечно вещь полезная, но она не одна. Фич направленных на безопасность очень много. Так что низнаеш ты в данном случае нихрена о предмете разговора вот и все.
G> Экономит (чаще) от 5 до (в редких случаях) 25% времени разработки. Зато: нет множественного наследования и нельзя создавать объекты на стеке.
О! Какие познания! Жаль только видимо не там. Так как объекты в стеке как раз создавать можно. В языке типы данных как раз на две группы делятся: ссылочные и вэлью-типы. Последние можно создавать в стеке и будучи помещенными в другие объеты они становятся их частью, а не ссылкоу (в том числе хранятся в массивах по значению). Так что ты явно с чем-то Шарп спутал. Видимо слышал что-то о Яве и ассоциировал ее с Шарпом.
G> Вот что замечает большинство людей в первую очередь, переходя с С++ на С#.
Не поверишь! Я как раз с плюсов и переходил. И еще языков 7 знал. Отсуствие МН по началу действительно казалось проблемой. Потом правда оказалось, что не смертельная проблема и с лихвой компенсируется упращением разработки.
G> И они от этого не в восторге.
G>Справедливости ради надо похвалить remouting, компонентную модель, и библиотеки. Удобно. Но к "отладке" это не относится.
Скажи, а отсуствие проблем с типами тоже отладки не способствует? А кортроль выхода за границы массива? А то, что в библиотеках проверок больше чем кода в вашем проекте? А то что отладчик позвляет налюдать за содержимым даже внутренних (закрытых) типов описанных в глубинах чужих модулей? А то, что стэк вызовов никогда не портится и колстэк всегда четко видно и с ним нет проблем?
VD>>Сдается мне, что мои знания С++ не меньше твоих. По крайней мере проработав на этом языке 10 лет я имею право рассуждать о его достоинствах и недостатках. Так что предлагаю избежать измерения пенисов. G>Так не меряйся.
Так ты все гордишся длинной и изгибом.
VD>>В общем, слушать тебя смешно. С++ надежен, Шарп неимеет никаких приемуществ, а вот Хаскель... Полная фигня. Серверы все больше и больше пишутся на Шарпе. Причем в основном из-за того, что это проще и надежнее. Да и не серверы тоже. Даже клиент к этому сайту написан на Шарпе. А вот есть ли подобные сайты и клиенты написанные на Хаскеле? G>Смешной ты человек.
Я то? Да...
G> Не помнишь даже, к чему это я про С++.
Ну, как же? Ты проталкивал идею о том, что ФЯ значительно проще и безопаснее чем ИЯ так как у тебя был жуткий опыт траха с С++ и небыло с ФЯ. На возражение о том, что не все ИЯ одинаково полезны, ты начал тщетно доказывать, что все и что это явное доказательство твоих слов. В пылу доказательств не поверил в то, что и Шарп значительно проше и удобнее чем С++ ну, и т.п.
G> Напомню. Ты предположил, что наша аппликуха не работает.
Я предположил?
G>Я тебя поправил. Ты предположил, что это потому, что я не знаю С++ на достаточном уровне, чтобы такое писать.
Я предположил, что люди "вдвоем ущущие ошибки и не находящие их на протяжении месяцев" просто не столь высокоскильны чтобы этим заниматься и что возможно им было бы проще взяв другой язык. И так же предполжил, что не обязательно брать ФЯ.
G> Я тебя поправил. Теперь ты говоришь, что слушать меня смешно, потому что я якобы говорю, что С++ супернадежный язык. Сам с собой ведешь беседу, вобщем. В автономный режим перешел.
А можт быть все было несколько иначе? Может быть ты предположил, что на С++ тяжело писать большие сложные проекты, и что единственным решением является переход на ФЯ (который вы в прочем не сделали)? А я предположил, что вместо ФЯ с тем же успехом можно было бы просто взять Шарп? А ты предположил, что Шарп фигня так как в нем кроме ЖЦ ничего нет и стал уверять, что тебе изучать что-то не нужно чтобы рассуждать о его возможностях?
VD>>Ты говорил и конкретно об отладке. Не нужно перепрыгивать. G>Ссылку где я это так конкретно говорил.
Ну, вот ту, наприер:
Поверь мне, я знаю, какие проблемы бывают на практике, а каких не бывает. И каждый, кто учавствовал в проектах размером от 100 тыщ строк, знает, какие интересные эффекты начинаются. И неделя на один дефект — это ерунда, Влад, это типичная ситуация. А бывает месяц вдвоем на один дефект. А бывает два месяца — и никакого результата.
Или речь шала о дефектах проектировния? А может (страшно подумать! ) о дефектах мозга пользователей?
G>Хватит врать.
И правда, конча!
G> Задергался, гляди ка.
Это ты параллельно на себя в зеркало что ли смотриш и реакцию записываешь?
VD>>Но даже если говорить о "цену внесения изменений" и поддержке, то тут тоже твой любимый Хаскель вряд ли сможет тягаться с Шарпом или Явой просто потому, что для них создан целый ворох приложений, утилит, и мощьнейших IDE которые делают эти процессы простыми как три копейки. G>Понятно. Не понимаешь, что такое "цена внесения изменений".
Ну, куда мне убогому. Вот сэнсэй он все знает. Щаз носом тыкнет.
G> Утилиты и мощнейшие IDE, ее снижают, надо же .
А ты как-нибудь оторвись от размышлений о судьбе ФЯ и глянь современные IDE. Ну, там Эклипс, VS 2005, Решарпер и т.п. Там есть такие фичи как рефакторин. Забавнейшая вещь надо сказать. Позволяет делать громадные изменения кода довольно просто, быстро и без ошибок.
VD>> И нет проблем превратить в кашу самый что не наесть функциональный код. Как говорится с дуру можно и ... сломать. G>Это всем известно.
Ну, а тогда зачем проблемы недопродуманности проецировать тонь на ИЯ? Что на ФЯ нельзя довести проект до развала?
G> Да вот такой я отсталый. Не знаю прелестей отладки в седьмой студии, исскуственный интеллект которой находит ошибки за 5 минут вместо одной недели.
Ну, ты познакомься. Хотя уже давно пора с 8-ой знакомиться. Да и не в студии дело. С отладкой С++ хотя тоже изменения произошли, но до дотнета она не дошла. Все же язык имеет свои особенности.
G>Ты чо это заграничными непонятными словами обзываешься?
У тебя учусь.
G> На себя посмотри, сам такой . Например, на абзац выше.
Я про твой опыт начинаю говорить, когда ты им пытаешся помахать в воздухе. Надоели слова вроде "ты в чужой код изменения не вносил". Я лет пять только и занимлся, что правил чужой код. Что мне перед тобой теперь отчитываться. Запомни по умолчанию, катят только факты. Все попытки сказать, что кто-то чего-то не делал идут в лес.
VD>>А какая мне тогда нафиг разница какой я парадигмы придерживаюсь? Если есть логическая ошибка, то ее осмысление зависит только от степени гибкости мозга. G>Тебе — без разницы. Пиши на ассемблере. Умища должно хватить.
То есть типа провел аналогию между всеми ИЯ по сравнению с ФЯ и ассемблером по сравнению с ИЯ. Вот только для того, чтобы такие аналогии проводить нужно еще сходность черт доказать. А без того это дешевый демагогический прием. В общем, неумелая подколка.
Логическая ошибка и на ассемблере будет таковой. Другое дело, что на ассемблере вероятность того, что имеется и не логическая ошибка намного больше. А вот ФЯ и ИЯ такой пропости нет. Многие вещи что легко пишутся императивно выглядят в рекурсивной, функциональной записи более чем плохо. И чтобы найти там логическую ошибку мозг прийдтся поставить раком. Так что умища может не хватить.
VD>>Не всегда. Как раз на плюсах очень часто возникают ошибки которые не свзаны с ошибкой непосредственно. G>Пардон?
Про ошибки второго и третьего порядка, или в просторечье налаженку слышал?
G>Ошибки такой природы (связанные с повреждением памяти) у нас в релиз попадают крайне редко, а потому проблемой не являются, и группой тестеров находятся редко.
Позволь усомниться. Не думаю, что в той же команде Ворда сидят менее талантливые люди, но вот у них почему-то проходы по памяти живут в релизах и переходят из версии в версию. Да и тогда совсем не ясно, что вы там искали месяцы на пролет (вдвоем) и так и не нашли.
G> Это во первых. Во вторых, за немотивированный "проход по памяти" в плюсах — по рукам. Нехрен. Здесь вам не С.
Да за любую ошибку премию не дадут. Но на плюсах без тех же вызовов АПИ вряд ли обойдешся. И не факт, что все параметры заданы верно. Безобидыный вроде с виду код может привести к порче байтика, тат в свою очередь запортит другой, а где-нибудь в другом месте программы в 100%-но корректном участке кода грохнет. И будете вы сидеть тот самый месяц но так ошибку и не найдете. А в типобезопасном Хаскеле или Окамле такую ошибку сделать невозможно принципиально. Вот тебе и значительное приемущество в простоте отладки. Вот только в Шарпе с этим тоже проблем нет, так как невозможно обойти систему типов, а вызовов АПИ на порядки меньше, да и те защищаются так, что если и грохнет, то сразу.
VD>>То что в народе называют скилами. Я как раз очень долго занимался тем, что отлавливал ошибки не буеручки сделанные другими (на плюсах). С некоторым чутьем и набором отладочного софта эти проблемы тоже решаем, хотя не так быстро. Так вот когда я начал программировать на Шарпе, то понял насколько проще отлаживаться когда принципиально нет подобных проблем. Код попросту не может содержать то, что не ненаписано в коде. Ошибок высшего порядка добиться очень сложно, а от того обычные ошибки вылавливаются быстро и просто.
G>Не верю ((с) Станиславский). Не нужно рассказывать сказки.
Фома не верующая (с) народная мудрость. Зайди на форум по дотнету и спроси. Думаю, там тебе каждый подтвердит.
И вообще, зачем верить? Сядь и попробуй. Ты же сам говоришь, что для стольк опытного человека как ты изучить какой-то там язык без МН проблем не сотавит. Глядишь тогда и взгляды изменятся.
G>>> И при неопределенном порядке вычислений и наличии побочных эффектов это очень сложно. VD>>Еще раз повторю. Не нужно рассказывать сказки. 20 минут на самую сложную ошибку. При создании того же парсера для R#-а намного сложнее было создать верную граматику, нежели найти мелкие ошибки. При более-менее человеческом дизайне они отлавливаются в секунды. G>Ты вместо того, чтобы повторять ерунду всякую, прочитал бы предложение, на которое отвечаешь. Где это ты в парсере видал неопределенный порядок вычислений?
Дык он же на ИЯ. А "в них побочные эффекты". Ну, а "неопределенный порядок вычислений" создается просто неопределенностью потока данных. Исходники знае те ли... Бежит набор токенов (кстати именно поток в котором можно толучать только следующий токен) и нужно их анализировать какое бы причудливое сочетание они не составляли бы.
G> Парсеры вообще штука простая и прямолинейная. Если знать теорию. И особенно, если пользоваться генератором
Да если не пользоваться генератором, то эта простая штука до белого коления может довести. Правда ФЯ так круты, что немного не ясно зачем они им. Но ведь есть же? Да и не такая простая штука эти парсеры если язык сложную граматику имеет.
G>Ну-ну. Волшебные шарпы уменьшают цену исправления дефекта в 50 раз.
Да порой просто устраняет возможность их появления. Это даже в процентах не измерить. Но ты же не повеириш? Ведь на это способны только ФЯ.
G> Наверно, благодаря отсутствию адресной арифметики и операторов delete. Смешно.
Благодаря наличию строгой типизации и рантайм-проверок. Ну, и еще куче факторов. В общем, смейся.
G>>> И ты знаешь, иногда (редко) понять не получается, и приходится применять симптоматическое лечение — клиенты ждать не хотят! VD>>Назвал то как! "симптоматическое лечение"! По простому — это называется заплатки/замазки, или сопли. Понятно что если продукт уже у заказчика, то иной раз не обойтись. Но намного лучше просто не доводить до подобного. И опять же когда ошибка ищится за пять минут, то подобные проблемы встречаются намного реже. G> Умные все стали. "До такого лучше не доводить". Нет, мы специально берем и доводим до такого. Ну не хватает ума у нас за 5 минут найти ошибку, на которую спец по подсистеме (не по языку!) тратит день, а не спец — неделю как рыба об лед.
Ума у вас не хватило на то чтобы взять другой язык или вообще не писать код, а например его генерировать. Но ты же не поверишь, что без ФЯ можено упростить программирование и отладку?
G>Но теперь я знаю, что если то же самое написать на C# или Java, то любой человек с улицы найдет любую ошибку за 5 минут.
Опять дешевые трюки. "любой человек с улицы". Зачем передергивать? Не любой конечно, но именно, что вместо месяца отладка сведется к десяти минутам, максимум к паре часов. Естественно если в результате анализа станет ясно, что ошибка в проекте и нужно перелопатить его десятую часть, то тут ничего не попишешь. Но установить проблему можно довольно быстро.
Вообще, забавно, что ты восхваля ФЯ даже не задумался, что во многом это достоинства строгой типизации и контроля, а не самой парадигмы как таковой.
G>Абонент не отвечает, или временно не доступен.
G> Ты мне всего-лишь заметил, что я плохо знаю плюсы
Я? Где? Цитату в студию!
G>, ничего не понимаю в итераторах,
Ну, это ты просто таки доказывал на протяжении нескольких постов споря с Синклером. Правда потом вроде де бы до тебя дошло.
G> рассказываю сказки про дефекты, не понимаю по русски, итд. То есть ты перешел на личности. Нехорошо.
Да? А я то думал не хорошо тыкать других носом и говорить, что они что-то там не знают, при этом вообще не удостоверившись в том, что они знаю, а что нет. Так же думл, что не хорошо говорить про себя "я эксперт". Думал, что не здорово говорить собеседнику про "быдляцкие манеры". Или чтобы они нихрена не понимают и что с ними разговривать не охота. А оказывается это все хорошо. А замечать об этом плохо, так как переходит на обсуждение личности оппонента. Во оно как?...
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Сильные стороны функционального программирования
Здравствуйте, Gaperton, Вы писали:
G>Ну, то что свое хамство ты считаешь "называнием вещей своими именами" и "говорением правды", я в курсе.
Кстати, а ты в курсе как разывается твое хамсвто? Да и вообще в курсе о его существовании?
G> И по моему ясно высказал свое мнение на эту тему.
Ага помню. Я тебе как-то дико оскорбил фразой "тут ты не прав".
G> Блин. Ты русский язык понимаешь? (пример называния вещей своими именами) Судя по твоим сообщениям — нет. (а этот оборот, тоже из тебя — это я правду говорю.)
И?
G>Что же до хамства и быдляцких манер, то сосчитай минусы, которых ты нахватал в той ветке, рассуждая на эту тему.
И что мне их считать? Они от трех человек в основном. Хочешь тебе тут тоже трое четверо минусов нафигачет? Пойми просто есть адекватные люди не разбрасывающиеся своими оценками на право и на лево. А то они ведь деградируют от частого применения. Если бы этоту ветку прочитали бы по болше людей, то думаю было бы и море плюсов. Но этоти фанатичные разборки просто никто уже читать не хочет. Вот и получается, что сидишь ты с Лойдом (который вообще минусы на право и на лево расставляет) и лепиш минусы по чем зря. Ну, да хорошо хоть в одной теме. А то вон Мика вообще случая не упустит чтобы минус жмякнуть. Ну, а я рад. Поклонник все же.
Ты вот свои минусы что-то не считашь. А тебе их точно не чтобы насолить ставят.
G> Ллойда можешь вычесть,
Дык если его вычесть, то остаешся в основном ты. Остальные ставят минусы довольно редко. Так же ставят еще плюсы и оценки. Хотя мне как то на это наплевать. Хочется и ставят.
G> все равно неплохо останется.
Ну, да. Ты не скупишся.
G> Так что может мне об этом и не говорить, а уж тебе то точно на эту тему молчать. Впрочем, это не твой метод .
Кстати, хочешь эксперемент? Вскажи все что ты тут про Шарп налепил в отдельной теме или (что еще лучше) в форуме по дотнету. Я тебе гарантирую несколько десятков минусов. Просто этот бред обычные люди дочитать не могут. Тут остались только те кто слишком не равнодушен к ФЯ.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: Сильные стороны функционального программирования
Здравствуйте, Lloyd, Вы писали:
L>Дружок, не заклинивайся на себе. Если ты считаешь себе центром вселенной, то поверь мне, ты сильно ошибаешься.
Да я вот тоже думал, что центром вселенского зла не являюсь. Но глядя на твое нерное тыканье на минсу начинаю сомниваться в своих "думах".
L>Ху из послал меня подальше? Администраторы — члены rsdn-team?
Да что-ты... послали люди. Там народ пунктик создал "удалить эту провакацию" (или что-то вроде того). А админы просто с дури выполнили требование. А потом народ еще два дня искал голосование в пусорке чтобы скриншот сделать для "Колеги улыбнитесь".
VD>>Да мне даже забавно. Но итересны мотивы.
L>Повторяешься, просмотри мои ответы на твои посты. И ты увидишь мотивы.
Да ответы то есть, а вот мотивы как-то так ясными и не становятся. Хотя в принципе понятно.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: Сильные стороны функционального программирования
Здравствуйте, Lloyd, Вы писали:
L>Ну во первых кнопочка с минусом называется "Не согласен". А что касается именно этого сообщения, то понимай это как "я не согласен, что без качественной затравки в виде статейки ..."
Не, ну должен же быть какой-то разумный предел несогласия. Как можно понять с чем ты там не согласен? Обычно люди как-то словами выражают несогласие по отдельным частям сообщения. А то может ты не согласен с "Нужно сфорировать нормальный документ способный привлечь к проблеме тех кто пока не видит смысла в ФЯ" или "Принципиальное решение уже принято". Не находишь?
VD>>И почему тогда ты ненашел ничего хамского в данном? Не кажется ли тебе, что свое явно предвзятое суждение о человеке ты выливашь в толпу минусов?
L>Ну откуда у меня может быть о тебе предвзятое суждение?
Да? Откуда?
L> Мое мнение о тебе могло сформировалось только исключительно по постам в те форумы, что я читаю. Ах да, забыл. Есть же еще профиль. Но и там вроде ничего преступного нет. Так что твое предположение неверно.
Предположение о чем? Не не может же быть так, что ты видишь только мое хамство, и хамство АВК. А хамство Gaperton становится лично для тебя невидимым? Ну, и уж точно не поверю, что ты согласен со всем что говорится в форумах так как не ставишь минусы на каждый пост.
VD>>И не наводит ли тебя на мысль, что тебя в большинстве случаев не поддерживат даже те кто спорит со мной?
L>Ну я бы не сказал, что совсем уж не поддерживают.
А я бы сказал. Ты то же голосование создал, чтобы убедиться, что еще четыре человека есть согласных с тобой или все же хотел найти поддержку в массах?
VD>>Почему я не видел ни одного твоего минуса даже на окровенные оскарбления тем же Gaperton других участников форума?
L>Ок. Давай посмотрим.
VD>>Re[10]: ФЯ
Правда? "Быляцкие манеры" раз и на всегда заткнувшие рот Larm-а — это не хамство? Как интересно! А за что же он был удостоен такой чести? Он как-то оскорбил кого-то? Да и куда ты там лазил по ветке вверх? Это было первое и последнее сообщение Larm-а в этой теме.
L>Посмотри сообщение выше по ветке. Со стороны Gaperton-а это была совершенно нормальная реакция.
VD>>Re[10]: Сильные стороны функционального программирования
И здесь все ОК? И здесь ты что-то выискал вверх по ветке? Маладэс. Ай браво. Честный судья. Главное лубиш судать. Это приятно. Ну, а то что после этого хамства Glоbus так же прекратил всякое общение с Gaperton — это уже мелочи. Так?
VD>>Re[8]: Сильные стороны функционального программирования
Кто бы сомневался.
VD>>Двойные стандарты?
L>Отнюдь. Очень даже одинарные.
Это радует. Я вообще считаю, что самое обидное это посредственность. Ее не замечают. А такая принципиальность таки просто не может не радовать.
VD>>Чесное слово. Просто любопыткно.
L>Всегда пожалуйста.
Всегда сапасибо. Приятно видеть человека честного, непредвзятого и с чистой совестью.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
, ни такого увеличения качества.
