Здравствуйте, Аноним, Вы писали:
А>Если скрестить cherry-picking и коммутативность патчей, то открываются новые возможности. А>Поэтому не надо тупо гуглить, почитайте туториал и оцените сами.
Меня не настолько интересует "алгебра пэтчей", чтобы читать по ней туториал. Я просто привел, что похожий функционал есть в Hg. Говорить об архиважности этой фичи для пользователя в виду практической невостребованости darcs по причине общей слабости функционала, надежности и скорости по сравнению с hg/git в последнее время смешно. Конь экологичней автомобиля и сложнее, вот только не нужен он больше никому.
А>По поводу того, что алгебру патчей можно реализовать на любом языке. С этим глупо спорить, однако небольшая ремарка. А>Первая версия darcs была написана на c++. К сожалению, она не работала. Совсем. А>Вторая версия была написана на хаскеле. И она заработала. Сразу. А>("Заработала" -- имеется в виду алгебра патчей).
Это говорит лишь о неумение автора пользоваться C++, что для теор. физика вполне нормально.
Здравствуйте, novitk, Вы писали:
N>>>Замечательно, но Хаскель то здесь причем? Ты считаешь, что "алгебры патчей" не реализуема в Питоне?
BZ>>насколько я понимаю, это из разряда алгоритмически сложных вещей, которые при реализации на С++ потребовали бы на порядок больше времени
N>На C++ — может быть, но это каменный век, хотя и на нем сделаны много сложных вещей, да и автор не программист. Мы же вроде говорили о гибридах и Питоне?
по моему приватному мнению, по времени разработки сложных алгоритмов, хаскел превосходит С++ на порядок, C#/Java раза в три, а гибридные языки — раза в 1.5-2
Здравствуйте, thesz, Вы писали:
N>>Замечательно, но Хаскель то здесь причем? Ты считаешь, что "алгебры патчей" не реализуема в Питоне?
T>Насколько мне известно, в её реализации используется ленивость.
afair, во второй версии darcs они сделали type-safe описание патчей с помощью GADT. типа того, что если патчи применять в неправильном порядке — то это обнаружит type checker
Здравствуйте, novitk, Вы писали:
N>Здравствуйте, thesz, Вы писали:
T>>Если есть числодробилка, то её можно как-то соптимизировать, если выразить проблему в символьном виде. T>>Вот как-то так.
N>Спасибо, почитаю, но под числодробилками я понимаю именно численные методы, так как мои дефуры в символах пока не решить даже человеческим мозгом...
я тут выше писал, что хаскел используют в 2-3 инвест-банках
Здравствуйте, lomeo, Вы писали:
L>Здравствуйте, pgregory, Вы писали:
P>>У меня есть точка зрения, что такое хороший яп, а что — нет. Основная мысль в том, что реально хороший язык реально прост.
L>Хаскель — прост.
Не, это нелегко вынести :-)
Через 15 минут другой сторонник хаскеля пишет здесь
«в этом плане чистый ооп или чистый фп язык может иметь лучшее соотношение сложность/полезность. ну а если учесть, что по показателю сложность хаскел превосходит скалу с f#, то получается, что мы сравниваем результаты 20-летнего развития чистого ФП языка с результатами 10-летней эпопеи по скрещиванию ужа и ежа. нет сомнений, базовые ФП фичи (на уровне классического ML) скала успешно впитала, но это состояние ФП 30-летней примерно давности. хаскел-то уже на старте был мощней»
Быть сложнее скалы — это теперь признак простоты?
Вы там для начала между собой разберитесь, друзья :-)
Здравствуйте, Rtveliashvili Denys, Вы писали:
RD>>>Ага, и взрывает потребление памяти там, где этого не ждешь. В проекте <1K lines может быть это и не проблема. А если <1M lines? Не согласны? Приведите успешный контр-пример.
давай посмотрим правде в глаза — в проекте такого объёма могут быть проблемы с памятью в любом языке
мне кажется, что вы наслушались страшилок. да, среди писем новичков в cafe неожиданное переполнение памяти из-за ленивости — это настолько стандартная проблема, что я уже не глядя отвечаю но это проблема смена парадигмы, а не рабочего процесса
реально за 5 лет использования и 15к строк написанного на нём проекта что у меня было:
— попытка сериализации большой структуры данных прямиком в строку. ес-но это всё превращалось в огромный невычисленный thunk, который переполнял стек. это в первые же месяцы работы
— единственный случай переполнения именно памяти. точнее сохранения в ней тех данных, которые я считал отфильтрованными. наткнулся я на это через полтора года (!) использования хаскела. грубо говоря, пришлось заменить return (filter ...) на return $! evalList (filter ...)
— недавно наткнулся на проблему, когда программа не могла обрабатывать многогигабайтные файлы из-за того, что в одном списке накапливалась промежуточная статистика по файлу, и опять-таки этот огромный thunk переполнял стёк при своём вычислении. решить опять же было несложно — форсировать вычисления при каждом (императивном) обновлении списка
проблемы были в том, чтобы найти эти части, но я подозреваю, что средства отладки/профилирования ghc могут тут помочь. я ими просто не умею пользоваться за ненадобностью
Здравствуйте, pgregory, Вы писали:
L>>Хаскель — прост.
P>Простые вещи можно объяснить на пальцах. Или в двух словах.
P>Не расскажешь ли, в двух словах P>— что такое monomorphism restriction P>— что такое монада
Ты обучение или использование языка имел в виду, когда говорил о простоте?
P>Еще. Скажи, найти среднее списка даблов — простая задача? Ответь, не компилируя, справится ли этот код:
P>
P>Если да, то насколько быстро? Если нет, то почему?
Задача с подводхом из-за использования плавающей точки? Или из-за особенности реализации enumFromTo для Double?
Думаю, справится. Можно написать код в два раза быстрее из-за двух проходов в существующем.
Только какое отношение это имеет к простоте языка?
Здравствуйте, pgregory, Вы писали:
P>Простые вещи можно объяснить на пальцах. Или в двух словах.
P>Не расскажешь ли, в двух словах P>— что такое monomorphism restriction P>— что такое монада
о, может ты наконец объяснишь мне, что такое ссылки? только пожалуйста не прибегай к непонятным терминам типа адресов памяти, объясни исходя из самого обычного лямбда-исчисления
Здравствуйте, lomeo, Вы писали:
L>Ты обучение или использование языка имел в виду, когда говорил о простоте?
И о том, и о другом. Я считаю, что они тесно связаны.
P>>Еще. Скажи, найти среднее списка даблов — простая задача? Ответь, не компилируя, справится ли этот код:
import System.Environment
import Text.Printf
mean :: [Double] -> Double
mean xs = sum xs / fromIntegral (length xs)
main = do
[d] <- map read `fmap` getArgs
printf "%f\n" (mean [1 .. d])
P>>Если да, то насколько быстро? Если нет, то почему?
L>Задача с подводхом из-за использования плавающей точки? Или из-за особенности реализации enumFromTo для Double? L>Думаю, справится. Можно написать код в два раза быстрее из-за двух проходов в существующем.
Вау! Ответ мне очень нравится. Опытный хаскель-программист (так ведь?) не может точно ответить на вопрос, будет ли работать программа из 9 строк, считающая среднее число списка. Предлагает 2 варианта, в чем здесь может быть подвох. И, более того, не отмечает, что эта программа будет просто падать для сколько-нибудь большого d. Мне лично это многое говорит о хаскеле.
L>Только какое отношение это имеет к простоте языка?
У простого в моем понимании языка не может быть подвохов при выполнении настолько простых задач.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>Здравствуйте, pgregory, Вы писали:
P>>Простые вещи можно объяснить на пальцах. Или в двух словах.
P>>Не расскажешь ли, в двух словах P>>— что такое monomorphism restriction P>>— что такое монада
BZ>о, может ты наконец объяснишь мне, что такое ссылки? только пожалуйста не прибегай к непонятным терминам типа адресов памяти, объясни исходя из самого обычного лямбда-исчисления
Я надеюсь, это ирония, а настоящий смысл в том, что все зависит от того, что взять в качестве понятного и простого базиса.
(Забавно, на РСДН не принято прямо говорить «я не могу этого сделать»?)
Так вот.
Плоская память и адрес в ней, а также ссылка на объект — это вещи, которые легко объяснить даже ребенку. Лямбда-исчисление, monomorphism restriction и монады — нет. Более того, для объяснения последних взрослым бородатым профессиональным программистам в интернете лежит дофигища статей, «одна другой доступней».
Из этого следует очевидный вывод, что годится на роль простого и понятного базиса, а что — нет.
Если ты не согласен, мне, честно говоря, плевать. Не сочти за грубость. Просто когда спор опускается до элементарных понятий, дальше обычно спорить бессмысленно. И я не буду.
Здравствуйте, Rtveliashvili Denys, Вы писали:
RD>А withCAString уже использует castCharToCChar, что работает только для символов к кодом меньше чем 256.
RD>
RD>Вместо того, чтобы провести превращение в кодировку, стандартную для данной платформы. Конечно, тупо засадить "fromIntegral (ord ch)" и баран может.
у каждой задачи есть простое, дешёвое и при этом неправильное решение "стандартная кодировка платформы" существует только в умах тех, кто с этими платформами малознаком. скажем, в линуксе кодировка имён файлов может быть любой, utf-8 — просто наиболее популярный вариант. как и под виндами сколько угодно библиотек, использующих utf-8 или тупо просто 8 бит
далее, какие функции мы должны вызывать с этой "стандартной кодировкой"? мой gcc4, во всяком случае, не поддерживаем семейства _t* — хотя может ему опцию какую надо скормить?
Здравствуйте, pgregory, Вы писали:
L>>Ты обучение или использование языка имел в виду, когда говорил о простоте?
P>И о том, и о другом. Я считаю, что они тесно связаны.
Ну, то есть thesz прав? Лучший язык — тот, который ты знаешь?
L>>Задача с подводхом из-за использования плавающей точки? Или из-за особенности реализации enumFromTo для Double? L>>Думаю, справится. Можно написать код в два раза быстрее из-за двух проходов в существующем.
P>Вау! Ответ мне очень нравится. Опытный хаскель-программист (так ведь?) не может точно ответить на вопрос, будет ли работать программа из 9 строк, считающая среднее число списка. Предлагает 2 варианта, в чем здесь может быть подвох. И, более того, не отмечает, что эта программа будет просто падать для сколько-нибудь большого d. Мне лично это многое говорит о хаскеле.
Неопытный.
Но. Давай разберём наш случай. Ты предлагаешь мне задачу, чтобы оценить сложность языка. При этом задача выражена максимально абстрактно — среднее списка даблов, а пример приведён для последовательности. Я поставлен в ситуацию, когда должен сидеть и догадываться, что ты имел в виду. Положившись на то, что описание задачи имеет больший приоритет над кодом (т.к. последний может быть ошибочным) я рассматривал код, исходя из этого. Иначе я просто мог привести тебе формулу, которая считала бы ещё быстрее mean [1..d] — верно? Т.к. мы считаем, что задача — это расчёт среднего списка даблов, не последовательности [1..d], а вообще любого списка, то, возможно, он у нас посчитан, возможно, нет. Напиши среднее списка даблов на другом языке — не будет валиться для длинного списка? Реализация в программе не сливает список в цикл. Я не посчитал это ошибкой. Ты из этого сделал странный вывод о том, что Хаскель сложен. По-моему, это странно.
L>>Только какое отношение это имеет к простоте языка?
P>У простого в моем понимании языка не может быть подвохов при выполнении настолько простых задач.
Ещё раз — подвох не в том, верен код или нет — он верен. Подвод в том, что я должен догадываться, что ты имел в виду.
Здравствуйте, pgregory, Вы писали:
P>Плоская память и адрес в ней, а также ссылка на объект — это вещи, которые легко объяснить даже ребенку.
Это вещи, которые не понимают многие взрослые люди. Не раз писано, что, мол, некоторые даже рождаются без некоторой части мозга, необходимой, чтобы понять, что такое указатели.
Ты просишь объяснить тебе монады в терминах машины Тьюринга. Тебя просят объяснить ссылки в терминах лямбда-исчисления.
Ирония ясна же вроде, нет?
Здравствуйте, lomeo, Вы писали:
L>Здравствуйте, pgregory, Вы писали:
L>>>Ты обучение или использование языка имел в виду, когда говорил о простоте?
P>>И о том, и о другом. Я считаю, что они тесно связаны.
L>Ну, то есть thesz прав? Лучший язык — тот, который ты знаешь?
Вы там что, сговорились? :-) Еще раз, по слогам:
Моя аксиома №1: реально хороший язык реально прост.
Реально прост значит имеет реально простую семантику. Примеры — Си и Питон. Или даже Common Lisp. Реально простая семантика проста при изучении и при использовании. Это ясно?
Реально просто не значит офигенно похож на какой-то из знакомых мне. Реально прост — значит, если взять не-программиста, то ему будет просто объяснить семантику языка. Всего языка. (Нет, семантика хаскеля — не лямбда. Это я так, на всякий случай :-)
Откуда вы делаете какой-то дикий вывод, что я считаю однозначно лучшими языки, которые я знаю? Реально, откуда??? Я просто в замешательстве, честное слово!
L>>>Задача с подводхом из-за использования плавающей точки? Или из-за особенности реализации enumFromTo для Double? L>>>Думаю, справится. Можно написать код в два раза быстрее из-за двух проходов в существующем.
P>>Вау! Ответ мне очень нравится. Опытный хаскель-программист (так ведь?) не может точно ответить на вопрос, будет ли работать программа из 9 строк, считающая среднее число списка. Предлагает 2 варианта, в чем здесь может быть подвох. И, более того, не отмечает, что эта программа будет просто падать для сколько-нибудь большого d. Мне лично это многое говорит о хаскеле.
L>Неопытный.
Надеюсь, достаточно опытный, чтобы с пониманием рассуждать о program in question, все же.
L>Но. Давай разберём наш случай. Ты предлагаешь мне задачу, чтобы оценить сложность языка. При этом задача выражена максимально абстрактно — среднее списка даблов, а пример приведён для последовательности. Я поставлен в ситуацию, когда должен сидеть и догадываться, что ты имел в виду. Положившись на то, что описание задачи имеет больший приоритет над кодом (т.к. последний может быть ошибочным) я рассматривал код, исходя из этого. Иначе я просто мог привести тебе формулу, которая считала бы ещё быстрее mean [1..d] — верно? Т.к. мы считаем, что задача — это расчёт среднего списка даблов, не последовательности [1..d], а вообще любого списка, то, возможно, он у нас посчитан, возможно, нет. Напиши среднее списка даблов на другом языке — не будет валиться для длинного списка? Реализация в программе не сливает список в цикл. Я не посчитал это ошибкой. Ты из этого сделал странный вывод о том, что Хаскель сложен. По-моему, это странно.
Надеюсь, мой русский достаточно понятен людям?
Я написал, цитирую, «Ответь, не компилируя, справится ли этот код: [...] Если да, то насколько быстро? Если нет, то почему?»
Очевидно, что это вопрос про конкретный кусок кода, решающий нашу игрушечную задачу. Не так ли?
Очевидно, что я не проверял тебя на знание формулы среднего числа, чтобы оценить сложность языка. Чтобы ее оценить, я попросил тебя оценить тривиальный кусок кода на этом языке.
Ты (поправь, если я не прав) не смог нормально ответить на тривиальные вопросы о тривиальной программе. Отсюда я сделал вывод, что хаскель сложен. По-твоему, это странно?
Здравствуйте, pgregory, Вы писали:
P>Не расскажешь ли, в двух словах P>— что такое monomorphism restriction P>— что такое монада
О! Придумал, как в двух словах рассказать, что такое монада.
Монада — это те же сопряженные функторы, вид сбоку
Если серьёзно, то обучение языку и его использование — разные вещи. Хотя если и то, и другое даётся легко — то это скорее плюс. Но я говорил об использовании. В этом смысле вопросы "в двух словах" не имеют смысла — они сложны только на этапе обучения. Если учить питон с нуля — он тоже будет сложен. И вопросов "в двух словах" там тоже можно позадавать немало. Просто Хаскель — совсем другой, там очень много нового, больше учить — в этом смысле да, в обучении он сложнее. Бэкграунд среднего программиста гораздо ближе к питону.
Здравствуйте, VoidEx, Вы писали:
VE>Здравствуйте, pgregory, Вы писали:
P>>Плоская память и адрес в ней, а также ссылка на объект — это вещи, которые легко объяснить даже ребенку.
VE>Это вещи, которые не понимают многие взрослые люди. Не раз писано, что, мол, некоторые даже рождаются без некоторой части мозга, необходимой, чтобы понять, что такое указатели.
Да, я это тоже слышал. Только мне кажется, что большинство рождается без некоторой части мозга, необходимой, чтобы понять монады. Указатель выражает одну и довольно простую вещь — индирекцию. Это понятие никак не связано с машинами Тьюринга и программированием вообще. А что же выражает монада?
VE>Ты просишь объяснить тебе монады в терминах машины Тьюринга. Тебя просят объяснить ссылки в терминах лямбда-исчисления. VE>Ирония ясна же вроде, нет?
Ясна, но, мне кажется, неуместна.
Я прошу объяснить в терминах «на пальцах», а это не связано ни с какими машинами Тьюринга.
Пока никто даже не пытался. Наверно, это настолько просто, что даже неинтересно :-)
Здравствуйте, lomeo, Вы писали:
L>Здравствуйте, pgregory, Вы писали:
P>>Не расскажешь ли, в двух словах P>>— что такое monomorphism restriction P>>— что такое монада
L>О! Придумал, как в двух словах рассказать, что такое монада. L>Монада — это те же сопряженные функторы, вид сбоку :-)
Начало обнадеживающее :-)
L>Если серьёзно, то обучение языку и его использование — разные вещи. Хотя если и то, и другое даётся легко — то это скорее плюс. Но я говорил об использовании. В этом смысле вопросы "в двух словах" не имеют смысла — они сложны только на этапе обучения. Если учить питон с нуля — он тоже будет сложен. И вопросов "в двух словах" там тоже можно позадавать немало. Просто Хаскель — совсем другой, там очень много нового, больше учить — в этом смысле да, в обучении он сложнее. Бэкграунд среднего программиста гораздо ближе к питону.
Если серьезно, то, ребята, а вы никогда не задумывались, почему, например, ООП так популярно?
Вовсе не потому, что ему везде учат. Это — следствие, а не причина. Причина проста. Она не имеет ничего общего с тем, насколько (не-)адекватно ООП позволяет моделировать окружающий мир. И она кроется в том, что ООП гораздо ближе среднему человеку, чем что-либо еще на текущий момент.
Эта простая мысль, мне кажется, очень важная и правильная. И она имеет самое прямое отношение к тому факту, что хаскель — не mainstream (прости, thesz :-)
Здравствуйте, pgregory, Вы писали:
L>>Ну, то есть thesz прав? Лучший язык — тот, который ты знаешь?
P>Вы там что, сговорились? Еще раз, по слогам:
P>Моя аксиома №1: реально хороший язык реально прост.
P>Реально прост значит имеет реально простую семантику. Примеры — Си и Питон. Или даже Common Lisp. Реально простая семантика проста при изучении и при использовании. Это ясно?
Да. Семантика Хаскеля проще Си. Примерно как у Питона. Сложнее Лиспа (не CL).
P>Реально просто не значит офигенно похож на какой-то из знакомых мне. Реально прост — значит, если взять не-программиста, то ему будет просто объяснить семантику языка. Всего языка. (Нет, семантика хаскеля — не лямбда. Это я так, на всякий случай
А ты проводил такой опыт? Объяснял филологу семантику Си и Хаскеля?
P>Откуда вы делаете какой-то дикий вывод, что я считаю однозначно лучшими языки, которые я знаю? Реально, откуда??? Я просто в замешательстве, честное слово!
Не знаю, как thesz, но у меня такое мнение сложилось потому, что ты заявил, что простота неразрывно связана также и со сложностью в обучении. Для меня сложность в обучении — фактор маловажный. Теперь я вижу, что ты считаешь, что сложности обучения и использования — сильнозависимы (т.к. идут от семантики). Для меня обучение языку — это изучение его семантики и полезных практик, которые от этой семантики зависят. Т.е. сложная в обучении семантика может быть лёгкой в использовании — такое вот у меня мнение. Да и вообще лёгкость использования — это сумма удобства инструмента с тем, насколько программист близко с ним знаком. Мне кажется, что удобный инструмент должен быть посложнее перочиного ножика.
L>>>>Задача с подводхом из-за использования плавающей точки? Или из-за особенности реализации enumFromTo для Double? L>>>>Думаю, справится. Можно написать код в два раза быстрее из-за двух проходов в существующем.
P>Надеюсь, достаточно опытный, чтобы с пониманием рассуждать о program in question, все же.
Ну, так я же ответил. Даже привёл тебе ход своих мыслей. Тебе он не понравился
P>Надеюсь, мой русский достаточно понятен людям?
P>Я написал, цитирую, «Ответь, не компилируя, справится ли этот код: [...] Если да, то насколько быстро? Если нет, то почему?»
Цитирую тебя же полнее:
"Еще. Скажи, найти среднее списка даблов — простая задача? Ответь, не компилируя, справится ли этот код:"
Ответил — справится. Напиши мне код на питоне, на любом другом языке, который не загнётся на больших списках. Почему же другому языку это позволено, а Хаскелю нет?
P>Очевидно, что это вопрос про конкретный кусок кода, решающий нашу игрушечную задачу. Не так ли?
Да.
P>Очевидно, что я не проверял тебя на знание формулы среднего числа, чтобы оценить сложность языка. Чтобы ее оценить, я попросил тебя оценить тривиальный кусок кода на этом языке.
Да.
P>Ты (поправь, если я не прав) не смог нормально ответить на тривиальные вопросы о тривиальной программе. Отсюда я сделал вывод, что хаскель сложен. По-твоему, это странно?
Поправляю. Смог. И ответил.
Ты остался неудовлетворён ответом (или наоборот удовлетворён — это как посмотреть) — потому что твой код на Хаскель не умеет делать то, что не умеют делать и другие языки?? Ты напиши тот же код на Питон и скажи — что, он от этого станет менее тривиальным? Что, он так же не загнётся на большом d? И что — он от этого перестанет выполнять свою задачу — считать среднее списка даблов?
Нечестно играешь. Хочешь честно — давай смотрим код на Хаскеле, спрашиваем себя, что он делает? Смотрим код на "реально простом" Си — делаем то же самое. Хорошо, не на Си, на Питоне. Берём задачу — смотрим её решение на Хаскеле, смотрим на другом языке, где показалось удобнее писать, где получилось быстрее написать, где работает правильнее.
А так — для Хаскеля и более тривиальные куски кода можно привести с вопросами "справится ли". Про Си уж молчу. А уж на что простой казалось бы язык!
