Здравствуйте, thesz, Вы писали:
T>Наличие фичи не означает возможность её простого использования и отсутствия ошибок. T>В случае алгебры патчей отсутствие ошибок был by design.
Замечательно, но Хаскель то здесь причем? Ты считаешь, что "алгебры патчей" не реализуема в Питоне?
Здравствуйте, Rtveliashvili Denys, Вы писали:
T>>Ленивость стимулирует модульность (famous 'map f . map g === map (f . g)' example).
RD>Ага, и взрывает потребление памяти там, где этого не ждешь. В проекте <1K lines может быть это и не проблема. А если <1M lines? Не согласны? Приведите успешный контр-пример.
ghc. ленивость можно контролировать на уровне тех немногих структур данных, чей размер может быть критичен. но для остальных, т.е. >99% переменных, никаких проблем это не вызывает а программирование упрощается. это аналогично использованию ЯВУ — вы ведь не пишете на ассемблере всю программу только потому, что у вас есть пара time-critical мест
RD>А еще, отсутствие приличного IDE заставляет 100 раз подумать, прежде чем написать хоть строчку кода.
если вы пишете код, не думая, то c#+vs — это идеальная среда. я серьёзно. писать такого рода программы на других языках — бесхозяйственность, граничащая с преступлением
RD>Еще есть масса полезностей: RD>1. невозможность использовать стандартные технологии передачи сообщений. Действительно, зачем JMS и AMQP если можно тупо текст гонять по сырому TCP?
это всё обобщается до неразвитости инфраструктуры. мало библиотек, нет современных IDE с отладчиками, нет курсов "haskell за 5 минут для тех, кто не привык думать"
RD>2. Удивительные красоты самого языка вроде операторов (,,,,,,,,).
как раз в плане синтаксиса хаскел даёт большую фору любому другому языку (из нескольких десятков, что я знаю). если уж приводить пример, то не неиспользуемую в реальной жизни операцию построения 10-элементной анонимной структуры, а скажем такое:
fac n = prod [1..n]
что автоматом определяет полиморфную по всем числовым типам процедуру вычисления факториала. я автоматичсеким выводом наиболее общего типа пользуюсь постоянно
RD>В общем, Haskell может и подойдет для чего-то в production, но область приминимости стремится к нулю.
ты в общем правильно определил — хаскел не подойдёт тем, кому не надо думать, а лишь быстро педалить, используя готовые библиотеки/генераторы кода. хаскел не подойдёт тем, для кого единственный способ написать правильную программу — гонять её часами в отладчике. хаскел не подойдёт для industrial programmers, если под ними понимать тех, для кого существуют только языки, поддерживаемые IDE
Здравствуйте, BulatZiganshin, Вы писали:
N>>Это все громадные риски, на которые можно пойти только если реально видеть свет в конце туннеля. Извини, но я его не вижу. Где "killer app", где "success stories"? И это при том, что среда (GHC) уже давно на вполне индустриальном уровне.
BZ>в подписи как раз вполне success story (на killer app она не тянет ввиду малопопулярности архиваторов вообще). кратко — это аналог rar/7-zip, разработанный в несколько раз быстрее. конкретно, я сравнивал 7-zip и fa, когда набор их фич примерно совпадал — размеры моих исходников были втрое меньше
Как человека, который попробовал freearc (0.40, которая была задекларирована как stable), меня совершенно не волнует размер исходников. А вот то, что freearc при какой-то комбинации ключей (по-моему, -mt2 на двухядерном Core2Duo) зависал намертво отжирая процессорное время... В общем, с точки зрения пользователя использования Haskell-я не убеждает.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, thesz, Вы писали:
T>Этот пункт справедлив только для ограниченного количества компиляторов: gcc, msvc, xlc и icc. Ну, ещё, наверное, cc от Sun. Ну, ещё .net. И Java.
+ Digital Mars компиляторы для C/C++ и D.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
BZ>команды ghc и f# работают в Кембридже, где находятся лаборатории MS Research. т.е. всё-таки это "академики, работающие на индустрию", и в частности эти джве группы как раз и создают технологии компиляции для будущих студий BZ>jkff и thesz же работают в коммерческих компаниях, и применяют хаскел для зарабатывания денег
N>>а готов ли ты вложить значительные ресурсы в разработку на Хаскеле? Посмотри на риски... BZ>насчёт меня смешно спрашивать — я как раз пятый год пишу freearc на хаскеле
Я так понимаю, что freearc это чудная и полезная программа, но коммерческим проектом это не является. Или может я неправ?
Насчет jkff и thesz: раз работают в _коммерческих_ компаниях, то это внушает оптимизм. Быть может, они даже поведают миру о том, какие коммерчески успешные продукты были созданы на хаскелле/с помощью хаскелля? (про иммитацию железа я уже в курсе, жаль это очень узкая область). Кто знает, может это потянет на success story и повысить популярность хаскеля...
BZ>риски — надо сравнивать, а то ты рассуждаешь так, как будто при работе с явой рисков никаких. так вот, на одной стороне находятся риски того, что ваши программисты не освоят хаскел на том же уровне, что они уже освоили яву, и поэтому у вас возникнут сложности с отладкой, оптимизацией и т.п. на жругой стороне находятся риски большего проекта, который рискует погибнуть под своей тяжестью. просто риски второго типа хоршо хнакомы и никто тебя не убьёт, если ты с ними не справишься
Риски второго типа часто включают в себя и интеграцию с уже написанным софтом. В случае в Haskell это IMHO просто могила. Был бы рад, если было бы иначе, но в ближайшие годы видимо не судьба.
Здравствуйте, eao197, Вы писали:
T>>Ленивость стимулирует модульность (famous 'map f . map g === map (f . g)' example).
E>А можно развернуть для чайников, о какой модульности здесь идет речь?
читай "why functional programming matters"
T>>Отсутствие отладчика стимулирует написание программ, о которых легко рассуждать и не нужно отлаживать.
E>Прошу прощения за грубость, но это достойно войти в аналы вместе с вот этой
просто ты не понял, о чём речь. о программе можно думать локально — о том, что если на входе будет 123, то на выходе должно быть 456. или глобально — как об алгоритме преобразования
работая с отладчиком, ты имеешь дело с одним конкретным прогоном программы. более того, находишься в одной конкретной точке выполнения. имея дело с логами — ты работаешь с историей выполнения целиком, а то и с историей нескольких прогонов. наконец, работая с текстом программы, ты имеешь дело с самим алгоритмом, со всеми возможными вариантами его работы
понятно, что использование более глобальных средств отладки — сложнее и требует большей квалификации. но при этом использование более локальных среджств — оно порвоцирует и более локальные исправления, заплатки. во-первых, потому, что выглядит глупо, найдя ошибку за одну минуту, затем целый день думать над её исправлением. во-вторых, потому, что отладка даёт только локальную информацию о произошедшей ошибке что провофирует на локальные же исправления заплатки, вместо осмысления всего алгоритма
вот и выходит, что наличие средств отладки провоцирует написание программы в quick-and-dirty style
E>Вот Дональд Кнут, к примеру, считает отладчик очень важным инструментом программиста.
но он ведь не говорил, что программисты, снабжённые отладчиком, пишут столь же ясные программы?
Здравствуйте, eao197, Вы писали:
T>>Я пишу программы, не пользуясь отладчиком. Это написанные программы, полезные не только мне.
E>Когда весь мейнстрим будет состоять из людей типа thesz, тогда можно будет рассматривать отладчики, как ухудшающий качество программ атавизм...
маинстримом хаскел станет только тогда, когда станет маинстримом т.е. когда под него будут ide, библиотеки, курсы и прочая. если же речь идёт о командах вроде вашей, то вроде они как раз состоят из людей подобных Сергею или скажем мне. мы обычные квалифицированные программисты, не марсиане какие-нибудь и я, честное слово, до сих пор не знаю теорию категорий
Здравствуйте, Rtveliashvili Denys, Вы писали:
RD>С другой стороны, не много пользовался потому что мелких недочетов полно. Элементарный пример: поддеркжа unicode в Haskell библиотеках вообще никакая.
поддержка юникода встроена в компилятор. проблемы возникают только там, где нужно делать интерфейс к С-библиотекам
Здравствуйте, novitk, Вы писали:
T>>Наличие фичи не означает возможность её простого использования и отсутствия ошибок. T>>В случае алгебры патчей отсутствие ошибок был by design.
N>Замечательно, но Хаскель то здесь причем? Ты считаешь, что "алгебры патчей" не реализуема в Питоне?
насколько я понимаю, это из разряда алгоритмически сложных вещей, которые при реализации на С++ потребовали бы на порядок больше времени
Здравствуйте, BulatZiganshin, Вы писали:
BZ>jkff и thesz же работают в коммерческих компаниях, и применяют хаскел для зарабатывания денег
Да, но у меня кроме их слов ничего нет, а их слова это слова фанатов. Может у них задачи хорошо ложаться на Хаскель, а у меня не выйдет.
N>>а готов ли ты вложить значительные ресурсы в разработку на Хаскеле? Посмотри на риски...
BZ>насчёт меня смешно спрашивать — я как раз пятый год пишу freearc на хаскеле
Я говорю в контексте "индустиального программирования". К тебе приходит инвестор/заказчик, ставит задачу, и дает деньги и сроки. Тебе нужно собрать команду и выбрать инструмент для решения. Для предметной области опыта успешного применения Хаскеля не было. В этих условиях ты реально поставишь на Хаскель или возьмешь гибрид?
BZ>риски — надо сравнивать, а то ты рассуждаешь так, как будто при работе с явой рисков никаких. просто риски второго типа хоршо хнакомы и никто тебя не убьёт, если ты с ними не справишься
+1
BZ>что касается вообще, то процесс внедрения новых технологий вроде не хаскел-специфичен, стоит ли 120-й раз повторять чужие слова?
"хаскел специфичен" тем, что его плавно не внедрить. Питон можно, Скалу можно, а Хаскель нельзя. А еще команду не собрать — число "гениев" на квадрат площади очень маленький
BZ>в подписи как раз вполне success story (на killer app она не тянет ввиду малопопулярности архиваторов вообще). кратко — это аналог rar/7-zip, разработанный в несколько раз быстрее. конкретно, я сравнивал 7-zip и fa, когда набор их фич примерно совпадал — размеры моих исходников были втрое меньше
Ты меня извини, но в оценке "качества и функционала" ты обьективным быть не можешь, как автор. FreeАrc по "качеству и функционалу" с 7zip/rar-у сравнить нельзя по причине низкого использования, а значит размер исходников сравнивать смысла пока нет.
BZ>как языки они находятся где-то посредине между c++ и хаскелом. а вот внешняя среда у f# к 2010-му году будет несравненно лучше, чем у хаскела
С "посередине" не согласен. Большинство вкусностей приводящие к улучшению кода в них доступны. Хаскель лучше из за чистоты и системы типов, но это все не бесплатно. Теоритические аргументы thesz-а убедить, что цена маленькая или ее вообще нет, мне понятны, но без примеров остаются теорией.
N>>Буду рад, хотя мне нужна открытая платформа, поэтому я хочу что-нибудь Scala-подобное...
BZ>scala и f# — это всё же две большие разницы: ооп+фп и фп+ооп. имей в виду, что это не одно и то же
Почему это принципиально? Ментально? На скале вполне можно писать без слова class. Очень похоже на Питон, который я использую в основном функционально без всякого дискомфорта.
Здравствуйте, BulatZiganshin, Вы писали:
N>>Замечательно, но Хаскель то здесь причем? Ты считаешь, что "алгебры патчей" не реализуема в Питоне?
BZ>насколько я понимаю, это из разряда алгоритмически сложных вещей, которые при реализации на С++ потребовали бы на порядок больше времени
На C++ — может быть, но это каменный век, хотя и на нем сделаны много сложных вещей, да и автор не программист. Мы же вроде говорили о гибридах и Питоне?
Здравствуйте, eao197, Вы писали:
BZ>>в подписи как раз вполне success story (на killer app она не тянет ввиду малопопулярности архиваторов вообще). кратко — это аналог rar/7-zip, разработанный в несколько раз быстрее. конкретно, я сравнивал 7-zip и fa, когда набор их фич примерно совпадал — размеры моих исходников были втрое меньше
E>Как человека, который попробовал freearc (0.40, которая была задекларирована как stable), меня совершенно не волнует размер исходников. А вот то, что freearc при какой-то комбинации ключей (по-моему, -mt2 на двухядерном Core2Duo) зависал намертво отжирая процессорное время... В общем, с точки зрения пользователя использования Haskell-я не убеждает.
не помню именно такой ошибки. вообще, есть три уровня отладки программы. первый — когда она у тебя уже компилируется, но не работает так, как ты ожидаешь. вот на этом уровне использование хаскела сильно сокращает работу — если ты смог откомпилировать код, то вероятность его безошибочности гораздо выше. второй — это ошибки работы в различных улсовиях, находимые различного рода тестированием. я этим не пользуюсь, хотя у хаскела здесь есть замечательный козырь пере другими языками — QuickCheck и его последователи (который позволяет написать что-то вроде
propertySort (\xs -> orderedBy (<) (sort xs))
и библиотека сама сгенерит энное кол-во списков и проверит, что заданное свойство действительно на всех них выполняется). и наконец третий уровень — это feedback от пользователей, в чём моя программа рахзумеется на порядки уступает популярным архиваторам
свойства языка позволяют значительно уменьшить кол-во ошибок первого типа, дают некоторый базис для улучшения модульного тестирования, но для того чтобы это почувствовать тебе придётся попробовать программировать самому. ну или хотя бы почитать History.txt из его комплекта и обратить внимание, что в нём никогда не было ошибок, приводивших к нарушению структуры архива, на что у нас были бы все шансы в случае использования C++ или даже динамических языков
T>>А чего ты здесь не спрашиваешь? T>>Узнать, как быть в какой-то ситуации, можно двумя способами: 1) попасть в неё самому, и 2) спросить у попадавших в неё. N>А зачем мне спрашивать? И здесь и в других местах достаточно ответов и вопросов. Ответы меня пока не убедили, поэтому хотелось бы подкрепить их примером. Достойных примеров вне компиляторостроения я не видел.
Дело в том, что Хаскель, большей частью, используется по месту. Тут утилитку, там оптимизатор, здесь редактор.
Тут вместо ошибки оценки в 20% получили 2%. Там ускорили выполнение в четыре раза. Здесь студент справился за три, что ли, месяца (не мой опыт — vshabanov).
T>>"Попасть в ситуацию самому" ты не хочешь. Для этого надо начать использовать Хаскель. T>>Из чего следует неопровержимый вывод, что использовать Хаскель (ФЯ вообще) ты не хочешь. N>Я не "не хочу использовать Хаскель", а не могу оправдать риски связанные с ним в "индустриальной" среде.
Судя по всему, ты не простой программист. Как минимум, team lead.
Это значит, что ты в курсе процесса тестирования технологии и оценки рисков, когда выделяется пилотная группа, она что-то делает и потом даёт отчёт о применимости и подводных камнях.
А дальше все плюются и расходятся делать по старому.
N>Дома я с удовольствием с ним поковыряюсь, как и большинство здесь. Хаскель это очень серьезный прыжок, переползти плавно на него нельзя. Предсказуемость в нашем ремесле и так ниже плинтуса, а тут предлагается сменить лыжи на коньки. Тебе, фанату и эксперту, все это представляется ерундой, но влезь в мою шкуру.
Если впереди лёд — сменить лыжи на коньки необходимо.
T>>(мутабельные числодробилки после переноса на ФЯ приобретают интересные возможности, кстати) N>Интересно. Можно детали...
RD>Насчет jkff и thesz: раз работают в _коммерческих_ компаниях, то это внушает оптимизм. Быть может, они даже поведают миру о том, какие коммерчески успешные продукты были созданы на хаскелле/с помощью хаскелля? (про иммитацию железа я уже в курсе, жаль это очень узкая область).
Ты либо крестик сними, либо трусы одень.
Ты требуешь отчёта об успехах, но при этом сразу говоришь, что успехи "в ваших узких областях" меня не интересуют.
Я думаю, что даже http://cufp.galois.com/ тебя не удовлетворит. Там тоже какие-то узкие области.
RD>Риски второго типа часто включают в себя и интеграцию с уже написанным софтом. В случае в Haskell это IMHO просто могила. Был бы рад, если было бы иначе, но в ближайшие годы видимо не судьба.
У меня могила код на Джаве написать. Сводящий воедино мой код на Джаве и старый код на Джаве. Обработку данных через утилитки на Хаскеле я написал уже давно.
Могила, конечно, да только не там, где ты предполагал.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
T>>Наличие фичи не означает возможность её простого использования и отсутствия ошибок. T>>В случае алгебры патчей отсутствие ошибок был by design.
N>Замечательно, но Хаскель то здесь причем? Ты считаешь, что "алгебры патчей" не реализуема в Питоне?
Реализуема.
Насколько мне известно, в её реализации используется ленивость.
Те самые ленивые степенные ряды я реализовал-таки, с третьей попытки.
Поэтому реализация алгебры патчей на Питоне будет... ну, интересной, так скажу.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
N>>>Замечательно, но Хаскель то здесь причем? Ты считаешь, что "алгебры патчей" не реализуема в Питоне? BZ>>насколько я понимаю, это из разряда алгоритмически сложных вещей, которые при реализации на С++ потребовали бы на порядок больше времени N>На C++ — может быть, но это каменный век, хотя и на нем сделаны много сложных вещей, да и автор не программист. Мы же вроде говорили о гибридах и Питоне?
Дело в том, что для понимания, что надо сделать, это надо сделать на более прямом языке.
Мой знакомый и бывший коллега Ваня (lj user=_winnie) смог реализовать более-менее сносный оптимизатор символьных выражений только после основательного освоения Питона и после того, как мы с ним несколько раз поспорили с демонстрацией кусков кода на Хаскеле по этой же теме.
Поэтому прототип должен быть на более выразительном языке. На наиболее выразительном языке, поскольку тут надо за кратчайшее время выявить как можно больше всего.
В случае Питона и алгебры патчей прототип уже выполнен. Поэтому питоновцу будет проще, чем если бы он писал его с самого начала.
Что-либо сложное с нуля я бы на Питоне писать не стал бы.
T>>Кстати, упрощение выражений — мой любимый тест на выразительность языка. BZ>в таком случае лучший язык — пролог я на нём как-то писал дифференцирование с последующим упрощением
Я пытался.
Там тяжело менять представление (не говорят, где ты неправильно что задал), а от него много зависит.
А так пролог мощен, однозначно.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>Если есть числодробилка, то её можно как-то соптимизировать, если выразить проблему в символьном виде. T>Вот как-то так.
Спасибо, почитаю, но под числодробилками я понимаю именно численные методы, так как мои дефуры в символах пока не решить даже человеческим мозгом...
RD>>Насчет jkff и thesz: раз работают в _коммерческих_ компаниях, то это внушает оптимизм. Быть может, они даже поведают миру о том, какие коммерчески успешные продукты были созданы на хаскелле/с помощью хаскелля? (про иммитацию железа я уже в курсе, жаль это очень узкая область). T>Ты либо крестик сними, либо трусы одень.
Ну тогда уж, остряк Вы наш, будьте добры не заправлять рясу в трусы.
T>Ты требуешь отчёта об успехах, но при этом сразу говоришь, что успехи "в ваших узких областях" меня не интересуют.
Я не говорил что успехи в узких областях не интересут.
T>Я думаю, что даже http://cufp.galois.com/ тебя не удовлетворит. Там тоже какие-то узкие области.
Там есть несколько интересных историй успеха. На базе Erlang и Ocaml, например. Что дает основания считать что разработчики не пустозвонят. :-) А мне вот было интересно, чем же еще занимаются хаскелисты, особенно местные. Но молчат. Видимо коммерческая тайна. Ладно, раз тайна, не будем развивать тему.
RD>>Риски второго типа часто включают в себя и интеграцию с уже написанным софтом. В случае в Haskell это IMHO просто могила. Был бы рад, если было бы иначе, но в ближайшие годы видимо не судьба.
T>У меня могила код на Джаве написать. Сводящий воедино мой код на Джаве и старый код на Джаве. Обработку данных через утилитки на Хаскеле я написал уже давно. T>Могила, конечно, да только не там, где ты предполагал. ;)
"Могила код на Джаве написать" — понятно, очевидно.
"Обработка данных через утилитки на Хаскеле" — тоже понятно, в некоторых случаях это рационально. Особенно когда надо просто взять данные из файла, переработать и в другой файл скинуть.
"Сводящий воедино мой код на Джаве и старый код на Джаве." -... ндас, всегда думал что русский — мой родной язык. Но это предложение рвет мне мозг в фарш. Возможно, следует понимать так, что ежели Вы что-то напишете на Джава, то оно будет таким экзотичным, что его уже никак и ни с чем другим не соединить? Даже с другим софтом на Джава? А как же модульность? :-)
Не согласны? Приведите успешный контр-пример.
