Здравствуйте, pgregory, Вы писали: P>Пока никто даже не пытался. Наверно, это настолько просто, что даже неинтересно
Чем не устраивает простое описание свойств? Что-то типа:
Множество объектов, с которыми связаны три операции: создание объекта, создание специального "пустого" объекта, применение функции... детализировать по вкусу.
Здравствуйте, pgregory, Вы писали:
P>Если серьезно, то, ребята, а вы никогда не задумывались, почему, например, ООП так популярно?
P>Вовсе не потому, что ему везде учат. Это — следствие, а не причина. Причина проста. Она не имеет ничего общего с тем, насколько (не-)адекватно ООП позволяет моделировать окружающий мир. И она кроется в том, что ООП гораздо ближе среднему человеку, чем что-либо еще на текущий момент.
P>Эта простая мысль, мне кажется, очень важная и правильная. И она имеет самое прямое отношение к тому факту, что хаскель — не mainstream (прости, thesz
Хорошо, согласен. Допустим, филологу из моего предыдущего коммента объяснить Си проще, чем Хаскель. Даже С++ проще, там же ООП. Мне это, если честно, малоинтересно.
Но почему ты считаешь, что сложность использования Хаскеля у владеющего обоими инструментами специалиста будет выше сложности использования Си? Ты постоянно приводишь в пример среднего человека, или там незнакомого с программированием, но основной твой довод такой: если семантика сложна в обучении — она сложна в использовании. Это неправда для меня, весь мой опыт говорит об обратном. Процедуры Си проще ООП Явы, но Си использовать сложнее. ООП, как ты говоришь проще HOF, но HOF гораздо проще и удобнее использовать и т.д.
Мой опыт. Питон мне не пришлось по большому счёту учить. И использовать его легко. Но ведь я не учил никакой новой семантики. И ничего нового я не использую, когда пишу на нём — я уже хорошо был знаком с JavaScript и Scheme к тому моменту. С другой стороны, Хаскель я учил/учу тяжело, его вообще тяжело учить. Но использовать его легче Питона. Не на всех задачах, но у меня — на большинстве.
Здравствуйте, pgregory, Вы писали:
P>Я прекрасно понимаю твою позицию. Нажеюсь, ты понимаешь мою. Надеюсь, кто-нибудь еще понимает, о чем пишет каждый из нас. P>На этом предлагаю закончить эту ветвь спора и дружно лечь спать. В здоровом теле — здоровый дух!
Надо же — я как раз хотел извиниться за резкий тон и предложить закругляться.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>по моему приватному мнению, по времени разработки сложных алгоритмов, хаскел превосходит С++ на порядок, C#/Java раза в три, а гибридные языки — раза в 1.5-2
Боюсь местные хаскелеводы не согласятся Сам с оценкой согласен, но если это так, то боюсь мне (практику!) оно не надо...
По причине, что этого не достаточно чтобы оправдать все остальные расходы — слабую библиотеку, необходимость интеропа и т.д.
Здравствуйте, pgregory, Вы писали:
P>Пока никто даже не пытался. Наверно, это настолько просто, что даже неинтересно
Конечно просто. Это обобщённое вычисление (не процесс, его описание).
Вот в псевдокоде сиобразного языка:
// int foo(); int bar();
SequenceComputation x = do { f <- foo(); b <- bar(); return (f + b); }
x.Run();
// File openFile(); Result writeFile(); Result closeFile();
SequenceIfNotFailComputation y = do { f <- openFile(...); writeFile(f, ...); closeFile(f); }
y.Run();
// List<String> getLines(String); ...
MultipleResultsComputation z = do { line <- getLines(...); word <- getWords(line); return (word + "lala"); }
z.Run();
Здравствуйте, Rtveliashvili Denys, Вы писали:
RD>>>2. Удивительные красоты самого языка вроде операторов (,,,,,,,,). RD>Что до (,,,,,), то это просто побочный эффект системы типов, принятой в haskell. Равно как и то, что для некоторых задач надо использовать числа Пеано (а я от них не в восторге). Короче говоря, не критично, хотя и не sexy.
Во-первых, (,,,,,) это никакой не оператор и уже тем более не "побочный эффект системы типов", а самый обычный конструктор (типа и данных). Ну напишете вместо
(,,,,,) a b c d e f
Foo a b c d e f
Какая разница? Во-вторых — как можно не быть в восторге от чисел Пеано?
RD>1. сделать так, чтобы этот софт был не конем в вакууме а смог общаться с другим софтом — не ясно как. Варианты типа "гонять строки по сокетам" не подходят.
Что конкретно не ясно? ffi Хаскелла — (возможно) лучший вообще для языков такого уровня. Хотя, конечно, кофе он варить не умеет...
RD>4. многие пользователи Хаскель страдают яростным фанатизмом на ровном месте и предубежденностью. Это придает Хаскелю оттенок маргинальности (и не столько для меня, как для людей, от которых также много чего зависит).
Какой фанатизм и маргинальность? Посмотрите на community Хаскелла и найдите что-нибудь сопоставимое. Для меня — это один из основных аргументов в его пользу. Кроме того, за исключением тех, кто узнал Хаскелл из первых курсов CS, большинство — люди, имеющие большой mainstream опыт. Я, например, бОльшую часть сознательной жизни преимущественно использовал C++. Поэтому, имейте в виду, что люди, агитирующие за Хаскелл, как правило делают это не потому, что не знают ничего другого, а наоборот — потому что знают слишком хорошо.
Глупо считать, что Хаскелл (будем говорить о GHC) — серебряная пуля и платформа без недостатков. Их много. Но любая ситуация реального выбора это tradeoff.
Против:
1. Недостаток manpower для развития платформы. Отсюда:
— довольно среднее качество кода, при том, что из общих соображений, семантика Хаскелла должна обеспечивать простор для оптимизации, несопоставимо больший, нежели у C/C++;
— определенная сырость проблемно-ориентированных библиотек и даже некоторых базовых.
2. Недостаточное распространение и использование в real-world контексте, откуда — те же проблемы: некоторая лоскутность и (возможная) глючность библиотек и риски вступить на стезю, с большой вероятностью неизведанную, и, следовательно, непонятная прогнозируемость результатов.
За:
1. Теоретическая база. Правильная теория эффективнее *ЛЮБОГО СКОЛЬ УГОДНО ОБШИРНОГО* набора эмпирически сформированных практик.
2. В высшей степени плодотворный выбор функциональной чистоты и монадического контроля над side-effects. Да, из общих соображений можно предположить, что существовуют более сложные механизмы (в духе каких-нибудь disciple/ynot/whatever), но на сейчас монады — вполне адекватный инструмент. Кстати, именно поэтому становится важной ленивость, которая важна не сама по себе, а как (ПРАГМАТИЧЕСКИ) естественный порядок вычислений в этих условиях.
3. Выдающееся community.
4. GHC — действительно beast. Помимо главных обязанностей он умеет rewrite rules, template haskell и plugins и вообще с недавних пор организован как библиотека (GHC as a library), что, в принципе, сообщает ему силу, совершенно невиданную.
Здравствуйте, novitk, Вы писали:
BZ>>по моему приватному мнению, по времени разработки сложных алгоритмов, хаскел превосходит С++ на порядок, C#/Java раза в три, а гибридные языки — раза в 1.5-2
N>Боюсь местные хаскелеводы не согласятся Сам с оценкой согласен, но если это так, то боюсь мне (практику!) оно не надо...
Если бы вместо C++ стоял Си можно было бы согласится. C C++ все сложнее, он может быть как на уровне с Си а может и выше чем Java.
N>По причине, что этого не достаточно чтобы оправдать все остальные расходы — слабую библиотеку, необходимость интеропа и т.д.
У Ocaml'а более слабая библиотека чем у Хаскеля, интероп гораздо более сложный, и популярность его ниже, и он моложе. Но программ на нем написано больше.
Здравствуйте, FR, Вы писали:
FR>У Ocaml'а более слабая библиотека чем у Хаскеля, интероп гораздо более сложный, и популярность его ниже, и он моложе. Но программ на нем написано больше.
Здравствуйте, pgregory, Вы писали:
P>Если серьезно, то, ребята, а вы никогда не задумывались, почему, например, ООП так популярно?
P>Вовсе не потому, что ему везде учат. Это — следствие, а не причина. Причина проста. Она не имеет ничего общего с тем, насколько (не-)адекватно ООП позволяет моделировать окружающий мир. И она кроется в том, что ООП гораздо ближе среднему человеку, чем что-либо еще на текущий момент.
одна из моих любимейших цитат на эту тему:
Мне кажется, распространению Форта мешают лишь два
фактора: 1) воспитываемая сызмальства "классическая"
методология мышления у программистов (мешающая в равной степени
и внедрению объектно-ориентированной технологии)...
написано в 93-м году. нынешней молодёжи трудно представить, как все 80-е годы ООП боролось за умы программистов, имея в те времена точно такую же ауру мощной, но трудноиспользуемой технологии
Здравствуйте, BulatZiganshin, Вы писали: RD>>Вместо того, чтобы провести превращение в кодировку, стандартную для данной платформы. Конечно, тупо засадить "fromIntegral (ord ch)" и баран может. BZ>далее, какие функции мы должны вызывать с этой "стандартной кодировкой"? мой gcc4, во всяком случае, не поддерживаем семейства _t* — хотя может ему опцию какую надо скормить?
Кто виноват и что делать.
Если мы таки о кривой работе стандартной библиотеке haskell с WinApi, то мне видится 2 нормальных решения:
1. Вазывать нативные функции работающие со строками в unicode (те, которые с W на конце)
2. Явно перекодировать строки из ANSI.
Если забить на поддержку Win9x то первый вариант самый простой и удобный. Именно он применяется в Qt — там тоже все строки уникодные.
Если таки необходима поддержка Win9x то второй вариант таки не сильно тудоёмкий.
Ну и gcc поддерживает оба этих варианта безо всяких ключиков.
Здравствуйте, thesz, Вы писали: T>Ты на голубом глазу высказал утверждение, что если написать систему, которая будет перемалывать хотя бы мегабайт в секунду с нетривиальным обновлением модели, то на Хаскеле всё будет плохо. T>ЭТО. НАДО. ДОКАЗЫВАТЬ. T>Мегабайты в секунду с нетривиальным обновлением см. на CUFP. Но ты там в упор не видишь положительных примеров.
Пример подойдёт?
В рабочей папке darcs переместил 8 файлов (~100мб) в другой подкаталог.
darcs не смог гафиксировать изменения — вывалился по переполнению памяти.
На борту 2гб, darcs 2.2.1 (release), Win Vista Home.
Здравствуйте, Tonal-, Вы писали:
RD>>>Вместо того, чтобы провести превращение в кодировку, стандартную для данной платформы. Конечно, тупо засадить "fromIntegral (ord ch)" и баран может. BZ>>далее, какие функции мы должны вызывать с этой "стандартной кодировкой"? мой gcc4, во всяком случае, не поддерживаем семейства _t* — хотя может ему опцию какую надо скормить? T>Кто виноват и что делать. T>Если мы таки о кривой работе стандартной библиотеке haskell с WinApi, то мне видится 2 нормальных решения:
нет, мы о другом — о том, что FFI должен был предоставить операции и типы, скрывающие от программиста особенности платформы, после чего любой код, обращающийся к posix api, должен автоматом работать на обеих платформах
Здравствуйте, Klapaucius, Вы писали:
K>Здравствуйте, pgregory, Вы писали:
P>>Простые вещи можно объяснить на пальцах. Или в двух словах.
K>Сможете объяснить в двух словах, что такое коммутативное кольцо с единицей?
Нет. А вот что такое множество целых чисел (являющееся коммутативным кольцом с единицей, я правильно нашел подвох? :-) — не сомневаюсь.
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, FR, Вы писали:
FR>>У Ocaml'а более слабая библиотека чем у Хаскеля, интероп гораздо более сложный, и популярность его ниже, и он моложе. Но программ на нем написано больше.
К>Где можно посмотреть статистику?
Здравствуйте, VoidEx, Вы писали:
VE>Здравствуйте, pgregory, Вы писали:
P>>Пока никто даже не пытался. Наверно, это настолько просто, что даже неинтересно :-)
VE>Конечно просто. Это обобщённое вычисление (не процесс, его описание). VE>Вот в псевдокоде сиобразного языка:
// int foo(); int bar();
SequenceComputation x = do { f <- foo(); b <- bar(); return (f + b); }
x.Run();
// File openFile(); Result writeFile(); Result closeFile();
SequenceIfNotFailComputation y = do { f <- openFile(...); writeFile(f, ...); closeFile(f); }
y.Run();
// List<String> getLines(String); ...
MultipleResultsComputation z = do { line <- getLines(...); word <- getWords(line); return (word + "lala"); }
z.Run();
Косяк в том, что твой ответ неверный. Монада — это не обобщенное вычисление. Иначе — что же такое Arrow, тогда?
Забавно то, что никто не написал реального определения монады. А ведь это ничем не особенный (кроме syntax sugar) type class в хаскеле!
Его определение в студию! Трам-пара-рам, вот оно!
class Monad m where
(>>=) :: m a -> (a -> m b) -> m b
(>>) :: m a -> m b -> m b
return :: a -> m a
fail :: String -> m a
Итак, монада — это некая сущность, для которой мы можем определить эти четыре операции так, что они будут удовлетворять monad laws.
Поэтому да, монада — это сложная штука. То, что с помощью монад можно определить простые и понятные вещи типа Maybe не имеет к этому факту никакого отношения. Klapaucius здесь
Здравствуйте, BulatZiganshin, Вы писали:
BZ>Здравствуйте, pgregory, Вы писали:
P>>Если серьезно, то, ребята, а вы никогда не задумывались, почему, например, ООП так популярно?
P>>Вовсе не потому, что ему везде учат. Это — следствие, а не причина. Причина проста. Она не имеет ничего общего с тем, насколько (не-)адекватно ООП позволяет моделировать окружающий мир. И она кроется в том, что ООП гораздо ближе среднему человеку, чем что-либо еще на текущий момент.
BZ>одна из моих любимейших цитат на эту тему: BZ>
Мне кажется, распространению Форта мешают лишь два
BZ>фактора: 1) воспитываемая сызмальства "классическая"
BZ>методология мышления у программистов (мешающая в равной степени
BZ>и внедрению объектно-ориентированной технологии)...
BZ>написано в 93-м году. нынешней молодёжи трудно представить, как все 80-е годы ООП боролось за умы программистов, имея в те времена точно такую же ауру мощной, но трудноиспользуемой технологии :)))
Как представитель нынешней молодежи, скажу, что здесь, кажись, происходит подмена понятий.
Или ты реально считаешь, что FP так же интуитивно, как и ООП? (Чувствую, как люди с горящими глазами бросились писать «Да! Да! Да!!!» :-)
Если так, то что же, я с этим не согласен. Если не очевидно, почему, могу попытаться обосновать.
