О чем тут спорите, ещё вообще помнит кто-то ?
> E>>PS. Из статьи можно было бы смело выкинуть, как минимум, 1/3 текста > при сохранении той же информативности.
Ну кстати да. Экскурсы в недостатки делегатов и историю развития C# можно
было бы выкинуть смело, без потерь для основной цели статьи. Хотя конечно
было интересно.
Если ещё не позно, и нужно, я бы сказал ещё, что хорошо бы после введения
в чистые функции упомянуть, что весь функциональный мир делится на
две категории: кто ЗА чистые функции, и кто НЕ ЗА (а даже наоборот, против),
и, что главное, нечистота функций ничуть не мешает применять те достоинства ФП,
о которых идёт речь в статье, а мешает лишь только произвольному
распараллеливанию вычислений в произвольном месте.
VladD2 пишет:
> Дык разница между синтаксисом и семантикой С и Паскаля очень > незначительная.
Влад, ты ГЛУБОКО неправ. Паскаль — очень строго типизированный язык.
С — в С переменная того типа, о котором думает программист в процессе
написания программы.
С — модульный язык, Паскаль — нет.
Синтаксис — в общем пофигу, но в паскале строго всё разложено
по секциям, в С — где что напишешь,то и будет.
К>>Начал рефакторить схему на на immutable, потому что в том виде, в котором она сейчас реализована со связкой по состоянию получается слишком печально.
VD>Ты почитай все что вокруг. По-моему все очевидно.
Т.е. то, что он сам не считает твоё мнение о себе верным на тебя никак не влияет? Забавно
VD>>Да хоть разок. А то вот только сейчас ты сказал, что не всегда согласен с вышеупомянутым товарищем. А так казалось, что он просто громче других, но все остальные с ним согласны по всем пунктам.
FR>Просто, в отличии от поклоников Немерле или Оберона, он совершенно неагрессивен
Это вы про меня, что ли? Я нить утерял.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
T>>В конечном счёте все определяется количеством строк, которые необходимо написать и количеством ошибок в них. Это тема для отдельного обсуждения. VD>Не совсем так. Скажем наличие скобок строки конечно увеличивает, но ни на количество ошибок, ни на скорость создания кода, ни на скорость его чтения влияния не оказывает.
Убрав букву "ять" из русского языка, сэкономили что-то около 10% на типографской краске. Так и со скобками.
Количество строк, которые ты можешь оглядеть за один взгляд, фиксировано. Ты можешь добровольно отдать часть под скобки. А можешь не отдавать. Разница будет небольшой — единицы процентов, но эта разница сразу попадёт и в количество допущенных ошибок и во время их исправления.
VD>Вот количество ошибок и правда влияет на скорость создания законченного решения. Так как на их исправление может уйти больше время чем на написание кода. Именно по этому С++ серьезно проигрывает даже Яве (явно более ограниченной в выразительных возможностях по сравнению с С++). Причем загадки никакой тут нет. Просто Ява обеспечивает типобезопасность и сборку мусора. Этого достаточно чтобы сильно обогнать С++ по скорости получения рабочего решения.
Не могу не согласиться.
T>>Например, очень часто компоненты слишком сильно связывают, можно развязать. Очень часто возможно использовать DSL. Не менее часто DSEL. И тд, и тп. VD>Ну, так и на других языках можно делать точно так же. Причем в Лиспе и Немерле (как в прочем в Темплэйт Хаскеле) есть боле мощьные средства ДСЛ-естроения, которые позволяют создавать ДСЛи практически любой сложности и не иметь ограничений в области производительности.
Да-да.
Единственное, что скорость создания этого самого DSEL будет для Хаскеля повыше. Поэтому им и пользуются умные люди. Не все, но умные.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
Q>>В C#, в отличие от Java, хоть есть делегаты и замыкания, а не всякие там IRunnable/ICallable. А, ну да, это ж рюшечки.
T>Нет, это "попало в .Net недавно и не успело стать ещё широко используемым."
Да уж три года как появилось в C# 2.0, и уже используется большинством C#-программистов. Нормальный синтаксис лямбда-выражений и LINQ появились больше года назад.
T>Я не проводил измерения... T>Так, поговорили. Мне рассказали, я рассказал.
Ага, понятно. Спроси ещё этих ребят, как они относятся к программированию на Хаскеле. Они ответят: «Э-э-э... На чём?»
T>>>Всё самое полезное попало в .Net недавно и ещё не успело стать широко используемым.
Всё самое полезное попало в Хаскель уже давно и... ещё не успело стать широко используемым.
T>>>Взять, хотя бы, F#. Уж на что полезная вещь. Как велика его доля в современных проектах на .Net?
Уже через год после выхода в составе Студии его доля будет превышать долю Хаскеля, неторопливо формировавшуюся последние 20 лет (или сколько там лет Хаскелю?)
T>Так что давай — вот сколько у тебя кода на легко доступном в .Net F#?
Я не пишу в данный момент на F#. Не в последнюю очередь из-за того, что он ещё не так «легко доступен», как хотелось бы.
T>А планируешь ли ты на нём писать? А что планируешь писать?
Да, планирую. Всякие второстепенные вещи (прототипы, внутрикорпоративные тулзы), с целью попрактиковаться «на кошках».
Здравствуйте, thesz, Вы писали:
T>Всё это подводит нас к интересной проблеме.
Есть ещё одна интересная проблема. Я любую задачу решаю в голове, а записать могу хоть на Си++. Изучая разные ЯПы, можно заиметь другой способ мышления, а само решение можно написать на любом ЯПе. А сношаться с документацией и "почему тут не состыковывается" и "как сделать вот это же самое, только на языке Ъ", очень не хочется.
Здравствуйте, thesz, Вы писали:
T>>>В конечном счёте все определяется количеством строк, которые необходимо написать Q>>Ну да, поэтому лаконичности ради вместо «длинных» английских слов в Хаскель засунули лексемы типа «$», «::», «@», «:l», «_|_»? Если есть поддержка Юникод, можно вообще все токены иероглифами обозначить, и имена функций тоже. Количество строк уменьшится ⇒ читаемость возрастёт, так что ли? А Brainfuck, должно быть, самый читабельный язык?
T>Ты что-то с чем-то путаешь, по-моему.
T>Если я попытаюсь угадать твою мысль и ответить на неё...
Моя мысль была такой. В качестве «псевдокода» в книжках по программированию можно использовать практически любой современный ЯП, потому что они спроектированы так, что их может понять не знакомый с синтаксисом читатель. «Практически любой», но только не Хаскель. Потому что у него из всех боков торчат коленки и локти типа «:%» или «$!»
T>Да и наглядней, надо сказать.
Вот это у меня и не получается понять. Да и не только у меня. По твоим словам, Хаскель простой и понятный язык. Но я открываю книжку Ромы Душкина и что я там вижу? Откровенно стрёмный синтаксис.
T>Нет. Есть куча специальных программ, по одной на каждое действие.
Так что, на Хаскеле можно писать не только парсеры? Вау!
T>Я пишу транслятор VHDL в нетлисты и оптимизатор этих самых нетлистов... Что самое интересное, то, что можно было решить с использование готовой бесплатной библиотеки — разбор VHDL, — заняло всего неделю, время, сравнимое с подключением этой самой чужой библиотеки.
Мне известно, что ты занимался VHDL ещё минимум полтора года назад, т. к. неоднократно упоминал об этом в разных ЖЖ уже давно. Недавно это ещё и на RSDN упоминалось, когда некто gaperton выражал (не впервые) эм-м... некоторый скепсис в отношении целесообразности твоих VHDL-прототипов на Хаскель, ну да ладно. Я к тому, что много недель утекло с тех пор, должно быть целая уйма парсеров VHDL тобой уже написана.
T>Но мало, кто может придумать, как сделать наиболее хитрую закачку, ту, в которой нуждаются реальные пользователи. Мало, кто может придумать причину, по которой закачка не нужна вообще в данном продукте. И мало, кто может придумать что-то такое, в чём пользователи даже ещё не нуждаются — не поняли, что нуждаются. Пусть даже эти пользователи — твои коллеги, взаимодействующие с твоей подсистемой.
А как это связано с Хаскелем — умение придумать причину, по которой закачка не нужна пользователям?
T>А вот быстрота достижения цели стоит на повестке дня.
Понимаешь, я никак не могу взять в толк, за счёт чего цель на Хаскеле достигается быстрее, чем, скажем, на Немерле? Тут такой замкнутый круг получается: чтобы проникнуться Хаскелем, надо вначале проникнуться Хаскелем. Но в действительности, чтобы проникнуться Хаскелем, нужна изначально какая-то мотивация. Что может служить мотивацией? Сейчас мне мотивацией служит исключительно любознательность, но даже она приходит в уныние, глядя на этот синтаксис...
Здравствуйте, VladD2, Вы писали:
VD>Проблема в том, что если каждый напишет свое, то сравнивать будет ничего невозможно. А так есть реальная возможность сравнить конкретные реализации конкретной спецификации. Можно даже тестовые файлы сравнить. Если сравнить эту задачу скажем с "Проблемой К", то последняя была реализована слишком по разному, так как задача была описана слишком абстрактно.
Я пока не могу сказать "договорились", хотя и очень подмывает. Проблема в том, что сейчас у меня не очень много времени, а написать так быстро как ты я не смогу — мне надо разобраться с деталями, я не знаком с работой с XML на Haskell, у меня нет Windows, чтобы проверить результат, да и элементарно я медленнее думаю.
VD>Я говорю скорее не о своем опыте обучения программированию, а о своем опыте общения с людьми. Это конечно не научное исследование, но все же.
Тогда больше вероятности, что твоё мнение ближе к истине. Так как моя выборка нерепрезентативна — это народ с ru_lambda и т.д.
VD>Не понял твоего посыла про синтаксис, но синтаксис очень даже причем. Когда людям не приходится ломать привычки в области синтаксиса и семантики базовой части языка (или приходится, но не много), то им намного проще освоить сам ФП, так как для них ФП становится всего лишь новыми фичами которые нужно "доучить". В случае скажем Хаскля или ОКамла человек вынужден сильно и одномоментно ломать свое сознание.
Возможно, но ломка привычки в отношении синтаксиса — копейки.
VD>Кстати, то что ты знал Пролог могло сильно упростить тебе изучение ФЯ, так как Пролог уже помог тебе переломить сознание. Как минимум понять паттерн-матчинг в Хаскле не проблема если ты знаком с Прологом.
Думал об этом. Паттерн-матчинг не такая уж сложная часть — её понимают практически все, кому я его объяснял. Ещё не встречал проблемы с пониманием, один даже сходу предложил реализацию этого подхода.
VD>Елы-палы. Вот тебе пример с LaPerouse. Ты ему что-то показал. Он сказал "О, да! Кажись ФП короче..." и уже через пост стал говорить тоже самое, что и в начале. Не ужели не видно, что вариант "смотрите как круто" не работает просто потому, что для них показанная крутизна не более чем непонятный код который всего лишь чуть короче оригинала?
Ну, немного не так было, но смысл верный, да. Но! По своему опыту знаю, что я многого добился, если у LaPerouse зародилась хоть тень сомнения в своей правоте. А мне кажется, что так и есть.
VD>Why FP matters я пробовал читать когда пытался въехать в ФП. Результат был — скепсис и непонимание.
Из-за приведённых примеров? Или сам тезис о разбивании сложности с помощью ФВП?
T>>>>В конечном счёте все определяется количеством строк, которые необходимо написать Q>>>Ну да, поэтому лаконичности ради вместо «длинных» английских слов в Хаскель засунули лексемы типа «$», «::», «@», «:l», «_|_»? Если есть поддержка Юникод, можно вообще все токены иероглифами обозначить, и имена функций тоже. Количество строк уменьшится ⇒ читаемость возрастёт, так что ли? А Brainfuck, должно быть, самый читабельный язык? T>>Ты что-то с чем-то путаешь, по-моему. T>>Если я попытаюсь угадать твою мысль и ответить на неё... Q>Моя мысль была такой. В качестве «псевдокода» в книжках по программированию можно использовать практически любой современный ЯП, потому что они спроектированы так, что их может понять не знакомый с синтаксисом читатель. «Практически любой», но только не Хаскель. Потому что у него из всех боков торчат коленки и локти типа «:%» или «$!»
J, K, OCaml, you name it.
But I will return to the discussion when you grow up.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
T>>>>Всё самое полезное попало в .Net недавно и ещё не успело стать широко используемым. Q>Всё самое полезное попало в Хаскель уже давно и... ещё не успело стать широко используемым.
Okay, "grow up" check failed.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
T>>Всё это подводит нас к интересной проблеме. VE>Есть ещё одна интересная проблема. Я любую задачу решаю в голове, а записать могу хоть на Си++. Изучая разные ЯПы, можно заиметь другой способ мышления, а само решение можно написать на любом ЯПе. А сношаться с документацией и "почему тут не состыковывается" и "как сделать вот это же самое, только на языке Ъ", очень не хочется.
Я не понял тезиса.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>>>Всё это подводит нас к интересной проблеме. VE>>Есть ещё одна интересная проблема. Я любую задачу решаю в голове, а записать могу хоть на Си++. Изучая разные ЯПы, можно заиметь другой способ мышления, а само решение можно написать на любом ЯПе. А сношаться с документацией и "почему тут не состыковывается" и "как сделать вот это же самое, только на языке Ъ", очень не хочется.
T>Я не понял тезиса.
Для записи решения задачи язык почти не важен. Однако умение думать на некоем языке полезно, так как даёт простор, записать само решение можно почти на чём угодно, поэтому на первый план зачастую выходит именно удобство интеграции.
Новая задача, она новая везде, решить я её могу на "Хаскеле", а её решение записать потом на C#.
T>>Я не понял тезиса. VE>Для записи решения задачи язык почти не важен.
Тогда почему математики постоянно изобретают языки? Зачем, вообще, такое количество ЯП?
Посмотри на творцов Французской революции. Сплошь математики и физики. Они знали, что значит язык и умело его применяли. Пропагандистские приёмы используются до сих пор (не давать применять отрицательное там, где нужно положительное и наоборот). Гипотеза Сапира-Ворфа появилась гораздо позже.
VE>Однако умение думать на некоем языке полезно, так как даёт простор, записать само решение можно почти на чём угодно, поэтому на первый план зачастую выходит именно удобство интеграции. VE>Новая задача, она новая везде, решить я её могу на "Хаскеле", а её решение записать потом на C#.
Ну, попробуй написать библиотеку работы с ленивыми степенными рядами. Чтобы памяти отъедалось не больше ленивого варианта, чтобы семантика была ленивой — вычислений было не больше, чем нужно.
Народ пишет, обычно, на массивах. Тоже вариант, но не самый лучший. Памяти расходуется больше, количество вычислений труднее проконтролировать да и просто — больше кода.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>>>Я не понял тезиса. VE>>Для записи решения задачи язык почти не важен.
T>Ну, попробуй написать библиотеку работы с ленивыми степенными рядами. Чтобы памяти отъедалось не больше ленивого варианта, чтобы семантика была ленивой — вычислений было не больше, чем нужно.
Аналогия некорректна в виду того, что эта задача ни к чему не привязана. А когда тебе ставят задачу написать библиотеку для работы с ленивыми степенными рядами для платформы .NET, да ещё и классы описывают, которые ты должен предоставить, то, боюсь, выбор языка будет ограничен, хотя прототип можно будет написать на том, на чём удобнее.
Или ставят задачу написать некий алгоритм, входные данные для которого в виде объектов определённых классов из некоей библиотеки Си++ в исходниках. Можно, конечно, конвертать туда-обратно и в длл-ку заворачивать, но редко это стоит того.
Здравствуйте, thesz, Вы писали:
T>>>В конечном счёте все определяется количеством строк, которые необходимо написать и количеством ошибок в них. Это тема для отдельного обсуждения. VD>>Не совсем так. Скажем наличие скобок строки конечно увеличивает, но ни на количество ошибок, ни на скорость создания кода, ни на скорость его чтения влияния не оказывает.
T>Убрав букву "ять" из русского языка, сэкономили что-то около 10% на типографской краске. Так и со скобками.
Тут есть большая разница. Буква ять не несет никакой смысловой нагрузки и не способствует более быстрому пониманию текста, к тому же требует типографской краски. А скобочки помогают воспринимать текст программы, что же касается "типографской краски", то есть в нашем случае скорости набора, то современные IDE, которыми оснащены эти самые языки со скобочками, расставляют скобочки автоматом.
T>Количество строк, которые ты можешь оглядеть за один взгляд, фиксировано. Ты можешь добровольно отдать часть под скобки. А можешь не отдавать. Разница будет небольшой — единицы процентов, но эта разница сразу попадёт и в количество допущенных ошибок и во время их исправления.
Вот это совершенно непонятно. Каким образом это скобочки увеличат количество ошибок? По мне — они и количество ошибок при написании не увеличивают, и допущенные ошибки исправлять помогают, так как увеличивается читаемость.
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
T>>>>В конечном счёте все определяется количеством строк, которые необходимо написать и количеством ошибок в них. Это тема для отдельного обсуждения. VD>>>Не совсем так. Скажем наличие скобок строки конечно увеличивает, но ни на количество ошибок, ни на скорость создания кода, ни на скорость его чтения влияния не оказывает. T>>Убрав букву "ять" из русского языка, сэкономили что-то около 10% на типографской краске. Так и со скобками. LP>Тут есть большая разница. Буква ять не несет никакой смысловой нагрузки и не способствует более быстрому пониманию текста, к тому же требует типографской краски.
Вопрос предпочтений.
Совершенно ужасный готический шрифт считался в Германии идеальным достаточно долгое время. Немцы, вообще, считали, что английские и французские шрифты нечитаемы, поскольку не содержат дополнительных отличительных черт букв.
То же самое и с буквой ять. У неё тоже были сторонники.
(упомяну серифы — там специально добавлены засечки для лучшей читаемости, так что немцы были не совсем не правы.)
LP>А скобочки помогают воспринимать текст программы, что же касается "типографской краски", то есть в нашем случае скорости набора, то современные IDE, которыми оснащены эти самые языки со скобочками, расставляют скобочки автоматом.
"Ять способствует восприятию текста, а современные спеллчекеры вставляют ять автоматически," ага.
Я тебе снова дам ссылку про то, как Хаскель выигрывает (у меня все ссылки такие), но там, во-первых, общие мысли интересные и, во-вторых, кроме Хаскеля, есть сравнение и других ЯП между собой: Are Ours Really Smaller Than Theirs?
Там прямо на первой странице показан сравнительный "уровень" языков программирования по метрике Хальстеда, в которую входит учёт влияния лексем и всего такого ("синтаксический оверхед", насколько я понимаю). Assembler — 0,88, English prose — 2,16, PL/1 — 1,53. А у Хаскеля — 5,13. В частности, из-за отсутствия лишних скобочек, запятых и точек с запятой.
T>>Количество строк, которые ты можешь оглядеть за один взгляд, фиксировано. Ты можешь добровольно отдать часть под скобки. А можешь не отдавать. Разница будет небольшой — единицы процентов, но эта разница сразу попадёт и в количество допущенных ошибок и во время их исправления. LP>Вот это совершенно непонятно. Каким образом это скобочки увеличат количество ошибок? По мне — они и количество ошибок при написании не увеличивают, и допущенные ошибки исправлять помогают, так как увеличивается читаемость.
Да они место занимают. Мог бы стоять пробел, а стоит скобка+пробел или запятая+пробел. А то и вовсе пустая строка под {}.
Тут мы сделали перенос строки из-за длинной строки, там мы его сделали... Перед компиляцией не всю (под)программу просмотрели — на запуск ушёл неправильный код. Начали искать ошибку — надо больше текста просмотреть. И тд, и тп.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
T>>Ну, попробуй написать библиотеку работы с ленивыми степенными рядами. Чтобы памяти отъедалось не больше ленивого варианта, чтобы семантика была ленивой — вычислений было не больше, чем нужно. VE>Аналогия некорректна в виду того, что эта задача ни к чему не привязана. А когда тебе ставят задачу написать библиотеку для работы с ленивыми степенными рядами для платформы .NET, да ещё и классы описывают, которые ты должен предоставить, то, боюсь, выбор языка будет ограничен, хотя прототип можно будет написать на том, на чём удобнее. VE>Или ставят задачу написать некий алгоритм, входные данные для которого в виде объектов определённых классов из некоей библиотеки Си++ в исходниках. Можно, конечно, конвертать туда-обратно и в длл-ку заворачивать, но редко это стоит того.
Оба случая не исключают, что чуток переформулировав задачу (например, требуют именно классы для работы со степенными рядами, а можно попросить давать выражения и чтобы ты возвращал готовый степенной ряд вплоть до критерия остановки) можно значительно упростить себе работу.
Например, я две недели буду писать классы для .Net, тщательно их проектируя — там одно умножение стоит многого. А могу за день написать это дело на Хаскеле и ещё четыре дня прикручивать через FFI с обеих сторон это дело к .Net. И справится за неделю, в сумме.
Такая ситуация — при переформулировке задачи получается значительный выигрыш за счёт возможности использовать более лучший инструмент, — встречается чаще, чем ты думаешь.
И чем думают начальники и архитекторы.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
