В одном это обсуждении Хаскель встречается два раза и дважды же встречается термин "монада". И упоминание о Maybe тоже.
Причём один комментарий в стиле "я использовал Maybe потому, что надёжно, а теперь ещё и монады изучил, и получается коротко. мои волосы мягкие и шелковистые".
Из моих знаний про аудиторию слешдота я делаю вывод, что Хаскель уже давно в массах.
Просто не все читают слешдот.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, pgregory, Вы писали:
P>Или ты реально считаешь, что FP так же интуитивно, как и ООП? (Чувствую, как люди с горящими глазами бросились писать «Да! Да! Да!!!»
Нет, конечно. ООП интуитивно только для тех, кто широко практикует ООП.
Интуиция основана на опыте — так что интуитивно то, что хорошо знакомо. Сейчас, когда всех программистов учат ООП — оно интуитивно для программистов — только и всего.
С другой стороны — математике учат всех и все знания полученные в процессе обучения (за вычетом курса по ООП, естественно, для тех, у кого он был) работает против него. Мы 15 лет воспринимали a = 2 + 2 как утверждение, декларацию. Но внезапно выясняется, что за декларацией скрыта какая-то зависящая от времени работа — мы с ужасом видим как синглетону 2 посылают сообщение {+, 2} — но с годами можно, конечно, и к такому привыкнуть.
... << RSDN@Home 1.2.0 alpha 4 rev. 1110>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, pgregory, Вы писали:
P>Здравствуйте, EvilChild, Вы в числе прочих меня критиковали.
P>Я считаю, что окружающую реальность довольно легко представить в виде объектов, имеющих состояние, и изменяющих его при выполнении некоторых действий. На лингвистическом уровне — вроде существительных, прилагательных и глаголов.
Окружающую действительность довольно легко представить в виде объектов, над которыми можно произвести действия, и самих действий, в которых участвуют от 0 до нескольких объектов. Действие меняет состояние этих объектов. Более того, действию как правило нужно какое-то конкретное представление объекта (например телевизор в конкретном действии участвует только как параллепипед с массой).
Но это не ООП.
Тут нет объектов, обменивающихся сообщениями, тут нет наследования и полиморфизма, и даже инкапсуляции.
Тут есть объекты, которые в зависимости от ситуации надо представить так или иначе, а это в чистом виде либо преобразование в другой объект, либо type classes.
Тут есть действия, которые работают с _несколькими_ объектами в общем случае, а это функция от нескольких объектов, возвращающая новые состояния этих объектов, а не метод одного из них.
Я не вижу ООП.
Вот если бы можно было написать (man1, man2).поприветствовать(), тогда другое дело. Это действительно калька с реальности. А man1.поприветствовать(man2), это непойми что. Ну правда. Надо ведь (man1, man2, man3, man4).всем_привет().
Здравствуйте, FR, Вы писали:
FR>Но ML ветка функциональщины и современный мейнстримный ООП по сути ровесники, ты можешь объяснить почему FR>только сейчас есть робкие попытки проникновения ФП в мейнстрим?
Мне кажется, все может быть совершенно банально, если рассматривать языки не в платоновском смысле, а смотреть также на их реализации и рантайм. До середины 90-х у языков, требующих сборку мусора (а все упомянутые тут ФЯ без нее невозможны), просто не было шансов в мейнстриме. Развитие шло от железа: ассемблер — кроссплатформенный ассемблер (С) — кроссплатформенный ассемблер с доп. фишками (С++). Когда же развитие аппаратуры сделало GC доступным, 99% программистов привыкли думать в том же императивном стиле, и обучение новых программистов по-прежнему продолжается в том же ключе. Индустрия сегодня определяется навыками ее членов, те — образованием, которое определяется индустрией прошлого, которая была привязана к ограничениям железа. Хаскель — идеальный язык, ему нужен идеальный компьютер, а не наши ограниченные железки с парой гигов памяти.
Здравствуйте, pgregory, Вы писали:
P>Я в это просто верю.
Этому, конечно, трудно что-то противопоставить.
P>Я предъявляю претензию к языку. Потому, что он заставляет меня знать, что такое монада. Мне это не нравится. Заметьте, хаскель не заставляет знать, что такое коммутативное кольцо, чтобы оперировать числами.
Хаскель в точно такой же степени заставляет знать, что такое монады, в какой он, Питон, Схема, С, etc заставляют знать что такое коммутативное кольцо.
Если не знать что такое коммутативное кольцо с единицей — можно написать, например, b+0, хотя это то же свамое, что и b, а если не знать что такое монады можно написать
a <- foo
return a
хотя это то же самое, что и просто foo.
Писать без понимания монад на Haskell, разумеется, можно, но читать чужой код, по всей видимости, будет трудно.
P>Не знаю, почему, но то, что мне не нравятся сложные языки программирования, некоторые пытаются списать на мою ограниченность, нежелание изучать ничего нового и черт знает что еще.
P>Простота (и красота) — основа всего окружающего мира.
Просто те языки, которые вы считаете сложными, другие считают простыми и наоборот. Так происходит потому, что простой язык — это действительно язык привычный, а сложный — непривычный. Как я уже говорил, интуиция основана на опыте, а потому, знакомый язык — интуитивно понятный, а незнакомый — контринтуитивный. Никаких намеков на огранниченность и антиинтеллектуализм это не содержит, просто мир говорит с нами на том, языке, на котором мы думаем, а потому тот, кто знаком с ООП видит всюду подтвержения его интуитивности. Привычка определяет сознание в такой степени, что спустя годы использования C человек начинает думать, будто бы в школьных учебниках пользовались скобками не только для обозначения приоритета, и, следовательно писали не cos x, а cos(x). Т.е. это привычка делает мир "императивным", а не мир делает императивность привычной. Взгляд на мир меняется, и если роль времени в императивном языке соотвествует роли времени в ньютоновской механике, то роль времени в чистом функциональном языке соотвествует роли времени в ТО — и не зря в SICP проводится аналогия между ленивыми потоками и мировыми линиями, а полная энергия системы в квантовой механике, например, это комбинатор волновых функций.
P>И поэтому я верю, что реально хороший язык реально прост.
Что же касается объективной составляющей сложности, то она ограничена снизу выразительностью языка.
Т.е. невыразительный язык, разумеется, может быть неограниченно сложным, но при определенной выразительности должен иметь сложность не меньше минимальной для такого уровня выразительности.
Фактически, мы меняем сложность языка на простоту текста на этом языке — и реально простой язык не может быть реально хорош, ведь для испольхзования он непригоден.
Например Брейнфак — очень простой язык, который можно выучить за минуту, но он настолько маломощен, что не предоставляет практически никаких средств абстракции и декомпозиции и, следовательно, код на нем чудовищно сложен.
Понятно, что проще всего ничему не учиться и ничего не уметь, но для неумеющего ничего любая задача бесконечно сложна.
... << RSDN@Home 1.2.0 alpha 4 rev. 1110>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, pgregory, Вы писали:
P>Поинт не в том, что ООП это правильно. ООП это просто. Кнопка, говоришь? Хорошо, у нее будет метод «нажать». Почему у нее? А почему бы и нет? Да ни почему. Серьезно. Весь софт именно так пишется, и при этом еще и работает. Зачастую — очень хорошо.
Замечательное описание. Особенно выделенное.
Очень точно соотвествует распространённым представлениям об ООП как о какой-то совершенно аморфной и невнятной хрени.
Здравствуйте, pgregory, Вы писали:
P>Простые вещи можно объяснить на пальцах. Или в двух словах.
P>Не расскажешь ли, в двух словах P>— что такое monomorphism restriction P>— что такое монада
о, может ты наконец объяснишь мне, что такое ссылки? только пожалуйста не прибегай к непонятным терминам типа адресов памяти, объясни исходя из самого обычного лямбда-исчисления
Здравствуйте, Tonal-, Вы писали:
T>Здравствуйте, eao197, Вы писали: T>>>Я тут Java изучаю... E>>Java точно не вызывает у людей затем потом такого отвращения, как C++. T>Интересно почему так?
Не знаю. Тайна сия велика есть.
T>Я вот изучал Java уже после того, как довольно хорошо освоил плюсы. T>Ощущение — так себе. Есть интересные решения и сахар, но в основном Java изрядно сильнее ограничивает.
Я тоже программирован на Java после плюсов. Впечатления двойственные. С одной стороны, ловил себя на мыслях, что пишу многословный тупой код. Там, где на C++ можно было обойтись шаблонами или указателями на функции/методы, в Java нужно было делать интерфейсы, классы-наследники и пр. лабуду (правда я пользовался Java еще до введения в нее generic-ов). Зато в Java не нужно было думать об освобождении памяти. И никогда не было моментов, когда бы я не понимал где программа сломалась. Stack trace -- великая сила! А в C++ скомпилированная в релизе программа ломается через три недели непрерывной работы -- и все. Сиди и думай, где, как и почему, никаких следов.
Тем не менее, очень часто в адрес C++ слышатся высказывания о том, что С++ чуть ли не жизнь человеку поломал. Так уже поносят язык, что просто поражаешься. А адрес Java я такого пока не слышал. Хотя сам не упускаю момента вставить где-нибудь при случае Java must die!
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Klapaucius, Вы писали:
P>>Да, я понимаю, что вы хотели сказать. Но, как видите, у вас не получилось
K>От меня все пули ушли. Так что проблемы на принимающей стороне.
Здравствуйте, lomeo, Вы писали:
P>>В моем примере подразумевалась необходимость связки типа -XNoMonomorphismRestriction + import Control.Monad + liftM для превращения одного в другое. Если нужда в этой связке -- лишь плод моего воображения, я признаю, что неправ. Иначе вы признаете, что я прав.
L>... Очевидно, что для монады это сделать невозможно. Иначе это будет не монада. Игры же с типами совершенно несерьёзны и показывают, что ты не понимаешь, о чём говорил твой оппонент. В частности, в твоём определении f2 надо писать let f2 (x :: Monad m => m a) = x.
Согласен и с тем, и с тем. Нет проблем — признаю, что был не прав. Ответил, погорячившись.
Займусь-ка я теперь хаскелем посерьезней (возрадуйся, thesz! )
Здравствуйте, 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), что, в принципе, сообщает ему силу, совершенно невиданную.
T>>Обсуждение на слешдоте "Нулевой ссылки: ошибки на миллион долларов". T>>Из моих знаний про аудиторию слешдота я делаю вывод, что Хаскель уже давно в массах. Q>Честно говоря, не очень понятно, по какому поводу радость? Ну обсуждают, ну знают, и что? Зачем постить ссылку на каждое такое обсуждение?
(с горящими глазами) А где ещё посты со ссылками на такие обсуждения?
(внезапно меняя настроение, подозрительно) А где я ещё постил ссылки на каждые такие обсуждения?
Радость по поводу общего уровня знаний. Что в обсуждении нулевых ссылок, как ошибки, модераторы поднимают вверх комментарии про функциональные ЯП и алгебраические типы данных. Что это всё не проходит мимо обычного программиста.
Радость, ещё, по поводу весны.
Да последней причины вполне достаточно.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, BulatZiganshin, Вы писали:
BZ>Здравствуйте, thesz, Вы писали:
T>>Радость, ещё, по поводу весны.
T>>Да последней причины вполне достаточно.
BZ>почему тогда ссылка на слэшдот, а не telki.ru?
Чёй-то там ничего интересного... Сайт не соответствует адресу
Здравствуйте, thesz, Вы писали:
T>Ценнее всего сам факт, что монады и Maybe появляются в отвлеченном разговоре сами по себе и их поднимают модераторы.
С точки зрения обшей "культуры" — да, ценно, но я практик-эгоист. ИМХО монады монадами, но пока чистому ФП до "майнстрима", как до луны. Да и бог с ним, пусть хоть нормальный гибрид наконец выплывет на поверхность. Надоело, блин, в каменном веке сидеть!
Здравствуйте, pgregory, Вы писали:
P>Или ты реально считаешь, что FP так же интуитивно, как и ООП? (Чувствую, как люди с горящими глазами бросились писать «Да! Да! Да!!!»
Можно раскрыть тему интуитивности ООП?
А то у меня такое ощущение, что его почти никто не понимает (уж пользоваться точно не умеет).
Об интуитивности даже речь не идёт.
thesz, я тут долго писал Великий Пост, разносящий твою позицию в этой ветке в пух и прах. Но потом понял, что я теряю время. И прекратил. Счастливо повоевать!
Здравствуйте, eao197, Вы писали:
E>Только, имхо, для этого нужно вводить точный GC в язык раз и навсегда. Без оглядки на всякие встраиваемый системы, системы реального времени, high perfomance computing системы и пр. Только вот утопия это все пока.
Нет. Это Ява...
А вобще в С++ GC не нужен.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Klapaucius, Вы писали:
P>>Я предъявляю претензию к языку. Потому, что он заставляет меня знать, что такое монада. Мне это не нравится. Заметьте, хаскель не заставляет знать, что такое коммутативное кольцо, чтобы оперировать числами.
K>Хаскель в точно такой же степени заставляет знать, что такое монады, в какой он, Питон, Схема, С, etc заставляют знать что такое коммутативное кольцо.
K>Если не знать что такое коммутативное кольцо с единицей — можно написать, например, b+0, хотя это то же свамое, что и b, а если не знать что такое монады можно написать
a <- foo
return a
K>хотя это то же самое, что и просто foo.
Вот вы и попались!
Это -- чушь. Доказательство (GHCi, version 6.10.1):
Prelude> let f1 x = do { a <- x; return a }
Prelude> :t f1
f1 :: (Monad m) => m b -> m b
Prelude> let f2 x = x
Prelude> :t f2
f2 :: t -> t
Для разнообразия добавим еще
Prelude> let f3 x = return x
Prelude> :t f3
f3 :: (Monad m) => a -> m a
и
Prelude> let f4 x = do x
Prelude> :t f4
f4 :: t -> t
Сравните с
Prelude> let b = 0
Prelude> :t b + 0
b + 0 :: Integer
Prelude> :t b
b :: Integer
Комментарии нужны?
Да, я понимаю, что вы хотели сказать. Но, как видите, у вас не получилось :-)
Здравствуйте, pgregory, Вы писали: P>Попытаюсь объяснить. ООП — это объекты + сообщения/методы. Простейший способ ООП декомпозиции системы — написать текст, потом заменить существительные на объекты, а глаголы — на методы. (Все, конечно, сложнее, но идею, надеюсь, ты понял). Яблоко — объект. Человек — объект. У человека есть метод «спеть песню». У человека есть состояние. И у яблока есть состояние.
ООП — это инкапсуляция + наследование + полиморфизм.
А то что ты описал, это АТД.
И когда объясняют на примере яблок и коробок, оно всё на пальцах вроде как понятно, но когда начинают программировать сразу встаёт вопрос что от чего порождать прамоугольник от квадрата или наоборот.
После чего возникают совершенно монструозные леса наследований.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>правильный вопрос. а ООП коммерчески выгодно?
первой широко распространённой ООП системой стал turbo pascal 5.5, 1989-й год. сейчас скачал его руководство, быстренько просмотрел — и увидел ожидаемые слова:
The challenge of object-oriented programming (OOP) is that it sometimes
requires you to set aside habits and ways of thinking about programming that
have been considered standard for many years. Once that is done, however,
OOP is simple, straight-forward, and superior for solving many of the prob-
lems that plague traditional software programs.
Здравствуйте, Klapaucius, Вы писали:
K>Здравствуйте, eao197, Вы писали:
E>>Трудноиспользуемой ООП не была. ООП я начал использовать на втором курсе универа,
K>Думаю, что начни вы использовать ФП на втором курсе универа, трудноиспользуемым ФП вы также не назвали бы.
Интересно услышать комментарии.
E>>Причем я тогда даже не знал, что это ООП.
K>Вот в этом и заключается секрет успеха. Программисты на C# 3, например, в настоящее время широко используют монады и, в массе своей, не подозревают об этом.
Неужели не очевидно, что весь разговор именно об этом?! Программисты, например, в большинстве своем (нет, лично я не измерял) не знают, что целые числа образуют коммутативное кольцо с единицей (а также абелеву группу по ... и еще ... и еще ...). И это не мешает им писать программы, и делать это хорошо.
За простыми вещами должны следовать сложные, но не наоборот. Don't pay for what you don't need. Make simple things easy, but hard things possible. И так далее. Что здесь не ясно???
T>>Так он и моложе. И ситуация другая. FR>Так он и популярнее.
Так каких-то лет пять всего.
T>>И требования у тебя выше. FR>Так к лучшему из функциональных языков же
Так к ещё не развернувшемуся в полную силу.
T>>То, что евангелист я, не означает, что ты не должен подтверждать свои соображения. "Вывод явно притянутый" нуждается в другом, непритянутом выводе. FR>Притянутый потому что ты никак ни показал что именно из-за меньшей плотности ошибок переходят на Хаскель. Вот мне видится что из-за большей выразительности и большей гибкости языка по сравнению с ML.
Пример.
Внутреннее представление ghc типизировано. При желании можно включить проверку типов для него после каждого преобразования. Если преобразование неправильное, то проверка типов нам об этом сообщит. Эта фича позволила сэкономить разработчикам ghc много времени.
Итак, строго типизированные представления помогают.
Достаточно стандартным приёмом является и конструирование языка для своих внутренних нужд. Даже если это просто некое внутреннее представление.
Внутреннее представление есть у всех. Степень типизации, правда, разная.
Вот здесь показано, как пользоваться GADT, чтобы компилятор проверил правильность преобразований.
То есть, то, что ghc проверяет в рантайме, простому пользователю ghc доступно во время компиляции, хотя бы и для его нужд поменьше масштабом.
Это вынуждает этим пользоваться.
Это сокращает количество ошибок.
Всякого рода преобразования встречаются и в далёких от ЯП программах. В тех же оптимизаторах файловых систем, ведь файловая система и есть дерево с типами блоков, да ещё и хитро увязанных друг с другом.
FR>>>Иными словами, при любом конечном наборе аксиом мы имеем бесконечное число истин, которые не могут быть доказаны с помощью этого набора.
T>>Что это означает? FR>Это означает что универсальной покрывающей хотя бы большую часть решаемых задач системы типов не построить.
Поэтому нужна система типов, которую мы можем затачивать под наши конкретные цели. Система типов Хаскеля движется в этом направлении.
FR>Там же есть еще другой вывод, очень многие задачи вообще неприводимы и неупрощаемы
Essential complexity по Бруксу.
Такое встречается очень редко.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
RD>>Наверное это повод считать что проблемы нет? А.. Я понял. Индульгенцию дает то, что в _стандратной_ библиотеке взаимодействия с C-библиотеками просто положили болт на Unicode и тупо счатают что Char это char.
BZ>Рабинович напел? :) в FFI вообще разделены сишные и хаскеловские типы. 16-битные сишные символы — CWchar, они же TCHAR. работа с ними точно такая же, как с 8-битными символами: BZ>
Рабинович напел, что кое-кто не дочитал мое сообщение до конца.
Еще раз, по-пунктам:
1. В FFI разделены сишные и хаскеловские типы. ОК, это хорошо.
2. Поддерживаются как CString так и CWString. Тоже хорошо.
Но дальше начинается мусор, потому что:
1. При создании привязки к библиотеке как правило нужен locale-specific способ работы со стороками, что не просрет unicode.
2. В Foreign.C.String для этого есть группа ф-ций, но все они тупо используют ф-ции, поддерживающие только 8bit.
Пример:
withCString (что по-идее должна быть locale-specific) это просто вызов withCAString
withCString :: String -> (CString -> IO a) -> IO a
withCString = withCAString
А withCAString уже использует castCharToCChar, что работает только для символов к кодом меньше чем 256.
Вместо того, чтобы провести превращение в кодировку, стандартную для данной платформы. Конечно, тупо засадить "fromIntegral (ord ch)" и баран может. :-)
Но наверное это — еще одно мощное преимущество Хаскеля, о котором забыл упомянуть thesz. Впрочем, ему можно и простить. Он так был занят "разворачиванием" всех и вся, что мог просто не заметить.
А конкретно вышеописанное преимущество на практике означает следущее: когда рассматривается вопрос, не использовать ли Хаскель в очередном проекте, следует задуматься, стоит ли выразительность языка того гемора, что будет при попытке обойти все эти и им подобные грабли. Причем не только в своем коде, а и во всех сторонних библиотеках.
Здравствуйте, pgregory, Вы писали:
VE>>Т.е. хороший ЧПУ станок не даёт ничего (выделить ещё курсивом). Мастер с инструментами всегда сделает лучше, чем студент на таком станке.
P>Как написано у Страуструпа, «Доказательство по аналогии — это обман»
Как написано у Ожегова, доказательство и опровержение — это разные вещи.
Вы в одном предложении противоречите сами себе, я лишь это продемонстрировал.
Меня удивляет, как на каждое изобретение находится кто-то, кто говорит
— это что же ж, вечный двигатель штоля?
— нет конечно
— ну тогда нам и даром не нать
Вроде как давно уже порешили, что панацей не существует, а всё равно самым важным аргументом является, что сам по себе язык за вас проект не сделает. Ну это уж извините!
Прямо как будто в психологии у людей заложено панацею искать, хоть и знают, что нет её.
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, FR, Вы писали:
FR>>У Ocaml'а более слабая библиотека чем у Хаскеля, интероп гораздо более сложный, и популярность его ниже, и он моложе. Но программ на нем написано больше.
К>Где можно посмотреть статистику?
T>bracket :: Monad m => m open -> (open -> m close) -> (open -> m action) -> m (Maybe action)
T>bracket open close action = do
T> h <- open
T> r <- catch (liftM Just (action h)) (return . const Nothing)
T> close h
T> return r
T>
Это не RAII. В haskell-е нет аналога деструкторов, так что RAII там быть не может.
А то, что ты написал называется "шаблонный метод" по GoF.
Его можно вызывать там, где требуется аналог.
Здравствуйте, z00n, Вы писали: Z>Здравствуйте, Tonal-, Вы писали:
T>>Это не RAII. В haskell-е нет аналога деструкторов, так что RAII там быть не может. Z>RAII — это С++ название для устоичивого к исключениям scope-based resource management'а. Появилось это в лиспе, давно, лет 30 назад.
Если у тебя объект на стеке, то они аналогичны.
Если объект динамический, то нет. Z>Stroustrup — придумал как повторить это в С++ с помощью хака с деструкторами и воспомогательными обектами. Но деструкторы для этого не нужны.
На счёт хака — это эмоции.
Здравствуйте, thesz, Вы писали:
T>>>Ленивость стимулирует модульность (famous 'map f . map g === map (f . g)' example). E>>А можно развернуть для чайников, о какой модульности здесь идет речь?
T>Отдельно написал генератор, отдельно написал обработчик. В промежутке поставил фильтры.
T>Всё работает так, как будто написано в одном модуле.
Имхо, это достаточно специфическое отношение к модульности...
T>Особенно удобно писать переборные алгоритмы, например, Equality Saturation, про который было в моём блоге позавчера.
...да еще и применительно к решению специфических задач.
T>Я пишу программы, не пользуясь отладчиком. Это написанные программы, полезные не только мне.
Когда весь мейнстрим будет состоять из людей типа thesz, тогда можно будет рассматривать отладчики, как ухудшающий качество программ атавизм...
T>Да когда на железке гоняешь свой код, тоже особо отладчиком не попользуешься. Встроенных железок на порядки больше, чем обычных.
...но поскольку людей, программирующих на обычных железяках, а не на встроенных, на порядки больше, то наличие качественных отладчиков для _очень_ многих разработчиков является чуть ли не самым серьезным помошником в получении работающих программ. И пока инструменты не будут расчитаны именно на таких разработчиков, попасть в мейнстрим им не светит.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Rtveliashvili Denys, Вы писали:
RD>Повторяю еще раз: отсутствие возможности не может являться преимуществом. Особенно, если это преимущество не может помешать. RD>Если Вам это не очевидно, то что ж... Не расстраивайтесь, быть может Вы — Гений. Надеюсь, высокое жюри учтет и сей факт.
Ох как кстати!
Заранее уточню, что я не придерживаюсь ни одной из сторон.
А теперь прошу уточнить:
1. Почему отсутствие возможности — не может являться преимуществом
2. Почему наличие дебаггера не может помешать (не пользоваться — это не вариант, так как рассматривается сферический программист в вакууме, который пользуется)
3. Докажите очевидность.
Очень люблю слова "очевидно", они обычно скрывают то, что _кажется_ очевидным автору.
Здравствуйте, 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
T>>Ты требуешь отчёта об успехах, но при этом сразу говоришь, что успехи "в ваших узких областях" меня не интересуют. RD>Я не говорил что успехи в узких областях не интересут.
Это никак иначе понять нельзя.
"Про иммитацию железа я в курсе, жаль это очень узкая область."
Узкая, потому и жаль, что неинтересная.
T>>Я думаю, что даже http://cufp.galois.com/ тебя не удовлетворит. Там тоже какие-то узкие области. RD>Там есть несколько интересных историй успеха. На базе Erlang и Ocaml, например. Что дает основания считать что разработчики не пустозвонят. А мне вот было интересно, чем же еще занимаются хаскелисты, особенно местные. Но молчат. Видимо коммерческая тайна. Ладно, раз тайна, не будем развивать тему.
Именно. Будет что — обязательно расскажу.
T>>У меня могила код на Джаве написать. Сводящий воедино мой код на Джаве и старый код на Джаве. Обработку данных через утилитки на Хаскеле я написал уже давно. T>>Могила, конечно, да только не там, где ты предполагал. RD>"Могила код на Джаве написать" — понятно, очевидно. RD>"Обработка данных через утилитки на Хаскеле" — тоже понятно, в некоторых случаях это рационально. Особенно когда надо просто взять данные из файла, переработать и в другой файл скинуть. RD>"Сводящий воедино мой код на Джаве и старый код на Джаве." -... ндас, всегда думал что русский — мой родной язык. Но это предложение рвет мне мозг в фарш. Возможно, следует понимать так, что ежели Вы что-то напишете на Джава, то оно будет таким экзотичным, что его уже никак и ни с чем другим не соединить? Даже с другим софтом на Джава? А как же модульность?
Просто изучение платформы под названием Eclipse требует времени. Основная часть работы оного Eclipse выполняется не явно, путем передачи значений, а через побочные эффекты.
Вот выявить нужное количество этих эффектов и их проэксплуатировать и есть основная сложность.
Ничего приятного, откровенно говоря.
Код на императивных языках я пишу простой, понятный и элегантный. С хорошо изолированными эффектами, очень модульный.
Я, вообще, очень хороший программист, да. И как всякий хороший специалист, понявший дзен своей профессии (да и не только её), я очень скромен, про это я всегда стараюсь упомянуть.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, BulatZiganshin, Вы писали:
E>>Как человека, который попробовал freearc (0.40, которая была задекларирована как stable), меня совершенно не волнует размер исходников. А вот то, что freearc при какой-то комбинации ключей (по-моему, -mt2 на двухядерном Core2Duo) зависал намертво отжирая процессорное время... В общем, с точки зрения пользователя использования Haskell-я не убеждает.
BZ>не помню именно такой ошибки.
Конкретно вот эту не воспроизвел с ходу (уже не помню, что именно я архивировал), но вот сейчас попробовал заархивировать документацию по JDK:
D:\usr\share\doc\jdk>arc a -r -m9 -mt2 java_docs docs/*
ARC 0.40 creating archive: java_docs.arc
Compressing 9.482 files, 154.037.800 bytes. Processed 36.5%
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
BZ>вообще, есть три уровня отладки программы. первый — когда она у тебя уже компилируется, но не работает так, как ты ожидаешь. вот на этом уровне использование хаскела сильно сокращает работу — если ты смог откомпилировать код, то вероятность его безошибочности гораздо выше. второй — это ошибки работы в различных улсовиях, находимые различного рода тестированием. я этим не пользуюсь, хотя у хаскела здесь есть замечательный козырь пере другими языками — QuickCheck и его последователи (который позволяет написать что-то вроде
BZ>propertySort (\xs -> orderedBy (<) (sort xs))
BZ>и библиотека сама сгенерит энное кол-во списков и проверит, что заданное свойство действительно на всех них выполняется). и наконец третий уровень — это feedback от пользователей, в чём моя программа рахзумеется на порядки уступает популярным архиваторам
Это не правильный разговор. Проблема с программами у программистов состоит в чем? В том, что программы должны работать так, как того хочет пользователь. И если пользователь не видит нормальной работы, то ему абсолютно фиолетово все эти рассуждения программистов об уровнях и условиях.
Здесь постоянно говорят о том, как ФП вообще и Haskell в частности, сокращают время написания программ и увеличивают их качество. Но что можно увидеть на примере того же FreeArc? А нет качества. Заявлена фича в стабильной версии 0.40, но не работает. Ну и спрашивается -- если Haskell так помог сократить время на написание, то почему не было потрачено достаточно усилий на тестирование? Если уж возводят Haskell в ранг языка для написания программ без ошибок, то хочется видеть это на примерах -- берешь программу, используешь ее и с багами не сталкиваешься вообще. Вот это показатель. А так, на первом более-менее серьезном запуске -- облом. Не внушает, в общем
Булат, ничего личного. FreeArc действительно жмет очень сильно, но стабильности не хватает.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Не могу не встрять в этот эпичный флейм :-) Заранее извиняюсь за тон; читать следует, как будто после каждого предложения стоит смайлик, или типа того.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, novitk, Вы писали:
N>>Здравствуйте, thesz, Вы писали:
T>>>С функционалом?
N>>http://www.selenic.com/mercurial/wiki/index.cgi/UsingExtensions N>>и да cherry-picking тоже.
А>Если скрестить cherry-picking и коммутативность патчей, то открываются новые возможности. А>Поэтому не надо тупо гуглить, почитайте туториал и оцените сами.
Уважаемые защитники ФП! Здоровы ли вы? Работали ли вы когда-нибудь с исходным кодом программ? Известно ли вам, что между патчами существуют и _более_ сложные зависимости, чем то, что два патча один за другим модифицируют одно и то же место кода? (И, более того, эти более сложные, неявные, зависимости — правило, а не исключение?)
До тех пор, пока эта мега-алгебра не сможет разрешать такие зависимости (а этого она не сможет никогда — к слову, она хоть компилируемость программы (хоть на хаскелле) гарантирует при существующем авто-черри-пике?), она будет практически бесполезна. Черри-пик всегда будет операцией, при выполнении которой надо 7 раз подумать. И никакая алгебра тут не спасет.
А>По поводу того, что алгебру патчей можно реализовать на любом языке. С этим глупо спорить, однако небольшая ремарка. А>Первая версия darcs была написана на c++. К сожалению, она не работала. Совсем. А>Вторая версия была написана на хаскеле. И она заработала. Сразу. А>("Заработала" -- имеется в виду алгебра патчей).
Алгебра патчей, как мы видим, это киллер фича, да? И то, что другие dvcs ее не имеют, ставит их на ступеньку ниже, так? Очевидно, что любой вменяемый разработчик должен выбрать darcs, получается. А что мы имеем на самом деле?
Проекты, использующие darcs
— darcs
Проекты, использующие git
— git
— Linux kernel
— X.org
— Android
— Qt
— GHC (раньше использовали darcs :-)
— Perl
— Ruby on Rails
— WINE
Не, конечно, darcs еще использует какая-нибудь мега-программа типа xmonad... А что-нибудь покрупнее? Проект AAA-класса? Ход за вами!
И не надо про то, что пока, мол, так и так, но люди поймут, и тогда... На git _сейчас_ активно переходят проекты с cvs, svn, perforce и даже darcs (GHC!). Потому, что он лучше. И всем плевать, что он написан на C, перле и баше. Все настолько просто.
(Раз часть поста про алгебру патчей вы не комментируете, следует считать, что вы согласны? Если нет — буду рад, если укажете, где же я не прав)
BZ>Здравствуйте, pgregory, Вы писали:
P>>Не, конечно, darcs еще использует какая-нибудь мега-программа типа xmonad... А что-нибудь покрупнее? Проект AAA-класса? Ход за вами!
BZ>freearc, конечно же
No comments :-)
P>>И не надо про то, что пока, мол, так и так, но люди поймут, и тогда... На git _сейчас_ активно переходят проекты с cvs, svn, perforce и даже darcs (GHC!). Потому, что он лучше. И всем плевать, что он написан на C, перле и баше. Все настолько просто.
BZ>и отсюда ты делаешь вывод, что с, перл и баш — это лучшие в мире ЯП, на которые всем немедленно нужно перейти?
Отсюда я делаю вывод, что хорошесть программы абсолютно ортогональна хорошести яп, на котором она написана.
И хотя хороший яп может помочь в написании хорошего софта (а может и помешать — сколько контрибьюторов имел бы git, будь он написан на хаскелле, а?), само по себе использование хорошего яп не дает ничего. Что мы очень явно видим на примере darcs vs. git. Хороший дизайн + плохой яп всегда победят плохой дизайн + хороший яп.
Здравствуйте, novitk, Вы писали:
BZ>>jkff и thesz же работают в коммерческих компаниях, и применяют хаскел для зарабатывания денег
N>Да, но у меня кроме их слов ничего нет, а их слова это слова фанатов.
и никогда не будет — ты же всех, голосующих ха хаскел, в его фанатики заносишь
N>>>а готов ли ты вложить значительные ресурсы в разработку на Хаскеле? Посмотри на риски...
BZ>>насчёт меня смешно спрашивать — я как раз пятый год пишу freearc на хаскеле
N>Я говорю в контексте "индустиального программирования". К тебе приходит инвестор/заказчик, ставит задачу, и дает деньги и сроки. Тебе нужно собрать команду и выбрать инструмент для решения. Для предметной области опыта успешного применения Хаскеля не было. В этих условиях ты реально поставишь на Хаскель или возьмешь гибрид?
я возьму деньги и сбегу в южную америку. уложусь в 10 минут поскольку я совсем не менеджер и у меня стоят совсем иные задачи, я бы даже сказал прямо противоположные
при разработке своей программы я определил, какие её части на чём лучше писать:
C++ — там, где требуется скорость
C# — для интерфейса с существующими экосистемами, в частности GUI
хаскел — для остального
вот исходя из этого я бы определял, стоит ли использовать хаскел в проекте. плюс затраты на обучение ему
BZ>>что касается вообще, то процесс внедрения новых технологий вроде не хаскел-специфичен, стоит ли 120-й раз повторять чужие слова?
N>"хаскел специфичен" тем, что его плавно не внедрить. Питон можно, Скалу можно, а Хаскель нельзя. А еще команду не собрать — число "гениев" на квадрат площади очень маленький
насчёт "гениев" я не согласен — имхо, он доступен любому профессионалу. кому недоступен — те не профессионалы
постепенное внедрение скалы вместо явы я ещё могу представить — это чуть ли не строгое надмножество. а вот насчёт питона как — другие библиотеки, другие подходы к написанию надёжного кода. имхо это вполне сравнимо с переходом на хаскел, для которого достаточно усвоить, что функции не могут вызывать процедуры
BZ>>в подписи как раз вполне success story (на killer app она не тянет ввиду малопопулярности архиваторов вообще). кратко — это аналог rar/7-zip, разработанный в несколько раз быстрее. конкретно, я сравнивал 7-zip и fa, когда набор их фич примерно совпадал — размеры моих исходников были втрое меньше
N>Ты меня извини, но в оценке "качества и функционала" ты обьективным быть не можешь, как автор. FreeАrc по "качеству и функционалу" с 7zip/rar-у сравнить нельзя по причине низкого использования, а значит размер исходников сравнивать смысла пока нет.
по функционалу они были сравнимы, и в этом несложно убедиться, почитав доки или хотя бы заглянув на homepages с описаниями фич. по надёжности freearc далеко отстаёт, но на размере кода это не так уж сказывается
BZ>>как языки они находятся где-то посредине между c++ и хаскелом. а вот внешняя среда у f# к 2010-му году будет несравненно лучше, чем у хаскела
N>С "посередине" не согласен. Большинство вкусностей приводящие к улучшению кода в них доступны. Хаскель лучше из за чистоты и системы типов, но это все не бесплатно. Теоритические аргументы thesz-а убедить, что цена маленькая или ее вообще нет, мне понятны, но без примеров остаются теорией.
ок, это надо пробовать. не хватает ленивости, карринга, глобального вывода типов, type classes, многих чисто синтаксических удобств хаскела. там для лямбд тип автоматом выводится или как?
N>>>Буду рад, хотя мне нужна открытая платформа, поэтому я хочу что-нибудь Scala-подобное...
BZ>>scala и f# — это всё же две большие разницы: ооп+фп и фп+ооп. имей в виду, что это не одно и то же
N>Почему это принципиально? Ментально? На скале вполне можно писать без слова class. Очень похоже на Питон, который я использую в основном функционально без всякого дискомфорта.
есть разница между ооп языком, на который позже навешивают отдельные ФП фичи, которые влезли в эту паражигму, и обратным вариантом. скажем, HM type inference в f# есть, а в скале как я понимаю нету?
когда у тебя основная функциональность библиотек реализована предоставлением методов класса — это диктует совсем иные подходы, нежели когда ты имеешь голые функции
и не стоит рассчитывать, что комбинированный фп+ооп язык предоставит нам все преимущества того и другого. может оказаться наоборот т.е. при добавлении фп фич в ооп язык мы получаем меньшее увеличение функциональности чем от этих фич в чистом виде (потому что добавляются только те возможности, которые не предоставляет чистый ооп), но куда большее увеличение сложности (поскольку надо ещё описать взаимодействие этих двух монстров. хороший пример — ко/контра-вариантные типы, которые возникают только в гибридных языках)
в этом плане чистый ооп или чистый фп язык может иметь лучшее соотношение сложность/полезность. ну а если учесть, что по показателю сложность хаскел превосходит скалу с f#, то получается, что мы сравниваем результаты 20-летнего развития чистого ФП языка с результатами 10-летней эпопеи по скрещиванию ужа и ежа. нет сомнений, базовые ФП фичи (на уровне классического ML) скала успешно впитала, но это состояние ФП 30-летней примерно давности. хаскел-то уже на старте был мощней
в качестве промежуточного шага применение гиборидных языков неизбежно. таким же образом происходил переход к ООП — индустрия проигнорировала прогрессивные ObjC и Eiffel, и выбрала язык постепенного перехода. потом пообвыклась и уже смело перешла на яву. я здесь ожидаю такого же перехода, только думаю, что он произойдёт быстрей, и командовать парадом будет MS. пока на то похоже
Здравствуйте, Аноним, Вы писали:
А>Если скрестить cherry-picking и коммутативность патчей, то открываются новые возможности. А>Поэтому не надо тупо гуглить, почитайте туториал и оцените сами.
Меня не настолько интересует "алгебра пэтчей", чтобы читать по ней туториал. Я просто привел, что похожий функционал есть в Hg. Говорить об архиважности этой фичи для пользователя в виду практической невостребованости darcs по причине общей слабости функционала, надежности и скорости по сравнению с hg/git в последнее время смешно. Конь экологичней автомобиля и сложнее, вот только не нужен он больше никому.
А>По поводу того, что алгебру патчей можно реализовать на любом языке. С этим глупо спорить, однако небольшая ремарка. А>Первая версия darcs была написана на c++. К сожалению, она не работала. Совсем. А>Вторая версия была написана на хаскеле. И она заработала. Сразу. А>("Заработала" -- имеется в виду алгебра патчей).
Это говорит лишь о неумение автора пользоваться C++, что для теор. физика вполне нормально.
Здравствуйте, novitk, Вы писали:
BZ>>по моему приватному мнению, по времени разработки сложных алгоритмов, хаскел превосходит С++ на порядок, C#/Java раза в три, а гибридные языки — раза в 1.5-2
N>Боюсь местные хаскелеводы не согласятся Сам с оценкой согласен, но если это так, то боюсь мне (практику!) оно не надо...
Если бы вместо C++ стоял Си можно было бы согласится. C C++ все сложнее, он может быть как на уровне с Си а может и выше чем Java.
N>По причине, что этого не достаточно чтобы оправдать все остальные расходы — слабую библиотеку, необходимость интеропа и т.д.
У Ocaml'а более слабая библиотека чем у Хаскеля, интероп гораздо более сложный, и популярность его ниже, и он моложе. Но программ на нем написано больше.
Здравствуйте, eao197, Вы писали:
E>Трудноиспользуемой ООП не была. ООП я начал использовать на втором курсе универа,
Думаю, что начни вы использовать ФП на втором курсе универа, трудноиспользуемым ФП вы также не назвали бы.
E>Причем я тогда даже не знал, что это ООП.
Вот в этом и заключается секрет успеха. Программисты на C# 3, например, в настоящее время широко используют монады и, в массе своей, не подозревают об этом. Однако же, когда тьюториалы по монадам с примерами на C# в блогах перестанут быть еденичными явлениями, а станут массовыми — все они осознают каким сложным делом они все это время занимались и случится катастрофа.
... << RSDN@Home 1.2.0 alpha 4 rev. 1110>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, pgregory, Вы писали:
P>Неужели не очевидно, что весь разговор именно об этом?! Программисты, например, в большинстве своем (нет, лично я не измерял) не знают, что целые числа образуют коммутативное кольцо с единицей (а также абелеву группу по ... и еще ... и еще ...). И это не мешает им писать программы, и делать это хорошо.
а для программирования на хаскеле необходимо знать теорию категорий?
Здравствуйте, Klapaucius, Вы писали:
K>Кроме того, это противоречит вашим идеям — Схема значительно проще Питона — и для программирования и с точки зрения реализации интерпретатора.
С первым не согласен. Continuations — это жесть, по аналогии с монадами. Мне это не нравится.
P>>И это не мешает им писать программы, и делать это хорошо.
K>А вот это совсем не очевидно. А доказать вы это совершенно точно не сможете.
Думаю, при желании все-таки смогу. Мне, честно говоря, лень. Поэтому будем считать, что не смогу. Я в это просто верю.
K>С другой стороны дискретная математика включена в программу подготовки программистов не просто так. Хотя в таких пределах алгебру изучают вообще все инженеры.
И это очень хорошо.
P>>За простыми вещами должны следовать сложные, но не наоборот. Don't pay for what you don't need. Make simple things easy, but hard things possible. И так далее. Что здесь не ясно???
K>Мне не ясна ваша методика определения сложности. K>Кроме того, мне не ясно — вы предъявляете претензии к языку или к структуре образовательных курсов по этому языку? K>Ну, допустим GITH вашим требованиям не соотвествуют — а YAHT и RWH — вполне.
Я предъявляю претензию к языку. Потому, что он заставляет меня знать, что такое монада. Мне это не нравится. Заметьте, хаскель не заставляет знать, что такое коммутативное кольцо, чтобы оперировать числами. Напротив, все учебники начинаются в стиле «Смотрите, хаскель это так просто — пишем 1 + 1, а он нам пишет 2!» Только когда речь заходит об определенных (простых!) вещах, эта простота вдруг испаряется. Я об этом.
Не знаю, почему, но то, что мне не нравятся сложные языки программирования, некоторые пытаются списать на мою ограниченность, нежелание изучать ничего нового и черт знает что еще. Надеюсь, они все же не правы. Простота (и красота) — основа всего окружающего мира. И поэтому я верю, что реально хороший язык реально прост. В хаскеле куча интересных концепций, и когда для них будет найдена простая до очевидности интерпретация, они тут же промаршируют в мейнстрим. И я буду этому очень рад.
Здравствуйте, lomeo, Вы писали:
L>Вот ты можешь объяснить, почему монада в Хаскеле — это сложно, а ООП в Питоне — просто? Это возвращение к дискуссии о том, что сложность в обучении и использовании — разные вещи.
Есть такая вещь как порог вхождения. Если для того чтобы просто начать писать даже что-то простое и легкое нужно сильно напрягать мозги, то мало кто это будет делать, независимо от того насколько сложен или прост язык в целом. Например у того же питона этот порог очень низок, хотя в нем есть и реально сложные вещи, но можно спокойно писать не подозревая о них. Другой пример рефал и Smalltalk, оба по сути очень просты, но начальный порог который нужно преодолеть достаточно высок и поэтому они малопопулярны. У Хаскеля этот порог еще выше.
Здравствуйте, pgregory, Вы писали:
P>Или ты не разделяешь мое мнение, что «коммутативное кольцо с единицей» — на пару порядков более сложное понятие, чем «целое число»?
Наверное потому, что оно более общее?
У меня есть знакомый, который вполне так искренне спрашивает, а зачем какие-то объекты? Он данные через функции гоняет и всё нормально. Человек без опыта.
Чтобы ему понять, зачем ему нужно ООП, надо будет втирать про полиморфизм и наследование. А так совершенно неясно ведь, чем some_foo(x) хуже x.foo().
Кстати, как на пальцах наследование с полиморфизмом рассказать?
Либо у меня не такие знакомые, но я не видел интуитивного понимания ООП, просто это то, чему сейчас учат всех. Если ты про то ООП, где ящики сообщениями обмениваются, то тут ещё сложнее объяснить, зачем оно вообще всё нужно.
Здравствуйте, pgregory, Вы писали:
P>Или ты реально считаешь, что FP так же интуитивно, как и ООП? (Чувствую, как люди с горящими глазами бросились писать «Да! Да! Да!!!»
P>Если так, то что же, я с этим не согласен. Если не очевидно, почему, могу попытаться обосновать.
Здравствуйте, thesz, Вы писали:
T>>>Популярность git определяется Линусом Торвальдсом и ничем другим. P>>Чушь. T>За три месяца его бы не подхватило такое количество народу, не будь он написан Линусом.
Его подхватили, так как его использование в разработке Линукса _автоматически_ означает, что git имеет достаточно неплохой уровень.
На момент создания git'а не было _никаких_ равных ему по скорости систем контроля версий. Т.е. СОВСЕМ никаких, даже Mercurial тогда не мог работать достаточно быстро. Ну и хвалёная алгебра патчей с экспоненциально-тормозным алгоритмом merge'а на практике не особо лучше git'овского merge'а, который just works.
А использование sha-1 указателей для адресации контента и отслеживание изменений между файлами — так это вообще был гениальный штрих в git'е.
T>А если кто-то, кроме Линуса, написал бы такое на простых Сях, как написан git, то его бы съели без разделки тушки. T>Популярность git и его язык реализации определяется популярностью Линуса Торвальдса и ничем больше.
А ещё тем, что git работает.
T>"Практические по всем" параметрам, как я понимаю, включает в себя и разнообразные возможности. T>Cherry picking, anyone?
Какие проблемы? http://www.kernel.org/pub/software/scm/git/docs/git-cherry-pick.html
T>http://darcs.net/ — багтрекер есть T>http://git-scm.com/ — багтрекера нет. T>Почему так, я не знаю. Но быстро сравнить серьёзность и количество открытых ошибок я не могу.
У них работа идёт в mailing list'ах, так как Линус ненавидит Багзиллу в частности и багтрекеры вообще. http://marc.info/?l=git&w=2&r=1&s=unresolved+issues&q=b — как пример http://marc.info/?l=git&m=120580287718636&w=2
Здравствуйте, thesz, Вы писали:
T>Обсуждаемый вопрос: на Хаскеле обязательно получится плохо, много хуже, чем у других.
Э! Не передергивай! Обсуждается совсем не это. Обсуждается то, что в теории хаскель просто распрекрасен и на голову выше большинства, но на практике мы этого не видим. (Я не утверждаю, что не существует успешных проектов на хаскеле, нет, или областей, где его особенности очень удобны. Я о другом — о том, что (мне) не видно связи между хорошестью хаскеля и хорошестью софта на нем).
Черт побери, если эта связь есть — неужели она загадочна и необъяснима на человеческом языке (и реальных примерах)?
Сотый раз: если это не так — примеры в студию! Только не какие-нибудь упрощалки символьных вычислений. Я слишком глуп для этого, ты же понимаешь. Да и еще, не дай бог, скажу, что там Mathematica куда лучше справляется (зачеркнуто :-). Даже реально хороший музыкальный плейер меня вполне устроит. Или они _все_ покрыты мраком строжайшего секрета и коммерческой тайны?
P>Мне интересно, зачем же ты теряешь на меня время? Пойми, если я сказал глупость, другие это заметят и без твоей помощи.
Глупость должна быть разъяснена.
Я преследую две цели: чтобы никто не купился на глупость впредь, это первое. Тогда она будет меньше меня беспокоить. И вторая цель, не менее важная: активный оппонент, будучи переубежден, начинает работать на тебя.
Переубеждать у меня не очень получается, я срываюсь, но иногда мне это удаётся. Этим случаям я рад больше всего.
P>Не напрягайся так. К чему дурацкие фразы типа T>>Тут не сказали, падают ли другие системы. Пока я ответа не получил. P>Он не очевиден? Тебе что, факс прислать, где написано «смирись, джедай, darcs хуже git»?
Будь добр, ответить на простой вопрос: почему система на Хаскеле, проакчивающая мегабайт в секунду, с нетривиаьлным обновлением базы в 10-100 МБайт, будет работать значительно хуже, чем на других языках?
Собственно, ответ "падают ли другие (, отличные от darcs распределённые) системы (контроля версий) в тех же условиях" означал бы положительный ответ.
"В тех же условиях", в данном контексте — с попыткой вычислить патч, разность между репозиториями. А то знаем мы эти ваши subversion, заменят двоичный файл целиком и скажут, что так и было.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, pgregory, Вы писали: P>С первым не согласен. Continuations — это жесть, по аналогии с монадами. Мне это не нравится.
А тут-то что сложного? Всего лишь побочный эффект cps.
P>Не знаю, почему, но то, что мне не нравятся сложные языки программирования
Такое ощущение, что Вы готовы признать сложным все, выходящее за рамки сегодняшнего мейнстрима. Потому как Ваших критериев сложности яп я пока не понимаю.
Здравствуйте, EvilChild, Вы писали:
E>>Очень мощно утверждать, что C++ "самый слабый ОО язык". Из более-менее мейнстримовых языков множественное наследование для классов поддерживается только в C++ и Eiffel. EC>А как множественное наследование классов связано с ОО? EC>Нследование ортогонально ОО, множественное в особенности.
Если под ОО рассматривать тройку из наследования, инкапсуляции и полиморфизма, то самым непосредственным. И, если нельзя унаследоваться сразу от нескольких классов, то это как раз ограничение для ОО.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, EvilChild, Вы писали:
EC>>>Наследование ортогонально ОО, множественное в особенности.
E>>Если под ОО рассматривать тройку из наследования, инкапсуляции и полиморфизма, то самым непосредственным. И, если нельзя унаследоваться сразу от нескольких классов, то это как раз ограничение для ОО. EC>Смотри выделенное жирным.
Имхо, рассуждения об ОО без наследования лишены смысла.
EC>Наследование — это артефакт реализации ОО в конкретных языках.
Такая точка зрения, возможно, имеет право на жизнь. Но мне она не интересна. Для меня ОО это: наследования, инкапсуляции и полиморфизма. Все остальное теоритические изыски.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, z00n, Вы писали:
Z>Но наличие RAII в С++ сделали невозможным GC в стандарте С++ даже опционально.
Очень и очень неоднозначное утверждение. В D есть и RAII, и сборка мусора. Так что не похоже, что в отсутствии GC в C++ виноват RAII. Куда больше в этом виноваты голые указатели, адресная арифметика и неконтролируемые приведения типов.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, z00n, Вы писали: Z>Я тоже поясню. RAII есть абсолютно в любом языке с первокласными функциями — как правило в таких языках есть еще и сборка мусора.
Ты про что?
RAII — это Resource Acquisition Is Initialization (Получение ресурса есть инициализация)
При чём здесь первокласные функции?
Z>Но наличие RAII в С++ сделали невозможным GC в стандарте С++ даже опционально. Потому, что думать нужно рано
Сможешь разяснить каким боком RAII мешает?
Мне почему-то всегда казалось, что сборке мусора мешают адресная арихметика и касты.
Здравствуйте, z00n, Вы писали:
Z>>>Но наличие RAII в С++ сделали невозможным GC в стандарте С++ даже опционально.
E>>Очень и очень неоднозначное утверждение. В D есть и RAII, и сборка мусора. Так что не похоже, что в отсутствии GC в C++ виноват RAII. Куда больше в этом виноваты голые указатели, адресная арифметика и неконтролируемые приведения типов. Z>Главная проблема — деструкторы и то как их принято использовать в С++. Z>Страуструп говорит почему это сложно: Z>http://www.devx.com/SpecialReports/Article/38813/0/page/4
Беглый просмотр не дал ответа. RAII -- это механизм для временного владения ресурсами, время владения определяется областью видимости RAII переменной (о чем Страуструп говорит "We have RAII (for scoped resource use)"). В том же C# аналогичный эффект достигается с помощью using и IDisposable. В D есть специальные scope-классы, специально предназначенные для реализации RAII.
Другое дело, что GC при сборке мусора не будет звать деструкторы. Что не позволит освобождать ресурсы, время жизни которых превышают область видимости некоторого фрагмента (о чем Страуструп говорит "smart pointers" (for resources that don't have their lifetimes determined by a simple scope)"). Но это уже несколько другая песня. К RAII, имхо, имеющая лишь отдаленное отношение.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Tonal-, Вы писали:
T>Это не RAII. В haskell-е нет аналога деструкторов, так что RAII там быть не может.
RAII — это С++ название для устоичивого к исключениям scope-based resource management'а. Появилось это в лиспе, давно, лет 30 назад.
Stroustrup — придумал как повторить это в С++ с помощью хака с деструкторами и воспомогательными обектами. Но деструкторы для этого не нужны.
Я знаю что хаскель и развивается быстрее и библиотеки у него богаче, поэтому и удивительно что выхлопа
в виде приложений меньше.
FR>>Вывод по моему явно притянутый.
T>Сделай другой. Проведи исследования.
T>Чего всё я?
Тык ты у нас евангилист тебе и плясать
Я тут когда с питоном носился немало поплясал
T>>>Это может быть полезным везде, где хотелось бы проверять структуру вычислений во время компиляции. T>>>Если ты придумал, как тест заменить на тип (и сократить код), то смотри в эту сторону. FR>>Для меня пока это очень спорно и неоднозначно. Я предполагаю что система типов все-равно не сможет FR>>полностью заменить тестирование, также вообще сомневаюсь что это необходимо.
T>С "я предполагаю" очень трудно спорить.
T>Ты предполагаешь так почему конкретно?
В общем чисто субъективное мнение, подкрепленное только своим опытом и последними достижениями математики http://elementy.ru/lib/430319
Иными словами, при любом конечном наборе аксиом мы имеем бесконечное число истин, которые не могут быть доказаны с помощью этого набора.
T>>>Надо говорить об одном программисте. У него колебания около порядка в природе не наблюдаются (PSP/TSP). FR>>Как же не наблюдаются, очень даже наблюдаются, прямо сейчас и у меня лично
T>Тебя надо наблюдать со стороны и на протяжении всего проекта. Нескольких проектов.
T>Минутные слабости компенсируются часовыми мощностями.
Это да, но опыт тоже накапливается
T>Про небольшие проекты мы ничего не знаем — кто что внутреннее пишет.
T>А, похоже, пишут, возвращаясь к теме слешдота.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>соответственно, если добавить GC в С++, то legacy код будет несовместим с ним, поскольку в нём просто отсутствует разделение дестурукторов на освобождение ресурсов и освобождение памяти. т.е. несмотря на GC дестуруркторы всё равно придётся вызывать детерминированно для освобождения ресурсов
Не вижу больших препятствий к тому, чтобы вызывать деструкторы в C++ для тех объектов, которые GC посчитал мусором. Ведь вопрос упирается во что -- без GC утекает память и ресурсы для тех объектов, для которых сейчас пользователь явно не вызвал delete. Добавляется GC с вызовом деструкторов и оказывается, что и память больше не течет, и ресурсы освобождаются. Да, пусть не сразу, пусть через час. Но освобождаются. Это гораздо лучше, чем в случае теперешних утечек.
А если пользователь хочет гарантированно иметь освобождение ресурсов -- пусть и дальше вызывает delete явно. Как это есть сейчас. Так что для нормальных C++ программ вообще ничего не изменится. А у не очень нормальных появится шанс работать стабильнее.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
BZ>>соответственно, если добавить GC в С++, то legacy код будет несовместим с ним, поскольку в нём просто отсутствует разделение дестурукторов на освобождение ресурсов и освобождение памяти. т.е. несмотря на GC дестуруркторы всё равно придётся вызывать детерминированно для освобождения ресурсов
E>Не вижу больших препятствий к тому, чтобы вызывать деструкторы в C++ для тех объектов, которые GC посчитал мусором. Ведь вопрос упирается во что -- без GC утекает память и ресурсы для тех объектов, для которых сейчас пользователь явно не вызвал delete. Добавляется GC с вызовом деструкторов и оказывается, что и память больше не течет, и ресурсы освобождаются. Да, пусть не сразу, пусть через час. Но освобождаются. Это гораздо лучше, чем в случае теперешних утечек.
E>А если пользователь хочет гарантированно иметь освобождение ресурсов -- пусть и дальше вызывает delete явно. Как это есть сейчас. Так что для нормальных C++ программ вообще ничего не изменится. А у не очень нормальных появится шанс работать стабильнее.
ты полагаешь, что GC — это фича для того, чтобы сделать менее заметными баги? и корректные c++ программы им пользщоваться всё равно не должны, даже если он появится? тогда нафига он нужен — рассуждают авторы языка
вообще, сколько можно разжёвывать простейшие вещи. такое впечатление, что вы даже не пытаетесь понять, о чём идёт речь, прдепочитая 100 раз повторять одно и то же, чтобы оставить за собой "поле боя"
Здравствуйте, pgregory, Вы писали:
P>В моем примере подразумевалась необходимость связки типа -XNoMonomorphismRestriction + import Control.Monad + liftM для превращения одного в другое. Если нужда в этой связке -- лишь плод моего воображения, я признаю, что неправ. Иначе вы признаете, что я прав.
P>Идет?
Было сказано: do { a <- foo; return foo} то же самое, что и foo.
Напиши такое монадическое значение foo, для которого нельзя заменить do {...} на foo.
Тогда я признаю, что ты прав.
Очевидно, что для монады это сделать невозможно. Иначе это будет не монада. Игры же с типами совершенно несерьёзны и показывают, что ты не понимаешь, о чём говорил твой оппонент. В частности, в твоём определении f2 надо писать let f2 (x :: Monad m => m a) = x.
Здравствуйте, thesz, Вы писали: T>>>За счёт чего это? Те же конструкторы, те же деструкторы, то же непредсказуемое время из-за перегрузки. T>C++ не даёт создавать свои операторы, поэтому все перегружают уже существующие. T>Получается, что a << b может означать и сдвиг, и вывод в файл. T>Без профайлера и ассемблерного листинга не разобраться, Одного code review не достаточно.
Это у вас какой-то неправильный мёд! Его наверное готовят неправильные пчёлы.
Никакой неоднозначности нет. Зная типы a и b знаешь всё.
Профайлеров и листинов ассемблера не нужно.
Все затраты времени в языке детерминированы и могут быть учтены кроме внешних вызовов.
Чего не наблюдается в haskell-е, ну дык он вроде не для того.
Здравствуйте, BulatZiganshin, Вы писали: BZ>[и тут выхожу я — весь в белом ] E>>Я тоже программирован на Java после плюсов. Впечатления двойственные. С одной стороны, ловил себя на мыслях, что пишу многословный тупой код. Там, где на C++ можно было обойтись шаблонами или указателями на функции/методы, в Java нужно было делать интерфейсы, классы-наследники и пр. лабуду (правда я пользовался Java еще до введения в нее generic-ов). Зато в Java не нужно было думать об освобождении памяти. И никогда не было моментов, когда бы я не понимал где программа сломалась. Stack trace -- великая сила! А в C++ скомпилированная в релизе программа ломается через три недели непрерывной работы -- и все. Сиди и думай, где, как и почему, никаких следов. BZ>а теперь отгадаем с одного раза — какой язык сочетает преимущества их обоих?
Delphi конечно!
И писать дохрена, и за памятью самому следить без RAII, и падает без каких-либо вменяемых сообщений!
Зато можно делать asm вставки прямо в коде.
Само то для настоящего джидая не брезгующего большим объёмом работ.
Начал читать дальше и обнаружил упоминание об алгебраических типах данных.
Кстати, AFAIK, они были разработаны в 1969 году Тедом Бурсталлом, совсем недалеко по времени от разработки Algol-W, о котором шла речь. Также постарался и отец Коннора МакБрайда, одного из создателей Эпиграмма.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>Обсуждение на слешдоте "Нулевой ссылки: ошибки на миллион долларов".
T>В одном это обсуждении Хаскель встречается два раза и дважды же встречается термин "монада". И упоминание о Maybe тоже.
T>Причём один комментарий в стиле "я использовал Maybe потому, что надёжно, а теперь ещё и монады изучил, и получается коротко. мои волосы мягкие и шелковистые".
T>Из моих знаний про аудиторию слешдота я делаю вывод, что Хаскель уже давно в массах.
Честно говоря, не очень понятно, по какому поводу радость? Ну обсуждают, ну знают, и что? Зачем постить ссылку на каждое такое обсуждение?
N>С словом "мэйнстрим" не согласен. Сам при выборе инструментов использую следующую четырех-уровневую систему: N>1) Бангалор: Ява, С#, PHP N>2) Слэшдот-продакшен: Питон, Руби, C++, Перл, Лисп,... N>3) Слэшдот-песочница: Скала, Хаскелл, F#,... N>4) Академка: Epigram и прочая LTU
N>Переход из 4) в 3) Хаскель не может не радовать, но "мэйнстрим" это все же 1) и 2)
Нененене, Дэвид Блейн!
Нам Бангалор не нужен, это раз.
Два состоит в том, что люди какие-то программы на Хаскеле пишут. Воюют с монадами и Maybe. Ценно. Уровень "индустриальности" этих программ нам неизвестен, да ну и что.
Ценнее всего сам факт, что монады и Maybe появляются в отвлеченном разговоре сами по себе и их поднимают модераторы.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, E.V.E, Вы писали: EVE>Есть такой вопрос: почему Lisp считается продакшн
Скорее всего потому, что на CL работает немало проприетарных (легаси?)решений (иначе бы монстры, типа franz.com давно бы загнулись), просто со стороны, например мне, сложно оценить масштаб.
T>>Ценнее всего сам факт, что монады и Maybe появляются в отвлеченном разговоре сами по себе и их поднимают модераторы. N>С точки зрения обшей "культуры" — да, ценно, но я практик-эгоист. ИМХО монады монадами, но пока чистому ФП до "майнстрима", как до луны. Да и бог с ним, пусть хоть нормальный гибрид наконец выплывет на поверхность. Надоело, блин, в каменном веке сидеть!
Вот и весь практик-эгоист. Вместо того, чтобы пользоваться уже готовым, сидит и поёт арию князя Игоря "Ни сна, ни отдыха измученной душе": "ах дайте, дайте хотя бы гибрид, мне надоело в веке каменном жить!"
Эгоист виден. Практик — нет.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>Эгоист виден. Практик — нет.
Я практик не в гаражном стартапе, а в крупном бизнесе и социальные факторы игнорировать не могу.
И даже если смотреть только на технологию, в Хаскеле куча тонких мест (ленивость, монады, отсутствие отладчика, etc), которые не добавляют мне уверености, что процесс разработки улучшится в моей конкретной команде. Конечно, можно закрыть глаза и броситься "грудью на дзот", "трудности нам не страшны!", и ждать просветления, но хотелось бы иметь пару примеров "успешных подвигов". Где они? Был Darcs, но git и Mercurial, начавшие гораздо позже, просто убивают его функционалом и скоростью.
T>>Эгоист виден. Практик — нет. N>Я практик не в гаражном стартапе, а в крупном бизнесе и социальные факторы игнорировать не могу.
Эту фразу я вижу чаще всего.
Крупный бизнес состоит из кучи маленьких — подразделения, отделы и тп. Поэтому ты работаешь, на самом деле, в гаражном стартапе.
N>И даже если смотреть только на технологию, в Хаскеле куча тонких мест (ленивость, монады, отсутствие отладчика, etc), которые не добавляют мне уверености, что процесс разработки улучшится в моей конкретной команде.
Если смотреть только на технологии чуть-чуть пристальней, то в Хаскеле куча полезных мест (ленивость монады, отсутствие отладчика, etc), которые способствуют улучшению процесса разработки.
Разверну.
Ленивость стимулирует модульность (famous 'map f . map g === map (f . g)' example).
Монады стимулируют модульность. Но уже с другой стороны — написанным на комбинаторах вещам легко поменять реализацию комбинаторов, даже во время выполнения. Здесь — разбор, а здесь — подсветка.
Отсутствие отладчика стимулирует написание программ, о которых легко рассуждать и не нужно отлаживать.
N>Конечно, можно закрыть глаза и броситься "грудью на дзот", "трудности нам не страшны!", и ждать просветления, но хотелось бы иметь пару примеров "успешных подвигов".
"Другой смолчал, и стал пред ним ходить"
Я уже на втором месте работы их совершаю.
Другие их совершают: awson, vshabanov.
"Практиков" "на деле", а не на словах, на RSDN хватает.
Правда, не могу не отметить, что петь оперу князя Игоря гораздо проще. Я и сам грешен.
N>Где они? Был Darcs, но git и Mercurial, начавшие гораздо позже, просто убивают его функционалом и скоростью.
darcs2 и сейчас есть. "Просто убивают" это преувеличение, я думаю.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
N>>Я практик не в гаражном стартапе, а в крупном бизнесе и социальные факторы игнорировать не могу.
Евгений Кирпичёв работает в яндексе афаик
а вообще, недостатки есть у каждого языка. сложности с отладкой/оптимизацией у маинстримных языков имхо выше. а вот "поддержка индустрии", т.е. наличие обученных людей/библиотек — она разумеется пропорциональна популярности языка
ps: я лично полагаю, что f# станет переходным вариантом и хаскел пойдёт в индустрию во второй половине 2010-х
Здравствуйте, BulatZiganshin, Вы писали:
BZ>Евгений Кирпичёв работает в яндексе афаик
Вопрос не в том где кто работает (SPJ, например, работает в MS), а готов ли ты вложить значительные ресурсы в разработку на Хаскеле? Посмотри на риски...
Как быть с тем, что тебя с Зефировым мне не нанять, а если и нанять, то предметную область вы не знаете? Как быть с тем, что моей команде надо мозги кипятить полгода миниум, что бы просто овладеть всеми этими deforestation и zipper? А предметная область не компилятор, где есть хоть какой-то опыт, а числодробилка, где все существующие алгоритмы мутабельные? Добавь, что все это происходит в коммерческой компании, а не в "универе", и заказчики стоят над душой "неподетски"?
Это все громадные риски, на которые можно пойти только если реально видеть свет в конце туннеля. Извини, но я его не вижу. Где "killer app", где "success stories"? И это при том, что среда (GHC) уже давно на вполне индустриальном уровне.
Вот ты можешь честно сказать сейчас, что Хаскель дал бы реальный выигрыш при реализации FreeArc-а по сравнению с F# или Scala?
BZ>ps: я лично полагаю, что f# станет переходным вариантом и хаскел пойдёт в индустрию во второй половине 2010-х
Буду рад, хотя мне нужна открытая платформа, поэтому я хочу что-нибудь Scala-подобное...
Здравствуйте, thesz, Вы писали:
N>>Где они? Был Darcs, но git и Mercurial, начавшие гораздо позже, просто убивают его функционалом и скоростью. T>darcs2 и сейчас есть. "Просто убивают" это преувеличение, я думаю.
Нет.
T>>>Эгоист виден. Практик — нет. N>>Я практик не в гаражном стартапе, а в крупном бизнесе и социальные факторы игнорировать не могу.
T>Эту фразу я вижу чаще всего.
T>Крупный бизнес состоит из кучи маленьких — подразделения, отделы и тп. Поэтому ты работаешь, на самом деле, в гаражном стартапе. ;)
Я думаю, novitk имеет в виду _нормальную_ компанию, где желают получить прибыль и не в отдаленном будущем. :)
А если каждый отдел это гаражный стартап то и вся организация — большой гаражный стартап без определенного будущего, рвущийся во все стороны и топчущийся при этом на месте.
N>>И даже если смотреть только на технологию, в Хаскеле куча тонких мест (ленивость, монады, отсутствие отладчика, etc), которые не добавляют мне уверености, что процесс разработки улучшится в моей конкретной команде.
T>Если смотреть только на технологии чуть-чуть пристальней, то в Хаскеле куча полезных мест (ленивость монады, отсутствие отладчика, etc), которые способствуют улучшению процесса разработки.
T>Разверну.
T>Ленивость стимулирует модульность (famous 'map f . map g === map (f . g)' example).
Ага, и взрывает потребление памяти там, где этого не ждешь. В проекте <1K lines может быть это и не проблема. А если <1M lines? :-) Не согласны? Приведите успешный контр-пример.
T>Отсутствие отладчика стимулирует написание программ, о которых легко рассуждать и не нужно отлаживать.
Ага.. Тогда ASM-наше все. Отсутствие абстракций заставляет ну просто адски задуматься а потом реализовать эти абстракции вручную, да еще и с дикой оптимизацией. :)
А еще, отсутствие приличного IDE заставляет 100 раз подумать, прежде чем написать хоть строчку кода. Вплоть до того, что строчка эта потом пишется на Scala или F#.
Еще есть масса полезностей:
1. невозможность использовать стандартные технологии передачи сообщений. Действительно, зачем JMS и AMQP если можно тупо текст гонять по сырому TCP?
2. Удивительные красоты самого языка вроде операторов (,,,,,,,,).
можно и продолжить, но сейчас времени нет.
В общем, Haskell может и подойдет для чего-то в production, но область приминимости стремится к нулю.
Здравствуйте, thesz, Вы писали:
T>Ленивость стимулирует модульность (famous 'map f . map g === map (f . g)' example).
А можно развернуть для чайников, о какой модульности здесь идет речь?
T>Отсутствие отладчика стимулирует написание программ, о которых легко рассуждать и не нужно отлаживать.
Прошу прощения за грубость, но это достойно войти в аналы вместе с вот этой
BZ>>Евгений Кирпичёв работает в яндексе афаик N>Вопрос не в том где кто работает (SPJ, например, работает в MS), а готов ли ты вложить значительные ресурсы в разработку на Хаскеле? Посмотри на риски... N>Как быть с тем, что тебя с Зефировым мне не нанять, а если и нанять, то предметную область вы не знаете? Как быть с тем, что моей команде надо мозги кипятить полгода миниум, что бы просто овладеть всеми этими deforestation и zipper? А предметная область не компилятор, где есть хоть какой-то опыт, а числодробилка, где все существующие алгоритмы мутабельные?
А чего ты здесь не спрашиваешь?
Узнать, как быть в какой-то ситуации, можно двумя способами: 1) попасть в неё самому, и 2) спросить у попадавших в неё.
"Попасть в ситуацию самому" ты не хочешь. Для этого надо начать использовать Хаскель.
Но ты, также, и не спрашиваешь, как бы с этим поступили бы опытные в Хаскеле/ФЯ люди.
Из чего следует неопровержимый вывод, что использовать Хаскель (ФЯ вообще) ты не хочешь.
(мутабельные числодробилки после переноса на ФЯ приобретают интересные возможности, кстати)
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
N>>>Где они? Был Darcs, но git и Mercurial, начавшие гораздо позже, просто убивают его функционалом и скоростью. T>>darcs2 и сейчас есть. "Просто убивают" это преувеличение, я думаю. C>Нет.
Разворачивай.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
N>>>>Где они? Был Darcs, но git и Mercurial, начавшие гораздо позже, просто убивают его функционалом и скоростью. T>>>darcs2 и сейчас есть. "Просто убивают" это преувеличение, я думаю. C>>Нет. T>Разворачивай.
Чего разворачивать? Я darcs2 пробовал где-то год назад, когда интерсовался Хаскеллом. Он работает на порядки медленнее git'а (впрочем, почти всё работает медленнее git'а).
T>>Эту фразу я вижу чаще всего. T>>Крупный бизнес состоит из кучи маленьких — подразделения, отделы и тп. Поэтому ты работаешь, на самом деле, в гаражном стартапе. RD>Я думаю, novitk имеет в виду _нормальную_ компанию, где желают получить прибыль и не в отдаленном будущем.
Fuck near-term profits.
RD>А если каждый отдел это гаражный стартап то и вся организация — большой гаражный стартап без определенного будущего, рвущийся во все стороны и топчущийся при этом на месте.
Отделы, обычно, независимы, иначе с ними не управится. Два зависимых отдела — это один большой отдел, а управлять без иерархии толпой более пяти человек невозможно.
T>>Ленивость стимулирует модульность (famous 'map f . map g === map (f . g)' example). RD>Ага, и взрывает потребление памяти там, где этого не ждешь. В проекте <1K lines может быть это и не проблема.
Все мои проекты >2K.
В переводе на C++ это в районе 6-20 KLOC. Бери 13KLOC, не ошибёшься.
RD>А если <1M lines? Не согласны? Приведите успешный контр-пример.
Побью на проекты <1K и успешно всё решу.
Как, собственно, и делают в Эрланге.
T>>Отсутствие отладчика стимулирует написание программ, о которых легко рассуждать и не нужно отлаживать. RD>Ага.. Тогда ASM-наше все. Отсутствие абстракций заставляет ну просто адски задуматься а потом реализовать эти абстракции вручную, да еще и с дикой оптимизацией. RD>А еще, отсутствие приличного IDE заставляет 100 раз подумать, прежде чем написать хоть строчку кода. Вплоть до того, что строчка эта потом пишется на Scala или F#.
(если честно, то от настолько детского аргумента я, было, решил нарушить своё вето на хамство и просто написать, что ты идиот. но я этого не написал, прошу высокое жюри учесть сей факт.)
Программы (серверные, клиентские) могут быть запущены под отладчиком только в разработке.
Отлаживать программу у клиента нет никакой возможности.
Поэтому либо ты пишешь программу с учётом этого — модульно и прозрачно, чтобы было видно, где ошибка, чтобы не было eeek ошибок — либо надо менять профессию.
А Хаскель даёт тебе возможности так писать. Referential transparency у него в основе дизайна. Система типов ловит очень много.
В отличии от Asm.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
T>>Ленивость стимулирует модульность (famous 'map f . map g === map (f . g)' example). E>А можно развернуть для чайников, о какой модульности здесь идет речь?
Отдельно написал генератор, отдельно написал обработчик. В промежутке поставил фильтры.
Всё работает так, как будто написано в одном модуле.
Особенно удобно писать переборные алгоритмы, например, Equality Saturation, про который было в моём блоге позавчера.
T>>Отсутствие отладчика стимулирует написание программ, о которых легко рассуждать и не нужно отлаживать. E>Прошу прощения за грубость, но это достойно войти в аналы вместе с вот этой
Я пишу программы, не пользуясь отладчиком. Это написанные программы, полезные не только мне.
Отладчиком сейчас приходится пользоваться для разбирательств с кодом на Java. Блин. Ощущения — не передать словами.
Да когда на железке гоняешь свой код, тоже особо отладчиком не попользуешься. Встроенных железок на порядки больше, чем обычных.
E>Вот Дональд Кнут, к примеру, считает отладчик очень важным инструментом программиста.
N>>>>>Где они? Был Darcs, но git и Mercurial, начавшие гораздо позже, просто убивают его функционалом и скоростью. T>>>>darcs2 и сейчас есть. "Просто убивают" это преувеличение, я думаю. C>>>Нет. T>>Разворачивай. C>Чего разворачивать? Я darcs2 пробовал где-то год назад, когда интерсовался Хаскеллом. Он работает на порядки медленнее git'а (впрочем, почти всё работает медленнее git'а).
Со скоростью разобрались.
Оказалось, что "darcs практически убивает по скорости" только git.
С функционалом?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
C>>Чего разворачивать? Я darcs2 пробовал где-то год назад, когда интерсовался Хаскеллом. Он работает на порядки медленнее git'а (впрочем, почти всё работает медленнее git'а). T>Со скоростью разобрались. T>Оказалось, что "darcs практически убивает по скорости" только git.
Mercurial тоже.
T>С функционалом?
У darcs — средненький функционал для современных dvcs.
C>>>Чего разворачивать? Я darcs2 пробовал где-то год назад, когда интерсовался Хаскеллом. Он работает на порядки медленнее git'а (впрочем, почти всё работает медленнее git'а). T>>Со скоростью разобрались. T>>Оказалось, что "darcs практически убивает по скорости" только git. C>Mercurial тоже.
T>>>>Ленивость стимулирует модульность (famous 'map f . map g === map (f . g)' example). E>>>А можно развернуть для чайников, о какой модульности здесь идет речь? T>>Отдельно написал генератор, отдельно написал обработчик. В промежутке поставил фильтры. T>>Всё работает так, как будто написано в одном модуле. E>Имхо, это достаточно специфическое отношение к модульности...
Это наивысшее проявление модульности на данный момент — не заботиться ни о каких мелких деталях реализации соседей.
T>>Особенно удобно писать переборные алгоритмы, например, Equality Saturation, про который было в моём блоге позавчера. E>...да еще и применительно к решению специфических задач.
Структурируй решения любых задач определённым образом, вот и будут получатся такие полезные вещи.
Это требует тренировки.
T>>Я пишу программы, не пользуясь отладчиком. Это написанные программы, полезные не только мне. E>Когда весь мейнстрим будет состоять из людей типа thesz, тогда можно будет рассматривать отладчики, как ухудшающий качество программ атавизм...
К чему я и стремлюсь.
Если от отладчика будет отказываться по одному человеку в месяц и каждый из них будет убеждать в этом по одному человеку в месяц... то, получается, за год от отладчика откажется (2^12)-1=4095 человек.
За 27 месяцев мы доберёмся и до индусов.
И это если начинать только с одного меня. Но нас, программистов-без-отладчика, больше, чем 1
уже сейчас.
T>>Да когда на железке гоняешь свой код, тоже особо отладчиком не попользуешься. Встроенных железок на порядки больше, чем обычных. E>...но поскольку людей, программирующих на обычных железяках, а не на встроенных, на порядки больше, то наличие качественных отладчиков для _очень_ многих разработчиков является чуть ли не самым серьезным помошником в получении работающих программ. И пока инструменты не будут расчитаны именно на таких разработчиков, попасть в мейнстрим им не светит.
"Неприятность эту мы переживём."
Кстати, отладчик в ghc есть.
Это всё неграмотность novik.
Однако, поднятая тема очень важна. Наличие отладчика [b]когда-то[/url] было важным для среды программирования. Его использовали самые продвинутые пользователи.
Сейчас продвинутые пользователи отказываются от отладчика. На все DS(E)L отладчики не напишешь.
Я думаю, отсутствие отладчика не критерий для умного программиста. А потом перестанет быть критерием и для остальных.
Посмотрим, насколько я окажусь прав.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
T>Все мои проекты >2K. T>В переводе на C++ это в районе 6-20 KLOC. Бери 13KLOC, не ошибёшься.
RD>>А если <1M lines? Не согласны? Приведите успешный контр-пример.
T>Побью на проекты <1K и успешно всё решу.
А все же, вы хотя бы когда-нибудь работали в команде, где объем кода будет ~1M lines C/C++/Java/что-то подобное или ~100K lines кода на Хаскеле? Причем своего кода, сторонние библиотеки не в счет?
Вообще-то ваша беспочвенная самоуверенность рискует стать легендой.
T>Как, собственно, и делают в Эрланге.
Крупные проекты делят на проекты поменьше не только в Эрланге да Хаскеле. Это вообще-то стандартная практика. Но далеко не все так легко делится. И даже после деления остаются зависимости.
T>>>Отсутствие отладчика стимулирует написание программ, о которых легко рассуждать и не нужно отлаживать. RD>>Ага.. Тогда ASM-наше все. Отсутствие абстракций заставляет ну просто адски задуматься а потом реализовать эти абстракции вручную, да еще и с дикой оптимизацией. RD>>А еще, отсутствие приличного IDE заставляет 100 раз подумать, прежде чем написать хоть строчку кода. Вплоть до того, что строчка эта потом пишется на Scala или F#.
T>(если честно, то от настолько детского аргумента я, было, решил нарушить своё вето на хамство и просто написать, что ты идиот. но я этого не написал, прошу высокое жюри учесть сей факт.) T>Программы (серверные, клиентские) могут быть запущены под отладчиком только в разработке. T>Отлаживать программу у клиента нет никакой возможности. T>Поэтому либо ты пишешь программу с учётом этого — модульно и прозрачно, чтобы было видно, где ошибка, чтобы не было eeek ошибок — либо надо менять профессию. T>А Хаскель даёт тебе возможности так писать. Referential transparency у него в основе дизайна. Система типов ловит очень много. T>В отличии от Asm.
Думаете, что откровение изложили для меня?
То, что на дебаггере далеко не выедешь я знал еще лет в 10. И про referential transparency Вы тоже не открыли мне тайны.
Про пример с LSE: может забацаете в своем маленьком гаражном стартапе exchange, что будет лучше того что у них? На Хаскелле, конечно. Тогда можно будет и обсудить, насколько более удачным вышло Ваше решение и почему именно на крутейшем Хаскелле писать софт лучше всего.
Если честно, то я тоже сдержался и не нахамил после вашей заяки про debuggerы.
Повторяю еще раз: отсутствие возможности не может являться преимуществом. Особенно, если это преимущество не может помешать.
Если Вам это не очевидно, то что ж... Не расстраивайтесь, быть может Вы — Гений. Надеюсь, высокое жюри учтет и сей факт.
Здравствуйте, VoidEx, Вы писали:
VE>Это какой-то новый сленг РСДН что ли? Ну третий раз молча вынести "аналы" я уже не могу. Анналы же, ёлки-палки! Аналы истории
Здравствуйте, Cyberax, Вы писали: C>У darcs — средненький функционал для современных dvcs.
А как в этом обсуждении вообще darcs выплыл? Мне всегда казалось, что его основной поинт в алгебре патчей, а не в суперфункциональности и даже не в том, что он написан на хаскеле.
VE>Ох как кстати! VE>Заранее уточню, что я не придерживаюсь ни одной из сторон.
VE>А теперь прошу уточнить: VE>1. Почему отсутствие возможности — не может являться преимуществом VE>2. Почему наличие дебаггера не может помешать (не пользоваться — это не вариант, так как рассматривается сферический программист в вакууме, который пользуется) VE>3. Докажите очевидность.
VE>Очень люблю слова "очевидно", они обычно скрывают то, что _кажется_ очевидным автору.
Если у Вас не команда, а сброд идиотов, то не надо высоких технологий чтобы случась беда. Они себе вилкой глаза выколят и привет.
Если же у Вас нормальные люди (а я наивно предполагал, что FP в основном пользуются именно такие), то они будут писать нормальный софт и дебаггер им не понадобится. Поэтому дебаггер (как и любая другая не критичная фича) не является в нормальной ситуации вредной.
Но поскольку в отличии от некоторых я не страдаю красноглазием, то могу предположить, что в каких-то экзотических условиях дебаггер может оказаться полезен даже в Хаскелле. Лично я, конечно, с такими случаями не сталкивался (и дай Бог, чтоб не столкнулся).
RD>>>А если <1M lines? Не согласны? Приведите успешный контр-пример. T>>Побью на проекты <1K и успешно всё решу. RD>А все же, вы хотя бы когда-нибудь работали в команде, где объем кода будет ~1M lines C/C++/Java/что-то подобное или ~100K lines кода на Хаскеле? Причем своего кода, сторонние библиотеки не в счет?
Да, работал.
RD>Вообще-то ваша беспочвенная самоуверенность рискует стать легендой.
Моя уверенность имеет под собой основания.
T>>Как, собственно, и делают в Эрланге. RD>Крупные проекты делят на проекты поменьше не только в Эрланге да Хаскеле. Это вообще-то стандартная практика. Но далеко не все так легко делится. И даже после деления остаются зависимости.
Ты не путай зависимости, возникающие на Java и зависимости, возникающие на ФЯ.
T>>А Хаскель даёт тебе возможности так писать. Referential transparency у него в основе дизайна. Система типов ловит очень много. T>>В отличии от Asm. RD>Думаете, что откровение изложили для меня? RD>То, что на дебаггере далеко не выедешь я знал еще лет в 10. И про referential transparency Вы тоже не открыли мне тайны.
Тогда в чём проблема?
RD>Про пример с LSE: может забацаете в своем маленьком гаражном стартапе exchange, что будет лучше того что у них? На Хаскелле, конечно. Тогда можно будет и обсудить, насколько более удачным вышло Ваше решение и почему именно на крутейшем Хаскелле писать софт лучше всего.
Ты, по-моему, не смог соотнести eeek в ссылке и eeek в тексте по ссылке.
Ничего про exchange я не говорил и писать его не собираюсь (пока не собираюсь).
RD>Если честно, то я тоже сдержался и не нахамил после вашей заяки про debuggerы.
Высокое жюри не сможет учесть этот факт. Он не был запротоколирован, в отличии от моего.
RD>Повторяю еще раз: отсутствие возможности не может являться преимуществом. Особенно, если это преимущество не может помешать. RD>Если Вам это не очевидно, то что ж... Не расстраивайтесь, быть может Вы — Гений. Надеюсь, высокое жюри учтет и сей факт.
Спасибо.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
MC>Здравствуйте, Cyberax, Вы писали: C>>У darcs — средненький функционал для современных dvcs. MC>А как в этом обсуждении вообще darcs выплыл? Мне всегда казалось, что его основной поинт в алгебре патчей, а не в суперфункциональности и даже не в том, что он написан на хаскеле.
Алгебра патчей даёт ему функциональность, которой нет у hg/git.
Здравствуйте, thesz, Вы писали: T>Однако, поднятая тема очень важна. Наличие отладчика [b]когда-то[/url] было важным для среды программирования. Его использовали самые продвинутые пользователи. T>Сейчас продвинутые пользователи отказываются от отладчика. На все DS(E)L отладчики не напишешь. T>Я думаю, отсутствие отладчика не критерий для умного программиста. А потом перестанет быть критерием и для остальных.
Отладка отладке (и отладчик отладчику) рознь. Я вот вполне обхожусь без брейкпоинтов и прохода по шагам в haskell и scheme. Но для той же scheme без возможности поглядеть результат развертки макроса бывает туго. Так что инструментарий должен быть адекватен языку.
Кстати, а с чего вообще было решено, что для haskell нет средств отладки? Определенное количество тулзеней отчетливо гуглится (например, hood).
VE>>Очень люблю слова "очевидно", они обычно скрывают то, что _кажется_ очевидным автору. RD>Если у Вас не команда, а сброд идиотов, то не надо высоких технологий чтобы случась беда. Они себе вилкой глаза выколят и привет.
Это как-то связано с дебаггером и/или Хаскелем?
RD>Если же у Вас нормальные люди (а я наивно предполагал, что FP в основном пользуются именно такие), то они будут писать нормальный софт и дебаггер им не понадобится. Поэтому дебаггер (как и любая другая не критичная фича) не является в нормальной ситуации вредной.
На дебаггер тратятся усилия разработчиков ЯП, которые могли бы быть потраченными на другие вещи, на исправление тех же ошибок, например.
Поэтому наличие дебаггера в ЯП, при условии его неиспользования подавляющим большинством, является вредным.
RD>Но поскольку в отличии от некоторых я не страдаю красноглазием, то могу предположить, что в каких-то экзотических условиях дебаггер может оказаться полезен даже в Хаскелле. Лично я, конечно, с такими случаями не сталкивался (и дай Бог, чтоб не столкнулся).
Я не "красноглазен", глаза у меня серо-голубые, а склера голубоватая, как у любого здорового человека.
Я просто стараюсь быть логичным и последовательным, стараюсь рассмотреть феномен с разных сторон.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
T>>Я думаю, отсутствие отладчика не критерий для умного программиста. А потом перестанет быть критерием и для остальных. MC>Отладка отладке (и отладчик отладчику) рознь. Я вот вполне обхожусь без брейкпоинтов и прохода по шагам в haskell и scheme. Но для той же scheme без возможности поглядеть результат развертки макроса бывает туго. Так что инструментарий должен быть адекватен языку.
От Template Haskell у меня похожие ощущения.
MC>Кстати, а с чего вообще было решено, что для haskell нет средств отладки? Определенное количество тулзеней отчетливо гуглится (например, hood).
В ghc отладчик есть.
ghci :? выводит среди команд :trace, :step, :break и тп.
Но попытаться поселить сомнения в несомненной пользе наличия отладчика надо.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
RD>>Вообще-то ваша беспочвенная самоуверенность рискует стать легендой. T>Моя уверенность имеет под собой основания.
Верится с трудом. Даже через силу не получается.
А вообще-то мужики, что сжигали товарища Бруно, тоже были уверены на все 100% в своей правоте. И говорят, у них были на то все основания. Ведь Бруно не только утверждал что Земля вращается вокруг Солнца а еще и колдовством баловался.
T>Ты не путай зависимости, возникающие на Java и зависимости, возникающие на ФЯ.
Ага, конечно. Я вижу, Вы уже готовы начать лекцию на тему side effects. Зависимости они и в Африке зависимости. То, что на тот же объем кода у Haskell зависимостей меньше чем у Java, еще не значит что их нет.
T>Тогда в чём проблема?
Да ни в чем. Пожалуй только в том, что черное любите называть белым.
T>Ты, по-моему, не смог соотнести eeek в ссылке и eeek в тексте по ссылке. T>Ничего про exchange я не говорил и писать его не собираюсь (пока не собираюсь).
Ну хорошо, eeek так eeek. У меня тоже была подобная история. В offscreen bitmap была неправильная битность и лечилось это рисованием синей линии вне границ этого битмапа. Причем было это только в одной версии JVM и только на одной платформе. И что? Просто баг в сторонней библиотеке. Некоторые не исправляют годами. И можешь писать свою программу сколь угодно модульно, все равно от проблем в сторонних библиотеках это не защитит.
RD>>Если честно, то я тоже сдержался и не нахамил после вашей заяки про debuggerы. T>Высокое жюри не сможет учесть этот факт. Он не был запротоколирован, в отличии от моего.
Мне высокое жюри побоку. Его основная задача — объяснять приехавшим по вызову бригадам, что это на самом деле Гений, и забирать его не надо.
Здравствуйте, Rtveliashvili Denys, Вы писали:
RD>А вообще-то мужики, что сжигали товарища Бруно, тоже были уверены на все 100% в своей правоте. И говорят, у них были на то все основания. Ведь Бруно не только утверждал что Земля вращается вокруг Солнца а еще и колдовством баловался.
Самокритично.
Это мужики считали очевидной плоскостность земли, да
VE>>>Очень люблю слова "очевидно", они обычно скрывают то, что _кажется_ очевидным автору. RD>>Если у Вас не команда, а сброд идиотов, то не надо высоких технологий чтобы случась беда. Они себе вилкой глаза выколят и привет.
T>Это как-то связано с дебаггером и/или Хаскелем?
см. ниже
RD>>Если же у Вас нормальные люди (а я наивно предполагал, что FP в основном пользуются именно такие), то они будут писать нормальный софт и дебаггер им не понадобится. Поэтому дебаггер (как и любая другая не критичная фича) не является в нормальной ситуации вредной.
T>На дебаггер тратятся усилия разработчиков ЯП, которые могли бы быть потраченными на другие вещи, на исправление тех же ошибок, например.
1. усилия разработчиков _ЯП_ на дебаггер не тратятся. На это тратятся усилия как правило других команд. По крайней мере так происходит в mainstream.
2. Haskell появился в 1990г. Если 18 лет это так мало, но и 180 будет мало чтобы сделать окружение ЯП удобным.
T>Поэтому наличие дебаггера в ЯП, при условии его неиспользования подавляющим большинством, является вредным.
глупости. см. выше.
RD>>Но поскольку в отличии от некоторых я не страдаю красноглазием, то могу предположить, что в каких-то экзотических условиях дебаггер может оказаться полезен даже в Хаскелле. Лично я, конечно, с такими случаями не сталкивался (и дай Бог, чтоб не столкнулся).
T>Я не "красноглазен", глаза у меня серо-голубые, а склера голубоватая, как у любого здорового человека.
Есть такое понятие как "образное выражение". Видимо Вам оно не знакомо.
T>Я просто стараюсь быть логичным и последовательным, стараюсь рассмотреть феномен с разных сторон.
Что-то Ваши разные стороны находятся с одного боку.
RD>>А вообще-то мужики, что сжигали товарища Бруно, тоже были уверены на все 100% в своей правоте. И говорят, у них были на то все основания. Ведь Бруно не только утверждал что Земля вращается вокруг Солнца а еще и колдовством баловался.
VE>Самокритично. VE>Это мужики считали очевидной плоскостность земли, да
Нет, дорогой товарищ. Было очеведно что Бруно — колдун. Для тех кто в танке: колдун не потому, что Земля летает вокруг Солнца, он действительно занимался магией. А на все остальное легла тень именно из-за этого. И потому что те, кто его судили, тоже были очень во всем уверенны.
А как вы нашли самокритичность — тема для глубокого научного изыскания.
RD>>>Вообще-то ваша беспочвенная самоуверенность рискует стать легендой. T>>Моя уверенность имеет под собой основания. RD>Верится с трудом. Даже через силу не получается. RD>А вообще-то мужики, что сжигали товарища Бруно, тоже были уверены на все 100% в своей правоте. И говорят, у них были на то все основания. Ведь Бруно не только утверждал что Земля вращается вокруг Солнца а еще и колдовством баловался.
Умолкаю.
А то ещё сожгут.
Хотя Бруно сожгли за то, что воровал и колдовал, а множественность миров к тому времени публично обсуждалась на уровне кардиналов и ересью не считалась.
T>>Ты не путай зависимости, возникающие на Java и зависимости, возникающие на ФЯ. RD>Ага, конечно. Я вижу, Вы уже готовы начать лекцию на тему side effects. Зависимости они и в Африке зависимости. То, что на тот же объем кода у Haskell зависимостей меньше чем у Java, еще не значит что их нет.
Это качественное отличие.
T>>Тогда в чём проблема? RD>Да ни в чем. Пожалуй только в том, что черное любите называть белым.
Это надо доказывать, поскольку тянет на оскорбление.
Поэтому — р-р-разворачивай!
T>>Ты, по-моему, не смог соотнести eeek в ссылке и eeek в тексте по ссылке. T>>Ничего про exchange я не говорил и писать его не собираюсь (пока не собираюсь). RD>Ну хорошо, eeek так eeek. У меня тоже была подобная история. В offscreen bitmap была неправильная битность и лечилось это рисованием синей линии вне границ этого битмапа. Причем было это только в одной версии JVM и только на одной платформе. И что? Просто баг в сторонней библиотеке. Некоторые не исправляют годами. И можешь писать свою программу сколь угодно модульно, все равно от проблем в сторонних библиотеках это не защитит.
Я попрошу привести пример такой же ошибки в библиотеках на любом современном ФЯ.
Чтобы я перестал пребывать в уверенности, что в случае библиотек на современных ФЯ это невозможно.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
RD>>>Если у Вас не команда, а сброд идиотов, то не надо высоких технологий чтобы случась беда. Они себе вилкой глаза выколят и привет. T>>Это как-то связано с дебаггером и/или Хаскелем? RD>см. ниже
см. ниже.
RD>>>Если же у Вас нормальные люди (а я наивно предполагал, что FP в основном пользуются именно такие), то они будут писать нормальный софт и дебаггер им не понадобится. Поэтому дебаггер (как и любая другая не критичная фича) не является в нормальной ситуации вредной.
T>>На дебаггер тратятся усилия разработчиков ЯП, которые могли бы быть потраченными на другие вещи, на исправление тех же ошибок, например.
RD>1. усилия разработчиков _ЯП_ на дебаггер не тратятся. На это тратятся усилия как правило других команд. По крайней мере так происходит в mainstream.
Даже не знаю, что сказать.
Этот пункт справедлив только для ограниченного количества компиляторов: gcc, msvc, xlc и icc. Ну, ещё, наверное, cc от Sun. Ну, ещё .net. И Java.
У всех остальных всё по-другому. Те, кто разрабатывает компиляторы, те и пишут отладчики.
Организация вычислений-то разная. Те же вложенные функции Паскаля, например, если не далеко уходить от Си.
RD>2. Haskell появился в 1990г. Если 18 лет это так мало, но и 180 будет мало чтобы сделать окружение ЯП удобным.
Ну-ка, когда появились отладчики для Си? Через сколько лет после его появления?
T>>Поэтому наличие дебаггера в ЯП, при условии его неиспользования подавляющим большинством, является вредным. RD>глупости. см. выше.
Глупости. см. выше.
RD>>>Но поскольку в отличии от некоторых я не страдаю красноглазием, то могу предположить, что в каких-то экзотических условиях дебаггер может оказаться полезен даже в Хаскелле. Лично я, конечно, с такими случаями не сталкивался (и дай Бог, чтоб не столкнулся). T>>Я не "красноглазен", глаза у меня серо-голубые, а склера голубоватая, как у любого здорового человека. RD>Есть такое понятие как "образное выражение". Видимо Вам оно не знакомо.
А ты, значит, не знаком с термином "подыграть".
T>>Я просто стараюсь быть логичным и последовательным, стараюсь рассмотреть феномен с разных сторон. RD>Что-то Ваши разные стороны находятся с одного боку.
Если говорить о том, что современные ЯП в большинстве своём полное... полный... отстой, в общем, то да, я односторонен.
Но к этому выводу я пришёл после рассмотрения с многих сторон, а также после многочисленных экспериментов.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
RD>>>А вообще-то мужики, что сжигали товарища Бруно, тоже были уверены на все 100% в своей правоте. И говорят, у них были на то все основания. Ведь Бруно не только утверждал что Земля вращается вокруг Солнца а еще и колдовством баловался. VE>>Самокритично. VE>>Это мужики считали очевидной плоскостность земли, да RD>Нет, дорогой товарищ. Было очеведно что Бруно — колдун. Для тех кто в танке: колдун не потому, что Земля летает вокруг Солнца, он действительно занимался магией. А на все остальное легла тень именно из-за этого. И потому что те, кто его судили, тоже были очень во всем уверенны.
Ещё раз: множественность миров и всё такое нормально обсуждалась на высшем церковном уровне и до Бруно, и после. Ересью не считалась.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, Rtveliashvili Denys, Вы писали:
RD>А как вы нашли самокритичность — тема для глубокого научного изыскания.
Просто когда человек оперирует очевидностями, "глупость"ями, и там и тут сомневается в опыте оппонента, жутко уверен в своей правоте (даже сомнений нет, но оснований почему-то кроме перечисленных выше нет), и вдруг заявляет, что это как раз оппонент "уверен на 100%", то это выглядит как минимум глупо.
Подозревая, что Вы человек неглупый, я подумал, что Вы это о себе.
Здравствуйте, thesz, Вы писали:
C>>Mercurial тоже. T>Это такое абсолютное утверждение? [url=http://allmydata.org/pipermail/tahoe-dev/2007-November/000228.html]Исключений[/url быть не может?
Это проблемы реализации сетевого протокола в Mercurial, так что неинтересно. В Mercurial интересна их система хранения файлов, оптимизированая для быстрой локальной работы.
T>>>С функционалом? C>>У darcs — средненький функционал для современных dvcs. T>Существуют и другие мнения. T>Поэтому — р-разворачивай.
Ну вот, опять спать не дают...
T>Я попрошу привести пример такой же ошибки в библиотеках на любом современном ФЯ. T>Чтобы я перестал пребывать в уверенности, что в случае библиотек на современных ФЯ это невозможно.
Я не собираюсь тратить свое время и искать там ошибки, что были бы настолько вопиющими. Сходу ни одной назвать не могу. Но это просто от того, что я не так много этими библиотеками пользовался.
С другой стороны, не много пользовался потому что мелких недочетов полно. Элементарный пример: поддеркжа unicode в Haskell библиотеках вообще никакая. Такое ощущение, что люди просто не догадываются, что кроме ASCII бывают еще и другие кодировки. Но у этой проблемы ноги растут от лени и пофигизма разработчиков а не от недочетов ЯП.
Здравствуйте, thesz, Вы писали:
T>А чего ты здесь не спрашиваешь? T>Узнать, как быть в какой-то ситуации, можно двумя способами: 1) попасть в неё самому, и 2) спросить у попадавших в неё.
А зачем мне спрашивать? И здесь и в других местах достаточно ответов и вопросов. Ответы меня пока не убедили, поэтому хотелось бы подкрепить их примером. Достойных примеров вне компиляторостроения я не видел.
T>"Попасть в ситуацию самому" ты не хочешь. Для этого надо начать использовать Хаскель. T>Из чего следует неопровержимый вывод, что использовать Хаскель (ФЯ вообще) ты не хочешь.
Я не "не хочу использовать Хаскель", а не могу оправдать риски связанные с ним в "индустриальной" среде. Дома я с удовольствием с ним поковыряюсь, как и большинство здесь. Хаскель это очень серьезный прыжок, переползти плавно на него нельзя. Предсказуемость в нашем ремесле и так ниже плинтуса, а тут предлагается сменить лыжи на коньки. Тебе, фанату и эксперту, все это представляется ерундой, но влезь в мою шкуру.
T>(мутабельные числодробилки после переноса на ФЯ приобретают интересные возможности, кстати)
RD>>>>А вообще-то мужики, что сжигали товарища Бруно, тоже были уверены на все 100% в своей правоте. И говорят, у них были на то все основания. Ведь Бруно не только утверждал что Земля вращается вокруг Солнца а еще и колдовством баловался. VE>>>Самокритично. VE>>>Это мужики считали очевидной плоскостность земли, да RD>>Нет, дорогой товарищ. Было очеведно что Бруно — колдун. Для тех кто в танке: колдун не потому, что Земля летает вокруг Солнца, он действительно занимался магией. А на все остальное легла тень именно из-за этого. И потому что те, кто его судили, тоже были очень во всем уверенны.
T>Ещё раз: множественность миров и всё такое нормально обсуждалась на высшем церковном уровне и до Бруно, и после. Ересью не считалась.
Какой такое "еще раз"? При чем вообще тут множественность миров? Или Вы это в категорию "колдовство" отнесли?
Здравствуйте, thesz, Вы писали:
RD>>2. Haskell появился в 1990г. Если 18 лет это так мало, но и 180 будет мало чтобы сделать окружение ЯП удобным.
T>Ну-ка, когда появились отладчики для Си? Через сколько лет после его появления?
Здравствуйте, Rtveliashvili Denys, Вы писали:
RD>Ага, и взрывает потребление памяти там, где этого не ждешь. В проекте <1K lines может быть это и не проблема. А если <1M lines? Не согласны? Приведите успешный контр-пример.
xmonad. И на рабочей и на домашней машине живет без перезагрузки по много-много дней и немного месяцев. Потом выходит новое ядро, я перегружаю машину и оно опять живёт и не ликает.
Здравствуйте, novitk, Вы писали:
BZ>>Евгений Кирпичёв работает в яндексе афаик
N>Вопрос не в том где кто работает (SPJ, например, работает в MS),
команды ghc и f# работают в Кембридже, где находятся лаборатории MS Research. т.е. всё-таки это "академики, работающие на индустрию", и в частности эти джве группы как раз и создают технологии компиляции для будущих студий
jkff и thesz же работают в коммерческих компаниях, и применяют хаскел для зарабатывания денег
N>а готов ли ты вложить значительные ресурсы в разработку на Хаскеле? Посмотри на риски...
насчёт меня смешно спрашивать — я как раз пятый год пишу freearc на хаскеле
риски — надо сравнивать, а то ты рассуждаешь так, как будто при работе с явой рисков никаких. так вот, на одной стороне находятся риски того, что ваши программисты не освоят хаскел на том же уровне, что они уже освоили яву, и поэтому у вас возникнут сложности с отладкой, оптимизацией и т.п. на жругой стороне находятся риски большего проекта, который рискует погибнуть под своей тяжестью. просто риски второго типа хоршо хнакомы и никто тебя не убьёт, если ты с ними не справишься
N>Как быть с тем, что тебя с Зефировым мне не нанять, а если и нанять, то предметную область вы не знаете? Как быть с тем, что моей команде надо мозги кипятить полгода миниум, что бы просто овладеть всеми этими deforestation и zipper? А предметная область не компилятор, где есть хоть какой-то опыт, а числодробилка, где все существующие алгоритмы мутабельные? Добавь, что все это происходит в коммерческой компании, а не в "универе", и заказчики стоят над душой "неподетски"?
что касается числодробилок, то afaik хаскел для них сейчас малоинтересен. тут идёт активная академическая работа, рабочих инструментов пока не видно. впрочем, это не моя область — готов ошибиться
что касается вообще, то процесс внедрения новых технологий вроде не хаскел-специфичен, стоит ли 120-й раз повторять чужие слова?
N>Это все громадные риски, на которые можно пойти только если реально видеть свет в конце туннеля. Извини, но я его не вижу. Где "killer app", где "success stories"? И это при том, что среда (GHC) уже давно на вполне индустриальном уровне.
в подписи как раз вполне success story (на killer app она не тянет ввиду малопопулярности архиваторов вообще). кратко — это аналог rar/7-zip, разработанный в несколько раз быстрее. конкретно, я сравнивал 7-zip и fa, когда набор их фич примерно совпадал — размеры моих исходников были втрое меньше
N>Вот ты можешь честно сказать сейчас, что Хаскель дал бы реальный выигрыш при реализации FreeArc-а по сравнению с F# или Scala?
как языки они находятся где-то посредине между c++ и хаскелом. а вот внешняя среда у f# к 2010-му году будет несравненно лучше, чем у хаскела
BZ>>ps: я лично полагаю, что f# станет переходным вариантом и хаскел пойдёт в индустрию во второй половине 2010-х
N>Буду рад, хотя мне нужна открытая платформа, поэтому я хочу что-нибудь Scala-подобное...
scala и f# — это всё же две большие разницы: ооп+фп и фп+ооп. имей в виду, что это не одно и то же
Здравствуйте, thesz, Вы писали:
T>Наличие фичи не означает возможность её простого использования и отсутствия ошибок. T>В случае алгебры патчей отсутствие ошибок был by design.
Замечательно, но Хаскель то здесь причем? Ты считаешь, что "алгебры патчей" не реализуема в Питоне?
Здравствуйте, 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>Могила, конечно, да только не там, где ты предполагал. ;)
"Могила код на Джаве написать" — понятно, очевидно.
"Обработка данных через утилитки на Хаскеле" — тоже понятно, в некоторых случаях это рационально. Особенно когда надо просто взять данные из файла, переработать и в другой файл скинуть.
"Сводящий воедино мой код на Джаве и старый код на Джаве." -... ндас, всегда думал что русский — мой родной язык. Но это предложение рвет мне мозг в фарш. Возможно, следует понимать так, что ежели Вы что-то напишете на Джава, то оно будет таким экзотичным, что его уже никак и ни с чем другим не соединить? Даже с другим софтом на Джава? А как же модульность? :-)
RD>>С другой стороны, не много пользовался потому что мелких недочетов полно. Элементарный пример: поддеркжа unicode в Haskell библиотеках вообще никакая.
BZ>поддержка юникода встроена в компилятор. проблемы возникают только там, где нужно делать интерфейс к С-библиотекам
Наверное это повод считать что проблемы нет? А.. Я понял. Индульгенцию дает то, что в _стандратной_ библиотеке взаимодействия с C-библиотеками просто положили болт на Unicode и тупо счатают что Char это char. Да, я в курсе про w_char, но это ситуацию не меняет. Особенно в свете того, что далеко не всегда 16бит на символ — стандартное представление unicode.
RD>>Ага, и взрывает потребление памяти там, где этого не ждешь. В проекте <1K lines может быть это и не проблема. А если <1M lines? :-) Не согласны? Приведите успешный контр-пример. L>xmonad. И на рабочей и на домашней машине живет без перезагрузки по много-много дней и немного месяцев. Потом выходит новое ядро, я перегружаю машину и оно опять живёт и не ликает.
xmonad.. слышал, слышал. Может даже поставлю, посмотрю.
Так значит, в нем порядка ~1M строк? Немало для оконного менеджера.
Проверим...
Чуток не дотянуло до 4K вместе с тестами. Ну да, думаю при таком объеме можно и выловить все возможные проблемы с памятью.
Да и большими объемами данных xmonad точно не ворочает. Вот если бы он прогонял через себя хотя бы мегабайт в секунду, да еще и вынужден был держать в себе сложную модель, объемом мегов в 100-100 и нетривиально ее обновлять, то была бы другая история.
Здравствуйте, Rtveliashvili Denys, Вы писали:
RD>Наверное это повод считать что проблемы нет? А.. Я понял. Индульгенцию дает то, что в _стандратной_ библиотеке взаимодействия с C-библиотеками просто положили болт на Unicode и тупо счатают что Char это char.
Рабинович напел? в FFI вообще разделены сишные и хаскеловские типы. 16-битные сишные символы — CWchar, они же TCHAR. работа с ними точно такая же, как с 8-битными символами:
RD>Да и большими объемами данных xmonad точно не ворочает. Вот если бы он прогонял через себя хотя бы мегабайт в секунду, да еще и вынужден был держать в себе сложную модель, объемом мегов в 100-100 и нетривиально ее обновлять, то была бы другая история.
Докажиземлюешь.
Я серьёзно. Чего это ты выдвигаешь безосновательные тезисы? Получается игра в одни ворота: сторонники Хаскеля говорят, что он хорош и им надо это доказывать, а противники Хаскеля говорят, что он плох и это считается доказанным априори.
Поэтому сказал А, говори и Б. Сказал, что у Хаскеля будет "другая история", предоставь use case, где это так.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
T>>Я думаю, что даже http://cufp.galois.com/ тебя не удовлетворит. Там тоже какие-то узкие области. RD>Там есть несколько интересных историй успеха. На базе Erlang и Ocaml, например. Что дает основания считать что разработчики не пустозвонят. А мне вот было интересно, чем же еще занимаются хаскелисты, особенно местные. Но молчат. Видимо коммерческая тайна. Ладно, раз тайна, не будем развивать тему.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, thesz, Вы писали:
N>>>Где они? Был Darcs, но git и Mercurial, начавшие гораздо позже, просто убивают его функционалом и скоростью. T>>darcs2 и сейчас есть. "Просто убивают" это преувеличение, я думаю. C>Нет.
Убивают скоростью и стабильностью, но не функционалом, нет.
Здравствуйте, BulatZiganshin, Вы писали:
T>>>Ленивость стимулирует модульность (famous 'map f . map g === map (f . g)' example).
E>>А можно развернуть для чайников, о какой модульности здесь идет речь?
BZ>читай "why functional programming matters"
Я читал, чесно. Но, воспитываясь в свое время на Turbo Pascal (Modula-2), о модульности у меня сложилось несколько другое впечатление. И я вообще-то не понимаю, при чем здесь модульность.
E>>Прошу прощения за грубость, но это достойно войти в аналы вместе с вот этой
. Поскольку эта фраза об ненаписанных программах.
BZ>просто ты не понял, о чём речь.
Я-то понял. Но на моей памяти в первый раз в достоинство программы возвели "о которых легко рассуждать".
BZ>работая с отладчиком, ты имеешь дело с одним конкретным прогоном программы. более того, находишься в одной конкретной точке выполнения.
Временами именно в этом ценность и состоит. Когда ты можешь просмотреть содержимое памяти (скажем, буфер, возвращенный от девайса или подготовленный для отправки в девайс), модифицировать его и увидеть, как это сказалось в дальнейшем. Особенно, когда ты только-только знакомишься с какой-то новой предметной областью.
BZ>во-первых, потому, что выглядит глупо, найдя ошибку за одну минуту, затем целый день думать над её исправлением.
Почему это глупо? У меня бывали случаи, когда я находил ошибки и потом по нескольку дней думал, как их лучше исправить. Я, конечно, не самый умный человек и не самый лучший программист, но еще никогда не всречал программиста который бы вообще не ошибался. А раз ошибки все-таки случаются, то почему день на ее исправление -- это много? Особенно, если ошибка была допущена где-то на этапе постановки задачи или проектирования, тогда чем позже она обнаруживается, тем дороже обходится ее исправление.
E>>Вот Дональд Кнут, к примеру, считает отладчик очень важным инструментом программиста.
BZ>но он ведь не говорил, что программисты, снабжённые отладчиком, пишут столь же ясные программы?
Нет, но то, что Дональду Кнуту для работы нужен отладчик является показателем того, что для написания столь же качественных программ отладчик может пригодится
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Если скрестить cherry-picking и коммутативность патчей, то открываются новые возможности.
Поэтому не надо тупо гуглить, почитайте туториал и оцените сами.
По поводу того, что алгебру патчей можно реализовать на любом языке. С этим глупо спорить, однако небольшая ремарка.
Первая версия darcs была написана на c++. К сожалению, она не работала. Совсем.
Вторая версия была написана на хаскеле. И она заработала. Сразу.
("Заработала" -- имеется в виду алгебра патчей).
Здравствуйте, Rtveliashvili Denys, Вы писали:
RD>xmonad.. слышал, слышал. Может даже поставлю, посмотрю. RD>Так значит, в нем порядка ~1M строк? Немало для оконного менеджера. RD>Проверим...
Ты забыл прибавить ещё xmonad-contrib, который гораздо больше
RD>Чуток не дотянуло до 4K вместе с тестами. Ну да, думаю при таком объеме можно и выловить все возможные проблемы с памятью. RD>Да и большими объемами данных xmonad точно не ворочает. Вот если бы он прогонял через себя хотя бы мегабайт в секунду, да еще и вынужден был держать в себе сложную модель, объемом мегов в 100-100 и нетривиально ее обновлять, то была бы другая история.
Вижу, что если я дам тебе такой пример — ты придумаешь что нибудь ещё.
Ты уже всё решил — зачем мне с тобой спорить?
Здравствуйте, thesz, Вы писали: N>>Замечательно, но Хаскель то здесь причем? Ты считаешь, что "алгебры патчей" не реализуема в Питоне? T>Реализуема. T>Насколько мне известно, в её реализации используется ленивость. T>Те самые ленивые степенные ряды я реализовал-таки, с третьей попытки. T>Поэтому реализация алгебры патчей на Питоне будет... ну, интересной, так скажу.
Ленивость в python-е довольно хорош через итераторы реализуется.
До haskell-я конечно далеко, но таки многое можно.
Здравствуйте, BulatZiganshin, Вы писали: RD>>Наверное это повод считать что проблемы нет? А.. Я понял. Индульгенцию дает то, что в _стандратной_ библиотеке взаимодействия с C-библиотеками просто положили болт на Unicode и тупо счатают что Char это char. BZ>Рабинович напел? в FFI вообще разделены сишные и хаскеловские типы. 16-битные сишные символы — CWchar, они же TCHAR. работа с ними точно такая же, как с 8-битными символами:
А вот другой кусок кода:
#ifdef __GLASGOW_HASKELL__
getCurrentDirectory :: IO FilePath
getCurrentDirectory = do
#ifdef mingw32_HOST_OS
-- XXX: should use something from Win32
p <- mallocBytes long_path_size
go p long_path_size
where go p bytes = do
p' <- c_getcwd p (fromIntegral bytes)
if p' /= nullPtr
then do s <- peekCString p'
free p'
return s
else do errno <- getErrno
if errno == eRANGE
then do let bytes' = bytes * 2
p'' <- reallocBytes p bytes'
go p'' bytes'
else throwErrno "getCurrentDirectory"
#else
System.Posix.getWorkingDirectory
#endif
#ifdef mingw32_HOST_OS
foreign import ccall unsafe "getcwd"
c_getcwd :: Ptr CChar -> CSize -> IO (Ptr CChar)
#endif
Из System.Directory.
Именно из за него ghci (6.10.1) не работает если в имени текущей директории есть русские символы (Ticket #2963).
Здравствуйте, Tonal-, Вы писали:
T>Именно из за него ghci (6.10.1) не работает если в имени текущей директории есть русские символы (Ticket #2963).
T>И таких мест там довольно много.
стандартная хаскеловская библиотека не поддерживает юникодные имена файлов вообще. лет 5-10 назад, когда она была написана, это видимо было малосущественно. но это всё же недотаток языка, а не библиотеки — у меня в программе например своя библиотека, которой чужды эти недостатки. у на уровне языка поддержка всё-таки полная вплоть до того, что ты можешь писать идентификаторы арабской вязью
Здравствуйте, pgregory, Вы писали:
P>Не, конечно, darcs еще использует какая-нибудь мега-программа типа xmonad... А что-нибудь покрупнее? Проект AAA-класса? Ход за вами!
freearc, конечно же
P>И не надо про то, что пока, мол, так и так, но люди поймут, и тогда... На git _сейчас_ активно переходят проекты с cvs, svn, perforce и даже darcs (GHC!). Потому, что он лучше. И всем плевать, что он написан на C, перле и баше. Все настолько просто.
и отсюда ты делаешь вывод, что с, перл и баш — это лучшие в мире ЯП, на которые всем немедленно нужно перейти?
Здравствуйте, pgregory, Вы писали:
P>Отсюда я делаю вывод, что хорошесть программы абсолютно ортогональна хорошести яп, на котором она написана.
Вывод не меньшей наивности, чем был предложен.
P>И хотя хороший яп может помочь в написании хорошего софта (а может и помешать — сколько контрибьюторов имел бы git, будь он написан на хаскелле, а?), само по себе использование хорошего яп не дает ничего. Что мы очень явно видим на примере darcs vs. git. Хороший дизайн + плохой яп всегда победят плохой дизайн + хороший яп.
Т.е. хороший ЧПУ станок не даёт ничего (выделить ещё курсивом). Мастер с инструментами всегда сделает лучше, чем студент на таком станке.
Здравствуйте, pgregory, Вы писали:
P>И хотя хороший яп может помочь в написании хорошего софта (а может и помешать — сколько контрибьюторов имел бы git, будь он написан на хаскелле, а?), само по себе использование хорошего яп не дает ничего.
Ой ой ой, что я вижу!
А это как понимать-то?
И хотя на мотоцикле я доеду быстрее, чем дойду пешком, сам по себе мотоцикл не даёт ничего?
Так может помочь или не даёт ничего?
Кстати, доказывай "не даёт ничего". Интересно послушать объективные обоснования.
Мне тут второе я подсказывает, что ты, как и многие, оспариваешь панацейность, о которой никто и не говорил? Ну, мол, ФП не панацея и если бездарю его дать, то оно ему не поможет? Надеюсь, нет же? Надеюсь, в твоих изложениях заложена мысль.
Здравствуйте, VoidEx, Вы писали:
VE>Здравствуйте, pgregory, Вы писали:
P>>Отсюда я делаю вывод, что хорошесть программы абсолютно ортогональна хорошести яп, на котором она написана. VE>Вывод не меньшей наивности, чем был предложен.
С радостью откажусь от этого вывода, как только увижу реальные контрпримеры.
P>>И хотя хороший яп может помочь в написании хорошего софта (а может и помешать — сколько контрибьюторов имел бы git, будь он написан на хаскелле, а?), само по себе использование хорошего яп не дает ничего. Что мы очень явно видим на примере darcs vs. git. Хороший дизайн + плохой яп всегда победят плохой дизайн + хороший яп.
VE>Т.е. хороший ЧПУ станок не даёт ничего (выделить ещё курсивом). Мастер с инструментами всегда сделает лучше, чем студент на таком станке.
Как написано у Страуструпа, «Доказательство по аналогии — это обман» :-)
Нет никакого «т.е.». Есть объективная реальность и мой субъективный взгляд на нее. Безусловно, хаскель с друзями — очень крутые, мощные и высокоуровневые языки. Глупо с этим спорить. Но мой (думаю, не только мой) субъективный взгляд пока не видит в объективной реальности корреляции между крутостью хаскелла и хорошестью софта на нем.
Еще раз повторю, с радостью изменю этот мой взгляд. Было бы, от чего!
RD>>Да и большими объемами данных xmonad точно не ворочает. Вот если бы он прогонял через себя хотя бы мегабайт в секунду, да еще и вынужден был держать в себе сложную модель, объемом мегов в 100-100 и нетривиально ее обновлять, то была бы другая история.
T>Докажиземлюешь. T>Я серьёзно. Чего это ты выдвигаешь безосновательные тезисы? Получается игра в одни ворота: сторонники Хаскеля говорят, что он хорош и им надо это доказывать, а противники Хаскеля говорят, что он плох и это считается доказанным априори. T>Поэтому сказал А, говори и Б. Сказал, что у Хаскеля будет "другая история", предоставь use case, где это так.
Thesz, доказывать фанатикам вроде тебя бесполезно.
Если тебе говорят что-то, что не укладывается в твою картину мира, то ты орешь как недорезанный "разворачивай!" или твердишь что это не недостаток такой а крутейшая фича.
И в отличии от тебя, кричащего что "Хаскель крут ваще" я НЕ утверждаю что он не крут. Я просто показываю тебе на то, что пора снять розовые очки. Но видимо они вросли в кость.
А пример с xmonad был предложен как крупный софт, где все стабильно и нет утечек. Пример я не принимаю, т.к. софт небольшой. А меня бы заинтересовал именно БОЛЬШОЙ, перемалывающий кучу данных. И если это сможет так же стабильно работать как и xmonad — слава и хвала разработчикам. Но пока что такого примера не видел.
Здравствуйте, VoidEx, Вы писали:
VE>Здравствуйте, pgregory, Вы писали:
P>>И хотя хороший яп может помочь в написании хорошего софта (а может и помешать — сколько контрибьюторов имел бы git, будь он написан на хаскелле, а?), само по себе использование хорошего яп не дает ничего.
VE>Ой ой ой, что я вижу! VE>А это как понимать-то?
Хмм, дай подумать... Понимать в контексте «хороший яп == хаскель».
VE>И хотя на мотоцикле я доеду быстрее, чем дойду пешком, сам по себе мотоцикл не даёт ничего? VE>Так может помочь или не даёт ничего?
VE>Кстати, доказывай "не даёт ничего". Интересно послушать объективные обоснования.
VE>Мне тут второе я подсказывает, что ты, как и многие, оспариваешь панацейность, о которой никто и не говорил? Ну, мол, ФП не панацея и если бездарю его дать, то оно ему не поможет? Надеюсь, нет же? Надеюсь, в твоих изложениях заложена мысль.
Черт, видимо, я недостаточно ясно высказал свою мысль. Надеюсь, она может быть засчитана за мысль :-)
Я целиком за использование хороших яп вместо плохих яп. Вопрос в том, что же такое хороший яп? Хороший яп — это тот, который позволяет тебе мыслить на более высоком уровне, чем до этого, будучи сам по себе простым до очевидности. Сорри за курсив :-) Хороший яп должен «fit my mind». Он не должен требовать огромного багажа знаний, чтобы начать его использовать. Пример однозначно хорошего языка — питон. Или С.
(Я опускаю «я считаю», «мне кажется», «с моей точки зрения» и т.д. перед каждым предложением — ок?).
Проблема хаскеля в том, что он, с одной стороны, высокоуровневый (что хорошо), а с другой — взрывает мозг при попытке хотя бы освоить хороший учебник вроде «Real World Haskell». Потому, что он реально сложен. И это плохо. Конечно, возможно, проблема в моей личной глупости. Но, честно говоря, я, как и все :-) считаю себя above average.
У реально хорошего яп этой проблемы нет. С позволяет тебе мыслить на уровне выше ассемблера, при этом сам С прост, как гладильная доска. Питон позволяет тебе мыслить на уровне выше явы, но сам по себе он проще некуда.
Что ж, теперь попробую доказать «не дает ничего». Использование хорошего яп в смысле, определенном выше — это однозначно правильно. Это надо делать при любой возможности. Но. Хаскель не удовлетворяет определению однозначно хорошего языка. Поэтому, вместе с высокоуровневостью он принесет в проект свою сложность. (До сих пор помню, как в одном из популярных учебников по хаскелю monomorphism restriction встречалось чуть ли не сразу после вещей проде 1 + 1). И в этом смысле, сам по себе факт использования хаскеля не дает ничего. Ты в чем-то выигрываешь, а в чем-то (и серьезно!) проигрываешь.
Здравствуйте, VoidEx, Вы писали:
VE>Здравствуйте, pgregory, Вы писали:
VE>>>Т.е. хороший ЧПУ станок не даёт ничего (выделить ещё курсивом). Мастер с инструментами всегда сделает лучше, чем студент на таком станке.
P>>Как написано у Страуструпа, «Доказательство по аналогии — это обман» :-)
VE>Как написано у Ожегова, доказательство и опровержение — это разные вещи. VE>Вы в одном предложении противоречите сами себе, я лишь это продемонстрировал.
VE>Меня удивляет, как на каждое изобретение находится кто-то, кто говорит VE>- это что же ж, вечный двигатель штоля? VE>- нет конечно VE>- ну тогда нам и даром не нать
VE>Вроде как давно уже порешили, что панацей не существует, а всё равно самым важным аргументом является, что сам по себе язык за вас проект не сделает. Ну это уж извините!
VE>Прямо как будто в психологии у людей заложено панацею искать, хоть и знают, что нет её.
Полностью согласен с твоими высказываниями про панацею.
RD>>Ага, и взрывает потребление памяти там, где этого не ждешь. В проекте <1K lines может быть это и не проблема. А если <1M lines? :-) Не согласны? Приведите успешный контр-пример. BZ>ghc. ленивость можно контролировать на уровне тех немногих структур данных, чей размер может быть критичен. но для остальных, т.е. >99% переменных, никаких проблем это не вызывает а программирование упрощается. это аналогично использованию ЯВУ — вы ведь не пишете на ассемблере всю программу только потому, что у вас есть пара time-critical мест
В GHC есть некоторые средства контроля. Но кардинально это ничего не меняет. Этот пункт разбивается на два: 1) lazy&strict (предлагаю даже не поднимать нему снова, а то будет страшный флейм) 2) неразвитость инфраструктуры
RD>>А еще, отсутствие приличного IDE заставляет 100 раз подумать, прежде чем написать хоть строчку кода. BZ>если вы пишете код, не думая, то c#+vs — это идеальная среда. я серьёзно. писать такого рода программы на других языках — бесхозяйственность, граничащая с преступлением :)
Не надо перекручивать смысл. 100 раз подумать не над программой, а над тем, писать ли ее вообще на этом языке / с такой инфраструктурой.
RD>>Еще есть масса полезностей: RD>>1. невозможность использовать стандартные технологии передачи сообщений. Действительно, зачем JMS и AMQP если можно тупо текст гонять по сырому TCP? BZ>это всё обобщается до неразвитости инфраструктуры. мало библиотек, нет современных IDE с отладчиками, нет курсов "haskell за 5 минут для тех, кто не привык думать"
Предлагаю Вам не мешать святое с грешным.
Вот Вы — умный человек, ОК? Вы привыкли думать, и haskell вы знаете замечательно.
Теперь Вам надо написать программу (и Вы хотели бы ее писать на Хаскеле) но она должна общаться с другими программами. А те программы любят всякое middleware и им пользуются. Скажем, тот же AMQP. Ну или что-то аналогичное. Ваш ход? Я серьезно, мне очень интересно как Вы, как профессионал и спец в Хаскелле обойдете эту маленькую неприятность. Конечно, ничего кроме своей программы Вы менять не можете. Внешние системы и их протоколы зафиксированы.
RD>>2. Удивительные красоты самого языка вроде операторов (,,,,,,,,). BZ>как раз в плане синтаксиса хаскел даёт большую фору любому другому языку (из нескольких десятков, что я знаю). если уж приводить пример, то не неиспользуемую в реальной жизни операцию построения 10-элементной анонимной структуры, а скажем такое:
BZ>fac n = prod [1..n] BZ>что автоматом определяет полиморфную по всем числовым типам процедуру вычисления факториала. я автоматичсеким выводом наиболее общего типа пользуюсь постоянно
Абсолютно согласен с тем, что type inference и много чего другого в Хаскель — просто сказка.
Скажу по секрету: из-за этого я Очень хочу использовать его в реальных проектах. Но пока к сожалению не вижу практической возможности. Из-за той же инфраструктуры.
Что до (,,,,,), то это просто побочный эффект системы типов, принятой в haskell. Равно как и то, что для некоторых задач надо использовать числа Пеано (а я от них не в восторге). Короче говоря, не критично, хотя и не sexy.
RD>>В общем, Haskell может и подойдет для чего-то в production, но область приминимости стремится к нулю. BZ>ты в общем правильно определил — хаскел не подойдёт тем, кому не надо думать, а лишь быстро педалить, используя готовые библиотеки/генераторы кода. хаскел не подойдёт тем, для кого единственный способ написать правильную программу — гонять её часами в отладчике. хаскел не подойдёт для industrial programmers, если под ними понимать тех, для кого существуют только языки, поддерживаемые IDE
См. выше.
Вот есть я. Допустим, я даже готов не пользоваться IDE и как в каменном веке, высекать на камнях клинопись (уверен, haskell поддерживает и ее в идентификаторах). Много думать готов (я вообще грешен тем что думаю много). И есть теоретическая возможность применить Хаскель для реально полезных задач.
Но:
1. сделать так, чтобы этот софт был не конем в вакууме а смог общаться с другим софтом — не ясно как. Варианты типа "гонять строки по сокетам" не подходят.
2. нет четкого понимания как именно профайлить продукт _эффективно_ чтобы он не взорвался во время использования в самый неподходящий момент.
3. если все же взоврался, как по ошметкам понять, где была проблема. Java хотя бы дамп памяти оставит или stack trace. В Haskell такое есть?
4. многие пользователи Хаскель страдают яростным фанатизмом на ровном месте и предубежденностью. Это придает Хаскелю оттенок маргинальности (и не столько для меня, как для людей, от которых также много чего зависит).
Здравствуйте, BulatZiganshin, Вы писали: T>>Именно из за него ghci (6.10.1) не работает если в имени текущей директории есть русские символы (Ticket #2963). T>>И таких мест там довольно много. BZ>стандартная хаскеловская библиотека не поддерживает юникодные имена файлов вообще.
Это довольно ниприятно, особенно в свете того факта, что это таки стандартная библиотека.
BZ>лет 5-10 назад, когда она была написана, это видимо было малосущественно. но это всё же недотаток языка, а не библиотеки — у меня в программе например своя библиотека, которой чужды эти недостатки. у на уровне языка поддержка всё-таки полная вплоть до того, что ты можешь писать идентификаторы арабской вязью
Идентификаторы с локальными символами это конечно хорошо, но согласись, что язык претендующий на широкое распространение должен поствалятся с нормальными стандартными библиотеками.
Писать свою версию работы с системым апи конечно занимательно но довольно накладно.
N>>>Замечательно, но Хаскель то здесь причем? Ты считаешь, что "алгебры патчей" не реализуема в Питоне? T>>Реализуема. T>>Насколько мне известно, в её реализации используется ленивость. T>>Те самые ленивые степенные ряды я реализовал-таки, с третьей попытки. T>>Поэтому реализация алгебры патчей на Питоне будет... ну, интересной, так скажу. T>Ленивость в python-е довольно хорош через итераторы реализуется. T>До haskell-я конечно далеко, но таки многое можно.
Алгебраические типы данных представлять итераторами — мысль.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
T>>Докажиземлюешь. T>>Я серьёзно. Чего это ты выдвигаешь безосновательные тезисы? Получается игра в одни ворота: сторонники Хаскеля говорят, что он хорош и им надо это доказывать, а противники Хаскеля говорят, что он плох и это считается доказанным априори. T>>Поэтому сказал А, говори и Б. Сказал, что у Хаскеля будет "другая история", предоставь use case, где это так. RD>Thesz, доказывать фанатикам вроде тебя бесполезно.
Я — не фанат.
Я идеалист, но это, просто, наивысшая ступень прагматизма.
RD>Если тебе говорят что-то, что не укладывается в твою картину мира, то ты орешь как недорезанный "разворачивай!" или твердишь что это не недостаток такой а крутейшая фича.
Именно. Потому, что после "разворачивания", обычно, выясняется слабость аргументов и позиции вообще.
RD>И в отличии от тебя, кричащего что "Хаскель крут ваще" я НЕ утверждаю что он не крут. Я просто показываю тебе на то, что пора снять розовые очки. Но видимо они вросли в кость.
То, что ты называешь "розовыми очками", я называю прогрессом.
Ты не поверишь, но не кто иной, как Джон Кармак по выпуску первого Quake говаривал, что C++ для игр не предназначен, у него нельзя контролировать расход памяти и задержки по времени из-за перегрузки и конструкторов-декструкторов.
См. на Doom3 инструменты 2005 года.
Все аргументы против применения Хаскеля, что ты (да большинство) выкладывают на стол, все они, до единого, звучали в отношении C++ в 1995 году.
Вот и вся причина моего упрямства.
Просто у меня хорошая память.
RD>А пример с xmonad был предложен как крупный софт, где все стабильно и нет утечек. Пример я не принимаю, т.к. софт небольшой. А меня бы заинтересовал именно БОЛЬШОЙ, перемалывающий кучу данных. И если это сможет так же стабильно работать как и xmonad — слава и хвала разработчикам. Но пока что такого примера не видел.
Ещё раз.
Ты на голубом глазу высказал утверждение, что если написать систему, которая будет перемалывать хотя бы мегабайт в секунду с нетривиальным обновлением модели, то на Хаскеле всё будет плохо.
ЭТО. НАДО. ДОКАЗЫВАТЬ.
Это твой тезис, будь добр, докажи его.
Мегабайты в секунду с нетривиальным обновлением см. на CUFP. Но ты там в упор не видишь положительных примеров.
Расскажи мне ещё раз про розовые очки, пожалуйста.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
P>Отсюда я делаю вывод, что хорошесть программы абсолютно ортогональна хорошести яп, на котором она написана.
Это если мы смотрим уже на готовые программы.
А если мы будем смотреть на стартовавшие и не завершённым программы, то всё будет по другому.
"Хорошесть" завершённой программы будет определяться языком программирования.
P>И хотя хороший яп может помочь в написании хорошего софта (а может и помешать — сколько контрибьюторов имел бы git, будь он написан на хаскелле, а?), само по себе использование хорошего яп не дает ничего. Что мы очень явно видим на примере darcs vs. git. Хороший дизайн + плохой яп всегда победят плохой дизайн + хороший яп.
P>Я целиком за использование хороших яп вместо плохих яп. Вопрос в том, что же такое хороший яп? Хороший яп — это тот, который позволяет тебе мыслить на более высоком уровне, чем до этого, будучи сам по себе простым до очевидности. Сорри за курсив Хороший яп должен «fit my mind». Он не должен требовать огромного багажа знаний, чтобы начать его использовать. Пример однозначно хорошего языка — питон. Или С.
Перевод: "хороший яп — тот, что я знаю прямо сейчас."
Your language is hard to learn. My language is easy to learn, because I already know it. People won’t learn what they don’t already know.
Твоё высказывание прямо классическая демонстрация принципа.
Я думаю, что если специально стараться, так не получится. Значит, ты искренен.
Это хорошо. Значит, тебя можно переубедить.
P>Проблема хаскеля в том, что он, с одной стороны, высокоуровневый (что хорошо), а с другой — взрывает мозг при попытке хотя бы освоить хороший учебник вроде «Real World Haskell». Потому, что он реально сложен. И это плохо. Конечно, возможно, проблема в моей личной глупости. Но, честно говоря, я, как и все считаю себя above average.
Я считаю себя above average, у меня взрывает мозг при изучении теории типов и я её намеренно изучаю: за взрывом мозга и за расширением сознания.
P>Что ж, теперь попробую доказать «не дает ничего». Использование хорошего яп в смысле, определенном выше — это однозначно правильно. Это надо делать при любой возможности. Но. Хаскель не удовлетворяет определению однозначно хорошего языка. Поэтому, вместе с высокоуровневостью он принесет в проект свою сложность. (До сих пор помню, как в одном из популярных учебников по хаскелю monomorphism restriction встречалось чуть ли не сразу после вещей проде 1 + 1). И в этом смысле, сам по себе факт использования хаскеля не дает ничего. Ты в чем-то выигрываешь, а в чем-то (и серьезно!) проигрываешь.
Если мы проигрываем (и серьёзно!) в не нужной для решения наших задач области, то мы выигрываем в общем и целом.
Я к чему. Сейчас задачи такие, что вред от использование Хаскеля минимален. В том смысле, что да, Хаскель сильно нетороплив, но сейчас быстрые процессора, да он, еще, и параллелится легко. И дальше по аналогии.
P>Am I clear?
Pretty clear.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
P>>Отсюда я делаю вывод, что хорошесть программы абсолютно ортогональна хорошести яп, на котором она написана.
T>Это если мы смотрим уже на готовые программы.
T>А если мы будем смотреть на стартовавшие и не завершённым программы, то всё будет по другому.
T>"Хорошесть" завершённой программы будет определяться языком программирования.
Не понял мысль. Это следует читать как «когда реальные программы на хаскеле будут, наконец, написаны, они будут очень круты»? С чего вдруг? Почему, кроме GHC, таких программ сейчас нет? Если есть — примеры в студию!
P>>И хотя хороший яп может помочь в написании хорошего софта (а может и помешать — сколько контрибьюторов имел бы git, будь он написан на хаскелле, а?), само по себе использование хорошего яп не дает ничего. Что мы очень явно видим на примере darcs vs. git. Хороший дизайн + плохой яп всегда победят плохой дизайн + хороший яп.
T>Ты будешь удивлён, но контрибуторов git меньше, чем контрибуторов darcs: http://cufp.galois.com/2005/slides/DavidRoundy.pdf, стр. 12, 13, 15
Это твой легендарный юмор?
Ты будешь удивлен, но на дворе не 2005 год. Поэтому кидать ссылки на презентацию автора darcs от 2005 — смешно.
В этой презентации (от 24 сентября 2005 года) утверждается, что у darcs — 91 контрибьютор, у git — 79. На тот момент. Вот только, согласно википедии, разработка darcs началась на 3 года раньше, чем git'а. На момент презентации git'у было 4-5 месяцев.
Здравствуйте, Rtveliashvili Denys, Вы писали:
RD>Я так понимаю, что freearc это чудная и полезная программа, но коммерческим проектом это не является. Или может я неправ?
ну.. я готов продавать его, если это для тебя так важно
RD>Насчет jkff и thesz: раз работают в _коммерческих_ компаниях, то это внушает оптимизм. Быть может, они даже поведают миру о том, какие коммерчески успешные продукты были созданы на хаскелле/с помощью хаскелля? (про иммитацию железа я уже в курсе, жаль это очень узкая область). Кто знает, может это потянет на success story и повысить популярность хаскеля...
сейчас вспомнил — один из создателей языка работает в Credit Suisse и насколько я понимаю, использует его для финансового моделирования. причём он там не один. ещё — насколько я помню — нью-йоркское отделение ДойчеБанк приглашало спецов по ФП на подобную работу. недавно ещё некий американский инвестфонд приглашал опять же хаскелистов
это как раз к интересующей вас с novitk теме коммерческого использования хаскела, обработки больших объёмов данных и даже перемалывания чисел. вообще год назад в haskell list появлялась примерно одна вакансия в месяц
я тут уже рассказывал, как поискал на monster "haskell" и нашёл что-то вроде "требуется уборщик. обращаться к Люси Хаскел, 3-й корпус библиотеки"
BZ>>риски — надо сравнивать, а то ты рассуждаешь так, как будто при работе с явой рисков никаких. так вот, на одной стороне находятся риски того, что ваши программисты не освоят хаскел на том же уровне, что они уже освоили яву, и поэтому у вас возникнут сложности с отладкой, оптимизацией и т.п. на жругой стороне находятся риски большего проекта, который рискует погибнуть под своей тяжестью. просто риски второго типа хоршо знакомы и никто тебя не убьёт, если ты с ними не справишься
RD>Риски второго типа часто включают в себя и интеграцию с уже написанным софтом. В случае в Haskell это IMHO просто могила. Был бы рад, если было бы иначе, но в ближайшие годы видимо не судьба.
1. интеграция в существующие экосистемы типа JVM/.NET. единственная практическая система, которую я знаю — CAL от BusinessObjects, (неполный) клон хаскела для JVM.
2. Для хаскела легко делаются биндинги к существующим C API libraries, даже есть тулза автоматической их генерации — HSFFIG. и очень удобно делать language-specific обёртки вокруг библиотек, поэтому если у меня будет нечто чисто сишное, то использовать его из хаскела будет проще, чем из какого-либо другого языка (кроме C++, и то не факт)
3. как я понял из дальнейшего, тебе нужна поддержка стандартных протоколов, и это опять же упирается в скромный размер экосистемы Хаскела, как и любого другого языка не из первой десятки
т.е. если писать большую систему на хаскеле, то недостающие библиотеки придётся дописывать самим. например, freearc включает 3-4 библиотеки общего назначения, аналоги пары из которых на данный момент уже есть в виде независимых библиотек. кстати, одна из оставшихся — библиотека многопоточной обработки, сейчас её оформить и закинуть на hackage было бы весьма актуально (это уже мысли вслх)
опять-таки, с очки зрения бизнеса это аргумент против хаскела, а с точки зрения хаскеллистов гораздо приятней сэкономить на разработке вдвое и в сэкономленное время написать библиотеку общего назначения, нежели педалить монструозный код, используя готовые библиотеки
Здравствуйте, thesz, Вы писали:
P>>Я целиком за использование хороших яп вместо плохих яп. Вопрос в том, что же такое хороший яп? Хороший яп — это тот, который позволяет тебе мыслить на более высоком уровне, чем до этого, будучи сам по себе простым до очевидности. Сорри за курсив :-) Хороший яп должен «fit my mind». Он не должен требовать огромного багажа знаний, чтобы начать его использовать. Пример однозначно хорошего языка — питон. Или С.
T>Перевод: "хороший яп — тот, что я знаю прямо сейчас."
Чушь.
Можешь читать мои слова буквально, без переводов?
У меня есть точка зрения, что такое хороший яп, а что — нет. Основная мысль в том, что реально хороший язык реально прост. Я ее высказал и попытался обосновать. Того, что ты усмотрел, в ней и близко нет. Замечания по сути есть?
T>В философии программирования недавно была ссылка: http://enfranchisedmind.com/blog/posts/programming-doesnt-suck-or-at-least-it-shouldnt/
Не поверишь, я видел эту ссылку еще до того, как она попала в «философию программирования» :-)
T>
Your language is hard to learn. My language is easy to learn, because I already know it. People won’t learn what they don’t already know.
T>Твоё высказывание прямо классическая демонстрация принципа.
T>Я думаю, что если специально стараться, так не получится. Значит, ты искренен.
T>Это хорошо. Значит, тебя можно переубедить. ;)
Я абсолютно искренен. Только вот того, что ты пытаешься мне пришить, руководствуясь стереотипами, во мне нет.
P>>Проблема хаскеля в том, что он, с одной стороны, высокоуровневый (что хорошо), а с другой — взрывает мозг при попытке хотя бы освоить хороший учебник вроде «Real World Haskell». Потому, что он реально сложен. И это плохо. Конечно, возможно, проблема в моей личной глупости. Но, честно говоря, я, как и все :-) считаю себя above average.
T>Я считаю себя above average, у меня взрывает мозг при изучении теории типов и я её намеренно изучаю: за взрывом мозга и за расширением сознания.
Рад за тебя. Это как-то противоречит моей мысли о том, что такому не место в мейнстриме?
P>>Что ж, теперь попробую доказать «не дает ничего». Использование хорошего яп в смысле, определенном выше — это однозначно правильно. Это надо делать при любой возможности. Но. Хаскель не удовлетворяет определению однозначно хорошего языка. Поэтому, вместе с высокоуровневостью он принесет в проект свою сложность. (До сих пор помню, как в одном из популярных учебников по хаскелю monomorphism restriction встречалось чуть ли не сразу после вещей проде 1 + 1). И в этом смысле, сам по себе факт использования хаскеля не дает ничего. Ты в чем-то выигрываешь, а в чем-то (и серьезно!) проигрываешь.
T>Если мы проигрываем (и серьёзно!) в не нужной для решения наших задач области, то мы выигрываем в общем и целом.
T>Я к чему. Сейчас задачи такие, что вред от использование Хаскеля минимален. В том смысле, что да, Хаскель сильно нетороплив, но сейчас быстрые процессора, да он, еще, и параллелится легко. И дальше по аналогии.
Ты пишешь какую-то ерунду. Где в моем сообщении упоминалась скорость? Там упоминалось другое слово на букву «с» — сложность.
P>>Am I clear?
T>Pretty clear.
Боюсь, ты по-быстрому загнал меня в стереотип тупых нелюбителей хаскеля и толком даже не прочитал, что я написал. Жаль.
И да, отвечать на сообщения, толком их не читая, а на лету подстраивая под стереотипы — попахивает фанатизмом. Это плохой пиар для хаскеля. «Энтузиазм заразителен, но фанатизм неотразим». Помни это, джедай :-)
RD>1. сделать так, чтобы этот софт был не конем в вакууме а смог общаться с другим софтом — не ясно как. Варианты типа "гонять строки по сокетам" не подходят.
У меня вот занедолго получилось интергировать простенький SQLBeautifier на хаскель в аксапту в виде использования dll.
То есть написать dll на хаскелле можно, ипользовать вроде тоже и что-то еще проскакивало по использованию .NET классов.
По крайней мере, можно писать какие-то сложные куски ПО с небольшим интерфейсом наружу и вставлять их в продукт в виде dll.
Здравствуйте, pgregory, Вы писали:
P>У меня есть точка зрения, что такое хороший яп, а что — нет. Основная мысль в том, что реально хороший язык реально прост.
Здравствуйте, lomeo, Вы писали:
L>Здравствуйте, pgregory, Вы писали:
P>>У меня есть точка зрения, что такое хороший яп, а что — нет. Основная мысль в том, что реально хороший язык реально прост.
L>Хаскель — прост.
Простые вещи можно объяснить на пальцах. Или в двух словах.
Не расскажешь ли, в двух словах
— что такое monomorphism restriction
— что такое монада
По поводу монад подсказка: сказать, что это перегруженный оператор «;» — значит не сказать ничего.
Еще. Скажи, найти среднее списка даблов — простая задача? Ответь, не компилируя, справится ли этот код:
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])
Если да, то насколько быстро? Если нет, то почему?
Здравствуйте, 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?
Думаю, справится. Можно написать код в два раза быстрее из-за двух проходов в существующем.
Только какое отношение это имеет к простоте языка?
Здравствуйте, 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? И что — он от этого перестанет выполнять свою задачу — считать среднее списка даблов?
Нечестно играешь. Хочешь честно — давай смотрим код на Хаскеле, спрашиваем себя, что он делает? Смотрим код на "реально простом" Си — делаем то же самое. Хорошо, не на Си, на Питоне. Берём задачу — смотрим её решение на Хаскеле, смотрим на другом языке, где показалось удобнее писать, где получилось быстрее написать, где работает правильнее.
А так — для Хаскеля и более тривиальные куски кода можно привести с вопросами "справится ли". Про Си уж молчу. А уж на что простой казалось бы язык!
Здравствуйте, 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();
Здравствуйте, 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>Сможете объяснить в двух словах, что такое коммутативное кольцо с единицей?
Нет. А вот что такое множество целых чисел (являющееся коммутативным кольцом с единицей, я правильно нашел подвох? :-) — не сомневаюсь.
Здравствуйте, 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 так же интуитивно, как и ООП? (Чувствую, как люди с горящими глазами бросились писать «Да! Да! Да!!!» :-)
Если так, то что же, я с этим не согласен. Если не очевидно, почему, могу попытаться обосновать.
Здравствуйте, BulatZiganshin, Вы писали: T>>Если мы таки о кривой работе стандартной библиотеке haskell с WinApi, то мне видится 2 нормальных решения: BZ>нет, мы о другом — о том, что FFI должен был предоставить операции и типы, скрывающие от программиста особенности платформы, после чего любой код, обращающийся к posix api, должен автоматом работать на обеих платформах
Это в смысле что не следует использовать haskell в винде? Всё равно будет глючить?
На винде нормальная реализация posix api ест в 2х видах cygwin и irix. Обе они не являются достаточно распространёнными.
Кстати, приведённый тобой пример был именно из WinApi.
Тот же python, честно закрывает от пользователя все эти несуразности вполне успешно, не кивая на кривую поддержку posix api.
Мне кажется, если уж позиционировать haskell систему программирования общего назначения, то уж работу с файлами то нужно сделать нормальную.
Так же как и библиотеку регулярных выражений и стандартную библиотеку работы с кодировками.
Иначе простые утилиты, приходится писать на python-е — в нём и с кодировками, и с файлами, и с регэкспами всё нормально.
Здравствуйте, Tonal-, Вы писали:
T>>>Если мы таки о кривой работе стандартной библиотеке haskell с WinApi, то мне видится 2 нормальных решения: BZ>>нет, мы о другом — о том, что FFI должен был предоставить операции и типы, скрывающие от программиста особенности платформы, после чего любой код, обращающийся к posix api, должен автоматом работать на обеих платформах T>Это в смысле что не следует использовать haskell в винде? Всё равно будет глючить?
это то, что предлагает мой оппонент. а я ему объяснил, почему это невозможно
Здравствуйте, pgregory, Вы писали:
P>Или ты реально считаешь, что FP так же интуитивно, как и ООП? (Чувствую, как люди с горящими глазами бросились писать «Да! Да! Да!!!»
P>Если так, то что же, я с этим не согласен. Если не очевидно, почему, могу попытаться обосновать.
бытиё определяет сознание. ты знаешь, что у некоторых племён дикарей принято дарить женщинам половые органы растений? согласись, странный обычай. причём делается это ровно раз в год, в годовщину события, связанного с наиболее унижаемой прослойкой этих женщин. словом, нелепица на нелепице. тем не менее, дикари свои обычаи странными не считают. они просто живут так, как жили их предки, и верят что их обычаи совершенно нормальны и естественны. но мы-то, цивилизованные люди, так не считаем! возьмёшься доказать им, что их традиции глупы?
Здравствуйте, pgregory, Вы писали:
K>>Сможете объяснить в двух словах, что такое коммутативное кольцо с единицей? P>Нет. А вот что такое множество целых чисел (являющееся коммутативным кольцом с единицей, я правильно нашел подвох? — не сомневаюсь.
Начнем с того, что множество целых чисел таковым не является, а является таковым множество целых чисел с двумя бинарными операциями над ним — сложением и умножением, но принимая во внимание ваш ответ здесь
я думаю, что вы поняли первую половину аналогии правильно. Подвоха же никакого нет. Я просто пытаюсь понять, как вы определяете что сложно, а что нет. Пока у меня это не получается — наоборот я в смятении после вашего утверждения о том, что целые числа это проще чем кольцо. Звучит как "Планета Земля на несколько порядков проще, чем материальная точка".
Тут точно что-то не так. Поэтому, раз уж вы не сомневаетесь, что сможете в двух словах объяснить что такое множество целых чисел (да еще самое страшное, не будучи уверенным при этом что сможете объяснить что такое кольцо) может вы прямо сейчас в двух словах и объясните? Мне кажется что это будет гораздо худшее объяснение, чем объяснение монад как перегруженного оператора ;.
P>Так что — разворачивай!
Ну а там и развернем, если понадобится, когнечно.
... << RSDN@Home 1.2.0 alpha 4 rev. 1110>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, BulatZiganshin, Вы писали:
BZ>написано в 93-м году. нынешней молодёжи трудно представить, как все 80-е годы ООП боролось за умы программистов, имея в те времена точно такую же ауру мощной, но трудноиспользуемой технологии
Трудноиспользуемой ООП не была. ООП я начал использовать на втором курсе универа, после прочтения первых нескольких глав первого издания книги "Язык программирования C++". Причем я тогда даже не знал, что это ООП. А узнал об этом спустя несколько лет.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>Здравствуйте, pgregory, Вы писали:
P>>Или ты реально считаешь, что FP так же интуитивно, как и ООП? (Чувствую, как люди с горящими глазами бросились писать «Да! Да! Да!!!» :-)
P>>Если так, то что же, я с этим не согласен. Если не очевидно, почему, могу попытаться обосновать.
BZ>бытиё определяет сознание. ты знаешь, что у некоторых племён дикарей принято дарить женщинам половые органы растений? согласись, странный обычай. причём делается это ровно раз в год, в годовщину события, связанного с наиболее унижаемой прослойкой этих женщин. словом, нелепица на нелепице. тем не менее, дикари свои обычаи странными не считают. они просто живут так, как жили их предки, и верят что их обычаи совершенно нормальны и естественны. но мы-то, цивилизованные люди, так не считаем! возьмёшься доказать им, что их традиции глупы?
Очень увлекательно.
Скажи, ты споришь, чтобы лучше понять свою и чужую точку зрения, или чтобы любой ценой оставить последнее слово за собой?
Неужели моя позиция до сих пор не ясна, и есть необходимость натягивать эти нелепые аналогии с дикарями?
Здравствуйте, Klapaucius, Вы писали:
K>Здравствуйте, pgregory, Вы писали:
K>>>Сможете объяснить в двух словах, что такое коммутативное кольцо с единицей? P>>Нет. А вот что такое множество целых чисел (являющееся коммутативным кольцом с единицей, я правильно нашел подвох? :-) — не сомневаюсь.
K>Начнем с того, что множество целых чисел таковым не является, а является таковым множество целых чисел с двумя бинарными операциями над ним — сложением и умножением,
Начнем с того, что слова «коммутативное кольцо с единицей» также, строго говоря, требуют дополнения. Давай не будем придираться к словам, ок?
K>но принимая во внимание ваш ответ здесь
я думаю, что вы поняли первую половину аналогии правильно. Подвоха же никакого нет. Я просто пытаюсь понять, как вы определяете что сложно, а что нет. Пока у меня это не получается — наоборот я в смятении после вашего утверждения о том, что целые числа это проще чем кольцо. Звучит как "Планета Земля на несколько порядков проще, чем материальная точка".
Забавно.
K>Тут точно что-то не так. Поэтому, раз уж вы не сомневаетесь, что сможете в двух словах объяснить что такое множество целых чисел (да еще самое страшное, не будучи уверенным при этом что сможете объяснить что такое кольцо) может вы прямо сейчас в двух словах и объясните? Мне кажется что это будет гораздо худшее объяснение, чем объяснение монад как перегруженного оператора ;.
Даже не знаю, ты (можно на ты — не против?) реально хочешь от меня услышать рассказ о том, что «у Пети было 2 яблока, а у Маши — целых 239»?
Это — просто. Этому учат в детей садике. Коммутативное кольцо с единицей — это сложно. Этому учат в вузах.
Здравствуйте, pgregory, Вы писали:
P>Забавно то, что никто не написал реального определения монады.
Потому что это не было бы запрошенным объяснением на пальцах.
P>Итак, монада — это некая сущность, для которой мы можем определить эти четыре операции так, что они будут удовлетворять monad laws. P>Поэтому да, монада — это сложная штука.
И что в ней сложного? С чисто практической точки зрения?
P>Или ты не разделяешь мое мнение, что «коммутативное кольцо с единицей» — на пару порядков более сложное понятие, чем «целое число»?
Целые числа — такое же болото, как и вся математика.
Здравствуйте, pgregory, Вы писали:
K>>Тут точно что-то не так. Поэтому, раз уж вы не сомневаетесь, что сможете в двух словах объяснить что такое множество целых чисел (да еще самое страшное, не будучи уверенным при этом что сможете объяснить что такое кольцо) может вы прямо сейчас в двух словах и объясните? Мне кажется что это будет гораздо худшее объяснение, чем объяснение монад как перегруженного оператора ;. P>Даже не знаю, ты (можно на ты — не против?) реально хочешь от меня услышать рассказ о том, что «у Пети было 2 яблока, а у Маши — целых 239»?
Ну я и говорил — объяснение хуже чем перегруженная ;
P>Это — просто. Этому учат в детей садике. Коммутативное кольцо с единицей — это сложно. Этому учат в вузах.
С монадами то же самое.
Можно сначала просто "считать", а потом, в институте, систематизировать разрозненные практические знания.
P>Am I clear?
А я?
... << RSDN@Home 1.2.0 alpha 4 rev. 1110>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Tonal-, Вы писали:
T>Мне кажется, если уж позиционировать haskell систему программирования общего назначения, то уж работу с файлами
А можно напомнить, что с ними не так?
T>Так же как и библиотеку регулярных выражений
+1
Здравствуйте, Mr.Cat, Вы писали:
T>>Мне кажется, если уж позиционировать haskell систему программирования общего назначения, то уж работу с файлами MC>А можно напомнить, что с ними не так?
"но я не понял, что ты имела в виду"
уже сколько треплемся о том, что стд. библиотека не держит файлы с юникодными именами
Здравствуйте, Klapaucius, Вы писали:
K>Здравствуйте, pgregory, Вы писали:
P>>Даже не знаю, ты (можно на ты — не против?) реально хочешь от меня услышать рассказ о том, что «у Пети было 2 яблока, а у Маши — целых 239»?
K>Ну я и говорил — объяснение хуже чем перегруженная ;
Ерунда. Это не объяснение понятия коммутативного кольца, это объяснение понятия целого числа. А вот про ; — это именно попытка объяснения сложной штуки под названием «монада». Фиговая. Моя мысль о том, что понятие «целые числа» != понятию «коммутативное кольцо» понятна, надеюсь?
P>>Это — просто. Этому учат в детей садике. Коммутативное кольцо с единицей — это сложно. Этому учат в вузах.
K>С монадами то же самое. K>Можно сначала просто "считать", а потом, в институте, систематизировать разрозненные практические знания.
То есть, наконец-то, очевидный факт, что Maybe — это просто, а монады — это сложно, признан? Ура!
Здравствуйте, BulatZiganshin, Вы писали:
BZ>Здравствуйте, pgregory, Вы писали:
P>>Неужели не очевидно, что весь разговор именно об этом?! Программисты, например, в большинстве своем (нет, лично я не измерял) не знают, что целые числа образуют коммутативное кольцо с единицей (а также абелеву группу по ... и еще ... и еще ...). И это не мешает им писать программы, и делать это хорошо.
BZ>а для программирования на хаскеле необходимо знать теорию категорий?
Надеюсь, ты — исключение, и общая культура спора на рсдн все же выше.
Черт, я уже, честно говоря, устал разжевывать тебе одно и то же. Ты что, реально до сих пор не понял, о чем я пишу? Подумай о чем-нибудь отвлеченном, потом перечитай. Надеюсь, это поможет.
В последний раз, специально для тебя, разжую.
Для программирования простых вещей на хаскеле необходимо знать сложное понятие монада. (Посмотри оглавление Real World Haskell, прежде чем возражать, ок?) Это плохо. Ни в одном сколько-нибудь распространенном языке, чтобы оперировать числами, не требуется знать, что такое коммутативное кольцо. (Прежде чем возражать, раздобудь ссылку, это опровергающую, ок?)
Это моя позиция, и я ее аргументировал. Ясно?
Еслы ты не согласен, нормально аргументируй свою позицию, или не пиши ничего. Если твои ответы и дальше будут представлять из себя придирки и передергивания, я буду их просто игнорировать.
Когда это еще было новостью, здесь отгремел флеймовый тред. Комментариев там хоть отбавляй.
От себя хочу заметить следующее: SICP — это вводный курс программирования вообще — он ФП в такой же степени что и ООП.
Кроме того, это противоречит вашим идеям — Схема значительно проще Питона — и для программирования и с точки зрения реализации интерпретатора. Я не видел питонизированный SICP, но мне страшно представить реализацию интерпретатора ленивого питона на питоне.
P>Неужели не очевидно, что весь разговор именно об этом?! Программисты, например, в большинстве своем (нет, лично я не измерял) не знают, что целые числа образуют коммутативное кольцо с единицей (а также абелеву группу по ... и еще ... и еще ...).
Допустим.
P>И это не мешает им писать программы, и делать это хорошо.
А вот это совсем не очевидно. А доказать вы это совершенно точно не сможете.
С другой стороны дискретная математика включена в программу подготовки программистов не просто так. Хотя в таких пределах алгебру изучают вообще все инженеры.
P>За простыми вещами должны следовать сложные, но не наоборот. Don't pay for what you don't need. Make simple things easy, but hard things possible. И так далее. Что здесь не ясно???
Мне не ясна ваша методика определения сложности.
Кроме того, мне не ясно — вы предъявляете претензии к языку или к структуре образовательных курсов по этому языку?
Ну, допустим GITH вашим требованиям не соотвествуют — а YAHT и RWH — вполне.
... << RSDN@Home 1.2.0 alpha 4 rev. 1110>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, pgregory, Вы писали:
P>Ерунда. Это не объяснение понятия коммутативного кольца, это объяснение понятия целого числа.
Это не объяснение понятия целого числа. Объяснение в предложенном вам стиле занимает 2-3 учебных года.
P>А вот про ; — это именно попытка объяснения сложной штуки под названием «монада». Фиговая.
Она лучше чем ваша попытка. Начнем с того, что аналогия с ; — законченная мысль, а вы объяснение целых чисел едва ли начали.
Целые числа и операции над ними изучают 10 лет, и в том числе изучаются все войства кольца — ведь объяснение кольца должно быть включено в объяснение целых чисел в любом случае. Это-то понятно? Какие из свойств коммутативного кольца с единицей вы не изучали в школе? Разве что только слово "кольцо" не упоминали — вот и все. А все эти группы и кольца изучаются за еденицы академических часов — просто чтобы показать общность свойств разных объектов, которую можно и самому заметить.
С монадами то же самое. Вы утверждаете, что в RWH без привлечения монад ничего не объясняется — но ведь это не правда. Там монады сначала изобретаются трижды — для IO, для Maybe и для парсеров — и только потом эта общность свойств получает название "монада" — именно так это происходит и при изучении чисел и алгебраических структур.
P>Моя мысль о том, что понятие «целые числа» != понятию «коммутативное кольцо» понятна, надеюсь?
Понятно, конечно. Мы сравниваем попытки объяснить X и объяснить Y — это не означает, что мы считаем, что между X и Y нет разницы.
K>>Можно сначала просто "считать", а потом, в институте, систематизировать разрозненные практические знания. P>То есть, наконец-то, очевидный факт, что Maybe — это просто, а монады — это сложно, признан? Ура!
Нет, признан факт, что то, что вам уже известно вы считаете простым, а то, что неизвестно — сложным. Понять что такое Maybe и не понять при этом, что такое монада невозможно, точно также как нельзя научиться считать и при этом не узнать, что a + 0 = a.
... << RSDN@Home 1.2.0 alpha 4 rev. 1110>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, pgregory, Вы писали:
K>>Кроме того, это противоречит вашим идеям — Схема значительно проще Питона — и для программирования и с точки зрения реализации интерпретатора.
P>С первым не согласен. Continuations — это жесть, по аналогии с монадами. Мне это не нравится.
На схеме можно спокойно писать не подозревая о продолжениях.
Питон конечно прост, особенно его правила разрешения при множественном наследовании и концепция метаклассов
Здравствуйте, Klapaucius, Вы писали:
K>Здравствуйте, pgregory, Вы писали:
P>>А вот про ; — это именно попытка объяснения сложной штуки под названием «монада». Фиговая.
K>Она лучше чем ваша попытка. Начнем с того, что аналогия с ; — законченная мысль, а вы объяснение целых чисел едва ли начали.
Да ладно! Законченная-то законченная, только ничего не объясняющая. Иначе все монадные туториалы представляли бы из себя одну-единственную фразу.
K>Целые числа и операции над ними изучают 10 лет, и в том числе изучаются все войства кольца — ведь объяснение кольца должно быть включено в объяснение целых чисел в любом случае. Это-то понятно? Какие из свойств коммутативного кольца с единицей вы не изучали в школе? Разве что только слово "кольцо" не упоминали — вот и все.
Это принципиально. Я именно об этом и пишу.
K>А все эти группы и кольца изучаются за еденицы академических часов — просто чтобы показать общность свойств разных объектов, которую можно и самому заметить. K>С монадами то же самое. Вы утверждаете, что в RWH без привлечения монад ничего не объясняется — но ведь это не правда. Там монады сначала изобретаются трижды — для IO, для Maybe и для парсеров — и только потом эта общность свойств получает название "монада" — именно так это происходит и при изучении чисел и алгебраических структур.
Есть большая разница. После окончания нормальной школы, человек может хорошо решать кучу практических задач. При этом, он может ни разу в жизни не слышать о коммутативных кольцах.
В случае с хаскелем это неверно. Практически невозможно написать сколько-нибудь нетривиальную программу, не зная, что такое монада. That's the whole point.
K>>>Можно сначала просто "считать", а потом, в институте, систематизировать разрозненные практические знания. P>>То есть, наконец-то, очевидный факт, что Maybe — это просто, а монады — это сложно, признан? Ура!
K>Нет, признан факт, что то, что вам уже известно вы считаете простым, а то, что неизвестно — сложным. Понять что такое Maybe и не понять при этом, что такое монада невозможно, точно также как нельзя научиться считать и при этом не узнать, что a + 0 = a.
Ну неужели, печатая это, вы не поймали себя на том, что куда честнее было бы привести аналогию «точно также как нельзя научиться считать и при этом не узнать, что такое коммутативное кольцо с единицей»?!
А это ставит все на свои места, с моей точки зрения.
Еще раз. Я просто высказываю свою точку зрения. Я не считаю ее единственно правильной. Хотя и считаю, что у нее есть серьезные обоснования. Время покажет, кто прав. Вы понимаете мою точку зрения? Я вашу, думаю, понимаю.
Здравствуйте, pgregory, Вы писали:
P>Для программирования простых вещей на хаскеле необходимо знать сложное понятие монада. (Посмотри оглавление Real World Haskell, прежде чем возражать, ок?) Это плохо. Ни в одном сколько-нибудь распространенном языке, чтобы оперировать числами, не требуется знать, что такое коммутативное кольцо. (Прежде чем возражать, раздобудь ссылку, это опровергающую, ок?)
Вот ты можешь объяснить, почему монада в Хаскеле — это сложно, а ООП в Питоне — просто? Это возвращение к дискуссии о том, что сложность в обучении и использовании — разные вещи.
Ещё момент. Абстракция — это хорошо. Я в это верю, как ты веришь в то, что реальный язык реально прост. Аргументом для меня является тот факт, что программирование — это по большей части избавление от дублирования кода. Именно для этого служит абстракция. Абстракция может быть сложной в изучении, как ООП или монада (которая, кстати, несравненно проще). Это никак не отменяет её пользы в применении. И простоты, и лёгкости, и удобства.
Поэтому для меня простой язык — это язык, в котором есть высокоуровневые абстракции. И чем выше уровень, тем меньше зависимость от деталей реализации, а значит лучше, т.к. ближе к предметной области. При этом сложность в изучении этих абстракций (или инструментов их порождающих) не принимается во внимание Поэтому реально простой язык вполне может быть сложным в изучении.
pgregory wrote:
> Для программирования простых вещей на хаскеле необходимо знать сложное > понятие монада. (Посмотри оглавление Real World Haskell, прежде чем > возражать, ок?) Это плохо. Ни в одном сколько-нибудь распространенном > языке, чтобы оперировать числами, не требуется знать, что такое > коммутативное кольцо. (Прежде чем возражать, раздобудь ссылку, это > опровергающую, ок?)
Тоже не согласен. Для того, чтобы понять как использовать do, о монадах знать не требуется. А вот когда объясняешь, почему char a = 100 + 100 равно чёрт знает чему — приходится объяснять и о кольцах.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ., Вы писали:
.>Тоже не согласен. Для того, чтобы понять как использовать do, о монадах знать не требуется. А вот когда объясняешь, почему char a = 100 + 100 равно чёрт знает чему — приходится объяснять и о кольцах.
Здравствуйте, ., Вы писали:
.>pgregory wrote:
>> Для программирования простых вещей на хаскеле необходимо знать сложное >> понятие монада. (Посмотри оглавление Real World Haskell, прежде чем >> возражать, ок?) Это плохо. Ни в одном сколько-нибудь распространенном >> языке, чтобы оперировать числами, не требуется знать, что такое >> коммутативное кольцо. (Прежде чем возражать, раздобудь ссылку, это >> опровергающую, ок?) .>Тоже не согласен. Для того, чтобы понять как использовать do, о монадах знать не требуется.
RWH о них рассказал, потому что это просто занятно, или же потому, что их реально надо знать? Что-то он про коммутативные кольца молчит. Как и Страуструп молчит о том, что шаблоны плюсов — Тьюринг-полный ФЯП. С чего бы?
Заодно, сказал раз, скажи и два. Haskell for Dummies, где нет упоминаний о монадах — в студию!
Здравствуйте, FR, Вы писали:
FR>Есть такая вещь как порог вхождения. Если для того чтобы просто начать писать даже что-то простое и легкое нужно сильно напрягать мозги, то мало кто это будет делать, независимо от того насколько сложен или прост язык в целом. Например у того же питона этот порог очень низок, хотя в нем есть и реально сложные вещи, но можно спокойно писать не подозревая о них. Другой пример рефал и Smalltalk, оба по сути очень просты, но начальный порог который нужно преодолеть достаточно высок и поэтому они малопопулярны. У Хаскеля этот порог еще выше.
Да я согласен, согласен. Только я о другом спрашивал всё же
P>>>Отсюда я делаю вывод, что хорошесть программы абсолютно ортогональна хорошести яп, на котором она написана. T>>Это если мы смотрим уже на готовые программы. T>>А если мы будем смотреть на стартовавшие и не завершённым программы, то всё будет по другому. T>>"Хорошесть" завершённой программы будет определяться языком программирования. P>Не понял мысль. Это следует читать как «когда реальные программы на хаскеле будут, наконец, написаны, они будут очень круты»? С чего вдруг? Почему, кроме GHC, таких программ сейчас нет? Если есть — примеры в студию!
В моих трёх строках нет про Хаскель. Есть про хороший язык программирования.
P>В этой презентации (от 24 сентября 2005 года) утверждается, что у darcs — 91 контрибьютор, у git — 79. На тот момент. Вот только, согласно википедии, разработка darcs началась на 3 года раньше, чем git'а. На момент презентации git'у было 4-5 месяцев.
Это какого darcs? Что на плюсах или на что Хаскеле?
T>>Популярность git определяется Линусом Торвальдсом и ничем другим. P>Чушь.
За три месяца его бы не подхватило такое количество народу, не будь он написан Линусом.
А если кто-то, кроме Линуса, написал бы такое на простых Сях, как написан git, то его бы съели без разделки тушки.
Популярность git и его язык реализации определяется популярностью Линуса Торвальдса и ничем больше.
P>Популярность git сейчас определяется только тем, что он банально лучше всех остальных. Практически по всем параметрам. Зачастую — на порядок.
Насчёт "сейчас" — отлично.
"Практические по всем" параметрам, как я понимаю, включает в себя и разнообразные возможности.
Cherry picking, anyone?
Я с него не слезу.
P>Так что разворачивай, как говориться!
Здравствуйте, lomeo, Вы писали:
L>Здравствуйте, pgregory, Вы писали:
P>>Для программирования простых вещей на хаскеле необходимо знать сложное понятие монада. (Посмотри оглавление Real World Haskell, прежде чем возражать, ок?) Это плохо. Ни в одном сколько-нибудь распространенном языке, чтобы оперировать числами, не требуется знать, что такое коммутативное кольцо. (Прежде чем возражать, раздобудь ссылку, это опровергающую, ок?)
L>Вот ты можешь объяснить, почему монада в Хаскеле — это сложно, а ООП в Питоне — просто? Это возвращение к дискуссии о том, что сложность в обучении и использовании — разные вещи.
Попытаюсь объяснить. ООП — это объекты + сообщения/методы. Простейший способ ООП декомпозиции системы — написать текст, потом заменить существительные на объекты, а глаголы — на методы. (Все, конечно, сложнее, но идею, надеюсь, ты понял). Яблоко — объект. Человек — объект. У человека есть метод «спеть песню». У человека есть состояние. И у яблока есть состояние.
Лично я не могу привести таких же аналогий для фп. Можешь попробовать, я буду рад, если это возможно.
Side note: я не утверждаю, что ООП сколько-нибудь хорошо аппроксимирует реальность. На этот счет у меня самого к ООП большие претензии. Я утверждаю, что ООП — это просто и на пальцах. Это яблоки и кнопочки.
L>Ещё момент. Абстракция — это хорошо. Я в это верю, как ты веришь в то, что реальный язык реально прост. Аргументом для меня является тот факт, что программирование — это по большей части избавление от дублирования кода.
Программирование — это искусство абстракции с ограничениями.
L>Поэтому для меня простой язык — это язык, в котором есть высокоуровневые абстракции. И чем выше уровень, тем меньше зависимость от деталей реализации, а значит лучше, т.к. ближе к предметной области.
L>При этом сложность в изучении этих абстракций (или инструментов их порождающих) не принимается во внимание ;-) Поэтому реально простой язык вполне может быть сложным в изучении.
Вот здесь я не согласен. Я не вижу причины, по которой язык очень высокого уровня должен быть хоть сколько-нибудь сложным. Представь его в виде слоеной штуки, где каждый уровень выше и проще предыдущего в том же смысле, что си выше и проще ассемблера.
L>Где у меня ошибка в рассуждениях?
Нигде. Просто у нас разные мнения. Если бы существовало единственное правильное, этого спора просто не было бы.
pgregory wrote:
> RWH о них рассказал, потому что это просто занятно, или же потому, что > их реально надо знать? Что-то он про коммутативные кольца молчит. Как и
Научить пользоваться списками, do, Maybe и прочим можно и без монад. А вот взорвать мозг и сказать, что все эти на первый взгляд абсолютно разные вещи — лишь частные случаи некой штуки, которую мы называем монада. По-моему, это просто красиво.
> Страуструп молчит о том, что шаблоны плюсов — Тьюринг-полный ФЯП. С чего бы?
Далеко не все программеры, к сожалению, понимают что онзачает "Т-п ФЯП". Поэтому это упоминание ничего нового не даст. Мало того, эта Т-п шаблонов — настолько монстроидальна, что лучше об этом забыть как о страшном сне. Километровые совершенно неосымсливаемые сообщения об ошибках, время компиляции... брр.. Эстетики никакой.
> Заодно, сказал раз, скажи и два. Haskell for Dummies, где нет упоминаний > о монадах — в студию!
А ты мне C for Dummies где нет этой злобной арифметики указателей, о которую столько копий сломали.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, pgregory, Вы писали:
P>Попытаюсь объяснить. ООП — это объекты + сообщения/методы. Простейший способ ООП декомпозиции системы — написать текст, потом заменить существительные на объекты, а глаголы — на методы. (Все, конечно, сложнее, но идею, надеюсь, ты понял). Яблоко — объект. Человек — объект. У человека есть метод «спеть песню». У человека есть состояние. И у яблока есть состояние.
P>Лично я не могу привести таких же аналогий для фп. Можешь попробовать, я буду рад, если это возможно.
функция — это отображение входных данных в выходные. к примеру, если у тебя стакан наполовину пуст, то функция id отобразит его в стакан, который наполовину полон
Как приятно отвечать, когда точно знаешь, что оппонент не прав!
Здравствуйте, thesz, Вы писали:
P>>В этой презентации (от 24 сентября 2005 года) утверждается, что у darcs — 91 контрибьютор, у git — 79. На тот момент. Вот только, согласно википедии, разработка darcs началась на 3 года раньше, чем git'а. На момент презентации git'у было 4-5 месяцев.
T>Это какого darcs? Что на плюсах или на что Хаскеле?
У тебя, извини, википедия перестала открываться?
«Darcs evolved out of David Roundy's efforts to design a new patch format for GNU arch in June 2002. These discussions didn't lead to any code being committed to arch, but did lead to his theory of patches. After writing an initial version of darcs in C++, the Haskell version was written in Autumn 2002 and released to the public in April 2003.»
«The development of Git began on 3 April 2005.[33] The project was announced on 6 April,[34] and became self-hosting as of 7 April.[33] The first merge of multiple branches was done on 18 April.[35] Torvalds achieved his performance goals; on 29 April, the nascent Git was benchmarked recording patches to the Linux kernel tree at the rate of 6.7 per second.[36] On 16 June, the kernel 2.6.12 release was managed by Git.[37]»
И да, если то, что ты писал, оказалось неверным, мне было бы очень приятно, если бы ты не просто скипал это при ответах, а писал что-то типа «да, был не прав» Со своей стороны подобное обещаю.
T>За три месяца его бы не подхватило такое количество народу, не будь он написан Линусом.
Возможно. И?
T>А если кто-то, кроме Линуса, написал бы такое на простых Сях, как написан git, то его бы съели без разделки тушки.
а) спорно
б) ни о чем
T>Популярность git и его язык реализации определяется популярностью Линуса Торвальдса и ничем больше.
Еще раз, это чушь. Список крупных проектов, использующих git, я уже приводил здесь
. Ок, вычеркнем из него git и linux. А теперь докажи свой забавный тезис о том, что оставшиеся выбрали его из-за неимоверной любви к Линусу.
T>"Практические по всем" параметрам, как я понимаю, включает в себя и разнообразные возможности.
T>Cherry picking, anyone?
T>Я с него не слезу.
Зря, очень зря — это заранее проигрышная позиция.
Для начала, cherry-pick есть и в git, и в hg. Да, безо всяких алгебр. Тупее некуда.
Но. Цитирую свой первый пост в теме:
«Уважаемые защитники ФП! Здоровы ли вы? Работали ли вы когда-нибудь с исходным кодом программ? Известно ли вам, что между патчами существуют и _более_ сложные зависимости, чем то, что два патча один за другим модифицируют одно и то же место кода? (И, более того, эти более сложные, неявные, зависимости — правило, а не исключение?)
До тех пор, пока эта мега-алгебра не сможет разрешать такие зависимости (а этого она не сможет никогда — к слову, она хоть компилируемость программы (хоть на хаскелле) гарантирует при существующем авто-черри-пике?), она будет практически бесполезна. Черри-пик всегда будет операцией, при выполнении которой надо 7 раз подумать. И никакая алгебра тут не спасет.»
Не согласен?
И далее:
«Алгебра патчей, как мы видим, это киллер фича, да? И то, что другие dvcs ее не имеют, ставит их на ступеньку ниже, так? Очевидно, что любой вменяемый разработчик должен выбрать darcs, получается. А что мы имеем на самом деле?»
Я-то писал, что я вижу. Может, у тебя на этот счет другая точка зрения, и лидеры проектов только и ждут, когда-же наконец git получит алгебру патчей?
T>http://darcs.net/ — багтрекер есть T>http://git-scm.com/ — багтрекера нет.
T>Почему так, я не знаю. Но быстро сравнить серьёзность и количество открытых ошибок я не могу.
Я помогу. Быстро сравни серьезность и количество использующих их проектов. Начни с GHC.
Здравствуйте, ., Вы писали:
.>pgregory wrote:
>> RWH о них рассказал, потому что это просто занятно, или же потому, что >> их реально надо знать? Что-то он про коммутативные кольца молчит. Как и .>Научить пользоваться списками, do, Maybe и прочим можно и без монад. А вот взорвать мозг и сказать, что все эти на первый взгляд абсолютно разные вещи — лишь частные случаи некой штуки, которую мы называем монада. По-моему, это просто красиво.
То есть, ты считаешь, что везде о монадах пишут просто для красоты изложения? Здесь наши взгляды серьезно расходятся.
>> Страуструп молчит о том, что шаблоны плюсов — Тьюринг-полный ФЯП. С чего бы? .>Далеко не все программеры, к сожалению, понимают что онзачает "Т-п ФЯП". Поэтому это упоминание ничего нового не даст. Мало того, эта Т-п шаблонов — настолько монстроидальна, что лучше об этом забыть как о страшном сне. Километровые совершенно неосымсливаемые сообщения об ошибках, время компиляции... брр.. Эстетики никакой. ;)
Согласен, но это не по теме.
>> Заодно, сказал раз, скажи и два. Haskell for Dummies, где нет упоминаний >> о монадах — в студию! .>А ты мне C for Dummies где нет этой злобной арифметики указателей, о которую столько копий сломали.
1) Арифметика указателей злобная, но простая. Она — арифметика.
2) Я первый спросил :-)
Здравствуйте, pgregory, Вы писали:
P>Лично я не могу привести таких же аналогий для фп. Можешь попробовать, я буду рад, если это возможно.
Ага! И у нас пойдёт философский спор существительные против глаголов
P>Вот здесь я не согласен. Я не вижу причины, по которой язык очень высокого уровня должен быть хоть сколько-нибудь сложным. Представь его в виде слоеной штуки, где каждый уровень выше и проще предыдущего в том же смысле, что си выше и проще ассемблера.
Я не говорил "должен", я говорил "может". Слоёная штука относится к обучению, IMHO.
P>>>Я целиком за использование хороших яп вместо плохих яп. Вопрос в том, что же такое хороший яп? Хороший яп — это тот, который позволяет тебе мыслить на более высоком уровне, чем до этого, будучи сам по себе простым до очевидности. Сорри за курсив Хороший яп должен «fit my mind». Он не должен требовать огромного багажа знаний, чтобы начать его использовать. Пример однозначно хорошего языка — питон. Или С. T>>Перевод: "хороший яп — тот, что я знаю прямо сейчас." P>Чушь. P>Можешь читать мои слова буквально, без переводов?
Да у тебя именно это и написано. Открытым текстом.
"Перевод", конечно, надо было бы заменить на "тезис высказывания", моя вина.
P>У меня есть точка зрения, что такое хороший яп, а что — нет. Основная мысль в том, что реально хороший язык реально прост. Я ее высказал и попытался обосновать. Того, что ты усмотрел, в ней и близко нет. Замечания по сути есть?
"Реально прост" чем определяется?
Хаскель реально прост теоретически. У него внутре неонка, то есть, ЛИ с нормальным порядком упрощений. Все его конструкции могут быть записаны на этом ЛИ. Да даже типы у него функции:
instance Monad m where-- m - параметр
return :: m a -- из этого следует, что m - функция из типа в тип.
...
С помощью ЛИ можно сделать всё, что есть внутри Хаскеля. if-then-else, if-then, циклы. Даже сравнение с образцом. Type safe pattern matching combinators
Coq/Agda2 ещё проще в теоретическом плане. В Coq товарищи ради прикола сделали реализацию типов классов, не выходя за рамки языка. То же самое я сделал для Agda2 после небольшого количества экспериментов.
Tcl. Надо выучить, что такое список и как он связан с синтаксисом команды. И как протаскиваются коды исключений. Далее делается сравнение с образцом на тикле и почти всё, что душе угодно. Я это использовал во внутреннем компиляторе с SQL constraints.
Пролог. Отличная штука.
Теперь смотрим на Питон. Можно ли выделить минимальное подмножество Питона, на котором можно выразить всё остальное в Питоне? Можем ли мы расширить язык новыми управляющими конструкциями?
Смотрим на Си, C++, C# или Java. Система типов совершенно не связана с моделью вычислений. В C++ этот отрыв ещё сильней.
Кто оказывается "реально прост"?
Тот, что ты знаешь прямо сейчас и похож на уже знакомое, или то, что ты можешь прогнуть под себя с минимумом усилий после изучения?
Your language is hard to learn. My language is easy to learn, because I already know it. People won’t learn what they don’t already know.
T>>Твоё высказывание прямо классическая демонстрация принципа. T>>Я думаю, что если специально стараться, так не получится. Значит, ты искренен. T>>Это хорошо. Значит, тебя можно переубедить. P>Я абсолютно искренен. Только вот того, что ты пытаешься мне пришить, руководствуясь стереотипами, во мне нет.
Перечисли стереотипы, которыми я руководствуюсь.
Мне, что-то, начали надоедать наезды ad hominem.
P>>>Проблема хаскеля в том, что он, с одной стороны, высокоуровневый (что хорошо), а с другой — взрывает мозг при попытке хотя бы освоить хороший учебник вроде «Real World Haskell». Потому, что он реально сложен. И это плохо. Конечно, возможно, проблема в моей личной глупости. Но, честно говоря, я, как и все считаю себя above average. T>>Я считаю себя above average, у меня взрывает мозг при изучении теории типов и я её намеренно изучаю: за взрывом мозга и за расширением сознания. P>Рад за тебя. Это как-то противоречит моей мысли о том, что такому не место в мейнстриме?
Да. Моя мысль вот какая: интеллектуальной трусости не место в мейнстриме.
P>>>Что ж, теперь попробую доказать «не дает ничего». Использование хорошего яп в смысле, определенном выше — это однозначно правильно. Это надо делать при любой возможности. Но. Хаскель не удовлетворяет определению однозначно хорошего языка. Поэтому, вместе с высокоуровневостью он принесет в проект свою сложность. (До сих пор помню, как в одном из популярных учебников по хаскелю monomorphism restriction встречалось чуть ли не сразу после вещей проде 1 + 1). И в этом смысле, сам по себе факт использования хаскеля не дает ничего. Ты в чем-то выигрываешь, а в чем-то (и серьезно!) проигрываешь. T>>Если мы проигрываем (и серьёзно!) в не нужной для решения наших задач области, то мы выигрываем в общем и целом. T>>Я к чему. Сейчас задачи такие, что вред от использование Хаскеля минимален. В том смысле, что да, Хаскель сильно нетороплив, но сейчас быстрые процессора, да он, еще, и параллелится легко. И дальше по аналогии. P>Ты пишешь какую-то ерунду. Где в моем сообщении упоминалась скорость? Там упоминалось другое слово на букву «с» — сложность.
Okay, mea culpa.
Но и со сложностью ты перегнул. Хаскель не сложней C++, как язык, а в использовании проще, чем Java.
Бляха муха, вот три основных части: функции + алгебраические типы + монады.
У меня 90% кода такого.
P>>>Am I clear? T>>Pretty clear. P>Боюсь, ты по-быстрому загнал меня в стереотип тупых нелюбителей хаскеля и толком даже не прочитал, что я написал. Жаль.
В этом нет ничего страшного. Являться тебе в снах и хохотать "ХА-ХА-ХА-ХАСКЕЛЬ!!!" над застывшим в ужасе тобой я не буду.
Поскольку ты уже выбрал свою синюю пилюлю, то и жалеть не о чем.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, pgregory, Вы писали:
P>Да ладно! Законченная-то законченная, только ничего не объясняющая. Иначе все монадные туториалы представляли бы из себя одну-единственную фразу.
Цель монадных тьюториалов — научить вас новой абстракции. Есть другой путь, по нему пошли Scala и C# — делать вид, что за монадами нет никакой абстракции, а просто есть некоторые удобные фичи языка. В "Programming in Scala" на 514 странице вскользь
упоминается, что "for comprehensions" — это и есть монада — дальше никто не углубляется.
abstract class C[A] {
def map[B](f: A => B): C[B]
def flatMap[B](f: A => C[B]): C[B]
def filter(p: A => Boolean): C[A]
def foreach(b: A => Unit): Unit
}
...
Concentrating on just the first three functions, the following facts are
noteworthy. In functional programming, there’s a general concept called a
monad, which can explain a large number of types with computations, ranging
from collections, to computations with state and I/O, backtracking computations,
and transactions, to name but a few. You can formulate functions
map, flatMap, and filter on a monad, and, if you do, they end up having
exactly the types given above. Furthermore, you can characterize every
monad by map, flatMap, and filter, plus a “unit” constructor that produces
a monad from an element value. In an object-oriented language, this “unit”
constructor is simply an instance constructor or a factory method. Therefore,
map, flatMap and filter can be seen as an object-oriented version of
the functional concept of monad. Because for expressions are equivalent to
applications of these three methods, they can be seen as syntax for monads
В долгосторочной перспективе первый подход лучше — как учил нас старик Перлис: Accumulate idioms. Standardize.
С точки зрения PL коммивояжера — возможно лучше второй.
Здравствуйте, thesz, Вы писали:
T>Теперь смотрим на Питон. Можно ли выделить минимальное подмножество Питона, на котором можно выразить всё остальное в Питоне? Можем ли мы расширить язык новыми управляющими конструкциями?
А нужно ли чтобы в языке было такое подмножество? Почему во многом близкий к питону Smalltalk в котором это возможно, менее популярен?
В мейнстрим почему-то попадают более корявые и не имеющие теоретической базы языки.
Вон тому же Немерли даже мимикрирование под мейнстрим ничем ни помогло.
N>>>Замечательно, но Хаскель то здесь причем? Ты считаешь, что "алгебры патчей" не реализуема в Питоне? T>>Насколько мне известно, в её реализации используется ленивость. BZ>afair, во второй версии darcs они сделали type-safe описание патчей с помощью GADT. типа того, что если патчи применять в неправильном порядке — то это обнаружит type checker
Во дают!
Это уж точно на Питоне замучаешься реализовывать.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
P>>>>Я целиком за использование хороших яп вместо плохих яп. Вопрос в том, что же такое хороший яп? Хороший яп — это тот, который позволяет тебе мыслить на более высоком уровне, чем до этого, будучи сам по себе простым до очевидности. Сорри за курсив :-) Хороший яп должен «fit my mind». Он не должен требовать огромного багажа знаний, чтобы начать его использовать. Пример однозначно хорошего языка — питон. Или С. T>>>Перевод: "хороший яп — тот, что я знаю прямо сейчас." P>>Чушь. P>>Можешь читать мои слова буквально, без переводов?
T>Да у тебя именно это и написано. Открытым текстом.
thesz, извини конечно, но тут я уже бессилен. Можешь, конечно, считать, что я туп настолько, что сам не понимаю, что я пишу — дело твое.
P>>У меня есть точка зрения, что такое хороший яп, а что — нет. Основная мысль в том, что реально хороший язык реально прост. Я ее высказал и попытался обосновать. Того, что ты усмотрел, в ней и близко нет. Замечания по сути есть?
T>"Реально прост" чем определяется?
Реально прост определяется тем, что я его реально просто смогу объяснить ребенку или старику. Нет, я не докажу это утверждение.
T>Хаскель реально прост теоретически. У него внутре неонка, то есть, ЛИ с нормальным порядком упрощений. Все его конструкции могут быть записаны на этом ЛИ. Да даже типы у него функции: T>
T>instance Monad m where-- m - параметр
T> return :: m a -- из этого следует, что m - функция из типа в тип.
T> ...
T>
T>С помощью ЛИ можно сделать всё, что есть внутри Хаскеля. if-then-else, if-then, циклы. Даже сравнение с образцом. Type safe pattern matching combinators
Ты чего в ответ на эту тираду ждешь? Что с помощью асма можно сделать все, что ты можешь придумать на хаскеле вообще?
T>Coq/Agda2 ещё проще в теоретическом плане. В Coq товарищи ради прикола сделали реализацию типов классов, не выходя за рамки языка. То же самое я сделал для Agda2 после небольшого количества экспериментов.
А теперь заметь забавную закономерность. Чем проще язык по твоему определению, тем меньше людей им пользуется.
T>Теперь смотрим на Питон. Можно ли выделить минимальное подмножество Питона, на котором можно выразить всё остальное в Питоне? Можем ли мы расширить язык новыми управляющими конструкциями?
1) Думаю, да. Но мне лень, поэтому будем считать, что нет.
2) А оно реально надо? Какая именно управляющая конструкция так помогла darcs? (Тут говорили, что у него вообще какой-то type safe patch application — вот круто! Правда, еще тут говорили, что он падает при перемещении 100 мб файлов в репозитории. Надеюсь, скоро у него будет type-safe file movement, или типа того :-)
thesz, в твоих постах я, недалекий интеллектуальный трус, по твоей характеристике, вижу сквозящую в бэкграунде мысль о том, что хаскель способствует написанию хороших программ. Так ли это? Если да — примеры в студию. Ведь, цитируя тебя самого в похожей ситуации, «ЭТО. НАДО. ДОКАЗЫВАТЬ.». Чтобы тебе было полегче, я, со своей стороны, буду приводить примеры хорошего софта на самом ужасном из существующих языков — на плюсах. Идет?
T>Смотрим на Си, C++, C# или Java. Система типов совершенно не связана с моделью вычислений. В C++ этот отрыв ещё сильней.
Прекрасно. Я что, защищал здесь плюсы?
T>Кто оказывается "реально прост"?
Питон и си. Я много раз уже это писал. Еще CL. Если выкинуть мусор всякой обратной совместимости.
T>Тот, что ты знаешь прямо сейчас и похож на уже знакомое, или то, что ты можешь прогнуть под себя с минимумом усилий после изучения?
T>Синяя и красная пилюли. От того, что ты выберешь, зависит твоя карьера программиста.
Ох как образно! А что выбрал Кнут — хаскель или схему? Блин, забыл!
T>Перечисли стереотипы, которыми я руководствуюсь.
Если человеку не нравиться хаскель, то причина в том, что этот человек слишком туп и труслив, чтобы по-настоящему оценить Язык. Похоже?
T>Мне, что-то, начали надоедать наезды ad hominem.
Отвечай аккуратнее, в таком случае. Я не бросаюсь на людей :-)
P>>>>Проблема хаскеля в том, что он, с одной стороны, высокоуровневый (что хорошо), а с другой — взрывает мозг при попытке хотя бы освоить хороший учебник вроде «Real World Haskell». Потому, что он реально сложен. И это плохо. Конечно, возможно, проблема в моей личной глупости. Но, честно говоря, я, как и все :-) считаю себя above average. T>>>Я считаю себя above average, у меня взрывает мозг при изучении теории типов и я её намеренно изучаю: за взрывом мозга и за расширением сознания. P>>Рад за тебя. Это как-то противоречит моей мысли о том, что такому не место в мейнстриме?
T>Да. Моя мысль вот какая: интеллектуальной трусости не место в мейнстриме.
Отвечай аккуратнее, еще раз. Ты не на митинге, все же :-)
T>В этом нет ничего страшного. Являться тебе в снах и хохотать "ХА-ХА-ХА-ХАСКЕЛЬ!!!" над застывшим в ужасе тобой я не буду.
Жаль, это было бы весело.
T>Поскольку ты уже выбрал свою синюю пилюлю, то и жалеть не о чем.
О Гуру! Научи меня хоть толике своей легендарной чуткости и прозорливости!
pgregory wrote:
> То есть, ты считаешь, что везде о монадах пишут просто для красоты > изложения? Здесь наши взгляды серьезно расходятся.
Не совсем. Просто это не только красивая вещь, но и очень мощная. Чем раньше взорвётся мозг, тем раньше появится пониманипе как это использовать.
Скажем, шаблоны при изучении С++ можно и не рассказывать. Просто сказать, что массив строк будет vector<string>, а массив чисел будет vector<int>. И всё. Но если человеку рассказать о шаблонах, то он сможет применять эту абстракцию в своём коде для облегчения своего труда.
>> > Заодно, сказал раз, скажи и два. Haskell for Dummies, где нет упоминаний >> > о монадах — в студию! > .>А ты мне C for Dummies где нет этой злобной арифметики указателей, о > которую столько копий сломали. > 1) Арифметика указателей злобная, но простая. Она — арифметика.
Не скажи... Далеко не все сразу понимают почему [] и * — почти то же самое и зачем оно нужно так.
> 2) Я первый спросил
Честно говоря — не знаю, я много литературы не читал, не копенгаген.
На самом деле я совершенно не знаю хаскелл, но то что видел — очень впечатляет. Красиво и элегантно. А трудности изучения — лишь следствие традиций и популярности. А так если повспоминать себя давным давно, как, скажем, в школе я осознавал понятие файловой системы (банальное понимание дерева каталогов), или система контроля версий... Вроде простые очевидные понятия сейчас, но ведь и это я когда-то не знал и казалось сложным и непонятным.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, pgregory, Вы писали:
P>Чтобы тебе было полегче, я, со своей стороны, буду приводить примеры хорошего софта на самом ужасном из существующих языков — на плюсах. Идет?
Кстати о птичках. Меня как-то человек, изучающий плюсы, спросил, что значит "std::cout << 1". Вот как это на двух пальцах? Без упоминания namespace std, потоков, перегрузки операторов. И ничего, он просто запомнил и пишет.
Уж с do { x <- getLine; putStrLn $ show 1 } я думаю он справится?
И вон на плюсах сколько всего строчат, а такая сложность никого не спугнула. Тут какая-то не та сложность или что-то не сходится?
В общем, я твой пойнт понял, но очень сомневаюсь, что он верен. Надо проверять на неопытных программистах, насколько сложно им будет писать с использованием do Про монады им ни-ни, разумеется.
T>>Ты на голубом глазу высказал утверждение, что если написать систему, которая будет перемалывать хотя бы мегабайт в секунду с нетривиальным обновлением модели, то на Хаскеле всё будет плохо. T>>ЭТО. НАДО. ДОКАЗЫВАТЬ. T>>Мегабайты в секунду с нетривиальным обновлением см. на CUFP. Но ты там в упор не видишь положительных примеров. T>Пример подойдёт? T>В рабочей папке darcs переместил 8 файлов (~100мб) в другой подкаталог. T>darcs не смог гафиксировать изменения — вывалился по переполнению памяти. T>На борту 2гб, darcs 2.2.1 (release), Win Vista Home.
Отлично.
Что по этому поводу говорят другие системы? Им плохо?
Обсуждаемый вопрос: на Хаскеле обязательно получится плохо, много хуже, чем у других.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, EvilChild, Вы писали:
EC>Здравствуйте, pgregory, Вы писали:
P>>Или ты реально считаешь, что FP так же интуитивно, как и ООП? (Чувствую, как люди с горящими глазами бросились писать «Да! Да! Да!!!» :-) EC>Можно раскрыть тему интуитивности ООП? EC>А то у меня такое ощущение, что его почти никто не понимает (уж пользоваться точно не умеет). EC>Об интуитивности даже речь не идёт.
«Попытаюсь объяснить. ООП — это объекты + сообщения/методы. Простейший способ ООП декомпозиции системы — написать текст, потом заменить существительные на объекты, а глаголы — на методы. (Все, конечно, сложнее, но идею, надеюсь, ты понял). Яблоко — объект. Человек — объект. У человека есть метод «спеть песню». У человека есть состояние. И у яблока есть состояние.
Лично я не могу привести таких же аналогий для фп. Можешь попробовать, я буду рад, если это возможно.
Side note: я не утверждаю, что ООП сколько-нибудь хорошо аппроксимирует реальность. На этот счет у меня самого к ООП большие претензии. Я утверждаю, что ООП — это просто и на пальцах. Это яблоки и кнопочки.»
Могу даже попытаться немного развить тему. Если все кошки имеют четыре лапы, то и сиамские — тоже. Это наследование. У представителей разных народностей разные способы приветствовать друг друга при встрече, но я могу от этого абстрагироваться, и написать что-то типа: поприветствуйте_друг_друга(человек1, человек2). В зависимости от того, что это за люди, они поприветствуют друг-друга по-разному. Это полиморфизм.
И, разумеется, наследование реализации — зло :-), а инкапсуляция и полиморфизм — отнюдь не уникальная фича ООП.
Здравствуйте, pgregory, Вы писали:
P>«Попытаюсь объяснить. ООП — это объекты + сообщения/методы. Простейший способ ООП декомпозиции системы — написать текст, потом заменить существительные на объекты, а глаголы — на методы. (Все, конечно, сложнее, но идею, надеюсь, ты понял). Яблоко — объект. Человек — объект. У человека есть метод «спеть песню». У человека есть состояние. И у яблока есть состояние.
Нипаняяяятна. Что такое "у человека есть метод"? Это значит, что человек это умеет делать? А если два человека здороваются, это чей именно метод? Первого или второго? А если десять человек танцуют общий танец?
А кнопку нажали, это метод кнопки, или Человек.НажалКнопкаБыстра? Кнопка ж сама не нажимается, правда?
P>Могу даже попытаться немного развить тему. Если все кошки имеют четыре лапы, то и сиамские — тоже. Это наследование. У представителей разных народностей разные способы приветствовать друг друга при встрече, но я могу от этого абстрагироваться, и написать что-то типа: поприветствуйте_друг_друга(человек1, человек2). В зависимости от того, что это за люди, они поприветствуют друг-друга по-разному. Это полиморфизм.
А почему сиамские наследуются о кошек? Они же просто их подмножество? Что такое наследование, я не понял. Это специализация? Только?
Очень хочу посмотреть на реализацию функции "поприветствуйте_друг_друга(человек_народности_1, человек_народности_2)"
Заодно про мультиметоды расскажешь Тоже на пальцах, конечно.
P>Так вот я думаю. Hope this helps.
Nope
Здравствуйте, pgregory, Вы писали:
P>«Попытаюсь объяснить. ООП — это объекты + сообщения/методы. Простейший способ ООП декомпозиции системы — написать текст, потом заменить существительные на объекты, а глаголы — на методы. (Все, конечно, сложнее, но идею, надеюсь, ты понял). Яблоко — объект. Человек — объект. У человека есть метод «спеть песню». У человека есть состояние. И у яблока есть состояние.
P>Лично я не могу привести таких же аналогий для фп. Можешь попробовать, я буду рад, если это возможно.
P>Side note: я не утверждаю, что ООП сколько-нибудь хорошо аппроксимирует реальность. На этот счет у меня самого к ООП большие претензии. Я утверждаю, что ООП — это просто и на пальцах. Это яблоки и кнопочки.»
P>Могу даже попытаться немного развить тему. Если все кошки имеют четыре лапы, то и сиамские — тоже. Это наследование. У представителей разных народностей разные способы приветствовать друг друга при встрече, но я могу от этого абстрагироваться, и написать что-то типа: поприветствуйте_друг_друга(человек1, человек2). В зависимости от того, что это за люди, они поприветствуют друг-друга по-разному. Это полиморфизм.
Предположим ты это всё рассказал человеку пишущем на C.
Я не понимаю, что он должен извлечь из этого объяснения.
Как это должно повлиять на его способы решения задач?
Здравствуйте, pgregory, Вы писали:
P>Для программирования простых вещей на хаскеле необходимо знать сложное понятие монада. (Посмотри оглавление Real World Haskell, прежде чем возражать, ок?) Это плохо. Ни в одном сколько-нибудь распространенном языке, чтобы оперировать числами, не требуется знать, что такое коммутативное кольцо. (Прежде чем возражать, раздобудь ссылку, это опровергающую, ок?)
Я — дилетант в Хаскелле. Хотя монады понял. Про перегруженный оператор ; — очень понятное объяснение, но я понял раньше.
При этом, первые программы на Хаскелл я начал писать не имея НИКАКОГО понимания что такое монада. Написал примитивненький grep под виндой. На проблемы с именами файлов не наткнулся. Теоркатегор и по сей день не знаю.
Как так получилось? Мне крупно повезло, да? А всем остальным обязательно понимать монады и теоркат, чтобы написать на Хаскеле grep?
P>Это моя позиция, и я ее аргументировал. Ясно?
Это — Ваше _убеждение_. До сих пор не заметно, что оно основано на практике. Моя практика этому противоречит. Ясно?
Здравствуйте, Code Digger, Вы писали:
CD>Здравствуйте, pgregory, Вы писали:
P>>Для программирования простых вещей на хаскеле необходимо знать сложное понятие монада. (Посмотри оглавление Real World Haskell, прежде чем возражать, ок?) Это плохо. Ни в одном сколько-нибудь распространенном языке, чтобы оперировать числами, не требуется знать, что такое коммутативное кольцо. (Прежде чем возражать, раздобудь ссылку, это опровергающую, ок?)
CD>Я — дилетант в Хаскелле. Хотя монады понял. Про перегруженный оператор ; — очень понятное объяснение, но я понял раньше.
Это хорошо.
CD>При этом, первые программы на Хаскелл я начал писать не имея НИКАКОГО понимания что такое монада. Написал примитивненький grep под виндой. На проблемы с именами файлов не наткнулся. Теоркатегор и по сей день не знаю.
И это хорошо.
CD>Как так получилось? Мне крупно повезло, да? А всем остальным обязательно понимать монады и теоркат, чтобы написать на Хаскеле grep?
Всем остальным, видимо, монады сэкономили столько времени при написании хорошего софта, что теперь они от нечего делать пишут монадные туториалы :-) А у людей, их прочитавших, тут же загораются глаза, и они кидаются искать у себя в коде монады. Ведь код без монад — не код. Ты сколько нашел, кроме стандартных? Не поделишься результатами применения этого мощнейшего механизма абстракции?
P>>Это моя позиция, и я ее аргументировал. Ясно? CD>Это — Ваше _убеждение_. До сих пор не заметно, что оно основано на практике. Моя практика этому противоречит. Ясно?
Рад, что твоя практика противоречит моей. Когда динозавры вроде меня вымрут, Чистых Функциональных Программистов, наконец-то, никто не будет смущать подобными глупостями. И это хорошо. Я за прогресс!
P>Как приятно отвечать, когда точно знаешь, что оппонент не прав!
О, да. Различать нюансы, рассматривать необычные взгляды — это слишком сложно. Слишком старомодно. Soo 1990ish.
P>>>В этой презентации (от 24 сентября 2005 года) утверждается, что у darcs — 91 контрибьютор, у git — 79. На тот момент. Вот только, согласно википедии, разработка darcs началась на 3 года раньше, чем git'а. На момент презентации git'у было 4-5 месяцев. T>>Это какого darcs? Что на плюсах или на что Хаскеле? P>У тебя, извини, википедия перестала открываться? P>«Darcs evolved out of David Roundy's efforts to design a new patch format for GNU arch in June 2002. These discussions didn't lead to any code being committed to arch, but did lead to his theory of patches. After writing an initial version of darcs in C++, the Haskell version was written in Autumn 2002 and released to the public in April 2003.»
Никому не известный David Roundy с никому не известным Хаскелем выкатился, и приобрёл за два с половиной года 91-го контрибутора. Мегапопулярный Линус с гитом за полгода 79.
Смотрим на сегодняшнюю ситуацию: 652 и 222. Разница в три раза. Приращение в 4,3 раза больше. Знающих Си в десятки, если не в сотни раз больше, чем знающих Хаскель.
Участвующих в развитии не в 10 раз больше, а всего в три-четыре.
Это при мегапопулярности Линуса, Линукса и Си.
P>«The development of Git began on 3 April 2005.[33] The project was announced on 6 April,[34] and became self-hosting as of 7 April.[33] The first merge of multiple branches was done on 18 April.[35] Torvalds achieved his performance goals; on 29 April, the nascent Git was benchmarked recording patches to the Linux kernel tree at the rate of 6.7 per second.[36] On 16 June, the kernel 2.6.12 release was managed by Git.[37]» P>И да, если то, что ты писал, оказалось неверным, мне было бы очень приятно, если бы ты не просто скипал это при ответах, а писал что-то типа «да, был не прав» Со своей стороны подобное обещаю.
Пожалуй, я буду вести дискуссию как мне удобней. Со своей стороны гарантирую тебе свободу ведения дискуссии как удобней тебе.
Как сторонник северной этической системы, я не делаю по отношению к другим того, что они не делают по отношению ко мне. И могу делать по отношению к другим то, что они делают по отношению ко мне. Вот, как сейчас.
T>>За три месяца его бы не подхватило такое количество народу, не будь он написан Линусом. P>Возможно. И?
Популярность git определяется популярностью Линуса Торвальдса.
T>>А если кто-то, кроме Линуса, написал бы такое на простых Сях, как написан git, то его бы съели без разделки тушки. P>а) спорно P>б) ни о чем
1) бесспорно. ни один "трезвомыслящий" специалист не будет сегодня связываться с Си в большом и экспериментальном проекте.
2) непосредственно относится к дискуссии. язык реализации "продавлен" авторитетом Линуса и ничем иным.
T>>"Практические по всем" параметрам, как я понимаю, включает в себя и разнообразные возможности. T>>Cherry picking, anyone? T>>Я с него не слезу. P>Зря, очень зря — это заранее проигрышная позиция. P>Для начала, cherry-pick есть и в git, и в hg. Да, безо всяких алгебр. Тупее некуда. P>Но. Цитирую свой первый пост в теме: P>«Уважаемые защитники ФП! Здоровы ли вы? Работали ли вы когда-нибудь с исходным кодом программ? Известно ли вам, что между патчами существуют и _более_ сложные зависимости, чем то, что два патча один за другим модифицируют одно и то же место кода? (И, более того, эти более сложные, неявные, зависимости — правило, а не исключение?) P>До тех пор, пока эта мега-алгебра не сможет разрешать такие зависимости (а этого она не сможет никогда — к слову, она хоть компилируемость программы (хоть на хаскелле) гарантирует при существующем авто-черри-пике?), она будет практически бесполезна. Черри-пик всегда будет операцией, при выполнении которой надо 7 раз подумать. И никакая алгебра тут не спасет.» P>Не согласен?
Самое первое — авточеррипик есть оксиморон. Не бывает авточеррипика, он только ручной.
Второе. Алгебра патчей как раз сделана для того, чтобы была возможность высказывать как можно более общие зависимости между изменениями программы.
Третье, вытекающее из первых двух, и последнее: не согласен.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
T>>Теперь смотрим на Питон. Можно ли выделить минимальное подмножество Питона, на котором можно выразить всё остальное в Питоне? Можем ли мы расширить язык новыми управляющими конструкциями? FR>А нужно ли чтобы в языке было такое подмножество? Почему во многом близкий к питону Smalltalk в котором это возможно, менее популярен?
Питон "из коробки" применим лучше и шире. Он идёт, как скриптовый язык, который можно применять по месту без вовлечения в дело всего "образа", как в St.
St таким никто не делал, вот он и менее популярен. А сейчас он слишком старый, чтобы меняться.
Насчёт "нужно"... Мне — нужно. Даже не просто "нужно", а "НУЖНОНУЖНОНУЖНО!!!"
Насчёт остальных не могу утверждать. Хотя им может быть полезно.
DSEL же многие пишут.
FR>В мейнстрим почему-то попадают более корявые и не имеющие теоретической базы языки. FR>Вон тому же Немерли даже мимикрирование под мейнстрим ничем ни помогло.
Lisp?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, VoidEx, Вы писали:
VE>Здравствуйте, pgregory, Вы писали:
P>>«Попытаюсь объяснить. ООП — это объекты + сообщения/методы. Простейший способ ООП декомпозиции системы — написать текст, потом заменить существительные на объекты, а глаголы — на методы. (Все, конечно, сложнее, но идею, надеюсь, ты понял). Яблоко — объект. Человек — объект. У человека есть метод «спеть песню». У человека есть состояние. И у яблока есть состояние.
VE>Нипаняяяятна. Что такое "у человека есть метод"? Это значит, что человек это умеет делать? А если два человека здороваются, это чей именно метод? Первого или второго? А если десять человек танцуют общий танец?
VE>А кнопку нажали, это метод кнопки, или Человек.НажалКнопкаБыстра? Кнопка ж сама не нажимается, правда?
Вы с EvilChild практически об одном пишете, поэтому отвечу я вам вместе, ок?
Side note: я не утверждаю, что ООП сколько-нибудь хорошо аппроксимирует реальность. На этот счет у меня самого к ООП большие претензии. Я утверждаю, что ООП — это просто и на пальцах. Это яблоки и кнопочки.
Поинт не в том, что ООП это правильно. ООП это просто. Кнопка, говоришь? Хорошо, у нее будет метод «нажать». Почему у нее? А почему бы и нет? Да ни почему. Серьезно. Весь софт именно так пишется, и при этом еще и работает. Зачастую — очень хорошо.
Только не прочти это неправильно. Типа, раз работает, то и трогать не надо, и так хорошо. С этим я категорически не согласен. Я ни в коей мере не агитирую за здравие ООП, и тем более за ООП вместо ФП.
Здравствуйте, pgregory, Вы писали:
P>Поинт не в том, что ООП это правильно. ООП это просто. Кнопка, говоришь? Хорошо, у нее будет метод «нажать». Почему у нее? А почему бы и нет? Да ни почему. Серьезно. Весь софт именно так пишется, и при этом еще и работает. Зачастую — очень хорошо.
Ты ж про самое главное забыл. Про здорованье двух человек А меж тем важная проблема-то.
И что-то интуитивного решения я не вижу. Точнее я вижу такое — есть функция "нажать", в ней участвуют два объекта, которые в процессе как-то изменяются. Только это с ООП не вяжется
Вот и видим какие-то Object.Equals(Object) вместо Equals(Object, Object).
T>>Да у тебя именно это и написано. Открытым текстом. P>thesz, извини конечно, но тут я уже бессилен. Можешь, конечно, считать, что я туп настолько, что сам не понимаю, что я пишу — дело твое.
Это нормально, я так думаю.
В том случае, конечно, когда позволяешь себе перед текстом комментария написать "как приятно отвечать, когда знаешь, что оппонент не прав".
Когда ты заранее уверен в своей правоте.
Когда вместо хотя объяснения, как же надо читать твои слова ты даёшь себе волю просто отмахнуться "меня так, как ты читаешь, прочитать нельзя".
Так что твоё бессилие нормально.
P>>>У меня есть точка зрения, что такое хороший яп, а что — нет. Основная мысль в том, что реально хороший язык реально прост. Я ее высказал и попытался обосновать. Того, что ты усмотрел, в ней и близко нет. Замечания по сути есть? T>>"Реально прост" чем определяется? P>Реально прост определяется тем, что я его реально просто смогу объяснить ребенку или старику. Нет, я не докажу это утверждение.
Ты будешь основываться на своих знаниях. Ты будешь объяснять так, как ты это знаешь.
Мы приходим к моему первому тезису: реально прост язык, который ты уже знаешь (или я уже знаю).
А теперь попробуй рассказать ребенку или старику какую-либо твою программу на этом языке. Вот тут ситуация изменится радикально. Помимо простых знаний о синтаксисе и семантике тебе придётся рассказать про кучу неявных вещей, которые у тебя в подсознании, а стороннему лицу неизвестны. Как предметная область отображается в решения в программе.
(мне про Eclipse так на работе рассказывают. интересно!)
T>>С помощью ЛИ можно сделать всё, что есть внутри Хаскеля. if-then-else, if-then, циклы. Даже сравнение с образцом. Type safe pattern matching combinators P>Ты чего в ответ на эту тираду ждешь? Что с помощью асма можно сделать все, что ты можешь придумать на хаскеле вообще?
Видишь ли, ассемблер на ассемблере написать и то уже постараться придётся.
В отличии от достаточно прямого подхода с Хаскелем и его составными частями.
Как нам всем давно известно, библиотека — это язык программирования, рвущийся наружу. Они взаимосвязаны. Быстро пишу библиотеки, быстро пишу DSEL и наоборот. Где DSEL, там и DSL.
Где DSL — там и производительность программистов.
Точнее, программиста. Точнее, меня.
Хотя, всё же, программистов — меня и коллег.
А на остальных мне плевать.
T>>Coq/Agda2 ещё проще в теоретическом плане. В Coq товарищи ради прикола сделали реализацию типов классов, не выходя за рамки языка. То же самое я сделал для Agda2 после небольшого количества экспериментов. P>А теперь заметь забавную закономерность. Чем проще язык по твоему определению, тем меньше людей им пользуется.
Тем он моложе.
T>>Теперь смотрим на Питон. Можно ли выделить минимальное подмножество Питона, на котором можно выразить всё остальное в Питоне? Можем ли мы расширить язык новыми управляющими конструкциями? P>1) Думаю, да. Но мне лень, поэтому будем считать, что нет. P>2) А оно реально надо? Какая именно управляющая конструкция так помогла darcs? (Тут говорили, что у него вообще какой-то type safe patch application — вот круто! Правда, еще тут говорили, что он падает при перемещении 100 мб файлов в репозитории. Надеюсь, скоро у него будет type-safe file movement, или типа того
Тут не сказали, падают ли другие системы. Пока я ответа не получил.
P>thesz, в твоих постах я, недалекий интеллектуальный трус, по твоей характеристике, вижу сквозящую в бэкграунде мысль о том, что хаскель способствует написанию хороших программ.
Хороший язык способствует созданию хороших программ.
Пока Хаскель, по-моему, лучший.
P>Так ли это? Если да — примеры в студию. Ведь, цитируя тебя самого в похожей ситуации, «ЭТО. НАДО. ДОКАЗЫВАТЬ.». Чтобы тебе было полегче, я, со своей стороны, буду приводить примеры хорошего софта на самом ужасном из существующих языков — на плюсах. Идет?
Окей. Внутренний продукт, что я написал на моей текущей работе. Часть более крупного продукта.
Прямой аналог — Icarus Verilog, точнее, его часть с оптимизацией нетлистов. Версия 0.8.7 содержит следующие оптимизации:
Наш оптимизатор делает всё то же самое, плюс две дополнительные оптимизации, увеличивающие скорость моделирования в полтора и в два раза по отдельности.
Всё это в считанные недели. Оптимизатор, конкретно, 4 недели. Параллельно правился код на Java и Хаскеле.
T>>Смотрим на Си, C++, C# или Java. Система типов совершенно не связана с моделью вычислений. В C++ этот отрыв ещё сильней. P>Прекрасно. Я что, защищал здесь плюсы?
*тупо смотрит на экран в поисках хоть какого-то смысла*
*продолжает смотреть*
*устав, проголодавшись, замерзнув и полностью отчаявшись, переходит к ответу на другие параграфы*
T>>Кто оказывается "реально прост"? P>Питон и си. Я много раз уже это писал. Еще CL. Если выкинуть мусор всякой обратной совместимости.
О! Уже что-то.
T>>Перечисли стереотипы, которыми я руководствуюсь. P>Если человеку не нравиться хаскель, то причина в том, что этот человек слишком туп и труслив, чтобы по-настоящему оценить Язык. Похоже?
Нет.
T>>Мне, что-то, начали надоедать наезды ad hominem. P>Отвечай аккуратнее, в таком случае. Я не бросаюсь на людей
Да ты что?!
Ты обкладываешься подушками в стиле "читайте 'по-моему мнению' после каждой строчки", "я не бросаюсь на людей", и подобными ровно для того, чтобы тебе не могли в этом обвинить.
На самом деле ты бросаешься на людей.
Я тоже бросаюсь на людей. Более того, всем известно, что я БРОСАЮСЬ НА ЛЮДЕЙ, что я флеймер, хамло и у меня раздутое самомнение.
Ну, так я об этом заявляю прямо и открыто.
T>>Поскольку ты уже выбрал свою синюю пилюлю, то и жалеть не о чем.
P>О Гуру! Научи меня хоть толике своей легендарной чуткости и прозорливости!
Делов-то.
Сжимаешь твою основную руку в кулак, оттопыриваешь указательный палец.
Тыкаешь им в монитор и говоришь либо "хороший, умный пост", либо "плохой, дурацкий пост".
Далее аргументируешь эту точку зрения в комментарии к посту.
Всё.
Больше никаких секретов.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, eao197, Вы писали:
P>>>Сотый раз: если это не так — примеры в студию! Только не какие-нибудь упрощалки символьных вычислений. Z>>Commercial Users of Functional Programming 2008
E>Кстати интересно, почему при всей своей долгой истории ФП нуждается в международных конференциях, посвященных теме коммерческого использования ФП?
потому, что оно было коммерчески невыгодно. и остаётся
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, z00n, Вы писали:
P>>>Сотый раз: если это не так — примеры в студию! Только не какие-нибудь упрощалки символьных вычислений. Z>>Commercial Users of Functional Programming 2008
E>Кстати интересно, почему при всей своей долгой истории ФП нуждается в международных конференциях, посвященных теме коммерческого использования ФП?
Потому что назрело А если серьезно — межденародные конференции есть совершенно обо всем.
Здравствуйте, BulatZiganshin, Вы писали:
Z>>>Commercial Users of Functional Programming 2008
E>>Кстати интересно, почему при всей своей долгой истории ФП нуждается в международных конференциях, посвященных теме коммерческого использования ФП?
BZ>потому, что оно было коммерчески невыгодно. и остаётся
Но почему? Если ФП действительно повышает производительность и улучшает качество, почему это не выгодно? Даже парное кодирование и unit-тесты широко проникают в коммерческие проекты, поскольку они преследуют те же самые цели.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
: P>«Попытаюсь объяснить. ООП — это объекты + сообщения/методы. Простейший способ ООП декомпозиции системы — написать текст, потом заменить существительные на объекты, а глаголы — на методы. (Все, конечно, сложнее, но идею, надеюсь, ты понял). Яблоко — объект. Человек — объект. У человека есть метод «спеть песню». У человека есть состояние. И у яблока есть состояние.
Итак, внимательно читаем.
Сперва ООП — это объекты и методы, понятно. Затем декомпозиция системы, тоже понятно. Глаголы, существительные, ничего удивительного.
И вдруг появляется состояние. Более того, появляется владение состоянием, как до этого появилось "владение методом" ("есть метод 'спеть песню'").
Получается, что ООП — это объекты + методы (сообщения) + владение методами + владение состоянием.
Теперь бы научится писать с этим всем программы...
P>Лично я не могу привести таких же аналогий для фп. Можешь попробовать, я буду рад, если это возможно.
Можно я за него?
ФП сводится к двум вещам: чистым вычислениям (упрощениям значений, beta-reduction) и, в случае работы с внешним миром, к обратной связи в смысле теории управления. Мы получили информацию о внешнем мире, вычислили необходимое воздействие, произвели его. Можем зациклиться, если хотим.
Чистые вычисления сводятся к двум вещам: правила построения значений и правила их вычислений. Первое состоит из двух вещей: лямбда-абстракция (построение функции) и применение функции. Второе сводится к двум правилам переписывания: над чистым подмножеством ЛИ и операции с константами (во что упрощать 1+1).
Теперь мы можем уточнять, что и как мы должны знать про внешний мир. Мы должны знать про внешний мир две вещи...
Вот как-то так.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, eao197, Вы писали:
BZ>>потому, что оно было коммерчески невыгодно. и остаётся
E>Но почему? Если ФП действительно повышает производительность и улучшает качество, почему это не выгодно? Даже парное кодирование и unit-тесты широко проникают в коммерческие проекты, поскольку они преследуют те же самые цели.
правильный вопрос. а ООП коммерчески выгодно? если да, почему оно не вытеснило ПЛ/1 с того самого 67-го года, когда было изобретено?
E>>>Трудноиспользуемой ООП не была. ООП я начал использовать на втором курсе универа, K>>Думаю, что начни вы использовать ФП на втором курсе универа, трудноиспользуемым ФП вы также не назвали бы. P>http://lambda-the-ultimate.org/node/1840 P>Интересно услышать комментарии.
http://lambda-the-ultimate.org/node/2845
E>>>Причем я тогда даже не знал, что это ООП. K>>Вот в этом и заключается секрет успеха. Программисты на C# 3, например, в настоящее время широко используют монады и, в массе своей, не подозревают об этом. P>Неужели не очевидно, что весь разговор именно об этом?! Программисты, например, в большинстве своем (нет, лично я не измерял) не знают, что целые числа образуют коммутативное кольцо с единицей (а также абелеву группу по ... и еще ... и еще ...). И это не мешает им писать программы, и делать это хорошо.
Я тут затеял написать на Хаскеле самую лучшую в мире программу и упёрся в своё незнание о коммутативной группе с единицей.
Мне понадобилось упрощение выражений после дифференцирования. Эффективность работы упростителя сильно зависит от представления. Наилучшим оказалось именно алгебраическое (вместо Div a b надо писать Mul a (Inv b), то же со сложением).
P>За простыми вещами должны следовать сложные, но не наоборот. Don't pay for what you don't need. Make simple things easy, but hard things possible. И так далее. Что здесь не ясно???
BZ>первой широко распространённой ООП системой стал turbo pascal 5.5, 1989-й год. сейчас скачал его руководство, быстренько просмотрел — и увидел ожидаемые слова:
Здравствуйте, BulatZiganshin, Вы писали:
E>>Но почему? Если ФП действительно повышает производительность и улучшает качество, почему это не выгодно? Даже парное кодирование и unit-тесты широко проникают в коммерческие проекты, поскольку они преследуют те же самые цели.
BZ>правильный вопрос. а ООП коммерчески выгодно? если да, почему оно не вытеснило ПЛ/1 с того самого 67-го года, когда было изобретено?
Чуток не дотянуло до 4K вместе с тестами. Ну да, думаю при таком объеме можно и выловить все возможные проблемы с памятью.
Да и большими объемами данных xmonad точно не ворочает. Вот если бы он прогонял через себя хотя бы мегабайт в секунду, да еще и вынужден был держать в себе сложную модель, объемом мегов в 100-100 и нетривиально ее обновлять, то была бы другая история.
T>Обсуждаемый вопрос: на Хаскеле обязательно получится плохо, много хуже, чем у других.
P>Э! Не передергивай! Обсуждается совсем не это.
T>Поэтому — переписывай свой ответ заново. T>Дальше я читать не стал, и отвечать тоже.
Здравствуйте, BulatZiganshin, Вы писали:
E>>Но почему? Если ФП действительно повышает производительность и улучшает качество, почему это не выгодно? Даже парное кодирование и unit-тесты широко проникают в коммерческие проекты, поскольку они преследуют те же самые цели.
BZ>правильный вопрос. а ООП коммерчески выгодно?
Выгодно. Достаточно просмотреть на Java Application Server-а и другой middleware софт, построенный на ОО языках.
BZ>если да, почему оно не вытеснило ПЛ/1 с того самого 67-го года, когда было изобретено?
То, что ООП вытеснило PL/1 уже очевидно лет двадцать как. ООП было настолько выгодно, что в 1979-м году некто Страуструп начал создание языка, который бы сочетал эффективность C и высокоуровневость Simula. Успешность его попытки ощущается до сих пор. Как в количестве OpenSource-проектов, так и в количестве коммерческих проектов, выполняемых в данный момент только на C++. Не считая его улучшенных наследников вроде Java и C#.
Знаменитые функциональные языки вроде ML (1973) и Miranda (1985) появились в тот же исторический период. Но успешные проекты на функциональных языках составляют небольшую долю от общего количества программных проектов.
Так вот, если ты говоришь, что ФП коммерчески не выгодно, значит ты знаешь какие-то причины этого. Соображения на счет смены парадигмы они, как бы это сказать... Допустим, что смена парадигмы требует некоторых дополнительных вложений средств. Ну т.е. процедурный программист стоил $5K в месяц, для перевода его в разряд объектно-ориентированных программистов работодатель должен был дополнительно затратить, скажем, единоразово $20K (на обучение, приобритение новых инструментальных средств и пр). И в случае ООП эти дополнительные вложения окупались. Допустим, что смена парадигмы в случае ФП несколько дороже. Не $20K, а $60K. Но, на мой рабоче-крестьянский взгляд, если бы такие дополнительные вложения окупались, на них бы все равно пошли. Может, такие вложения не окупаются?
PS. Утверждение о том, что самым широкораспространенным ОО языком был Turbo Pascal нуждается в доказательстве.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[14]: [haskell] considered mainstream
От:
Аноним
Дата:
08.03.09 18:09
Оценка:
Здравствуйте, novitk, Вы писали:
N>Здравствуйте, Аноним, Вы писали:
А>>Если скрестить cherry-picking и коммутативность патчей, то открываются новые возможности. А>>Поэтому не надо тупо гуглить, почитайте туториал и оцените сами.
N>Меня не настолько интересует "алгебра пэтчей", чтобы читать по ней туториал. Я просто привел, что похожий функционал есть в Hg. Говорить об архиважности этой фичи для пользователя в виду практической невостребованости darcs по причине общей слабости функционала, надежности и скорости по сравнению с hg/git в последнее время смешно. Конь экологичней автомобиля и сложнее, вот только не нужен он больше никому.
Ещё раз призываю не настаивать на "общей слабости функционала" не прочитав хотя бы туториала. Это неконструктивно.
А>>По поводу того, что алгебру патчей можно реализовать на любом языке. С этим глупо спорить, однако небольшая ремарка. А>>Первая версия darcs была написана на c++. К сожалению, она не работала. Совсем. А>>Вторая версия была написана на хаскеле. И она заработала. Сразу. А>>("Заработала" -- имеется в виду алгебра патчей).
N>Это говорит лишь о неумение автора пользоваться C++, что для теор. физика вполне нормально.
Это ни о чём не говорит. Просто замчание в сторону.
P>Чуток не дотянуло до 4K вместе с тестами. Ну да, думаю при таком объеме можно и выловить все возможные проблемы с памятью.
P>Да и большими объемами данных xmonad точно не ворочает. Вот если бы он прогонял через себя хотя бы мегабайт в секунду, да еще и вынужден был держать в себе сложную модель, объемом мегов в 100-100 и нетривиально ее обновлять, то была бы другая история.
T>>Обсуждаемый вопрос: на Хаскеле обязательно получится плохо, много хуже, чем у других. P>>Э! Не передергивай! Обсуждается совсем не это. T>>Поэтому — переписывай свой ответ заново. T>>Дальше я читать не стал, и отвечать тоже. P>No comments. Остынь, что ли.
Будь добр, разверни. Я не понимаю, что ты хотел этим сказать. RD выдвинул совершенно бредовый тезис не потрудившись его обосновать. Ты его повторил.
Ты думаешь, что повторение глупости переведёт её в разряд истины? Это не совсем так.
Для этого надо обладать большими деньгами и, как следствие, трибуной побольше одной темы одного из форумов RSDN.
У Microsoft это получится повторять мантру и сделать её истиной. У SUN получится. У IBM. Масштабы, примерно, такие.
Поэтому, будь добр, перепиши свой ответ. Оба своих ответа.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, eao197, Вы писали:
E>>>Но почему? Если ФП действительно повышает производительность и улучшает качество, почему это не выгодно? Даже парное кодирование и unit-тесты широко проникают в коммерческие проекты, поскольку они преследуют те же самые цели.
BZ>>правильный вопрос. а ООП коммерчески выгодно?
E>Выгодно. Достаточно просмотреть на Java Application Server-а и другой middleware софт, построенный на ОО языках.
да, но ведь ООП появилось в 67-м. почему же мы не можем увидеть его выгодность в 68-м, 69-м... а массово коммерческий софт на ООП языках стали писать в конце 80-х. что целых 20 лет мешало людям получать столь очевидную коммерческую выгоду?
BZ>>если да, почему оно не вытеснило ПЛ/1 с того самого 67-го года, когда было изобретено?
E>То, что ООП вытеснило PL/1 уже очевидно лет двадцать как. ООП было настолько выгодно, что в 1979-м году некто Страуструп начал создание языка
а лисп был создан 50 лет назад, где-то между фортраном и алголом. так значит преимущества ФП очевидны уже лет 50 как? или не значит?
E>, который бы сочетал эффективность C и высокоуровневость Simula. Успешность его попытки ощущается до сих пор.
т.е. сама по себе сиула не была успешным проектом? а смолток, apple object pascal, eiffel? наконец, сам c++ — он с 79-го года стал активно использоваться для коммерческой разработки или может с 80-го?
E>Как в количестве OpenSource-проектов, так и в количестве коммерческих проектов, выполняемых в данный момент
в данный момент. но ведь успешность парадигмы не зависит от времени и языка, так почему бы нам не рассмотреть 80-й год или 68-й?
E>Так вот, если ты говоришь, что ФП коммерчески не выгодно, значит ты знаешь какие-то причины этого.
ты их и сам знаешь. просто думать отказываешься
E>Соображения на счет смены парадигмы они, как бы это сказать... Допустим, что смена парадигмы требует некоторых дополнительных вложений средств. Ну т.е. процедурный программист стоил $5K в месяц, для перевода его в разряд объектно-ориентированных программистов работодатель должен был дополнительно затратить, скажем, единоразово $20K (на обучение, приобритение новых инструментальных средств и пр). И в случае ООП эти дополнительные вложения окупались.
точно? почему же в 68-м году весь мир не перешёл на симулу? в 72-м — на смолток? в 85-м — на apple pascal? в 87-м — на eiffel? почему переход состоялся только в 89/90-м годах на самые слабые ооп языки — turbo pascal и с++? ну же, подумай!
E>PS. Утверждение о том, что самым широкораспространенным ОО языком был Turbo Pascal нуждается в доказательстве.
"первым широко распространённым ооп языком". разницу видишь?
Здравствуйте, BulatZiganshin, Вы писали:
BZ>а лисп был создан 50 лет назад, где-то между фортраном и алголом. так значит преимущества ФП очевидны уже лет 50 как? или не значит?
Ладно лисп как и смаллтолк сидит в свой нише и никому не мешает.
Но ML ветка функциональщины и современный мейнстримный ООП по сути ровесники, ты можешь объяснить почему
только сейчас есть робкие попытки проникновения ФП в мейнстрим?
Здравствуйте, FR, Вы писали:
FR>Но ML ветка функциональщины и современный мейнстримный ООП по сути ровесники, ты можешь объяснить почему FR>только сейчас есть робкие попытки проникновения ФП в мейнстрим?
а мы уже доказали, что коммерческая успешность языка определяется именно его возрастом?
Здравствуйте, BulatZiganshin, Вы писали:
FR>>Но ML ветка функциональщины и современный мейнстримный ООП по сути ровесники, ты можешь объяснить почему FR>>только сейчас есть робкие попытки проникновения ФП в мейнстрим?
BZ>а мы уже доказали, что коммерческая успешность языка определяется именно его возрастом?
Здравствуйте, FR, Вы писали:
BZ>>а мы уже доказали, что коммерческая успешность языка определяется именно его возрастом?
FR>У тебя это плохо получается
научить тебя думать? ну, я по крайней мере попытался
RD>>Если тебе говорят что-то, что не укладывается в твою картину мира, то ты орешь как недорезанный "разворачивай!" или твердишь что это не недостаток такой а крутейшая фича. T>Именно. Потому, что после "разворачивания", обычно, выясняется слабость аргументов и позиции вообще.
Ну если Ваш единственный аргумент — "разворачивай", то несомненно под его весом собеседник точно прогнется. Низкий поклон Вашему Гениальному Мозгу.
Кстати, перечитайте свой же пост в своем же блоге на тему культуры общения. Было бы неплохо если бы Вы сами придерживались этих правил. http://thesz.livejournal.com/657874.html
RD>>И в отличии от тебя, кричащего что "Хаскель крут ваще" я НЕ утверждаю что он не крут. Я просто показываю тебе на то, что пора снять розовые очки. Но видимо они вросли в кость. T>То, что ты называешь "розовыми очками", я называю прогрессом. T>Ты не поверишь, но не кто иной, как Джон Кармак по выпуску первого Quake говаривал, что C++ для игр не предназначен, у него нельзя контролировать расход памяти и задержки по времени из-за перегрузки и конструкторов-декструкторов. T>См. на Doom3 инструменты 2005 года.
Вы наверное удивитесь, но мир не стоит на месте. И в то время C++ возможно (ВОЗМОЖНО) действительно не подходил для написания игр. Но если ДАЖЕ он не подходил ТОГДА, то сейчас, после долгой эволюции уже подходит.
T>Все аргументы против применения Хаскеля, что ты (да большинство) выкладывают на стол, все они, до единого, звучали в отношении C++ в 1995 году. T>Вот и вся причина моего упрямства. T>Просто у меня хорошая память.
Может память у Вас и хорошая. Но см. выше. Если аналогия с Хаскелем имеет место, то МОЖЕТ БЫТЬ (но не факт) в будущем (а не сразу сейчас) все будет заметно шоколаднее.
RD>>А пример с xmonad был предложен как крупный софт, где все стабильно и нет утечек. Пример я не принимаю, т.к. софт небольшой. А меня бы заинтересовал именно БОЛЬШОЙ, перемалывающий кучу данных. И если это сможет так же стабильно работать как и xmonad — слава и хвала разработчикам. Но пока что такого примера не видел. T>Ещё раз. T>Ты на голубом глазу высказал утверждение, что если написать систему, которая будет перемалывать хотя бы мегабайт в секунду с нетривиальным обновлением модели, то на Хаскеле всё будет плохо. T>ЭТО. НАДО. ДОКАЗЫВАТЬ. T>Это твой тезис, будь добр, докажи его. T>Мегабайты в секунду с нетривиальным обновлением см. на CUFP. Но ты там в упор не видишь положительных примеров. T>Расскажи мне ещё раз про розовые очки, пожалуйста.
Дорогой товарищ Великий Программист, я не намерен доказывать Вам тезисы, которые я не утверждал.
Я понимаю, что как Боец Ордена Св. Лябмды Вы в любом встречном видите грешника-иноверца и жаждете вспороть ему брюхо. Ничего, это бывало и раньше, и не только с Вами. Через сотню-другую лет обычно попускает даже крестоносцев.
И ваши голубые глаза если кто и трогал, то не я. Я в этом плане вообще гуманист.
Очень прискорбно, но мы с Вами не прийдем к единому мнению. Тут мне уже все ясно как Божий день. И причина этому проста. Вы просто не освоили тернарную логику. Ну, или чтобы Вам было понятнее, разницу между Maybe Bool и Bool.
Последняя попытка с моей стороны.
1. Я НЕ утверждал что крупные программы на Хаскель не могут работать надежно и без проблем с потреблением памяти.
1.1 Я утверждал что я НЕ УВЕРЕН (и не имею достаточно веских с моей точки зрения оснований считать) что в случае разработки действительно большой софтины (порядка миллиона строк) да еще и большим коллективом, да еще и сегодня а не через десять лет... эти проблемы с памятью и общим пониманием всего этого хозяйства не станут проявляться.
1.2 Про CUFP я знаю давно. Но деталей там мало. И поэтому те примеры к тревожащему меня вопросу не клеются.
2 Я НЕ утвержал что Haskell это отстой. Это Вам, уважаемый, везде видятся Враги. Слава Богу, что не все Хаскелисты столь слепо яростны. Скажем, с Булатом общаться, как я вижу, можно и даже интересно. И Simon — очень конструктивный человек.
2.1 Обратно же, пока Вы не научитесь Слушать, Понимать и Уважать собеседника, то и уважать Вас никто не будет.
BZ>>а лисп был создан 50 лет назад, где-то между фортраном и алголом. так значит преимущества ФП очевидны уже лет 50 как? или не значит? FR>Ладно лисп как и смаллтолк сидит в свой нише и никому не мешает. FR>Но ML ветка функциональщины и современный мейнстримный ООП по сути ровесники, ты можешь объяснить почему FR>только сейчас есть робкие попытки проникновения ФП в мейнстрим?
Simula-67 и C++ (79-й) — 12 лет разницы. В мейнстрим C++ попал в районе 90-93. MFC, AFAIK. Ещё 12 лет.
ML и Haskell — ~10 лет разницы. 78+24 — 2002. Ну, 2000. Так в 2000 SPJ на работу в Майкрософт и взяли, AFAIR.
Но сейчас количество кода, с которым приходится общаться, значительно выше. Информационная связность повысилась в разы, если не на порядки.
Считается, что для решения задач обязательно, обязательно-обязательно надо использовать сторонние библиотеки. А они, вот засада, на обычных ЯП. А на ФП они странные какие-то, с монадами. А обычные вот они, с привычными классами.
Вот и проникает всё в индустрию медленно и с трудом.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
RD>>>Если тебе говорят что-то, что не укладывается в твою картину мира, то ты орешь как недорезанный "разворачивай!" или твердишь что это не недостаток такой а крутейшая фича. T>>Именно. Потому, что после "разворачивания", обычно, выясняется слабость аргументов и позиции вообще. RD>Ну если Ваш единственный аргумент — "разворачивай", то несомненно под его весом собеседник точно прогнется. Низкий поклон Вашему Гениальному Мозгу.
"Разворачивай" — это не аргумент. Это указание на то, что для обсуждения мало информации. Нечего обсуждать-то, поэтому надо изложить тезисы более обстоятельно. Не видно, где ошибка и что можно комментировать.
RD>Кстати, перечитайте свой же пост в своем же блоге на тему культуры общения. Было бы неплохо если бы Вы сами придерживались этих правил. http://thesz.livejournal.com/657874.html
Это правила поведения в моём блоге внешних комментаторов.
Правила RSDN другие. Правил RSDN я, проде, придерживаюсь, нет?
RD>>>И в отличии от тебя, кричащего что "Хаскель крут ваще" я НЕ утверждаю что он не крут. Я просто показываю тебе на то, что пора снять розовые очки. Но видимо они вросли в кость. T>>То, что ты называешь "розовыми очками", я называю прогрессом. T>>Ты не поверишь, но не кто иной, как Джон Кармак по выпуску первого Quake говаривал, что C++ для игр не предназначен, у него нельзя контролировать расход памяти и задержки по времени из-за перегрузки и конструкторов-декструкторов. T>>См. на Doom3 инструменты 2005 года. RD>Вы наверное удивитесь, но мир не стоит на месте. И в то время C++ возможно (ВОЗМОЖНО) действительно не подходил для написания игр. Но если ДАЖЕ он не подходил ТОГДА, то сейчас, после долгой эволюции уже подходит.
За счёт чего это? Те же конструкторы, те же деструкторы, то же непредсказуемое время из-за перегрузки.
Что изменилось-то? Не развернёшь?
(кстати, JC до сих пор пишет в стиле "почти C++" — более строгие проверки, структуры вместо классов и, изредка, перегрузка, если безопасно)
T>>Все аргументы против применения Хаскеля, что ты (да большинство) выкладывают на стол, все они, до единого, звучали в отношении C++ в 1995 году. T>>Вот и вся причина моего упрямства. T>>Просто у меня хорошая память. RD>Может память у Вас и хорошая. Но см. выше. Если аналогия с Хаскелем имеет место, то МОЖЕТ БЫТЬ (но не факт) в будущем (а не сразу сейчас) все будет заметно шоколаднее.
Так готовится к будущему надо сейчас. А то оно наступит, а мы не готовы.
RD>>>А пример с xmonad был предложен как крупный софт, где все стабильно и нет утечек. Пример я не принимаю, т.к. софт небольшой. А меня бы заинтересовал именно БОЛЬШОЙ, перемалывающий кучу данных. И если это сможет так же стабильно работать как и xmonad — слава и хвала разработчикам. Но пока что такого примера не видел. T>>Ещё раз. T>>Ты на голубом глазу высказал утверждение, что если написать систему, которая будет перемалывать хотя бы мегабайт в секунду с нетривиальным обновлением модели, то на Хаскеле всё будет плохо. T>>ЭТО. НАДО. ДОКАЗЫВАТЬ. T>>Это твой тезис, будь добр, докажи его. T>>Мегабайты в секунду с нетривиальным обновлением см. на CUFP. Но ты там в упор не видишь положительных примеров. T>>Расскажи мне ещё раз про розовые очки, пожалуйста. RD>Дорогой товарищ Великий Программист, я не намерен доказывать Вам тезисы, которые я не утверждал.
Спасибо. Очень лестно. Нет, серьёзно, тронут до глубины души.
RD>Я понимаю, что как Боец Ордена Св. Лябмды Вы в любом встречном видите грешника-иноверца и жаждете вспороть ему брюхо. Ничего, это бывало и раньше, и не только с Вами. Через сотню-другую лет обычно попускает даже крестоносцев.
Что-то я поторопился с выражением признательности.
RD>И ваши голубые глаза если кто и трогал, то не я. Я в этом плане вообще гуманист.
Ура! "Я буду жить!"
RD>Очень прискорбно, но мы с Вами не прийдем к единому мнению. Тут мне уже все ясно как Божий день. И причина этому проста. Вы просто не освоили тернарную логику. Ну, или чтобы Вам было понятнее, разницу между Maybe Bool и Bool.
Что это означает?
RD>1. Я НЕ утверждал что крупные программы на Хаскель не могут работать надежно и без проблем с потреблением памяти.
Что же это было за утверждение тогда?
RD>1.1 Я утверждал что я НЕ УВЕРЕН (и не имею достаточно веских с моей точки зрения оснований считать) что в случае разработки действительно большой софтины (порядка миллиона строк) да еще и большим коллективом, да еще и сегодня а не через десять лет... эти проблемы с памятью и общим пониманием всего этого хозяйства не станут проявляться.
Прошу прощения, но эти проблемы проявляются в инструментах, специально заточенных под такие задачи. В программах на Эрланге, например. Про утечки памяти в C++ легенды ходят. В C# такие же проблемы.
Про Хаскель мы не уверены, что они не проявятся. А про другие инструменты знаем, что они могут проявится.
Другие инструменты — Эрланг, C++ и C#/Java, — можно использовать, а Хаскель нет.
Эта логика выше моего понимания. Наверное, в ней используют Maybe Bool вместо Bool.
RD>2 Я НЕ утвержал что Haskell это отстой. Это Вам, уважаемый, везде видятся Враги. Слава Богу, что не все Хаскелисты столь слепо яростны. Скажем, с Булатом общаться, как я вижу, можно и даже интересно. И Simon — очень конструктивный человек.
Вы глупости на голубом глазу не утверждайте, и я тоже стану спокойным.
Утверждения типа "вы пишите такой код, что он ни с чем не интегрируется" и "вот с хаскелем системы на мегабайт пропускной способности не получится" как-то не добавляют конструктивности в беседу.
RD>2.1 Обратно же, пока Вы не научитесь Слушать, Понимать и Уважать собеседника, то и уважать Вас никто не будет.
Для того, чтобы я Слушал, Понимал и Уважал собеседника, необходимо всего ничего: говорить Ясно, говорить Связно и говорить Уважительно. Либо отличиться на почве того, что мне интересно.
Я не могу сказать, что я не стремлюсь быть уважаемым. Но я стремлюсь быть уважаемым теми, кто сам достоин уважения.
Общая популярность меня мало заботит. Иначе я был бы lj user=drugoi, а не lj user=thesz.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>Simula-67 и C++ (79-й) — 12 лет разницы. В мейнстрим C++ попал в районе 90-93. MFC, AFAIK. Ещё 12 лет.
T>ML и Haskell — ~10 лет разницы. 78+24 — 2002. Ну, 2000. Так в 2000 SPJ на работу в Майкрософт и взяли, AFAIR.
ML 73 Миранда 85 так что должно быть 97.
T>Но сейчас количество кода, с которым приходится общаться, значительно выше. Информационная связность повысилась в разы, если не на порядки.
Так это не помешало в конце 90-ых начале 2000 динамическим языкам.
T>Считается, что для решения задач обязательно, обязательно-обязательно надо использовать сторонние библиотеки. А они, вот засада, на обычных ЯП. А на ФП они странные какие-то, с монадами. А обычные вот они, с привычными классами.
T>Вот и проникает всё в индустрию медленно и с трудом.
Угу, слишком медленно. Конечно ООП заползло почти во все ниши это тоже надо учитывать, но если бы присутствовала серебрянопулесть это бы не помешало, значит она или отсутствует или слишком дорога.
Здравствуйте, BulatZiganshin, Вы писали:
E>>Выгодно. Достаточно просмотреть на Java Application Server-а и другой middleware софт, построенный на ОО языках.
BZ>да, но ведь ООП появилось в 67-м. почему же мы не можем увидеть его выгодность в 68-м, 69-м... а массово коммерческий софт на ООП языках стали писать в конце 80-х. что целых 20 лет мешало людям получать столь очевидную коммерческую выгоду?
Где доказательство, что мешало? Имхо, как раз люди видели существующую выгоду от использования ООП. Потому и создавали все новые и новые инструменты, которые находили свое применение в реальных проектах. И в конце-концов это вылилось в подавляющее преимущество сейчас. Т.ч. я вижу коммерческую выгоду от конкретной парадигмы. Ты же заявляешь, что от ФП нет коммерческой выгоды. И я пытаюсь выяснить у тебя почему.
BZ>>>если да, почему оно не вытеснило ПЛ/1 с того самого 67-го года, когда было изобретено?
E>>То, что ООП вытеснило PL/1 уже очевидно лет двадцать как. ООП было настолько выгодно, что в 1979-м году некто Страуструп начал создание языка
BZ>а лисп был создан 50 лет назад, где-то между фортраном и алголом. так значит преимущества ФП очевидны уже лет 50 как? или не значит?
Лисп я не стал упоминать, поскольку сталкивался со мнение, что Lisp нельзя считать именно ФП языком.
E>>, который бы сочетал эффективность C и высокоуровневость Simula. Успешность его попытки ощущается до сих пор.
BZ>т.е. сама по себе сиула не была успешным проектом? а смолток, apple object pascal, eiffel?
Я привел только один пример того, как ОО язык стал успешным. Это вовсе не было отрицанием наличия других примеров.
BZ>наконец, сам c++ — он с 79-го года стал активно использоваться для коммерческой разработки или может с 80-го?
Сам Страуструп, AFAIK, говорил, что C++ начал применяться где-то с 1983. А в 1986 вышел его первый коммерческий компилятор. За период с 1986 по 1990 появилось несколько различных C++ компиляторов на различных платформах. Что вполне можно считать доказательством успешности языка.
E>>Как в количестве OpenSource-проектов, так и в количестве коммерческих проектов, выполняемых в данный момент
BZ>в данный момент. но ведь успешность парадигмы не зависит от времени и языка, так почему бы нам не рассмотреть 80-й год или 68-й?
Ну давай рассмотрим 1973-й и ML. Когда великого и ужасного C++ не было в зародыше, а реализации Simula были настолько кривые, что люди подумывали о создании собственных ОО альтернатив. И когда Smalltalk даже не вышел из ясельного возраста (насколько я знаю, Smalltalk-72 никуда за пределы лаборатории не вышел).
И еще: откуда взялся тезис, что успешность парадигмы не зависит от времени и языка?
E>>Так вот, если ты говоришь, что ФП коммерчески не выгодно, значит ты знаешь какие-то причины этого.
BZ>ты их и сам знаешь. просто думать отказываешься
Я продолжаю настаивать, что обосновывать тезис должен человек, который его выдвинул.
BZ>почему переход состоялся только в 89/90-м годах на самые слабые ооп языки — turbo pascal и с++?
Очень мощно утверждать, что C++ "самый слабый ОО язык". Из более-менее мейнстримовых языков множественное наследование для классов поддерживается только в C++ и Eiffel.
E>>PS. Утверждение о том, что самым широкораспространенным ОО языком был Turbo Pascal нуждается в доказательстве.
BZ>"первым широко распространённым ооп языком". разницу видишь?
Вижу. Поправка: утверждение о том, что первым широкораспространенным ОО языком был Turbo Pascal нуждается в доказательстве.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
T>>Simula-67 и C++ (79-й) — 12 лет разницы. В мейнстрим C++ попал в районе 90-93. MFC, AFAIK. Ещё 12 лет. T>>ML и Haskell — ~10 лет разницы. 78+24 — 2002. Ну, 2000. Так в 2000 SPJ на работу в Майкрософт и взяли, AFAIR. FR>ML 73 Миранда 85 так что должно быть 97.
С полиморфизмом — 1978. Алгоритм W.
T>>Но сейчас количество кода, с которым приходится общаться, значительно выше. Информационная связность повысилась в разы, если не на порядки. FR>Так это не помешало в конце 90-ых начале 2000 динамическим языкам.
Они использовались в качестве клея. Основная часть кода была написана на других ЯП.
Кстати, написание библиотек-биндингов провоцирует определённую организацию кода, что улучшает взаимодействие библиотек. Та самая компонентная модель.
T>>Считается, что для решения задач обязательно, обязательно-обязательно надо использовать сторонние библиотеки. А они, вот засада, на обычных ЯП. А на ФП они странные какие-то, с монадами. А обычные вот они, с привычными классами. T>>Вот и проникает всё в индустрию медленно и с трудом. FR>Угу, слишком медленно. Конечно ООП заползло почти во все ниши это тоже надо учитывать, но если бы присутствовала серебрянопулесть это бы не помешало, значит она или отсутствует или слишком дорога.
Здравствуйте, thesz, Вы писали:
T>Будь добр, разверни. Я не понимаю, что ты хотел этим сказать. RD выдвинул совершенно бредовый тезис не потрудившись его обосновать. Ты его повторил.
T>Ты думаешь, что повторение глупости переведёт её в разряд истины? Это не совсем так.
...
T>Поэтому, будь добр, перепиши свой ответ. Оба своих ответа.
Как бы тебя послать помягче?
3 (или уже больше?) человека говорят о том, что ты из поста RD высосал несусветно бредовую мысль, а потом приписал ее своим оппонентам. Ты там как, в порядке?
На всякий случай, процитирую RD:
1. Я НЕ утверждал что крупные программы на Хаскель не могут работать надежно и без проблем с потреблением памяти.
1.1 Я утверждал что я НЕ УВЕРЕН (и не имею достаточно веских с моей точки зрения оснований считать) что в случае разработки действительно большой софтины (порядка миллиона строк) да еще и большим коллективом, да еще и сегодня а не через десять лет... эти проблемы с памятью и общим пониманием всего этого хозяйства не станут проявляться.
1.2 Про CUFP я знаю давно. Но деталей там мало. И поэтому те примеры к тревожащему меня вопросу не клеются.
2 Я НЕ утвержал что Haskell это отстой. Это Вам, уважаемый, везде видятся Враги. Слава Богу, что не все Хаскелисты столь слепо яростны. Скажем, с Булатом общаться, как я вижу, можно и даже интересно. И Simon — очень конструктивный человек.
2.1 Обратно же, пока Вы не научитесь Слушать, Понимать и Уважать собеседника, то и уважать Вас никто не будет.
Герой, ты способен признать, что сказал глупость, а потом ее долго отстаивал?
Здравствуйте, thesz, Вы писали:
P>>Мне интересно, зачем же ты теряешь на меня время? Пойми, если я сказал глупость, другие это заметят и без твоей помощи.
T>Глупость должна быть разъяснена.
T>Я преследую две цели: чтобы никто не купился на глупость впредь, это первое. Тогда она будет меньше меня беспокоить. И вторая цель, не менее важная: активный оппонент, будучи переубежден, начинает работать на тебя.
T>Переубеждать у меня не очень получается, я срываюсь, но иногда мне это удаётся. Этим случаям я рад больше всего.
Рад, что за образом фанатика скрывается что-то человеческое :-). В принципе, я так и думал. Как я уже писал, буду очень рад быть переубежденным. Только вот чтобы переубедить меня, надо на порядок меньше срываться. И перед ответом пытаться найти в сообщениях мысль автора, а не свою мысль об авторе. И не скипать основные аргументы оппонента при ответе. И... ладно, и это навряд ли сбудется.
P>>Не напрягайся так. К чему дурацкие фразы типа T>>>Тут не сказали, падают ли другие системы. Пока я ответа не получил. P>>Он не очевиден? Тебе что, факс прислать, где написано «смирись, джедай, darcs хуже git»?
T>Будь добр, ответить на простой вопрос: почему система на Хаскеле, проакчивающая мегабайт в секунду, с нетривиаьлным обновлением базы в 10-100 МБайт, будет работать значительно хуже, чем на других языках?
«— Вы всегда отвечаете вопросом на вопрос? — Кто вам сказал?»
Собственно, есть простой тезис. Darcs серьезно уступает git, и его не спасает ни больший возраст, ни хаскель, ни алгебра патчей. Этот тезис неоднократно и подробно обосновывался. Для многих, этот тезис бросает серьезную тень на хаскель. И вовсе не потому, что, как ты пытаешься это выставить, оппоненты-идиоты отсюда сразу делают вывод о убогости хаскеля! А потому, что в ответ никто не говорит простое «на любом языке можно написать ерунду, вот и это тому пример». Все, напротив, (и ты в авангарде) стараются доказать, что darcs так же крут, как и хаскель, иначе и быть не может. Это, надеюсь, понятно?
Далее, ты наезжал на каждое подобное обоснование, из чего напрашивается вывод, что ты не согласен, и с твоей точки зрения, darcs лучше git. Ни единого вменяемого аргумента, при этом, приведено не было.
Здравствуйте, EvilChild, Вы в числе прочих меня критиковали.
Пока был в душе, появилась идея, как лучше объяснить свою позици. Итак:
Я считаю, что окружающую реальность довольно легко представить в виде объектов, имеющих состояние, и изменяющих его при выполнении некоторых действий. На лингвистическом уровне — вроде существительных, прилагательных и глаголов.
(Кстати, сама суть действий — изменение состояния. Если состояние постоянно, никаких действий в системе не происходит)
Важными частями, среди прочего, здесь являются
а) строгость действий
б) мутабельность объектов
Теперь: я считаю, что ООП, при всех перечисленных всеми подряд косяках, гораздо ближе к этой модели, чем pure lazy FP. И для pure lazy FP подобную объяснялку у меня выдумать не получается.
Поэтому я считаю, что ООП проще. В этом конкретном смысле простоты.
Если есть люди, заинтересованные в конструктивной дискуссии (может, даже thesz? :-), просьба, отвечая, сначала написать, понятна ли вам моя мысль. Если нет, то критику я игнорирую, так как проще объяснить свою позицию я навряд ли смогу, а терять время на базарные перебранки не хочу.
Да, подобные объяснялки для pure lazy FP приветствуются в любом случае. Пока лучшее, что я знаю — аналогия с Экселем.
Здравствуйте, Klapaucius, Вы писали:
K>Здравствуйте, eao197, Вы писали:
E>>Трудноиспользуемой ООП не была. ООП я начал использовать на втором курсе универа,
K>Думаю, что начни вы использовать ФП на втором курсе универа, трудноиспользуемым ФП вы также не назвали бы.
Я в этом сомневаюсь. Может быть, для людей с хорошим математическим и абстрактным мышлением так и было бы, но не для меня.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, pgregory, Вы писали: P>В случае с хаскелем это неверно. Практически невозможно написать сколько-нибудь нетривиальную программу, не зная, что такое монада. That's the whole point.
Часто достаточно понимания монады как соглашения об интерфейсе (для которого в языке предусмотрен сахар).
Здравствуйте, pgregory, Вы писали:
P>Здравствуйте, Code Digger, Вы писали:
CD>>Здравствуйте, pgregory, Вы писали:
P>>>Для программирования простых вещей на хаскеле необходимо знать сложное понятие монада. (Посмотри оглавление Real World Haskell, прежде чем возражать, ок?) Это плохо. Ни в одном сколько-нибудь распространенном языке, чтобы оперировать числами, не требуется знать, что такое коммутативное кольцо. (Прежде чем возражать, раздобудь ссылку, это опровергающую, ок?)
CD>>Как так получилось? Мне крупно повезло, да? А всем остальным обязательно понимать монады и теоркат, чтобы написать на Хаскеле grep?
P>Всем остальным, видимо, монады сэкономили столько времени при написании хорошего софта, что теперь они от нечего делать пишут монадные туториалы А у людей, их прочитавших, тут же загораются глаза, и они кидаются искать у себя в коде монады. Ведь код без монад — не код. Ты сколько нашел, кроме стандартных? Не поделишься результатами применения этого мощнейшего механизма абстракции?
Как-то писал на C# такой код, где постоянно повторялись не совсем тривиальные действия с разными параметрами. Очень сильно нехватало монад. Приходилось каждый раз вызывать руками.
P>>>Это моя позиция, и я ее аргументировал. Ясно? CD>>Это — Ваше _убеждение_. До сих пор не заметно, что оно основано на практике. Моя практика этому противоречит. Ясно?
P>Твоя практика, прости, чего? Написания маленького аналога грепа?
Я понимаю, что Вы ведёте войну на трёх фронтах, но всё же не надо спорить со мной о том, о чём Вы спорите в другой ветке. Здесь Вы заикались про обучение и необходимость знания монад.
Здравствуйте, thesz, Вы писали:
FR>>Так это не помешало в конце 90-ых начале 2000 динамическим языкам.
T>Они использовались в качестве клея. Основная часть кода была написана на других ЯП.
Клей только одно из использований, тот же PHP и Perl практически не используются как клей.
Да и на питоне пишут вполне полноценные приложения.
T>Кстати, написание библиотек-биндингов провоцирует определённую организацию кода, что улучшает взаимодействие библиотек. Та самая компонентная модель.
Угу и если есть хорошая модульность то практически ведет к своей платформе, например как в питоне.
FR>>Угу, слишком медленно. Конечно ООП заползло почти во все ниши это тоже надо учитывать, но если бы присутствовала серебрянопулесть это бы не помешало, значит она или отсутствует или слишком дорога.
T>Серебрянопулевость присутствует. Двухкратный прирост производительности наблюдается.
2 раза это в пределах колебаний при использовании одного и того же инструмента, мало.
T>Просто инерция выше, по-моему.
T>Но мы ещё посмотрим.
Здравствуйте, pgregory, Вы писали: P>>>У меня есть точка зрения, что такое хороший яп, а что — нет. Основная мысль в том, что реально хороший язык реально прост. Я ее высказал и попытался обосновать. Того, что ты усмотрел, в ней и близко нет. Замечания по сути есть? T>>"Реально прост" чем определяется? P>Реально прост определяется тем, что я его реально просто смогу объяснить ребенку или старику. Нет, я не докажу это утверждение.
Выделенное тут всё определяет.
Если ты думаешь о чём-то как о сложном, то ты не сможешь его никому просто объяснить.
Но ведь ты не единственный кто может кому-то что-то обяснять.
RD>>Ну если Ваш единственный аргумент — "разворачивай", то несомненно под его весом собеседник точно прогнется. Низкий поклон Вашему Гениальному Мозгу. T>"Разворачивай" — это не аргумент. Это указание на то, что для обсуждения мало информации. Нечего обсуждать-то, поэтому надо изложить тезисы более обстоятельно. Не видно, где ошибка и что можно комментировать. RD>>Кстати, перечитайте свой же пост в своем же блоге на тему культуры общения. Было бы неплохо если бы Вы сами придерживались этих правил. http://thesz.livejournal.com/657874.html T>Это правила поведения в моём блоге внешних комментаторов. T>Правила RSDN другие. Правил RSDN я, проде, придерживаюсь, нет?
Может и придерживаетесь. Только получается так: в своем блоге вы другим какать не разрешаете, а как удобрить RSDN, Вы — первый. Разве не так? :)
RD>>Вы наверное удивитесь, но мир не стоит на месте. И в то время C++ возможно (ВОЗМОЖНО) действительно не подходил для написания игр. Но если ДАЖЕ он не подходил ТОГДА, то сейчас, после долгой эволюции уже подходит. T>За счёт чего это? Те же конструкторы, те же деструкторы, то же непредсказуемое время из-за перегрузки. T>Что изменилось-то? Не развернёшь?
Лень разворачивать :) Но в общих чертах: изменилось железо, улучшились оптимизирующие компиляторы. Впрочем, даже сейчас на C++ писать игры не всегда легко.
T>(кстати, JC до сих пор пишет в стиле "почти C++" — более строгие проверки, структуры вместо классов и, изредка, перегрузка, если безопасно)
T>>>Все аргументы против применения Хаскеля, что ты (да большинство) выкладывают на стол, все они, до единого, звучали в отношении C++ в 1995 году. T>>>Вот и вся причина моего упрямства. T>>>Просто у меня хорошая память. RD>>Может память у Вас и хорошая. Но см. выше. Если аналогия с Хаскелем имеет место, то МОЖЕТ БЫТЬ (но не факт) в будущем (а не сразу сейчас) все будет заметно шоколаднее.
T>Так готовится к будущему надо сейчас. А то оно наступит, а мы не готовы.
Само собой. Но готовиться и праздновать, что оно уже наступило — две большине разницы.
RD>>Дорогой товарищ Великий Программист, я не намерен доказывать Вам тезисы, которые я не утверждал. T>Спасибо. Очень лестно. Нет, серьёзно, тронут до глубины души.
RD>>Я понимаю, что как Боец Ордена Св. Лябмды Вы в любом встречном видите грешника-иноверца и жаждете вспороть ему брюхо. Ничего, это бывало и раньше, и не только с Вами. Через сотню-другую лет обычно попускает даже крестоносцев. T>Что-то я поторопился с выражением признательности.
RD>>И ваши голубые глаза если кто и трогал, то не я. Я в этом плане вообще гуманист. T>Ура! "Я буду жить!"
RD>>Очень прискорбно, но мы с Вами не прийдем к единому мнению. Тут мне уже все ясно как Божий день. И причина этому проста. Вы просто не освоили тернарную логику. Ну, или чтобы Вам было понятнее, разницу между Maybe Bool и Bool. T>Что это означает? RD>>1. Я НЕ утверждал что крупные программы на Хаскель не могут работать надежно и без проблем с потреблением памяти. T>Что же это было за утверждение тогда?
Подумайте :-)
RD>>1.1 Я утверждал что я НЕ УВЕРЕН (и не имею достаточно веских с моей точки зрения оснований считать) что в случае разработки действительно большой софтины (порядка миллиона строк) да еще и большим коллективом, да еще и сегодня а не через десять лет... эти проблемы с памятью и общим пониманием всего этого хозяйства не станут проявляться.
T>Прошу прощения, но эти проблемы проявляются в инструментах, специально заточенных под такие задачи. В программах на Эрланге, например. Про утечки памяти в C++ легенды ходят. В C# такие же проблемы.
Снова рвет мозг на фарш. Что Вы имеете в виду?
— То, что Хаскель непригоден для разработки большого софта? (Уж не ересь ли это, уважаемое собрание?)
— То, что Эрланг специально заточен так, чтобы в нем появлялись проблемы? (Для многих это будет интересная новость)
— Что-то другое?
T>Про Хаскель мы не уверены, что они не проявятся. А про другие инструменты знаем, что они могут проявится. T>Другие инструменты — Эрланг, C++ и C#/Java, — можно использовать, а Хаскель нет. T>Эта логика выше моего понимания. Наверное, в ней используют Maybe Bool вместо Bool.
Даже безупречная логика приведет к кривым выводам если она основана на заведомо ложных утверждениях. См. утверждение (2). У тебя там "Хаскель нельзя использовать". А разумнее будет "Не до конца известно, возможно ли использовать Хаскель в подобных по масштабу проектах". Разницу ощущаем? Нет? Go читать про Maybe.
RD>>2 Я НЕ утвержал что Haskell это отстой. Это Вам, уважаемый, везде видятся Враги. Слава Богу, что не все Хаскелисты столь слепо яростны. Скажем, с Булатом общаться, как я вижу, можно и даже интересно. И Simon — очень конструктивный человек. T>Вы глупости на голубом глазу не утверждайте, и я тоже стану спокойным.
См. выше. Я не трогал Ваши глаза и глупости не утверждал. А вот Вы мои слова перекручиваете и действительно начинаете нести глупости.
T>Утверждения типа "вы пишите такой код, что он ни с чем не интегрируется" и "вот с хаскелем системы на мегабайт пропускной способности не получится" как-то не добавляют конструктивности в беседу.
См. выше. И думайте, пожалуйста.
RD>>2.1 Обратно же, пока Вы не научитесь Слушать, Понимать и Уважать собеседника, то и уважать Вас никто не будет. T>Для того, чтобы я Слушал, Понимал и Уважал собеседника, необходимо всего ничего: говорить Ясно, говорить Связно и говорить Уважительно. Либо отличиться на почве того, что мне интересно.
Ну уж... Вам тогда тоже следует придержаться этих правил. Очень хороши :-) Жаль только Вы ожидаете культуры общения от всех кроме себя.
T>Я не могу сказать, что я не стремлюсь быть уважаемым. Но я стремлюсь быть уважаемым теми, кто сам достоин уважения. T>Общая популярность меня мало заботит. Иначе я был бы lj user=drugoi, а не lj user=thesz.
Здравствуйте, thesz, Вы писали:
T>>>Со скоростью разобрались. T>>>Оказалось, что "darcs практически убивает по скорости" только git. C>>Mercurial тоже. T>Это такое абсолютное утверждение? Исключений быть не может?
А в чём собственно состоит исключение? Человек пишет следующее:
'hg convert' безбожно глючит и тупит
'darcs get' over HTTP — 47s
'hg clone' over HTTP — 13s
'darcs get' over SSH — 167s
'hg clone' over SSH — 18s
'darcs push -a' of a 3-line change over SSH — 2.67s
'hg push' of the same change over SSH — 1.16s
'darcs pull -a' of a new 3-line change over SSH — 4.82s
'hg pull -u' of the same change — 1.15s
Здравствуйте, BulatZiganshin, Вы писали: T>>>>Если мы таки о кривой работе стандартной библиотеке haskell с WinApi, то мне видится 2 нормальных решения: BZ>>>нет, мы о другом — о том, что FFI должен был предоставить операции и типы, скрывающие от программиста особенности платформы, после чего любой код, обращающийся к posix api, должен автоматом работать на обеих платформах T>>Это в смысле что не следует использовать haskell в винде? Всё равно будет глючить? BZ>это то, что предлагает мой оппонент. а я ему объяснил, почему это невозможно
Невозможно что?
1. Нормально использовать haskell в винде?
2. Нормально реализовать работу с файловым api винды в haskell?
3. Нормально реализовать posix api в винде?
Третье не имеет отношение к haskell.
Первому мешает кривая работа с файлами.
Что мешае второму я затрудняюсь ответить...
Здравствуйте, thesz, Вы писали:
T>>В рабочей папке darcs переместил 8 файлов (~100мб) в другой подкаталог. T>>darcs не смог гафиксировать изменения — вывалился по переполнению памяти. T>>На борту 2гб, darcs 2.2.1 (release), Win Vista Home. T>Что по этому поводу говорят другие системы? Им плохо?
SVN отработал без каких-нибудь нареканий и довольно быстро.
По сети перекинулость только инфа о том, что файлы переместились.
Hg тоже вполнее нормально отработал.
При добавлении файлов предупредил меня, что файл >10мб может вызвать проблемы но проблем не было.
Git был самый быстрый.
Т.е. из 4х рассматриваемых систем darcs просто не смог выполнить ожидаемого действия.
T>Обсуждаемый вопрос: на Хаскеле обязательно получится плохо, много хуже, чем у других.
Может быть обсуждаемый вопрос: на Хаскеле обязательно получится много лучше чем у других?
Не верно, с моей точки зрения, пока не то не другое.
Я, как бы сторонник Хаскеля, пытаюсь его учить и по маленьку использовать и подвигать.
Но постоянно натыкаюсь не только на своё незнание/неумение, но и на глюки стандартной библиотеки.
Всё это победимо и обходимо, можно написать свою работу с файлами как Булат, чуток подпачить регэксры, найти работу с кодировками и двигатся дальше...
А вот объяснить кому-то что он будет вынужден это делать уже несколько сложнее.
Здравствуйте, Tonal-, Вы писали:
BZ>>это то, что предлагает мой оппонент. а я ему объяснил, почему это невозможно T>Невозможно что?
слушай, я спорю с человеком. ты никак не можешь понять о чём мы спорим и вместо этого пишешь о вещах, которые возражений не вызывают. ну сколько можно?
Здравствуйте, thesz, Вы писали:
T>Никому не известный David Roundy с никому не известным Хаскелем выкатился, и приобрёл за два с половиной года 91-го контрибутора. Мегапопулярный Линус с гитом за полгода 79.
T>Смотрим на сегодняшнюю ситуацию: 652 и 222. Разница в три раза. Приращение в 4,3 раза больше. Знающих Си в десятки, если не в сотни раз больше, чем знающих Хаскель.
Для меня это звучит странно. Разве можно оценить качество продукта по количеству разработчиков?
К примеру, знаю я C (haskell, python ... на выбор); что я забыл в исходниках git (darcs, mercurial)?
Здравствуйте, BulatZiganshin, Вы писали: BZ>слушай, я спорю с человеком. ты никак не можешь понять о чём мы спорим и вместо этого пишешь о вещах, которые возражений не вызывают. ну сколько можно?
Мне показалось, что он писал именно о кривой поддержке unicode в стандартной библиотеке: Re[15]: [haskell] considered mainstream
Здравствуйте, pgregory, Вы писали:
P>Плоская память и адрес в ней, а также ссылка на объект — это вещи, которые легко объяснить даже ребенку.
Протестую — если ребенок имеет интерес к математике, то объяснить ФП ему проще, чем ООП, так как оно естественнее для него. Готов проиллюстрировать примером: я был ребенком, учился в 8 классе, когда, читая учебник по C++, был удивлен тем, что можно вызывать метод объекта с одними и теми же аргументами, получать разные значения. Сама возможность побочных действий, такая как изменение private переменной, мне показалось противоестественной и не логичной. Понятие ссылки почти не отделимо от возможности побочных действий, которые противоестественны, а усвоить то, что кажется нелогичным, сложно. Поэтому просто объяснить ссылки тоже трудно, замечу, что в тот момент я не был знаком с функциональной парадигмой, машиной Тьюринга и лямбда исчислением, поэтому пример корректен.
P>>>Не расскажешь ли, в двух словах P>>>— что такое монада
Монада имеет слабое отношение к ФП, поэтому её непонимание не мешает пользоваться haskell, достаточно рассматривать maybe, list и io как фичи языка, и не пытаться найти между ними общую структуру. Достаточно думать, что монада (io) это попытка органично ввести взаимодействие с внешнем миром в haskell. Но если от ФП программистов требовать на пальцах объяснить, что такое монада, то тогда разумно требовать от императивщиков на пальцах объяснить верификацию работы программ.
Здравствуйте, Tonal-, Вы писали:
T>Мне показалось, что он писал именно о кривой поддержке unicode в стандартной библиотеке:
а конкретно о предлагаемом им гениальном плане автоматической поддержки unicode во *всех* библиотеках. а ты всё думаешь, что речь идёт о том, как можно исправить библиотеку i/o. я знаю как это делать — ведь я её уже исправил
Здравствуйте, Рысцов Денис, Вы писали:
РД>Протестую — если ребенок имеет интерес к математике, то объяснить ФП ему проще, чем ООП, так как оно естественнее для него. Готов проиллюстрировать примером: я был ребенком, учился в 8 классе, когда, читая учебник по C++, был удивлен тем, что можно вызывать метод объекта с одними и теми же аргументами, получать разные значения.
ничего удивительно — в 8-м классе ребёнок ещё не осознаёт, что мир состоит из объектов, которые хранят внутреннее состояние и обмениваются сообщениями. квантовую физику изучают только в 9-м
Здравствуйте, BulatZiganshin, Вы писали:
РД>>Протестую — если ребенок имеет интерес к математике, то объяснить ФП ему проще, чем ООП, так как оно естественнее для него. Готов проиллюстрировать примером: я был ребенком, учился в 8 классе, когда, читая учебник по C++, был удивлен тем, что можно вызывать метод объекта с одними и теми же аргументами, получать разные значения.
BZ>ничего удивительно — в 8-м классе ребёнок ещё не осознаёт, что мир состоит из объектов, которые хранят внутреннее состояние и обмениваются сообщениями. квантовую физику изучают только в 9-м
Верно, но реальное устройство мира не имеет значения, так как работать мы можем только с его описанием. Само описание должно обладать рядом свойств, которые облегчают работу с ним. Так как программа является описанием, то естественно требовать от неё тех же свойств. В случае физики языком описания является математика. Но если вы затронули квантовую механику, но я не могу удержаться: частицу, можно описать множеством состояний, а принцип Гейзенберга гарантирует, что мы не можем сократить это множество до одного элемента. Поэтому множество возможных состояний следует взять за определение математического объекта частица. Этот математический объект является монадой. Той самой монадой, которая используется в haskell.
Здравствуйте, eao197, Вы писали:
E>Очень мощно утверждать, что C++ "самый слабый ОО язык". Из более-менее мейнстримовых языков множественное наследование для классов поддерживается только в C++ и Eiffel.
А как множественное наследование классов связано с ОО?
Нследование ортогонально ОО, множественное в особенности.
Здравствуйте, eao197, Вы писали:
EC>>Наследование ортогонально ОО, множественное в особенности.
E>Если под ОО рассматривать тройку из наследования, инкапсуляции и полиморфизма, то самым непосредственным. И, если нельзя унаследоваться сразу от нескольких классов, то это как раз ограничение для ОО.
Смотри выделенное жирным.
Наследование — это артефакт реализации ОО в конкретных языках.
T>>Никому не известный David Roundy с никому не известным Хаскелем выкатился, и приобрёл за два с половиной года 91-го контрибутора. Мегапопулярный Линус с гитом за полгода 79. T>>Смотрим на сегодняшнюю ситуацию: 652 и 222. Разница в три раза. Приращение в 4,3 раза больше. Знающих Си в десятки, если не в сотни раз больше, чем знающих Хаскель. К>Для меня это звучит странно. Разве можно оценить качество продукта по количеству разработчиков? К>К примеру, знаю я C (haskell, python ... на выбор); что я забыл в исходниках git (darcs, mercurial)?
Я уже немного подустал, поэтому отвечу кратко. Количество разработчиков darcs/git/mercurial примерно позволяет оценить уровень вхождения в произвольный продукт, написанный на конкретной смеси языков.
Функциональность, кстати, почти совпадает, что добавляет остроты в соревнование.
И последнее замечание: количество разработчиков косвенно показывает популярность проекта.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
T>>>В рабочей папке darcs переместил 8 файлов (~100мб) в другой подкаталог. T>>>darcs не смог гафиксировать изменения — вывалился по переполнению памяти. T>>>На борту 2гб, darcs 2.2.1 (release), Win Vista Home. T>>Что по этому поводу говорят другие системы? Им плохо? T>SVN отработал без каких-нибудь нареканий и довольно быстро. T>По сети перекинулость только инфа о том, что файлы переместились. T>Hg тоже вполнее нормально отработал. T>При добавлении файлов предупредил меня, что файл >10мб может вызвать проблемы но проблем не было. T>Git был самый быстрый. T>Т.е. из 4х рассматриваемых систем darcs просто не смог выполнить ожидаемого действия.
Ну, что же. bug tracker darcs доступен с его главной страницы.
Признаю, что darcs подкачал.
T>>Обсуждаемый вопрос: на Хаскеле обязательно получится плохо, много хуже, чем у других. T>Может быть обсуждаемый вопрос: на Хаскеле обязательно получится много лучше чем у других? T>Не верно, с моей точки зрения, пока не то не другое. T>Я, как бы сторонник Хаскеля, пытаюсь его учить и по маленьку использовать и подвигать. T>Но постоянно натыкаюсь не только на своё незнание/неумение, но и на глюки стандартной библиотеки. T>Всё это победимо и обходимо, можно написать свою работу с файлами как Булат, чуток подпачить регэксры, найти работу с кодировками и двигатся дальше... T>А вот объяснить кому-то что он будет вынужден это делать уже несколько сложнее.
(регэкспы неправильные, их надо по-своему писать, более типобезопасно)
Замечу, что это отнюдь не неподъёмная работа. Надо будет это прояснить как-нибудь.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
T>>>>Со скоростью разобрались. T>>>>Оказалось, что "darcs практически убивает по скорости" только git. C>>>Mercurial тоже. T>>Это такое абсолютное утверждение? Исключений быть не может?
К>А в чём собственно состоит исключение? Человек пишет следующее:
Да, не дочитал.
Тем не менее, неужто не может быть исключений?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
T>>Это правила поведения в моём блоге внешних комментаторов. T>>Правила RSDN другие. Правил RSDN я, проде, придерживаюсь, нет? RD>Может и придерживаетесь. Только получается так: в своем блоге вы другим какать не разрешаете, а как удобрить RSDN, Вы — первый. Разве не так?
Дорогой друг. Есть такой закон Годвина. Фекальная тема в твоём исполнении вполне тянет на его слабый вариант. Следствие из этого закона очень простое, доступное по ссылке.
RD>>>Вы наверное удивитесь, но мир не стоит на месте. И в то время C++ возможно (ВОЗМОЖНО) действительно не подходил для написания игр. Но если ДАЖЕ он не подходил ТОГДА, то сейчас, после долгой эволюции уже подходит. T>>За счёт чего это? Те же конструкторы, те же деструкторы, то же непредсказуемое время из-за перегрузки. T>>Что изменилось-то? Не развернёшь? RD>Лень разворачивать Но в общих чертах: изменилось железо, улучшились оптимизирующие компиляторы. Впрочем, даже сейчас на C++ писать игры не всегда легко.
Что означает, конечно же, что с ФП это не произойдёт.
RD>>>1. Я НЕ утверждал что крупные программы на Хаскель не могут работать надежно и без проблем с потреблением памяти. T>>Что же это было за утверждение тогда? RD>Подумайте
Разворачивай.
А то мне в голову лезут только нехорошие мысли.
RD>>>1.1 Я утверждал что я НЕ УВЕРЕН (и не имею достаточно веских с моей точки зрения оснований считать) что в случае разработки действительно большой софтины (порядка миллиона строк) да еще и большим коллективом, да еще и сегодня а не через десять лет... эти проблемы с памятью и общим пониманием всего этого хозяйства не станут проявляться. T>>Прошу прощения, но эти проблемы проявляются в инструментах, специально заточенных под такие задачи. В программах на Эрланге, например. Про утечки памяти в C++ легенды ходят. В C# такие же проблемы. RD>Снова рвет мозг на фарш. Что Вы имеете в виду? RD>- То, что Хаскель непригоден для разработки большого софта? (Уж не ересь ли это, уважаемое собрание?) RD>- То, что Эрланг специально заточен так, чтобы в нем появлялись проблемы? (Для многих это будет интересная новость) RD>- Что-то другое?
Сперва хотел сказать "подумай".
Потом решил, что глупость должна быть разъяснена.
Вот разъяснение. Ошибки можно допустить в любом ЯП, где-то это проще, где-то сложней. Даже в Эрланге, заточенном на мощную параллельную обработку, можно создать (не подумав) систему, что на одном ядре работает великолепно, а на двух и более валится по переполнению памяти.
Это специализированный инструмент. Что говорить об инструментах общего назначения?
T>>Про Хаскель мы не уверены, что они не проявятся. А про другие инструменты знаем, что они могут проявится. T>>Другие инструменты — Эрланг, C++ и C#/Java, — можно использовать, а Хаскель нет. T>>Эта логика выше моего понимания. Наверное, в ней используют Maybe Bool вместо Bool. RD>Даже безупречная логика приведет к кривым выводам если она основана на заведомо ложных утверждениях. См. утверждение (2). У тебя там "Хаскель нельзя использовать". А разумнее будет "Не до конца известно, возможно ли использовать Хаскель в подобных по масштабу проектах". Разницу ощущаем? Нет? Go читать про Maybe.
Где же можно почитать про чудесную логику с Maybe Bool, за исключением твоих трёх строчек?
Дело в том, что мы всегда не до конца знаем, можем ли мы использовать тот или иной инструмент в нашем большом проекте. Для всего проекта целиком это, вообще, невозможно для любого инструмента, любой удачности.
Именно поэтому современные проекты представляют смесь целой кучи парадигм, языков и инструментов. Питон, C++, Java, SQL, you name it.
Поэтому твой аргумент супротив Хаскеля работает против любого другого инструмента.
За Хаскель работает аргумент, что если тебе понадобился новый инструмент, то на Хаскеле он реализуем проще.
RD>>>2 Я НЕ утвержал что Haskell это отстой. Это Вам, уважаемый, везде видятся Враги. Слава Богу, что не все Хаскелисты столь слепо яростны. Скажем, с Булатом общаться, как я вижу, можно и даже интересно. И Simon — очень конструктивный человек. T>>Вы глупости на голубом глазу не утверждайте, и я тоже стану спокойным. RD>См. выше. Я не трогал Ваши глаза и глупости не утверждал. А вот Вы мои слова перекручиваете и действительно начинаете нести глупости.
"На голубом глазу" — это такое образное выражение.
T>>Утверждения типа "вы пишите такой код, что он ни с чем не интегрируется" и "вот с хаскелем системы на мегабайт пропускной способности не получится" как-то не добавляют конструктивности в беседу. RD>См. выше. И думайте, пожалуйста.
Я не обязан думать. Вообще. И уж никто не заставит меня додумывать за тебя аргументы в твою пользу.
Именно поэтому я всегда разъясняю глупость. Что кто чего лишнего не подумал.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
T>>Серебрянопулевость присутствует. Двухкратный прирост производительности наблюдается. FR>2 раза это в пределах колебаний при использовании одного и того же инструмента, мало.
Это консервативная оценка.
По строкам Java-vs-Haskell примерно 10 раз. Против C++ — 2-10 раз (вообще, в районе где-то 3-4-х, когда пишут не-продакшн код и по прототипу на Хаскеле.
Против 2 раз никто не поспорит.
ФЯ устраняет целый класс ошибок, что положительно сказывается на их плотности.
Ещё замечу, что серебренная пуля Брукса была выдумана в районе макроассемблера S/360 и PL/1. Разница между ними не так уж и высока, примерно два-три раза.
Но PL/1 тоже устранял класс ошибок — распределение регистров и передача параметров.
В историческом контексте "серебренная пуля" смотрится по-другому.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
T>>Будь добр, разверни. Я не понимаю, что ты хотел этим сказать. RD выдвинул совершенно бредовый тезис не потрудившись его обосновать. Ты его повторил. T>>Ты думаешь, что повторение глупости переведёт её в разряд истины? Это не совсем так. P>... T>>Поэтому, будь добр, перепиши свой ответ. Оба своих ответа. P>Как бы тебя послать помягче?
Какая интересная сюжетная линия!
P>3 (или уже больше?) человека говорят о том, что ты из поста RD высосал несусветно бредовую мысль, а потом приписал ее своим оппонентам. Ты там как, в порядке?
Мне говорят об этом ровно 2 человека: ты, да сам RD.
Всем остальным всё давно ясно.
P>На всякий случай, процитирую RD: P>
P>1. Я НЕ утверждал что крупные программы на Хаскель не могут работать надежно и без проблем с потреблением памяти.
Заявление RD по-другому истолковать нельзя. Мне, если честно, уж поднадоело его искать.
P>Герой, ты способен признать, что сказал глупость, а потом ее долго отстаивал?
Ты как-то неправильно переписываешь свои посты.
Вместо аргументации ты просто тиражируешь свою и чужую глупость.
Я не могу тебе этого запретить, но и не могу также толерантно пройти мимо.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
T>>Переубеждать у меня не очень получается, я срываюсь, но иногда мне это удаётся. Этим случаям я рад больше всего. P>Рад, что за образом фанатика скрывается что-то человеческое . В принципе, я так и думал. Как я уже писал, буду очень рад быть переубежденным. Только вот чтобы переубедить меня, надо на порядок меньше срываться. И перед ответом пытаться найти в сообщениях мысль автора, а не свою мысль об авторе. И не скипать основные аргументы оппонента при ответе. И... ладно, и это навряд ли сбудется.
Прошу прощения, но я буду отвечать так, как я намерен отвечать. Сорвусь или не сорвусь, это дело третье.
P>>>Не напрягайся так. К чему дурацкие фразы типа T>>>>Тут не сказали, падают ли другие системы. Пока я ответа не получил. P>>>Он не очевиден? Тебе что, факс прислать, где написано «смирись, джедай, darcs хуже git»? T>>Будь добр, ответить на простой вопрос: почему система на Хаскеле, проакчивающая мегабайт в секунду, с нетривиаьлным обновлением базы в 10-100 МБайт, будет работать значительно хуже, чем на других языках? P>«— Вы всегда отвечаете вопросом на вопрос? — Кто вам сказал?»
Видишь ли, другие товарищи потрудились и подтвердили фактами высказывание "darcs хуже git". По крайней мере, в перемещении больших файлов.
Но всё равно остаётся открытым техническое, а не ad hominem обоснование тезиса "система на Хаскеле, проакчивающая мегабайт в секунду, с нетривиаьлным обновлением базы в 10-100 МБайт, будет работать значительно хуже, чем на других языках".
Я отвечаю вопросом на вопрос в случае, когда считаю обращённый ко мне вопрос бессмысленным и когда мне надо вернуть оппонента на стезю обсуждения.
P>Собственно, есть простой тезис. Darcs серьезно уступает git, и его не спасает ни больший возраст, ни хаскель, ни алгебра патчей.
darcs уступает git в области скорости. Вопрос об индивидуальных патчах остаётся открыт.
P>Этот тезис неоднократно и подробно обосновывался. Для многих, этот тезис бросает серьезную тень на хаскель. И вовсе не потому, что, как ты пытаешься это выставить, оппоненты-идиоты отсюда сразу делают вывод о убогости хаскеля! P>А потому, что в ответ никто не говорит простое «на любом языке можно написать ерунду, вот и это тому пример». P>Все, напротив, (и ты в авангарде) стараются доказать, что darcs так же крут, как и хаскель, иначе и быть не может. Это, надеюсь, понятно?
Не совсем. Понятно, как твоё описание ООП. То есть, слова знакомые, фразы построены понятно, а общий смысл теряется.
Начну с того, что именно я говорил, что любой инструмент не совершенен. Что утверждение "на счёт Хаскеля не уверен" просто продолжение рассуждений о любом инструменте.
darcs имеет нечто уникальное, ту самую алгебру патчей, что тяжело реализовать на других ЯП и что всё же даёт ему преимущество в отдельных случаях. Тех самых, что встречаются чаще всего.
И на этом я остановлюсь, пока.
Прошу прощения, что не очень связно.
P>Далее, ты наезжал на каждое подобное обоснование, из чего напрашивается вывод, что ты не согласен, и с твоей точки зрения, darcs лучше git. Ни единого вменяемого аргумента, при этом, приведено не было.
Ты здесь путаешь обсуждение darcs и обсуждение Хаскеля вообще, как средства для больших проектов.
Здравствуйте, thesz, Вы писали:
T>По строкам Java-vs-Haskell примерно 10 раз. Против C++ — 2-10 раз (вообще, в районе где-то 3-4-х, когда пишут не-продакшн код и по прототипу на Хаскеле.
Угу, но примерно одинаково по тем же строкам с питоном или окамлом.
T>Против 2 раз никто не поспорит.
Угу, но при наблюдаемом 10 кратном разбросе при использовании одного и того же инструмента не
впечатляет.
T>ФЯ устраняет целый класс ошибок, что положительно сказывается на их плотности.
Да это преимущество по сравнению с тем же питоном, но с окамлом уже почти нет.
T>Хаскель во многом лучше других инструментов. Аргументы против слабы, так как применимы не только к Хаскелю. Проблемы Хаскеля окупаются высокой производительностью программиста на нём.
Угу только Хаскель не единственный инструмент который повышает производительность программиста, так что тоже не аргумент.
Здравствуйте, BulatZiganshin, Вы писали:
FR>>Угу только Хаскель не единственный инструмент который повышает производительность программиста
BZ>а какие ещё (кроме утюга и паяльника)?
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, BulatZiganshin, Вы писали:
FR>>>Угу только Хаскель не единственный инструмент который повышает производительность программиста
BZ>>а какие ещё (кроме утюга и паяльника)?
FR>Штанга и наркотические грибы.
Может, всё-таки, не грибы, а стимуляторы ЦНС? Кокаин, мета-амфетамин?
T>>По строкам Java-vs-Haskell примерно 10 раз. Против C++ — 2-10 раз (вообще, в районе где-то 3-4-х, когда пишут не-продакшн код и по прототипу на Хаскеле. FR>Угу, но примерно одинаково по тем же строкам с питоном или окамлом.
Плотность ошибок меньше?
Для питона надо тесты писать. Как для Лиспа. И это должно сказаться на количестве кода.
T>>Против 2 раз никто не поспорит. FR>Угу, но при наблюдаемом 10 кратном разбросе при использовании одного и того же инструмента не FR>впечатляет.
10-тикратном разбросе у одного программиста?
Позволю себе не поверить.
T>>ФЯ устраняет целый класс ошибок, что положительно сказывается на их плотности. FR>Да это преимущество по сравнению с тем же питоном, но с окамлом уже почти нет.
У Окамла система типов слабая.
Я думаю, что разница даст о себе знать в ближайшее время. Я тут попробовал на вкус это дело, впечатляет.
Matthias Blume [2] has derived a similar parameterization of arrays in SML, which can express such equality of size constraints. Matthias Blume however cautions one not to overstate the usefulness of the approach because the type system can express only fairly simple constraints: “There is still no type that, for example, would force two otherwise arbitrary arrays to di®er in size by exactly one.”
В статье по ссылке выше рассказывается, как в Хаскеле можно сделать то, что в SML нельзя.
С семействами типов это ещё проще.
Плотность ошибок ещё снизится.
T>>Хаскель во многом лучше других инструментов. Аргументы против слабы, так как применимы не только к Хаскелю. Проблемы Хаскеля окупаются высокой производительностью программиста на нём. FR>Угу только Хаскель не единственный инструмент который повышает производительность программиста, так что тоже не аргумент.
А что ещё повышает?
А это — то, что повышает, — ортогонально ЯП, или нет?
А если ортогонально, то как же тогда аргумент за Хаскель тоже не аргумент?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>>>По строкам Java-vs-Haskell примерно 10 раз. Против C++ — 2-10 раз (вообще, в районе где-то 3-4-х, когда пишут не-продакшн код и по прототипу на Хаскеле. FR>>Угу, но примерно одинаково по тем же строкам с питоном или окамлом.
T>Плотность ошибок меньше?
У тебя есть доказательства что она меньше в Хаскеле?
T>Для питона надо тесты писать. Как для Лиспа. И это должно сказаться на количестве кода.
Конечно надо, но даже с тестами у него очень хорошая плотность кода.
К тому же есть подозрения что для Хаскеля тоже не обойтись без тестов в случай длительно
подерживаемого проекта.
T>>>Против 2 раз никто не поспорит. FR>>Угу, но при наблюдаемом 10 кратном разбросе при использовании одного и того же инструмента не FR>>впечатляет.
T>10-тикратном разбросе у одного программиста?
T>Позволю себе не поверить.
В разы запросто, например у меня.
T>>>ФЯ устраняет целый класс ошибок, что положительно сказывается на их плотности. FR>>Да это преимущество по сравнению с тем же питоном, но с окамлом уже почти нет.
..... T>Плотность ошибок ещё снизится.
Все это конечно хорошо, надо почитать.
Но если брать реальный код на сколько процентов он будет короче и насколько надежнее по сравнению
с тем же окамлом, опять таки есть подозрения что очень немного, кроме спицифичных вырожденных случаев
конечно.
T>>>Хаскель во многом лучше других инструментов. Аргументы против слабы, так как применимы не только к Хаскелю. Проблемы Хаскеля окупаются высокой производительностью программиста на нём. FR>>Угу только Хаскель не единственный инструмент который повышает производительность программиста, так что тоже не аргумент.
T>А что ещё повышает?
T>А это — то, что повышает, — ортогонально ЯП, или нет?
То что ортогонально ЯП уже дает колебания близкие к порядку.
Но кроме этого Хаскель не единственный высокоуровневый язык.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, BulatZiganshin, Вы писали:
FR>>>Угу только Хаскель не единственный инструмент который повышает производительность программиста
BZ>>а какие ещё (кроме утюга и паяльника)?
FR>Штанга и наркотические грибы.
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, pgregory, Вы писали: P>>С первым не согласен. Continuations — это жесть, по аналогии с монадами. Мне это не нравится. MC>А тут-то что сложного? :xz: Всего лишь побочный эффект cps.
Scheme provides a very powerful control abstraction named call-with-current-continuation. Not only is the name intimidating, but many introductions to its semantics are as well.
По слогам: лично мне continuations кажутся сложными. Я не навязываю тебе свою точку зрения. Я пытаюсь донести, почему я так считаю.
P>>Не знаю, почему, но то, что мне не нравятся сложные языки программирования MC>Такое ощущение, что Вы готовы признать сложным все, выходящее за рамки сегодняшнего мейнстрима. Потому как Ваших критериев сложности яп я пока не понимаю.
Черт, жаль. Значит я плоха объясняю. Как я уже писал, например, CL без мусора обратной совместимости я тоже считаю простым.
Если на неделе появится время, постараюсь собрать свои мысли по поводу сложности и мейнстримности в одно сообщение.
Здравствуйте, VoidEx, Вы писали:
VE>Окружающую действительность довольно легко представить в виде объектов, над которыми можно произвести действия, и самих действий, в которых участвуют от 0 до нескольких объектов. Действие меняет состояние этих объектов. Более того, действию как правило нужно какое-то конкретное представление объекта (например телевизор в конкретном действии участвует только как параллепипед с массой). VE>Но это не ООП. VE>Тут нет объектов, обменивающихся сообщениями, тут нет наследования и полиморфизма, и даже инкапсуляции. VE>Тут есть объекты, которые в зависимости от ситуации надо представить так или иначе, а это в чистом виде либо преобразование в другой объект, либо type classes. VE>Тут есть действия, которые работают с _несколькими_ объектами в общем случае, а это функция от нескольких объектов, возвращающая новые состояния этих объектов, а не метод одного из них. VE>Я не вижу ООП. VE>Вот если бы можно было написать (man1, man2).поприветствовать(), тогда другое дело. Это действительно калька с реальности. А man1.поприветствовать(man2), это непойми что. Ну правда. Надо ведь (man1, man2, man3, man4).всем_привет().
Дорогой коллега! Готов подписаться под каждым твоим словом здесь. Я не пропагандирую ООП. И type classes я считаю на порядок более правильной идеей, чем обычные классы.
Я написал, что ООП гораздо ближе к этой модели, чем pure lazy FP. Согласен?
И на этом основано мое мнение, что ООП проще pure lazy FP. Понимаешь?
Можешь написать, какие применения стандартных и нестандартных монад ты видел в своих шарповых проектах? Чем подробнее, тем лучше. Это чистосердечный вопрос. Мне действительно интересно.
Здравствуйте, pgregory, Вы писали:
P>Дорогой коллега! Готов подписаться под каждым твоим словом здесь. Я не пропагандирую ООП. И type classes я считаю на порядок более правильной идеей, чем обычные классы.
P>Я написал, что ООП гораздо ближе к этой модели, чем pure lazy FP. Согласен?
Вот ведь и не знаю, возможно.
Знакомый у меня есть, начинает программировать. Я его попросил поучить Хаскель. ООП он не знает. Посмотрим, что он расскажет
Правда это будет нескоро.
P>И на этом основано мое мнение, что ООП проще pure lazy FP. Понимаешь?
Понимаю.
Здравствуйте, pgregory, Вы писали:
P>Ок, извини за мой тон.
Не за что. У меня нет проблем с тоном собеседника — подстраиваюсь под него.
P>Можешь написать, какие применения стандартных и нестандартных монад ты видел в своих шарповых проектах? Чем подробнее, тем лучше. Это чистосердечный вопрос. Мне действительно интересно.
К сожалению, не могу. Возможно, мне помогут более грамотные и опытные коллеги.
А вообще, методика простая: нужно один раз написать свою монаду на Хаскеле (можно реализовать любой пример, допустим, парсер), после чего в подсознание врезается понимание того, какой код (какие обобщения) "скрываются" монадой. Начинаешь видеть монады везде, где они применимы.
В точности так я освоил ФВП. Теперь органически не способен смешивать обход структуры (дерева XML, например) и вычисления. Даже на C#. Активно пользуюсь делегатами.
Здравствуйте, pgregory, Вы писали:
P>Здравствуйте, Mr.Cat, Вы писали:
MC>>Здравствуйте, pgregory, Вы писали: P>>>С первым не согласен. Continuations — это жесть, по аналогии с монадами. Мне это не нравится. MC>>А тут-то что сложного? Всего лишь побочный эффект cps.
P>Тонкая шутка P>По слогам: лично мне continuations кажутся сложными. Я не навязываю тебе свою точку зрения. Я пытаюсь донести, почему я так считаю.
Здравствуйте, Tonal-, Вы писали:
T>Здравствуйте, pgregory, Вы писали: P>>>>У меня есть точка зрения, что такое хороший яп, а что — нет. Основная мысль в том, что реально хороший язык реально прост. Я ее высказал и попытался обосновать. Того, что ты усмотрел, в ней и близко нет. Замечания по сути есть? T>>>"Реально прост" чем определяется? P>>Реально прост определяется тем, что я его реально просто смогу объяснить ребенку или старику. Нет, я не докажу это утверждение. T>Выделенное тут всё определяет.
Конечно.
T>Если ты думаешь о чём-то как о сложном, то ты не сможешь его никому просто объяснить.
Конечно.
T>Но ведь ты не единственный кто может кому-то что-то обяснять. :)
Конечно.
Почему-то на РСДН принято считать, что люди на форуме должны изрекать только доказуемые истины. Если бы моя точка зрения была доказуемой истиной, я бы написал, что все остальные — заблуждающиеся идиоты, и опубликовал бы доказательство вместе с набором аксиом. Дискуссия бы на этом закончилась. 2 + 2 = 4. Что здесь обсуждать?
Может, я чересчур наивен, но я считаю, что люди на форуме обмениваются личными мнениями. В идеале — чтобы лучше понять свою и чужую позиции. Иначе — см. предыдущий параграф.
Здравствуйте, Рысцов Денис, Вы писали:
РД>Протестую — если ребенок имеет интерес к математике, то объяснить ФП ему проще, чем ООП, так как оно естественнее для него. Готов проиллюстрировать примером: я был ребенком, учился в 8 классе, когда, читая учебник по C++, был удивлен тем, что можно вызывать метод объекта с одними и теми же аргументами, получать разные значения. Сама возможность побочных действий, такая как изменение private переменной, мне показалось противоестественной и не логичной. Понятие ссылки почти не отделимо от возможности побочных действий, которые противоестественны, а усвоить то, что кажется нелогичным, сложно. Поэтому просто объяснить ссылки тоже трудно, замечу, что в тот момент я не был знаком с функциональной парадигмой, машиной Тьюринга и лямбда исчислением, поэтому пример корректен.
Хорошо написано. Your point taken.
РД>Монада имеет слабое отношение к ФП, поэтому её непонимание не мешает пользоваться haskell, достаточно рассматривать maybe, list и io как фичи языка, и не пытаться найти между ними общую структуру. Достаточно думать, что монада (io) это попытка органично ввести взаимодействие с внешнем миром в haskell.
Понял тебя. Теперь уже двое говорят мне, что на хаскеле можно полноценно программировать без понимания монад. Ок, учту.
РД>Но если от ФП программистов требовать на пальцах объяснить, что такое монада, то тогда разумно требовать от императивщиков на пальцах объяснить верификацию работы программ.
Здравствуйте, pgregory, Вы писали:
P>Ок, извини за мой тон.
P>Можешь написать, какие применения стандартных и нестандартных монад ты видел в своих шарповых проектах? Чем подробнее, тем лучше. Это чистосердечный вопрос. Мне действительно интересно.
This paper is a personal account of my journey to democratize
the three-tier distributed programming problem using
(lazy) functional programming concepts. It starts with my
naive attempt to use Haskell as the language to write threetier
distributed data intensive applications, then continues
with my brief flirtation with designing a series of completely
new languages from scratch including Mondrian, XM, and
C!, and ends when I accidentally discover the Change Function
[37] and finally succeed by incorporating functional
programming and monads into the LINQ framework, C# 3.0
and Visual Basic 9.
Здравствуйте, pgregory, Вы писали:
P>Можешь написать, какие применения стандартных и нестандартных монад ты видел в своих шарповых проектах? Чем подробнее, тем лучше. Это чистосердечный вопрос. Мне действительно интересно.
Сорри, что влезаю в дискуссию, но прочитал обновления в ветке, оторвавшись от кода на nemerle (почти C#), в котором мне помог бы вариант монады List: код заключается в преобразовании неоднозначного дерева математических выражений в множество однозначных деревьев. Например, выражение "a+-b" должно перейти в список ["a+b","a-b"]. Во время разбора через дерево протаскивается объект, описывающий типы выражений, и потенциально на каждом узле дерево может раздваиваться. Весь процесс обладает структурой, которую можно оформить через монаду, а сам процесс описать через комбинаторы.
Здравствуйте, pgregory, Вы писали:
РД>>Но если от ФП программистов требовать на пальцах объяснить, что такое монада, то тогда разумно требовать от императивщиков на пальцах объяснить верификацию работы программ.
P>Не понял аналогии.
Существование монад в языке haskell связано не с его функциональной сущностью, а с его строгой системой типов. Вектор развития типизации лежит через зависимые типы к светлому будущему, в котором типизация программы практически совпадает со спецификацией. Такая точка зрения позволяет смотреть на типы как теоремы, а на код как на доказательство; потенциально его можно будет автоматически верифицировать. В общем, за монадами уже идет computer-science-жесть (я в ней понимаю мало, но пытаюсь просматривать статьи, и искать идеи, которые можно применить в заурядном коде), поэтому мне, кажется, что требовать объяснить на пальцах что такое монады и зачем они нужны некорректно.
В целом — да. То есть, сама идея очень простая. Но ее применение, мне кажется, привносит в код ненужную сложность (думаю, как и везде, исключения есть). Из статьи по ссылке: «Writing code in CPS, while not impossible, is often error-prone». Это плохо.
Здравствуйте, pgregory, Вы писали:
P>Здравствуйте, z00n, Вы писали:
Z>>А CPS вам кажется сложным? Z>>http://en.wikipedia.org/wiki/Continuation-passing_style
P>В целом — да. То есть, сама идея очень простая. Но ее применение, мне кажется, привносит в код ненужную сложность (думаю, как и везде, исключения есть). Из статьи по ссылке: «Writing code in CPS, while not impossible, is often error-prone». Это плохо.
Ее редко пишут руками, обычно CPS трансформацию делает компилятор. Но понять просто. Дальше: есть языки, где continuations — первокласная сущность, как int в C, ее можно получить в любом месте, сохранить в переменной, вызвать несколько раз — чего тут понимать?
Здравствуйте, z00n, Вы писали:
Z>Ее редко пишут руками, обычно CPS трансформацию делает компилятор. Но понять просто. Дальше: есть языки, где continuations — первокласная сущность, как int в C, ее можно получить в любом месте, сохранить в переменной, вызвать несколько раз — чего тут понимать? :)
Понимаешь, мне кажется (зачеркнуто) (черт — достало вставлять эти оговорки везде. Все, что я пишу — личное мнение, если не сказано иное — ок?), 99% случаев применения CPS, call-cc & friends можно переписать, используя более простые понятия. Генераторы, исключения и так далее. И код станет лучше. Я не согласен с тем, что абстракция любой ценой — это хорошо.
Здравствуйте, Рысцов Денис, Вы писали:
РД>Вектор развития типизации лежит через зависимые типы к светлому будущему, в котором типизация программы практически совпадает со спецификацией.
Я в это не верю. И я не хочу такого будущего. Типизация хороша в меру. Как и спецификация. Есть некий порог, за которым типизация становится сложной настолько, что сама начинает быть источником ошибок.
РД>Такая точка зрения позволяет смотреть на типы как теоремы, а на код как на доказательство; потенциально его можно будет автоматически верифицировать.
Не верю, что в сколько-нибудь обозримом будущем хотя бы 1% программ будет формально верифицироваться. Верификация гарантирует соответствие спецификации, не более. Не следует преувеличивать ее значение.
РД>В общем, за монадами уже идет computer-science-жесть (я в ней понимаю мало, но пытаюсь просматривать статьи, и искать идеи, которые можно применить в заурядном коде), поэтому мне, кажется, что требовать объяснить на пальцах что такое монады и зачем они нужны некорректно.
Я все равно не понял твоей логики, но давай забъем на это. Типизация и верификация гораздо интереснее :-)
Здравствуйте, pgregory, Вы писали:
P>Понимаешь, мне кажется (зачеркнуто) (черт — достало вставлять эти оговорки везде. Все, что я пишу — личное мнение, если не сказано иное — ок?), 99% случаев применения CPS, call-cc & friends можно переписать, используя более простые понятия. Генераторы, исключения и так далее. И код станет лучше. Я не согласен с тем, что абстракция любой ценой — это хорошо.
Continuations — не для написания программ, они для написания библиотек (тредов, исключений, генераторов, корутин, вебсерверов).
Есть разные подходы к проектированию языков:
Programming languages should be designed not by piling
feature on top of feature, but by removing the weaknesses
and restrictions that make additional features appear necessary.
R5RS
Типичный негативный пример С++ — там практически нет механизмов — одни фичи — расширять его дальше практически нельзя. Но язык живет долго, никто не может знать заранее какая фича понадобиться лет через 10-15.
Здравствуйте, z00n, Вы писали:
Z>Continuations — не для написания программ, они для написания библиотек (тредов, исключений, генераторов, корутин, вебсерверов).
Я не различаю «обычные» программы и библиотеки, и не считаю, что они должны как-то по-разному писаться.
Z>Есть разные подходы к проектированию языков: Z>
Z>Programming languages should be designed not by piling
Z>feature on top of feature, but by removing the weaknesses
Z>and restrictions that make additional features appear necessary.
Z>R5RS
Звучит красиво. Но теория и практика совпадают только в теории. Несмотря на концептуальную простоту, схема не получила распространения, и нет предпосылок к тому, что получит.
Side note: существует Kernel, еще более «суровый», чем схема.
Z>Типичный негативный пример С++ — там практически нет механизмов — одни фичи — расширять его дальше практически нельзя. Но язык живет долго, никто не может знать заранее какая фича понадобиться лет через 10-15.
Я понимаю, о чем ты, но, на самом деле, в плюсах слишком много механизмов и слишком мало фич :-) Поясню. В плюсах нет нормальной системы типов. Зато там есть шаблоны, которые по мощи уделывают типы хаскеля на порядок (другое дело, что воспользоваться этой мощью практически бесконечно трудно :-) Там нет сборки мусора, но есть смарт-поинтеры и RAII. И так далее.
Плюсы активно проживут еще лет 10, думаю (т.е. еще лет 10 люди будут начинать новые проекты на плюсах). Потом умрут, на смену придет более стройный язык. Потом он умрет. И так далее.
Это настраивает на прекрасную мысль о том, что идеальный язык должен быть создан для эволюции. Как лисп, только еще на порядок гибче. И, хотя есть опасность, что он, как схема, будет «jack of all trades, master of none», теоретически, он может быть создан. Я даже пытался думать в этом направлении, но понял, что для этого я слишком глуп.
Здравствуйте, pgregory, Вы писали:
P>>>С первым не согласен. Continuations — это жесть, по аналогии с монадами. Мне это не нравится. MC>>А тут-то что сложного? Всего лишь побочный эффект cps. P>Тонкая шутка
Честно говоря, я не шутил. Если над кодом произведено cps, то call/cc — можно реализовать в виде обычной функции:
P>Not only is the name intimidating, but many introductions to its semantics are as well.
Собственно, тут чувствуется намек на недостатки вводных курсов по scheme.
P>По слогам: лично мне continuations кажутся сложными.
В scheme действительно местами заковыристая семантика континуаций. Но на практике c ней нечасто приходится сталкиваться. Возврат/прием нескольких значений из функции (в scheme это можно делать, не применяя списки/векторы) в библиотеках местами используется. А вот на call/cc можно вообще забить — это все-же низкоуровневая штука, и проще пользоваться высокоуровневыми обертками, реализующими исключения, многопоточность и т.п.
Здравствуйте, pgregory, Вы писали:
P>thesz, я тут долго писал Великий Пост, разносящий твою позицию в этой ветке в пух и прах. Но потом понял, что я теряю время. И прекратил. Счастливо повоевать!
жаль, что на rsdn нет награды за дезертирство с Поля Брани
Здравствуйте, BulatZiganshin, Вы писали:
P>>thesz, я тут долго писал Великий Пост, разносящий твою позицию в этой ветке в пух и прах. Но потом понял, что я теряю время. И прекратил. Счастливо повоевать!
BZ>жаль, что на rsdn нет награды за дезертирство с Поля Брани :))
OMG! Ты что, реально считаешь, что мне было просто нечем ответить, и из-за этого я решил дезертировать?
Включи мозг — гораздо правильнее тогда было бы просто проигнорировать thesz'a — это совершенно типичное для него сообщение. Подумаешь — я, типа, не заметил.
Ну же, давай, напиши «да» — и я найду в себе силы ответить! Не дай угаснуть флейму!
Здравствуйте, pgregory, Вы писали:
P>Здравствуйте, z00n, Вы писали:
P>Я понимаю, о чем ты, но, на самом деле, в плюсах слишком много механизмов и слишком мало фич Поясню. В плюсах нет нормальной системы типов. Зато там есть шаблоны, которые по мощи уделывают типы хаскеля на порядок (другое дело, что воспользоваться этой мощью практически бесконечно трудно Там нет сборки мусора, но есть смарт-поинтеры и RAII. И так далее.
Я тоже поясню. RAII есть абсолютно в любом языке с первокласными функциями — как правило в таких языках есть еще и сборка мусора. Но наличие RAII в С++ сделали невозможным GC в стандарте С++ даже опционально. Потому, что думать нужно рано
P>Плюсы активно проживут еще лет 10, думаю (т.е. еще лет 10 люди будут начинать новые проекты на плюсах). Потом умрут, на смену придет более стройный язык. Потом он умрет. И так далее.
Scheme ровесник С — и еще очень долго не умрет
FR>>>Угу, но примерно одинаково по тем же строкам с питоном или окамлом. T>>Плотность ошибок меньше? FR>У тебя есть доказательства что она меньше в Хаскеле?
Косвенные.
Разработчики языков программирования переходят на Хаскель с *ML.
T>>Для питона надо тесты писать. Как для Лиспа. И это должно сказаться на количестве кода. FR>Конечно надо, но даже с тестами у него очень хорошая плотность кода. FR>К тому же есть подозрения что для Хаскеля тоже не обойтись без тестов в случай длительно FR>подерживаемого проекта.
Функциональных тестов. Их намного меньше юнит-тестов.
T>>>>Против 2 раз никто не поспорит. FR>>>Угу, но при наблюдаемом 10 кратном разбросе при использовании одного и того же инструмента не FR>>>впечатляет. T>>10-тикратном разбросе у одного программиста? T>>Позволю себе не поверить. FR>В разы запросто, например у меня.
"10 раз" и "разы" различаются, как бы, раза в три-четыре.
FR>..... T>>Плотность ошибок ещё снизится. FR>Все это конечно хорошо, надо почитать. FR>Но если брать реальный код на сколько процентов он будет короче и насколько надежнее по сравнению FR>с тем же окамлом, опять таки есть подозрения что очень немного, кроме спицифичных вырожденных случаев конечно.
С "есть подозрения" очень трудно спорить.
Давай перечислим участки кода, где это может помочь. Типичные случаи.
Вот где ты видишь применение всего этого дела?
FR>>>Угу только Хаскель не единственный инструмент который повышает производительность программиста, так что тоже не аргумент. T>>А что ещё повышает? T>>А это — то, что повышает, — ортогонально ЯП, или нет? FR>То что ортогонально ЯП уже дает колебания близкие к порядку.
Что же даёт колебания, близкие к порядку?
FR>Но кроме этого Хаскель не единственный высокоуровневый язык.
Я же тоже не дурак. Эта мысль ко мне в голову тоже пришла.
Вот сравнение языка Maude супротив Хаскеля на поле, где Maude должен показывать себя отлично, да ещё и выполненное авторами Maude: http://www.csl.sri.com/papers/denbas00/
С остальными примерно та же картина.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>Косвенные.
T>Разработчики языков программирования переходят на Хаскель с *ML.
Во первых я что-то не вижу такого перехода, все что знаю на Хаскеле кроме Хаскеля это Pugs,
на ML (включая OCaml) таких проектов гораздо больше.
Во вторых это точно никак ни доказывает что переходят из-за меньшей плотности ошибок.
T>Функциональных тестов. Их намного меньше юнит-тестов.
Неважно, важно то что питон и с тестами достаточно выразителен и компактен.
T>>>10-тикратном разбросе у одного программиста? T>>>Позволю себе не поверить. FR>>В разы запросто, например у меня.
T>"10 раз" и "разы" различаются, как бы, раза в три-четыре.
10 как раз крайний случай.
T>С "есть подозрения" очень трудно спорить.
T>Давай перечислим участки кода, где это может помочь. Типичные случаи.
T>Вот где ты видишь применение всего этого дела?
Я нигде не вижу, мельком проглядев статью, это ты должен показать
T>Что же даёт колебания, близкие к порядку?
Индивидуальные различия программистов, правильная или неправильная организация работы,
Ошибки и находки в архитектуре и алгоритмах.
FR>>Но кроме этого Хаскель не единственный высокоуровневый язык.
T>Я же тоже не дурак. Эта мысль ко мне в голову тоже пришла.
T>Вот сравнение языка Maude супротив Хаскеля на поле, где Maude должен показывать себя отлично, да ещё и выполненное авторами Maude: http://www.csl.sri.com/papers/denbas00/
И что думаешь посмотрев на сравнение одного языка который я плохо знаю, на другой который я первый раз вижу я буду
впечатлен?
T>С остальными примерно та же картина.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, z00n, Вы писали:
Z>>Но наличие RAII в С++ сделали невозможным GC в стандарте С++ даже опционально.
E>Очень и очень неоднозначное утверждение. В D есть и RAII, и сборка мусора. Так что не похоже, что в отсутствии GC в C++ виноват RAII. Куда больше в этом виноваты голые указатели, адресная арифметика и неконтролируемые приведения типов.
Главная проблема — деструкторы и то как их принято использовать в С++.
Страуструп говорит почему это сложно: http://www.devx.com/SpecialReports/Article/38813/0/page/4
Not quite ready for C++0x timetable, but actively pursued
Papers in this category have been in development and reviewed several times over the evolution of C++0x. However, although there is a strong interest the feature has not quite stabilised fast enough to meet the 2009 target deadline. Work will proceed outside the main committee meetings, and will be picked up with a view to an early adoption.
N1833 N1943 N2128 N2129 N2286 N2287 N2310 Transparent Garbage Collection for C++ H. Boehm, M. Spertus
...
T>>Косвенные. T>>Разработчики языков программирования переходят на Хаскель с *ML. FR>Во первых я что-то не вижу такого перехода, все что знаю на Хаскеле кроме Хаскеля это Pugs, FR>на ML (включая OCaml) таких проектов гораздо больше.
Есть такая интересная область, называется теория типов (система типов, исчисление конструкций, теория типов Мартина-Лёфа — всё примерно одинаково). Результаты оттуда попадают в Хаскель (семейства типов, GADT) и дальше расползаются по другим языкам.
Раньше языки этого класса писались на OCaml/SML (Coq, Isabelle), ещё раньше LISP (LCF, ACL). Сейчас все, до единого, новые языки этого класса пишутся на Хаскеле. Epigram/Epigram2, Agda2, Idris...
Не на Хаскеле остались системы, стартовавшие до начала 2000-х.
FR>Во вторых это точно никак ни доказывает что переходят из-за меньшей плотности ошибок.
Дело в том, что эта область никем, толком, не проработана. Там сплошные эксперименты. Поэтому если ЯП будет вносить ошибки, то будет сложнее, чем нужно.
Поэтому используют Хаскель.
А до этого использовали ML. А до этого Лисп, поскольку вообще ничего не было.
T>>Функциональных тестов. Их намного меньше юнит-тестов. FR>Неважно, важно то что питон и с тестами достаточно выразителен и компактен.
Я привёл пример количества тестов для выразительного языка.
"Выразителен и компактен" для разного человека выглядит по-разному. Для меня выразительные три строки и 50 строк тестов к ним никак не выглядят выразительными в целом.
T>>С "есть подозрения" очень трудно спорить. T>>Давай перечислим участки кода, где это может помочь. Типичные случаи. T>>Вот где ты видишь применение всего этого дела? FR>Я нигде не вижу, мельком проглядев статью, это ты должен показать
Это может быть полезным везде, где хотелось бы проверять структуру вычислений во время компиляции.
Если ты придумал, как тест заменить на тип (и сократить код), то смотри в эту сторону.
Я, например, делал не так давно прототип HDL. Там без типов с размерами никак. Получилось плохо, придётся переписывать, но кое-что понял для себя.
T>>Что же даёт колебания, близкие к порядку? FR>Индивидуальные различия программистов, правильная или неправильная организация работы, FR>Ошибки и находки в архитектуре и алгоритмах.
Надо говорить об одном программисте. У него колебания около порядка в природе не наблюдаются (PSP/TSP).
FR>>>Но кроме этого Хаскель не единственный высокоуровневый язык. T>>Я же тоже не дурак. Эта мысль ко мне в голову тоже пришла. T>>Вот сравнение языка Maude супротив Хаскеля на поле, где Maude должен показывать себя отлично, да ещё и выполненное авторами Maude: http://www.csl.sri.com/papers/denbas00/ FR>И что думаешь посмотрев на сравнение одного языка который я плохо знаю, на другой который я первый раз вижу я буду FR>впечатлен?
Я повторю. Maude играл на своём поле. За Maude играли сильные в нём люди. За Хаскель играли сильные в Maude люди.
Хаскель выиграл с большим отрывом.
Если тебя это не впечатляет, то что тогда впечатлит?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, pgregory, Вы писали: P>В целом — да. То есть, сама идея очень простая. Но ее применение, мне кажется, привносит в код ненужную сложность (думаю, как и везде, исключения есть). Из статьи по ссылке: «Writing code in CPS, while not impossible, is often error-prone». Это плохо.
А руками так писать не обязательно. Cps — это просто в некоторых аспектах удобное промежуточное представление кода.
Z>>Я тоже поясню. RAII есть абсолютно в любом языке с первокласными функциями — как правило в таких языках есть еще и сборка мусора. T>Ты про что? T>RAII — это Resource Acquisition Is Initialization (Получение ресурса есть инициализация) T>При чём здесь первокласные функции?
bracket :: Monad m => m open -> (open -> m close) -> (open -> m action) -> m (Maybe action)
bracket open close action = do
h <- open
r <- catch (liftM Just (action h)) (return . const Nothing)
close h
return r
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, pgregory, Вы писали: Z>>Continuations — не для написания программ, они для написания библиотек (тредов, исключений, генераторов, корутин, вебсерверов). P>Я не различаю «обычные» программы и библиотеки, и не считаю, что они должны как-то по-разному писаться.
А зря. Scheme позволяет писать на разных уровнях абстракции. Низкоуровневые фичи: макросы, континуации — позволяют создавать более высокоуровневые: библиотеки многопоточности, исключений, continuations-based серверы и т.п. Соседство разных уровней абстракции в одном языке свойственно не только scheme. Например, на уже обсуждаемом в ветке haskell можно писать используя только функции (тут кстати тоже разделение — можно исползовать рекурсию в чистом виде, а можно использовать готовые fold, unfold, map и т.п.), можно использовать традиционные абстракции более высокого уровня: монады, стрелки — а можно придумывать и реализовывать свои.
P>Звучит красиво. Но теория и практика совпадают только в теории. Несмотря на концептуальную простоту, схема не получила распространения, и нет предпосылок к тому, что получит.
Ну так это ничего не говорит о достоинствах или недостатках языка. Никто не отрицает, что scheme не является промышленным языком.
> On 11 Aug., 12:28, Walter Bright <wal...@digitalmars-nospamm.com>
> wrote:
>> gast...@hotmail.com wrote:
>> > I agree. Selectable GC (in a library or requiring that classes are
>> > derived from some sort of base class) would be nice extension. The
>> > power of c++ is always that it spans low level and high level
>> > constructs, but the high level constructs could be served better if
>> > programmers weren't required to think about this.
>> I'm not so sure optional gc would work out very well. Suppose you're a
>> library designer - do you design it to work with gc, without gc, or
>> both? Doesn't this make it more difficult for the library designer, not
>> less?
> More difficult in what way? I believe that all current code with
> manually managed memory will continue to work in gc C++.
Only if nobody actually use the GC features. :-)
In C++ today we write classes that manage non-memory resources by
freeing them in their destructors, and we can have confidence that if
people follow "standard C++ coding practices" these resources will be
freed at particular times. Other programmers aggregate instances of
these classes into structures and can rely on a particular order of
destruction, and thus on those resources getting freed. These classes
often become the implementation details of other classes (think of the
mutex associated with a threadsafe class instance), and we can allow
clients to handle such classes without concern over when, or if, the
underlying resources will be freed.
In the committee we (at least some of us) could only think of three
possible purposes for GC in C++. The first and most obvious would be to
make it a legitimate standard coding practice not to call delete. But
once you start doing that, the guarantees given by destructors that
manage other resources no longer apply. Furthermore, the fact that a
class (indirectly) manages a non-memory resource can no longer be an
implementation detail. In fact, that "detail" now needs to ripple
upward through the documentation of all classes that contain such a
resource manager, so clients will know they can't be safely leaked. So
far, nobody has been able to come up with a reasonable coding practice
that avoids this problem. Until we have a workable programming model
for C++ with GC, I don't want GC in the language.
The other purposes were 1. making it possible for buggy, leaky programs
to run longer before running out of memory, and 2. certain kinds of code
(especially some lock-free algorithms) are very hard to write without
GC. In my opinion, neither of these possible benefits justifies
accepting the dangers described in the previous paragraph. On the other
hand, the benefit of being able to skip "delete" is so compelling that I
think people would assume they can do it.
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Здравствуйте, Рысцов Денис, Вы писали:
РД>Сорри, что влезаю в дискуссию, но прочитал обновления в ветке, оторвавшись от кода на nemerle (почти C#), в котором мне помог бы вариант монады List: код заключается в преобразовании неоднозначного дерева математических выражений в множество однозначных деревьев. Например, выражение "a+-b" должно перейти в список ["a+b","a-b"]. Во время разбора через дерево протаскивается объект, описывающий типы выражений, и потенциально на каждом узле дерево может раздваиваться. Весь процесс обладает структурой, которую можно оформить через монаду, а сам процесс описать через комбинаторы.
Может я конечно чего не понял но:
public static GroupAdjacent[T](this lst : list[T], fn : T * T -> bool) : list[list[T]]
{
def lst = lst.Fold([[]], (item, acc) =>
{
match (acc)
{
| [] :: tail => [item] :: tail;
| (item2 :: items) :: tail =>
if (fn(item, item2))
(item :: item2 :: items) :: tail;
else
[item] :: (item2 :: items) :: tail;
}
});
lst.RevMap(l => l.Reverse());
}
Main() : void
{
try
{
def l = ['1', '+', '-', '2', '3'];
WriteLine(l);
def l = l.GroupAdjacent((x, y) => char.IsDigit(x) == char.IsDigit(y) );
WriteLine(l);
def l = l.Fold([[]], (l, acc) => $[x :: y | x in l, y in acc]).Map(l => l.Reverse());;
WriteLine(l);
T>Раньше языки этого класса писались на OCaml/SML (Coq, Isabelle), ещё раньше LISP (LCF, ACL). Сейчас все, до единого, новые языки этого класса пишутся на Хаскеле. Epigram/Epigram2, Agda2, Idris...
T>Не на Хаскеле остались системы, стартовавшие до начала 2000-х.
То есть на одном очень узком и очень академичном направлении Хаскель вытеснил ML, по моему явно недостаточно.
FR>>Во вторых это точно никак ни доказывает что переходят из-за меньшей плотности ошибок.
T>Дело в том, что эта область никем, толком, не проработана. Там сплошные эксперименты. Поэтому если ЯП будет вносить ошибки, то будет сложнее, чем нужно.
T>Поэтому используют Хаскель.
T>А до этого использовали ML. А до этого Лисп, поскольку вообще ничего не было.
Вывод по моему явно притянутый.
T>Я привёл пример количества тестов для выразительного языка.
T>"Выразителен и компактен" для разного человека выглядит по-разному. Для меня выразительные три строки и 50 строк тестов к ним никак не выглядят выразительными в целом.
реально тестов меньше чем кода получается.
T>Это может быть полезным везде, где хотелось бы проверять структуру вычислений во время компиляции.
T>Если ты придумал, как тест заменить на тип (и сократить код), то смотри в эту сторону.
Для меня пока это очень спорно и неоднозначно. Я предполагаю что система типов все-равно не сможет
полностью заменить тестирование, также вообще сомневаюсь что это необходимо.
T>Надо говорить об одном программисте. У него колебания около порядка в природе не наблюдаются (PSP/TSP).
Как же не наблюдаются, очень даже наблюдаются, прямо сейчас и у меня лично
T>Я повторю. Maude играл на своём поле. За Maude играли сильные в нём люди. За Хаскель играли сильные в Maude люди.
T>Хаскель выиграл с большим отрывом.
T>Если тебя это не впечатляет, то что тогда впечатлит?
Меня бы в контексте темы (Хаскель в мейнстриме) впечатлил нормальный большой неакадемический проект на Хаскеле. Еще больше бы впечатлили такие же пусть и небольшие проекты, но чтобы их можно было считать хотя бы десятками.
T>>Раньше языки этого класса писались на OCaml/SML (Coq, Isabelle), ещё раньше LISP (LCF, ACL). Сейчас все, до единого, новые языки этого класса пишутся на Хаскеле. Epigram/Epigram2, Agda2, Idris... T>>Не на Хаскеле остались системы, стартовавшие до начала 2000-х. FR>То есть на одном очень узком и очень академичном направлении Хаскель вытеснил ML, по моему явно недостаточно.
Сравни плотность изменений.
FR>>>Во вторых это точно никак ни доказывает что переходят из-за меньшей плотности ошибок. T>>Дело в том, что эта область никем, толком, не проработана. Там сплошные эксперименты. Поэтому если ЯП будет вносить ошибки, то будет сложнее, чем нужно. T>>Поэтому используют Хаскель. T>>А до этого использовали ML. А до этого Лисп, поскольку вообще ничего не было. FR>Вывод по моему явно притянутый.
Сделай другой. Проведи исследования.
Чего всё я?
T>>Это может быть полезным везде, где хотелось бы проверять структуру вычислений во время компиляции. T>>Если ты придумал, как тест заменить на тип (и сократить код), то смотри в эту сторону. FR>Для меня пока это очень спорно и неоднозначно. Я предполагаю что система типов все-равно не сможет FR>полностью заменить тестирование, также вообще сомневаюсь что это необходимо.
С "я предполагаю" очень трудно спорить.
Ты предполагаешь так почему конкретно?
T>>Надо говорить об одном программисте. У него колебания около порядка в природе не наблюдаются (PSP/TSP). FR>Как же не наблюдаются, очень даже наблюдаются, прямо сейчас и у меня лично
Тебя надо наблюдать со стороны и на протяжении всего проекта. Нескольких проектов.
Минутные слабости компенсируются часовыми мощностями.
T>>Если тебя это не впечатляет, то что тогда впечатлит?
FR>Меня бы в контексте темы (Хаскель в мейнстриме) впечатлил нормальный большой неакадемический проект на Хаскеле. Еще больше бы впечатлили такие же пусть и небольшие проекты, но чтобы их можно было считать хотя бы десятками.
Про небольшие проекты мы ничего не знаем — кто что внутреннее пишет.
А, похоже, пишут, возвращаясь к теме слешдота.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, WolfHound, Вы писали:
РД>>Сорри, что влезаю в дискуссию, но прочитал обновления в ветке, оторвавшись от кода на nemerle (почти C#), в котором мне помог бы вариант монады List: код заключается в преобразовании неоднозначного дерева математических выражений в множество однозначных деревьев. Например, выражение "a+-b" должно перейти в список ["a+b","a-b"]. Во время разбора через дерево протаскивается объект, описывающий типы выражений, и потенциально на каждом узле дерево может раздваиваться. Весь процесс обладает структурой, которую можно оформить через монаду, а сам процесс описать через комбинаторы.
WH>Может я конечно чего не понял но:
Задача для монадического комбинатора sequence, возможно, это имел в виду Рысцов Денис, когда говорил о монадах и описании процесса через комбинаторы.
sequence . groupBy (\x y -> isDigit x == isDigit y)
Из-за наличия готовых комбинаторов общего назначения (sequence) нет необходимости писать специальный код для списка. Из-за ленивости списка нет необходимости просматривать всё дерево. В твоём решении, например, даже если список ленивый, вычисление не будет таким из-за обращения списка.
Ну и, конечно, что именно имел в виду Рысцов Денис, я могу только догадываться
Здравствуйте, z00n, Вы писали:
Z>RAII — это С++ название для устоичивого к исключениям scope-based resource management'а. Появилось это в лиспе, давно, лет 30 назад. Z>Stroustrup — придумал как повторить это в С++ с помощью хака с деструкторами и воспомогательными обектами. Но деструкторы для этого не нужны.
RAII -- это Resource Acquisition Is Initialization. Способ структурировать ОО-style программы, привязывая произвольные ресурсы к объектам-владельцам. Это совсем не то же самое, что аналоги using-а на хаскеле или лиспе (если я правильно понял, о чем ты). Я считаю RAII более общей и элегантной техникой.
Здравствуйте, z00n, Вы приводили письмо Абрахамса:
>> More difficult in what way? I believe that all current code with
>> manually managed memory will continue to work in gc C++.
> Only if nobody actually use the GC features. :-)
> In C++ today we write classes that manage non-memory resources by
> freeing them in their destructors, and we can have confidence that if
> people follow "standard C++ coding practices" these resources will be
> freed at particular times. Other programmers aggregate instances of
> these classes into structures and can rely on a particular order of
> destruction, and thus on those resources getting freed. These classes
> often become the implementation details of other classes (think of the
> mutex associated with a threadsafe class instance), and we can allow
> clients to handle such classes without concern over when, or if, the
> underlying resources will be freed.
По этой части я полностью согласен.
Но дальше он пишет куда более интересные, на мой взгляд, вещи:
> In the committee we (at least some of us) could only think of three
> possible purposes for GC in C++. The first and most obvious would be to
> make it a legitimate standard coding practice not to call delete. But
> once you start doing that, the guarantees given by destructors that
> manage other resources no longer apply. Furthermore, the fact that a
> class (indirectly) manages a non-memory resource can no longer be an
> implementation detail. In fact, that "detail" now needs to ripple
> upward through the documentation of all classes that contain such a
> resource manager, so clients will know they can't be safely leaked. So
> far, nobody has been able to come up with a reasonable coding practice
> that avoids this problem. Until we have a workable programming model
> for C++ with GC, I don't want GC in the language.
> The other purposes were 1. making it possible for buggy, leaky programs
> to run longer before running out of memory, and 2. certain kinds of code
> (especially some lock-free algorithms) are very hard to write without
> GC. In my opinion, neither of these possible benefits justifies
> accepting the dangers described in the previous paragraph.
Кратко -- GC нужен, чтобы:
1) можно было писать код без явного delete
2) чтобы legacy программы не так быстро падали от забытых delete (sic!)
3) чтобы можно было реализовать некоторые интересные алгоритмы
Теперь по пунктам.
1) Думаю, все согласятся, что в сколько-нибудь современном плюсовом коде delete (да и вообще любое явное освобождение ресурсов) практически отсутствует. Лично я за последний год не написал ни единого delete, afair. RAII -- крайне мощная вещь при последовательном применении.
Да, я прочитал
> On the other hand, the benefit of being able to skip "delete" is so compelling that I
> think people would assume they can do it.
но я этого не могу понять. Чем плох RAII? Зачем вообще явно писать delete?
2) Поинт понятен, но не интересен.
3) А вот требуется ли для реализации этих алгоритмов глобальный GC? Может, что-то маленькое и локальное + какие-нибудь GC-аннотации сделают дело?
Здравствуйте, pgregory, Вы писали:
P>RAII -- это Resource Acquisition Is Initialization. Способ структурировать ОО-style программы, привязывая произвольные ресурсы к объектам-владельцам. Это совсем не то же самое, что аналоги using-а на хаскеле или лиспе (если я правильно понял, о чем ты).
Здравствуйте, Tonal-, Вы писали:
T>Здравствуйте, z00n, Вы писали: Z>>Здравствуйте, Tonal-, Вы писали:
T>>>Это не RAII. В haskell-е нет аналога деструкторов, так что RAII там быть не может. Z>>RAII — это С++ название для устоичивого к исключениям scope-based resource management'а. Появилось это в лиспе, давно, лет 30 назад. T>Если у тебя объект на стеке, то они аналогичны. T>Если объект динамический, то нет.
Объект может быть на другом компьютере — причем здесь это?
Здравствуйте, z00n, Вы писали:
P>>RAII -- это Resource Acquisition Is Initialization. Способ структурировать ОО-style программы, привязывая произвольные ресурсы к объектам-владельцам. Это совсем не то же самое, что аналоги using-а на хаскеле или лиспе (если я правильно понял, о чем ты).
Z>Цель у этого привязывания какая?
Сделать более простым, последовательным и error-resistant управление ресурсами в программах.
Здравствуйте, pgregory, Вы писали:
P>Сделать более простым, последовательным и error-resistant управление ресурсами в программах.
Вот именно. Мой поинт — для этого не обязателен RAII в том виде в котором он есть в С++. Зато само существование деструкторов мешает комитету улучшать язык, чего члены комитета не отрицают. D вроде как обошел эту проблему, но для С++ все выглядит (на мой взгляд) совершенно безнадежно.
Здравствуйте, z00n, Вы писали:
P>>Сделать более простым, последовательным и error-resistant управление ресурсами в программах. Z>Вот именно. Мой поинт — для этого не обязателен RAII в том виде в котором он есть в С++.
Полностью согласен. Но лично я не знаю более простой и мощной техники для этого. Аналоги using-а, как я уже писал, я таковыми не считаю.
Z>Зато само существование деструкторов мешает комитету улучшать язык, чего члены комитета не отрицают.
я уже выражал свою позицию по поводу того, что даст GC плюсам. Не стоит забывать, GC -- не абсолютное добро, и имеет, при всех плюсах, довольно большой список недостатков. Не знаю, насколько это мнение популярно, но в RAII vs. GC я однозначно выберу RAII.
Здравствуйте, z00n, Вы писали:
E>>Беглый просмотр не дал ответа. Z>comp.lang.c++.moderated Z>
Z>Only if nobody actually use the GC features. :-)
Z>In C++ today we write classes that manage non-memory resources by
Z>freeing them in their destructors, and we can have confidence that if
Z>people follow "standard C++ coding practices" these resources will be
Z>freed at particular times. Other programmers aggregate instances of
Z>these classes into structures and can rely on a particular order of
Z>destruction, and thus on those resources getting freed. These classes
Z>often become the implementation details of other classes (think of the
Z>mutex associated with a threadsafe class instance), and we can allow
Z>clients to handle such classes without concern over when, or if, the
Z>underlying resources will be freed.
Z>
Во-первых, как я уже говорил, к RAII это имеет косвенное отношение. Т.к. RAII используется только в синтаксически ограниченных фрагментах.
Во-вторых, я не понимаю, почему GC не может вызывать деструкторы у "мусорных" объектов. В Java и C# финалайзеры у объектов вызываются и ничего, все живы-здоровы. А если GC будет вызывать деструкторы, то описанной проблемы не будет в принципе.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, thesz, Вы писали:
T>>>Разработчики языков программирования переходят на Хаскель с *ML. FR>>Во первых я что-то не вижу такого перехода, все что знаю на Хаскеле кроме Хаскеля это Pugs, FR>>на ML (включая OCaml) таких проектов гораздо больше.
T>Есть такая интересная область, называется теория типов (система типов, исчисление конструкций, теория типов Мартина-Лёфа — всё примерно одинаково). Результаты оттуда попадают в Хаскель (семейства типов, GADT) и дальше расползаются по другим языкам.
T>Раньше языки этого класса писались на OCaml/SML (Coq, Isabelle), ещё раньше LISP (LCF, ACL). Сейчас все, до единого, новые языки этого класса пишутся на Хаскеле. Epigram/Epigram2, Agda2, Idris...
T>Не на Хаскеле остались системы, стартовавшие до начала 2000-х.
Есть такой язык Vala, стартовавший в 2006-м. Пишется, iirc, на C. Или речь идет о каких-то других языках?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, pgregory, Вы писали:
P>Здравствуйте, z00n, Вы писали: P>>>Сделать более простым, последовательным и error-resistant управление ресурсами в программах. Z>>Вот именно. Мой поинт — для этого не обязателен RAII в том виде в котором он есть в С++. P>Полностью согласен. Но лично я не знаю более простой и мощной техники для этого. Аналоги using-а, как я уже писал, я таковыми не считаю. Z>>Зато само существование деструкторов мешает комитету улучшать язык, чего члены комитета не отрицают. P>Здесь
я уже выражал свою позицию по поводу того, что даст GC плюсам. Не стоит забывать, GC -- не абсолютное добро, и имеет, при всех плюсах, довольно большой список недостатков. Не знаю, насколько это мнение популярно, но в RAII vs. GC я однозначно выберу RAII.
Я, честно говоря, вообще не интересуюсь мнениями и позициями — предпочитаю информацию
Здравствуйте, eao197, Вы писали:
E>Во-первых, как я уже говорил, к RAII это имеет косвенное отношение. Т.к. RAII используется только в синтаксически ограниченных фрагментах.
На мой взгляд, Абрахамс очень понятно пишет о том, что если бы деструкторы не использовали бы для управления ресурсами(RAII) — можно было бы добавить консервативный GC. А так он будет сильно против.
E>Во-вторых, я не понимаю, почему GC не может вызывать деструкторы у "мусорных" объектов. В Java и C# финалайзеры у объектов вызываются и ничего, все живы-здоровы. А если GC будет вызывать деструкторы, то описанной проблемы не будет в принципе.
Может, через час. А если нужно детерминированно?
Здравствуйте, z00n, Вы писали:
E>>Во-первых, как я уже говорил, к RAII это имеет косвенное отношение. Т.к. RAII используется только в синтаксически ограниченных фрагментах. Z>На мой взгляд, Абрахамс очень понятно пишет о том, что если бы деструкторы не использовали бы для управления ресурсами(RAII) — можно было бы добавить консервативный GC. А так он будет сильно против.
Консервативный GC идет в топку.
E>>Во-вторых, я не понимаю, почему GC не может вызывать деструкторы у "мусорных" объектов. В Java и C# финалайзеры у объектов вызываются и ничего, все живы-здоровы. А если GC будет вызывать деструкторы, то описанной проблемы не будет в принципе. Z>Может, через час. А если нужно детерминированно?
Ситуация ничем не будет отличаться от того, что есть в той же Java.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
T>>Раньше языки этого класса писались на OCaml/SML (Coq, Isabelle), ещё раньше LISP (LCF, ACL). Сейчас все, до единого, новые языки этого класса пишутся на Хаскеле. Epigram/Epigram2, Agda2, Idris... T>>Не на Хаскеле остались системы, стартовавшие до начала 2000-х. E>Есть такой язык Vala, стартовавший в 2006-м. Пишется, iirc, на C. Или речь идет о каких-то других языках?
И требования у тебя выше.
FR>>>Вывод по моему явно притянутый. T>>Сделай другой. Проведи исследования. T>>Чего всё я? FR>Тык ты у нас евангилист тебе и плясать FR>Я тут когда с питоном носился немало поплясал
То, что евангелист я, не означает, что ты не должен подтверждать свои соображения. "Вывод явно притянутый" нуждается в другом, непритянутом выводе.
T>>>>Это может быть полезным везде, где хотелось бы проверять структуру вычислений во время компиляции. T>>>>Если ты придумал, как тест заменить на тип (и сократить код), то смотри в эту сторону. FR>>>Для меня пока это очень спорно и неоднозначно. Я предполагаю что система типов все-равно не сможет FR>>>полностью заменить тестирование, также вообще сомневаюсь что это необходимо. T>>С "я предполагаю" очень трудно спорить. T>>Ты предполагаешь так почему конкретно?
FR>В общем чисто субъективное мнение, подкрепленное только своим опытом и последними достижениями математики FR>http://elementy.ru/lib/430319 FR>
FR>Иными словами, при любом конечном наборе аксиом мы имеем бесконечное число истин, которые не могут быть доказаны с помощью этого набора.
Что это означает?
T>>Про небольшие проекты мы ничего не знаем — кто что внутреннее пишет. T>>А, похоже, пишут, возвращаясь к теме слешдота. FR>Значит мало пишут раз наружу совсем не выплывает.
"Совсем" это ты загнул, да.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>Так он и моложе. И ситуация другая.
Так он и популярнее.
T>И требования у тебя выше.
Так к лучшему из функциональных языков же
T>То, что евангелист я, не означает, что ты не должен подтверждать свои соображения. "Вывод явно притянутый" нуждается в другом, непритянутом выводе.
Притянутый потому что ты никак ни показал что именно из-за меньшей плотности ошибок переходят на Хаскель. Вот мне видится что из-за большей выразительности и большей гибкости языка по сравнению с ML.
FR>>В общем чисто субъективное мнение, подкрепленное только своим опытом и последними достижениями математики FR>>http://elementy.ru/lib/430319 FR>>
FR>>Иными словами, при любом конечном наборе аксиом мы имеем бесконечное число истин, которые не могут быть доказаны с помощью этого набора.
T>Что это означает?
Это означает что универсальной покрывающей хотя бы большую часть решаемых задач системы типов не построить.
Там же есть еще другой вывод, очень многие задачи вообще неприводимы и неупрощаемы
T>"Совсем" это ты загнул, да.
Здравствуйте, z00n, Вы писали: T>>>>Это не RAII. В haskell-е нет аналога деструкторов, так что RAII там быть не может. Z>>>RAII — это С++ название для устоичивого к исключениям scope-based resource management'а. Появилось это в лиспе, давно, лет 30 назад. T>>Если у тебя объект на стеке, то они аналогичны. T>>Если объект динамический, то нет. Z>Объект может быть на другом компьютере — причем здесь это?
Вообще не в кассу.
RAII — это способ связать время жизни ресурса со временем жизни объекта. Всё.
Отсюда и его применение как scope-based resource management.
Но оно не ограничивается этим.
Здравствуйте, eao197, Вы писали:
E>Во-первых, как я уже говорил, к RAII это имеет косвенное отношение. Т.к. RAII используется только в синтаксически ограниченных фрагментах.
E>Во-вторых, я не понимаю, почему GC не может вызывать деструкторы у "мусорных" объектов. В Java и C# финалайзеры у объектов вызываются и ничего, все живы-здоровы. А если GC будет вызывать деструкторы, то описанной проблемы не будет в принципе.
всё очень просто — в C++ объединены освобождение памяти и освобождение ресурсов. и то и другое делается в деструкторе, вызов которого *детерминирован* благодаря явному вызову delete (сарт поинтеры, RAII тоже вызывают дестуруктор детерминированно). языки с GC используют для освобождения ресурсов другие техники, поскольку их разработчики знают, что на момент вызова деструктора полагаться нельзя
соответственно, если добавить GC в С++, то legacy код будет несовместим с ним, поскольку в нём просто отсутствует разделение дестурукторов на освобождение ресурсов и освобождение памяти. т.е. несмотря на GC дестуруркторы всё равно придётся вызывать детерминированно для освобождения ресурсов
Здравствуйте, eao197, Вы писали:
E>>>Во-вторых, я не понимаю, почему GC не может вызывать деструкторы у "мусорных" объектов. В Java и C# финалайзеры у объектов вызываются и ничего, все живы-здоровы. А если GC будет вызывать деструкторы, то описанной проблемы не будет в принципе. Z>>Может, через час. А если нужно детерминированно?
E>Ситуация ничем не будет отличаться от того, что есть в той же Java.
вот поэтому в яве, C#, D — любых языках с GC деструкторы не используются для освобождения *ресурсов*. а у C++ — legacy код
Здравствуйте, thesz, Вы писали:
T>Так каких-то лет пять всего.
За пять лет некторые языки устареть успевают
T>>>И требования у тебя выше. FR>>Так к лучшему из функциональных языков же
T>Так к ещё не развернувшемуся в полную силу.
Ттттормозиттт
T>Это сокращает количество ошибок.
Вот плохой ты евангилист, надо было сразу раскрывать
T>Всякого рода преобразования встречаются и в далёких от ЯП программах. В тех же оптимизаторах файловых систем, ведь файловая система и есть дерево с типами блоков, да ещё и хитро увязанных друг с другом.
T>Почему пишущие на C++ до сих пор не пользуются GADT, мне непонятно.
Ты это осторожней не накаркай, в буст уже почти засунули алгебраические типы
T>Поэтому нужна система типов, которую мы можем затачивать под наши конкретные цели. Система типов Хаскеля движется в этом направлении.
Да интересно, но эту ветку пилят еще метапрограммирование и динамика, так что посмотрим кто кого.
FR>>Там же есть еще другой вывод, очень многие задачи вообще неприводимы и неупрощаемы
T>Essential complexity по Бруксу.
T>Такое встречается очень редко.
Похоже не так уж и редко. И чем дальше в лес тем больше дров.
T>>Это сокращает количество ошибок. FR>Вот плохой ты евангилист, надо было сразу раскрывать
Так я сразу сказал — "сокращает".
T>>Поэтому нужна система типов, которую мы можем затачивать под наши конкретные цели. Система типов Хаскеля движется в этом направлении. FR>Да интересно, но эту ветку пилят еще метапрограммирование и динамика, так что посмотрим кто кого.
Динамика не ловит все возможные пути прохода кода и точно не на этапе компиляции. Метапрограммирование само нуждается в многоуровневой системе типов — чтобы глупости не создавало.
А так — да, посмотрим.
FR>>>Там же есть еще другой вывод, очень многие задачи вообще неприводимы и неупрощаемы T>>Essential complexity по Бруксу. T>>Такое встречается очень редко. FR>Похоже не так уж и редко. И чем дальше в лес тем больше дров.
Практически все встречавшиеся мне примеры упрощались сменой подхода.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, BulatZiganshin, Вы писали:
BZ>ты полагаешь, что GC — это фича для того, чтобы сделать менее заметными баги?
Блин, мне казалось, что пример Java должен был всем это уже давно доказать
BZ> и корректные c++ программы им пользщоваться всё равно не должны, даже если он появится? тогда нафига он нужен — рассуждают авторы языка
Он нужен для того, чтобы сделать жизнь проще. При наличии GC в языке 70% деструкторов можно будет выбросить вообще. При наличии GC в языке многопоточное программирование станет гораздо проще. При наличии GC в языке exception safety будет обеспечиваться на порядки проще. В итоге программы станут компактнее, проще и, временами, быстрее.
Только, имхо, для этого нужно вводить точный GC в язык раз и навсегда. Без оглядки на всякие встраиваемый системы, системы реального времени, high perfomance computing системы и пр. Только вот утопия это все пока.
BZ>вообще, сколько можно разжёвывать простейшие вещи. такое впечатление, что вы даже не пытаетесь понять, о чём идёт речь, прдепочитая 100 раз повторять одно и то же, чтобы оставить за собой "поле боя"
Лично мне не понятно, почему за главную причину невозможности внедрения GC в C++ выдается RAII и наличие деструкторов. В C++ гораздо больше других факторов, препятствующих внедрению GC. Но этого вы даже понять не пытаетесь. Как и объяснить, например, коммерческую невыгодность использования функционального программирования
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Лично мне не понятно, почему за главную причину невозможности внедрения GC в C++ выдается RAII и наличие деструкторов.
не наличие дестуркторов. а то, что в одном фрагменте кода делается высвобождение ресурсов и памяти. в результате чего несмотря на наличие GC придётся продолжать явно вызывать деструкторы. и проблема в том, что только 10% классов нуждается в освобождении ресурсов. в языках с GC эти 10% "деструкторов" вызываются явно, с помощью механизмов, аналогичных gc — bracket, using. в C++ приходится вызывать деструкторы для *всех* объектов — на всякий случай, вдруг там ресурсы тоже. и поэтому GC просто собирать нечего — разве что в ошибочных программах
Здравствуйте, eao197, Вы писали:
E>Лично мне не понятно, почему за главную причину невозможности внедрения GC в C++ выдается RAII и наличие деструкторов. В C++ гораздо больше других факторов, препятствующих внедрению GC. Но этого вы даже понять не пытаетесь.
Консервативному GC ничего больше не мешает. Разговор о неконсервативном GC пытаетесь навязать вы — по мне это подмена темы, и в целом мне даже 5-ти минут жалко чтобы помечтать о неконсервативном GC в C++.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>в языках с GC эти 10% "деструкторов" вызываются явно, с помощью механизмов, аналогичных gc — bracket, using
Здравствуйте, z00n, Вы писали:
Z>Консервативному GC ничего больше не мешает.
Мешают float-ы и double, которые могут содержать значения, очень похожие на указатели. А так же byte[], которые используются внутри криптографических алгоритмов. Вскоре после выхода D 1.000 на эту проблему указали Брайту и он добавил в std.gc метод hasNoPointers для ручного запрещения GC сканирования областей памяти, содержимое которых может быть похоже на указатель.
Если уж при обсуждении внедрения в C++ консервативного GC обсуждаются проблемы вызова деструкторов применительно к legacy codebase, то почему не принимается во внимание char[], float[] и doible[], которых в том же legacy codebase будет великое множество?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, z00n, Вы писали:
Z>>Консервативному GC ничего больше не мешает.
E>Мешают float-ы и double, которые могут содержать значения, очень похожие на указатели. А так же byte[], которые используются внутри криптографических алгоритмов.
Если после последующих 4 проверок GC будет продолжать считать что это указатель — утечет немного памяти. Расскажите(в смысле дайте ссылку), кто реально с этим столкнулся и к каким ужасам это привело.
E>Вскоре после выхода D 1.000 на эту проблему указали Брайту и он добавил в std.gc метод hasNoPointers для ручного запрещения GC сканирования областей памяти, содержимое которых может быть похоже на указатель.
Можно ссылку на описание проблемы? По мне — это больше похоже на оптимизацию. Я Брайта понимаю — жалко что ли? — комитет то уламывать не надо.
E>Если уж при обсуждении внедрения в C++ консервативного GC обсуждаются проблемы вызова деструкторов применительно к legacy codebase, то почему не принимается во внимание char[], float[] и doible[], которых в том же legacy codebase будет великое множество?
В ObjectiveC 2.0 уже 3 года как консервативный GC. Tim Sweeney применяет его в UnrealEngine2/3 уже несколько лет на приставках без виртуальной памяти.
Давайте вы дадите ссылки на релевантные документы о проблемах.
Здравствуйте, z00n, Вы писали:
E>>Мешают float-ы и double, которые могут содержать значения, очень похожие на указатели. А так же byte[], которые используются внутри криптографических алгоритмов. Z>Если после последующих 4 проверок GC будет продолжать считать что это указатель — утечет немного памяти. Расскажите(в смысле дайте ссылку), кто реально с этим столкнулся и к каким ужасам это привело.
Здравствуйте, eao197, Вы писали:
Z>>Если после последующих 4 проверок GC будет продолжать считать что это указатель — утечет немного памяти. Расскажите(в смысле дайте ссылку), кто реально с этим столкнулся и к каким ужасам это привело.
E>http://www.digitalmars.com/d/archives/digitalmars/D/The_problem_with_the_D_GC_46407.html
На dmd 1.041 это не воспроизвелось, из чего я делаю вывод, что это просто давно исправленный баг Брайтового велосипеда (интересно, чего он просто не взял Boehm?)
Еще?
PS. Конечно иногда имеет смысл не сканировать некоторые области памяти — все необходимые аннотации в прдложении Боема комитету есть(N2310- ссылку я уже давал)
Z>PS. Конечно иногда имеет смысл не сканировать некоторые области памяти — все необходимые аннотации в прдложении Боема комитету есть(N2310- ссылку я уже давал)
А кто будет делать аннотации к унаследованному коду?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>А кто будет делать аннотации к унаследованному коду?
К унаследованному коду не нужно делать аннотаций — а просто использовать его как есть, без GC. Достаточно очевидно, что GC не ищет указатели в памяти, которую не он выделял.
Для иллюстрации этот пример на С + libgc, он лечится убиранием GC из "Legacy Code".
#include <gc.h>
#include <stdlib.h>
int main(int argc, char *argv[])
{
int data_length = 5000000;
int i,incoming_length, *incoming;
/* 1 - Legacy Code */
// int *data = (int*)GC_MALLOC(sizeof(int)*data_length); // <-- Leakint *data = (int*)malloc(sizeof(int)*data_length); // <-- OKfor (i = 0; i < data_length; ++i)
{
data[i] = rand();
}
/* 2 - New Code */for(;;)
{
incoming_length = 1000 + rand()%5000;
incoming = (int*)GC_MALLOC(sizeof(int)*incoming_length);
for (i = 0; i < incoming_length; ++i) {
incoming[i] = rand();
}
}
}
Здравствуйте, eao197, Вы писали:
E>Я в этом сомневаюсь. Может быть, для людей с хорошим математическим и абстрактным мышлением так и было бы, но не для меня.
Вообще-то работа программиста — это оперирование абстракциями, так что для человека пишущего программы, (по всей видимости, не безуспешно) заявлять о плохости своего абстрактного мышления — это какая-то нездоровая скромность. Хотя, конечно, чем лучше — тем лучше — тут поспорить трудно.
... << RSDN@Home 1.2.0 alpha 4 rev. 1110>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, pgregory, Вы писали:
P>Да ладно! Законченная-то законченная, только ничего не объясняющая. Иначе все монадные туториалы представляли бы из себя одну-единственную фразу.
Самое сложное в монадах — это монадные туториалы. Я это понял в 2005-ом, кажется, году, когда прочел на этом форуме сообщение, в котором для объяснения монад проводились аналогии с унитарными эволюциями и коллапсом волновой функции.
K>>Целые числа и операции над ними изучают 10 лет, и в том числе изучаются все войства кольца — ведь объяснение кольца должно быть включено в объяснение целых чисел в любом случае. Это-то понятно? Какие из свойств коммутативного кольца с единицей вы не изучали в школе? Разве что только слово "кольцо" не упоминали — вот и все.
P>Это принципиально. Я именно об этом и пишу.
Т.е. узнать все про кольца кроме названия — это не принципиально, а услышать слово "Кольцо" — принципиально?
K>>А все эти группы и кольца изучаются за еденицы академических часов — просто чтобы показать общность свойств разных объектов, которую можно и самому заметить. K>>С монадами то же самое. Вы утверждаете, что в RWH без привлечения монад ничего не объясняется — но ведь это не правда. Там монады сначала изобретаются трижды — для IO, для Maybe и для парсеров — и только потом эта общность свойств получает название "монада" — именно так это происходит и при изучении чисел и алгебраических структур.
P>Есть большая разница. После окончания нормальной школы, человек может хорошо решать кучу практических задач. При этом, он может ни разу в жизни не слышать о коммутативных кольцах.
Если он умеет считать — все 8 свойств коммутативного кольца с единицей он знает.
P>В случае с хаскелем это неверно. Практически невозможно написать сколько-нибудь нетривиальную программу, не зная, что такое монада. That's the whole point.
В случае с Хаскелем все точно так же, как и с умением считать.
K>>Нет, признан факт, что то, что вам уже известно вы считаете простым, а то, что неизвестно — сложным. Понять что такое Maybe и не понять при этом, что такое монада невозможно, точно также как нельзя научиться считать и при этом не узнать, что a + 0 = a. P>Ну неужели, печатая это, вы не поймали себя на том, что куда честнее было бы привести аналогию «точно также как нельзя научиться считать и при этом не узнать, что такое коммутативное кольцо с единицей»?!
Еще раз, слов "коммутативное кольцо с единицей" можно не услышать, но все свойства изучаются — если нет — скажите какие.
P>Я просто высказываю свою точку зрения.
Это очевидно.
P>Я не считаю ее единственно правильной.
Что значит "единственно правильной"? Вы допускаете, что ваша точка зрения может быть не одна правильной, а на ряду с ней еще какая-то другая?
P>Хотя и считаю, что у нее есть серьезные обоснования. Время покажет, кто прав. Вы понимаете мою точку зрения?
Полагаю, что да. Но есть серьезные основания считать, что я понимаю ее не так, как понимаете ее вы.
P>Я вашу, думаю, понимаю.
Не уверен.
... << RSDN@Home 1.2.0 alpha 4 rev. 1110>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, pgregory, Вы писали:
P>Это -- чушь. Доказательство (GHCi, version 6.10.1):
А вот тоже смешно:
Prelude> let f = 42
Prelude> :t f
f :: Integer
Prelude> :t 42
42 :: (Num t) => t
Я доказал, что 42 — это не 42!
Re[32]: [haskell] considered mainstream
От:
Аноним
Дата:
11.03.09 17:30
Оценка:
Здравствуйте, pgregory, Вы писали:
K>>Если не знать что такое коммутативное кольцо с единицей — можно написать, например, b+0, хотя это то же свамое, что и b, а если не знать что такое монады можно написать P>
P>a <- foo
P>return a
P>
K>>хотя это то же самое, что и просто foo.
P>Вот вы и попались!
P>Это -- чушь. Доказательство (GHCi, version 6.10.1):
Ага, интерпретатором вы пользоваться умеете, осталось ещё мозг подключить.
Какое отношение приведённый код имеет к аналогии со знанием свойств кольца и знанием monad laws?
P>Комментарии нужны?
P>Да, я понимаю, что вы хотели сказать. Но, как видите, у вас не получилось
Здравствуйте, lomeo, Вы писали:
L>А вот тоже смешно:
L>
L>Prelude> let f = 42
L>Prelude> :t f
L>f :: Integer
L>Prelude> :t 42
L>42 :: (Num t) => t
L>
L>Я доказал, что 42 — это не 42!
:-)
Ок, вижу, комментарии все же нужны.
В моем примере подразумевалась необходимость связки типа -XNoMonomorphismRestriction + import Control.Monad + liftM для превращения одного в другое. Если нужда в этой связке -- лишь плод моего воображения, я признаю, что неправ. Иначе вы признаете, что я прав.
Здравствуйте, z00n, Вы писали:
Z>В ObjectiveC 2.0 уже 3 года как консервативный GC. Tim Sweeney применяет его в UnrealEngine2/3 уже несколько лет на приставках без виртуальной памяти.
Здравствуйте, Alxndr, Вы писали:
Z>В ObjectiveC 2.0 уже 3 года как консервативный GC. Tim Sweeney применяет его в UnrealEngine2/3 уже несколько лет на приставках без виртуальной памяти.
A>Ни в слайдах, ни в комментариях нет упоминания Objective-C.
Здравствуйте, z00n, Вы писали:
Z>Здравствуйте, Alxndr, Вы писали:
A>>Ни в слайдах, ни в комментариях нет упоминания Objective-C. Z>Местоимение 'его' относилось к GC.
Здравствуйте, thesz, Вы писали:
T>>>Ты не поверишь, но не кто иной, как Джон Кармак по выпуску первого Quake говаривал, что C++ для игр не предназначен, у него нельзя контролировать расход памяти и задержки по времени из-за перегрузки и конструкторов-декструкторов. T>>>См. на Doom3 инструменты 2005 года. RD>>Вы наверное удивитесь, но мир не стоит на месте. И в то время C++ возможно (ВОЗМОЖНО) действительно не подходил для написания игр. Но если ДАЖЕ он не подходил ТОГДА, то сейчас, после долгой эволюции уже подходит.
T>За счёт чего это? Те же конструкторы, те же деструкторы, то же непредсказуемое время из-за перегрузки.
T>>>>За счёт чего это? Те же конструкторы, те же деструкторы, то же непредсказуемое время из-за перегрузки. T>>C++ не даёт создавать свои операторы, поэтому все перегружают уже существующие. T>>Получается, что a << b может означать и сдвиг, и вывод в файл. T>>Без профайлера и ассемблерного листинга не разобраться, Одного code review не достаточно. T>Это у вас какой-то неправильный мёд! Его наверное готовят неправильные пчёлы.
Это не у меня. Это у Джона Кармака. Хотя и у меня тоже, надо сказать.
T>Никакой неоднозначности нет. Зная типы a и b знаешь всё. T>Профайлеров и листинов ассемблера не нужно. T>Все затраты времени в языке детерминированы и могут быть учтены кроме внешних вызовов.
Какая сложность у new/delete для произвольного класса?
Зависит ли скорость выделения/освобождения памяти от количества и других параметров объектов, выделенных ранее?
Скорость работы C++ недостаточно детерминирована. Для её приемлемой определённости необходимо поработать ручками.
T>Чего не наблюдается в haskell-е, ну дык он вроде не для того.
Именно это и говорили про C++ в 1993-5 годах.
Удивительно даже.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>>>>>За счёт чего это? Те же конструкторы, те же деструкторы, то же непредсказуемое время из-за перегрузки.
эх, молодёжь. берём программу на С и переписываем её на C++ без конструкторов/деструкторов и virtual. что получаем? ровно то же время работы. в 80-х годах именно дополнительное время, затрачиваемое на эти элементы языка в сравнении с С, считали его серьёзным недостатком. преимущества от ООП ещё доказывать надо, а вот выполнение замедлится, причём неизвестно ещё насколько
Здравствуйте, Tonal-, Вы писали:
T>Все затраты времени в языке детерминированы и могут быть учтены кроме внешних вызовов.
Справедливости ради, не все:
— использование исключений (*)
— использование динамической памяти
— преобразование типов во время выполнения (*) (**)
(*) но есть надежда, что в течение нескольких лет детерменированность будет достигнута.
(**) AFAIR уже есть экпериментальные реализации, выполняющие dynamic_cast за константное время.
Здравствуйте, thesz, Вы писали: T>>Никакой неоднозначности нет. Зная типы a и b знаешь всё. T>>Профайлеров и листинов ассемблера не нужно. T>>Все затраты времени в языке детерминированы и могут быть учтены кроме внешних вызовов. T>Какая сложность у new/delete для произвольного класса?
Зависит от менеджера памяти (как и в pure C) + константа зависимая от состава класса — его списка наследования и списка членов.
T>Зависит ли скорость выделения/освобождения памяти от количества и других параметров объектов, выделенных ранее?
Зависит от менеджера памяти (как и в pure C)
T>Скорость работы C++ недостаточно детерминирована. Для её приемлемой определённости необходимо поработать ручками. Согласен с здесь.
Здравствуйте, Alxndr, Вы писали: T>>Все затраты времени в языке детерминированы и могут быть учтены кроме внешних вызовов. A>Справедливости ради, не все: A>- использование исключений (*) A>- использование динамической памяти A>- преобразование типов во время выполнения (*) (**) A>(*) но есть надежда, что в течение нескольких лет детерменированность будет достигнута. A>(**) AFAIR уже есть экпериментальные реализации, выполняющие dynamic_cast за константное время.
Детерминированности общего времени при обработке исключений не очень ясно как добится — ведь она может повлечь за собой произвольное количество вызовов деструкторов.
Хотя, это можно тоже учесть.
T>>>Все затраты времени в языке детерминированы и могут быть учтены кроме внешних вызовов. T>>Какая сложность у new/delete для произвольного класса? T>Зависит от менеджера памяти (как и в pure C) + константа зависимая от состава класса — его списка наследования и списка членов.
Константа?
Менеджер памяти для какого-то класса может находиться в отдельном от определения класса файле?
T>>Зависит ли скорость выделения/освобождения памяти от количества и других параметров объектов, выделенных ранее? T>Зависит от менеджера памяти (как и в pure C)
Да. Но менеджер для C либо один на всех, либо явен — XXX* arena_XXX_allocate(void). В случае new/delete мы должны осведомиться по всему проекту.
Без IDE уже становится сложно.
По поводу исключений: в игростроении кидать исключение из основного цикла моветон. В принципе, их можно не рассматривать. Других проблем вполне достаточно.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>>>Какая сложность у new/delete для произвольного класса? T>>Зависит от менеджера памяти (как и в pure C) + константа зависимая от состава класса — его списка наследования и списка членов. T>Константа?
Да.
T>Менеджер памяти для какого-то класса может находиться в отдельном от определения класса файле?
Как и в pure C.
T>>Зависит от менеджера памяти (как и в pure C) T>Да. Но менеджер для C либо один на всех, либо явен — XXX* arena_XXX_allocate(void). В случае new/delete мы должны осведомиться по всему проекту.
И в pure C при удалении структуры мы должны корректно удалить все его члены.
Чтобы узнать что именно при этом происходит нужно осведомится по всему проекту.
T>Без IDE уже становится сложно.
Да. Как и в pure C.
T>По поводу исключений: в игростроении кидать исключение из основного цикла моветон. В принципе, их можно не рассматривать.
+1
T> Других проблем вполне достаточно.
Кроме исключений и динамического приведения вроде больше никто ничего не приводил.
Здравствуйте, thesz, Вы писали:
T>>Все затраты времени в языке детерминированы и могут быть учтены кроме внешних вызовов. T>>Чего не наблюдается в haskell-е, ну дык он вроде не для того. T>Именно это и говорили про C++ в 1993-5 годах.
Заметь, недетерминированнасть только для исключений и динамического приведения, которые можно и не использовать.
А вот в haskell-е, насколько я понимаю, главные причины недетерминированности — ленивость и сборка мусора. Или я не прав?
Как-то слабо представляется как от них можно отказатся...
T>>>Все затраты времени в языке детерминированы и могут быть учтены кроме внешних вызовов. T>>>Чего не наблюдается в haskell-е, ну дык он вроде не для того. T>>Именно это и говорили про C++ в 1993-5 годах. T>Заметь, недетерминированнасть только для исключений и динамического приведения, которые можно и не использовать. T>А вот в haskell-е, насколько я понимаю, главные причины недетерминированности — ленивость и сборка мусора. Или я не прав?
T>>>>Какая сложность у new/delete для произвольного класса? T>>>Зависит от менеджера памяти (как и в pure C) + константа зависимая от состава класса — его списка наследования и списка членов. T>>Константа? T>Да.
Прошу прощения, а конструкторы могут вызывать внешние сервисы?..
Это самое простое.
new во внутреннем цикле игры подсчитывалось. Каждый свой new надо было оправдать.
T>>Менеджер памяти для какого-то класса может находиться в отдельном от определения класса файле? T>Как и в pure C.
В чистом Си менеджер указывается именем. malloc, gc_malloc, arena_alloc...
T>>>Зависит от менеджера памяти (как и в pure C) T>>Да. Но менеджер для C либо один на всех, либо явен — XXX* arena_XXX_allocate(void). В случае new/delete мы должны осведомиться по всему проекту. T>И в pure C при удалении структуры мы должны корректно удалить все его члены.
Если ты не используешь арены. Арены рулят, надо сказать.
T>Чтобы узнать что именно при этом происходит нужно осведомится по всему проекту.
Путь проще. Иди себе по вверх именам, и всё. Иерархии наследования нет, опускаться не придётся.
T>>Без IDE уже становится сложно. T>Да. Как и в pure C.
На pure C я вполне могу справиться с достаточно большим проектом (gcc) с помощью mc и понять, что там к чему.
Похожее по сложности создание на плюсах (творение коллег) без VS в мою голову не поднималось. С VS тоже, однако. Но не всегда по моей вине.
T>> Других проблем вполне достаточно. T>Кроме исключений и динамического приведения вроде больше никто ничего не приводил.
Ты их не счёл проблемами.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>>>>>Какая сложность у new/delete для произвольного класса? T>>>>Зависит от менеджера памяти (как и в pure C) + константа зависимая от состава класса — его списка наследования и списка членов. T>>>Константа? T>>Да. T>Прошу прощения, а конструкторы могут вызывать внешние сервисы?.. T>Это самое простое. T>new во внутреннем цикле игры подсчитывалось. Каждый свой new надо было оправдать. T>>>Менеджер памяти для какого-то класса может находиться в отдельном от определения класса файле? T>>Как и в pure C. T>В чистом Си менеджер указывается именем. malloc, gc_malloc, arena_alloc...
Сергей, я профилировал руками довольно большое gis приложение (профилятора не было bc 5.0.2).
180424 строк на Delphi, 107346 на C++ и 289 на Asm. все данные хранились в базе (paradox файл сервер) ~20мб в исходном (без данных) виде.
Не реалтайм конечно, но основные юзекейсы у нас выполнялись без задержек.
Использовались все средства С++ которые тогда были доступны (всё, что обсуждается).
Среда bc 5 сильно уступает современным, например навигации по коду нет никакой.
Тем не менее, никаких неожиданностей/неучтёнок не обнаружилось.
T>>>>Зависит от менеджера памяти (как и в pure C) T>>>Да. Но менеджер для C либо один на всех, либо явен — XXX* arena_XXX_allocate(void). В случае new/delete мы должны осведомиться по всему проекту.
Как и в pure C.
Для освобождения члена структуры нам может понадобится вызвать некоторую функцию.
Что он делает — нужно смотреть.
T>>И в pure C при удалении структуры мы должны корректно удалить все его члены. T>Если ты не используешь арены. Арены рулят, надо сказать.
+1
T>>Чтобы узнать что именно при этом происходит нужно осведомится по всему проекту. T>Путь проще. Иди себе по вверх именам, и всё. Иерархии наследования нет, опускаться не придётся.
Значит просто оно тебе непривычно.
T>На pure C я вполне могу справиться с достаточно большим проектом (gcc) с помощью mc и понять, что там к чему.
Хорошо структуированный прроект в понятной предметной области читается с листа даже на не очень знакомом языке.
T>Похожее по сложности создание на плюсах (творение коллег) без VS в мою голову не поднималось. С VS тоже, однако. Но не всегда по моей вине.
Не используй VC. Тот же Slick Edit или Source Navigator может значительно облегчить задачу.
T>>> Других проблем вполне достаточно. T>>Кроме исключений и динамического приведения вроде больше никто ничего не приводил. T>Ты их не счёл проблемами.
Они таковыми и не являются.
T>>>Как и в pure C. T>>В чистом Си менеджер указывается именем. malloc, gc_malloc, arena_alloc... T>Сергей, я профилировал руками довольно большое gis приложение (профилятора не было bc 5.0.2). T>180424 строк на Delphi, 107346 на C++ и 289 на Asm. все данные хранились в базе (paradox файл сервер) ~20мб в исходном (без данных) виде. T>Не реалтайм конечно, но основные юзекейсы у нас выполнялись без задержек. T>Использовались все средства С++ которые тогда были доступны (всё, что обсуждается). T>Среда bc 5 сильно уступает современным, например навигации по коду нет никакой. T>Тем не менее, никаких неожиданностей/неучтёнок не обнаружилось.
Самое простое: ты на разброс (дисперсию) времён внимание обращал? В игре будь добр уложится в 16 миллисекунд 99,99% времени. Да и то, четыре девятки означает, что раз в три минуты у тебя будет скачок FPS.
T>>>>>Зависит от менеджера памяти (как и в pure C) T>>>>Да. Но менеджер для C либо один на всех, либо явен — XXX* arena_XXX_allocate(void). В случае new/delete мы должны осведомиться по всему проекту. T>Как и в pure C. T>Для освобождения члена структуры нам может понадобится вызвать некоторую функцию. T>Что он делает — нужно смотреть.
В случае арен ты эту структуру вообще не освобождаешь. ВООБЩЕ. Это раз. В C++ такой практики не встречал ни разу. Слыхом не слыхивал.
Второе — путь отслеживания не содержит никаких неявных вещей.
T>>>Чтобы узнать что именно при этом происходит нужно осведомится по всему проекту. T>>Путь проще. Иди себе по вверх именам, и всё. Иерархии наследования нет, опускаться не придётся. T>Значит просто оно тебе непривычно.
В общем, да. Непривычно. Напомню, что речь идёт не только обо мне, так и не привыкшему к [i]особенностям[/u] c++, но и про Джона Кармака образца 1995 года.
Когда мы будем через 10 лет разговаривать о преимуществах теории типов с наблюдаемым равенством перед тамошней версией чего там будет в C#, я напомню тебе этот разговор.
Потому, что ты обязательно скажешь, что вывод типов хиндли-милнера с простыми сортами мне просто непривычна.
Этот аргумент повторяется чаще, чем любому из нас хотелось бы.
T>>На pure C я вполне могу справиться с достаточно большим проектом (gcc) с помощью mc и понять, что там к чему. T>Хорошо структуированный прроект в понятной предметной области читается с листа даже на не очень знакомом языке.
Tell me that about gcc once more, ага. Уровень вхождения в gcc очень высок, по словам товарищей, которые за это деньги получают.
T>>Похожее по сложности создание на плюсах (творение коллег) без VS в мою голову не поднималось. С VS тоже, однако. Но не всегда по моей вине. T>Не используй VC. Тот же Slick Edit или Source Navigator может значительно облегчить задачу.
Это тоже встречается чаще, чем хотелось бы уже мне лично.
Нахрена мне сейчас этот Slick Edit, когда та работа в прошлом? Зачем мне это, если я буду стараться держаться подальше от C++?
Более того, нахрена мне все эти инструменты, если для работы на Си достаточно ctags и редактора с их поддержкой (а то и без поддержки)?
T>>>> Других проблем вполне достаточно. T>>>Кроме исключений и динамического приведения вроде больше никто ничего не приводил. T>>Ты их не счёл проблемами. T>Они таковыми и не являются.
Итак, поскольку ты не считаешь мои проблемы проблемами, я могу не считать проблемами твои.
Ты только что разрушил возможность диалога. Отличный ход, очень взрослый.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>>>>>Да. Но менеджер для C либо один на всех, либо явен — XXX* arena_XXX_allocate(void). В случае new/delete мы должны осведомиться по всему проекту. T>>Как и в pure C. T>>Для освобождения члена структуры нам может понадобится вызвать некоторую функцию. T>>Что он делает — нужно смотреть.
T>В случае арен ты эту структуру вообще не освобождаешь. ВООБЩЕ. Это раз. В C++ такой практики не встречал ни разу. Слыхом не слыхивал.
Элементарно реализуется в C++: роль арены выполняет placement new, с помощью которого создаются структуры без деструкторов. Что-то вроде:
T>>>На pure C я вполне могу справиться с достаточно большим проектом (gcc) с помощью mc и понять, что там к чему. T>>Хорошо структуированный прроект в понятной предметной области читается с листа даже на не очень знакомом языке.
T>Tell me that about gcc once more, ага. Уровень вхождения в gcc очень высок, по словам товарищей, которые за это деньги получают.
Уровень вхождения в OpenSSL (даже на уровне пользователя) так же очень высок. В отличии от, например, Crypto++. Не в последнюю очередь из-за того, что в OpenSSL на C пытались реализовать какое-то подобие объектно-ориентированного подхода.
T>Нахрена мне сейчас этот Slick Edit, когда та работа в прошлом? Зачем мне это, если я буду стараться держаться подальше от C++?
T>Более того, нахрена мне все эти инструменты, если для работы на Си достаточно ctags и редактора с их поддержкой (а то и без поддержки)?
Просто в качестве ремарки. Никогда не встречал языка, от которого бы люди плевались больше, чем от C++. В крайнем случае на C++ можно программировать в стиле C. Только использовать такие удобные вещи, как ссылки, шаблоны и RAII.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
T>>В случае арен ты эту структуру вообще не освобождаешь. ВООБЩЕ. Это раз. В C++ такой практики не встречал ни разу. Слыхом не слыхивал. E>Элементарно реализуется в C++: роль арены выполняет placement new, с помощью которого создаются структуры без деструкторов. Что-то вроде: E>
1) мне не совсем понятен сам механизм и
2) не отменяет того, что арены в C++ слегка менее часто используются.
T>>Tell me that about gcc once more, ага. Уровень вхождения в gcc очень высок, по словам товарищей, которые за это деньги получают. E>Уровень вхождения в OpenSSL (даже на уровне пользователя) так же очень высок. В отличии от, например, Crypto++. Не в последнюю очередь из-за того, что в OpenSSL на C пытались реализовать какое-то подобие объектно-ориентированного подхода.
То есть, усложняли на ровном месте.
Нет, чтобы писать, как проще.
T>>Более того, нахрена мне все эти инструменты, если для работы на Си достаточно ctags и редактора с их поддержкой (а то и без поддержки)? E>Просто в качестве ремарки. Никогда не встречал языка, от которого бы люди плевались больше, чем от C++. В крайнем случае на C++ можно программировать в стиле C. Только использовать такие удобные вещи, как ссылки, шаблоны и RAII.
Я тут Java изучаю...
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>Самое простое: ты на разброс (дисперсию) времён внимание обращал? В игре будь добр уложится в 16 миллисекунд 99,99% времени. Да и то, четыре девятки означает, что раз в три минуты у тебя будет скачок FPS.
Разброс не мерял.
T>В случае арен ты эту структуру вообще не освобождаешь. ВООБЩЕ. Это раз. В C++ такой практики не встречал ни разу. Слыхом не слыхивал.
Это стандартная практика. Читал по моему у Страуструпа и ещё где-то.
Оператор new с дополнительными параметрами называется "размещающим" и соответствующего оператора delete не имеет.
T>Второе — путь отслеживания не содержит никаких неявных вещей.
Деструкторы — вполне явная вещь.
T>Потому, что ты обязательно скажешь, что вывод типов хиндли-милнера с простыми сортами мне просто непривычна. T>Этот аргумент повторяется чаще, чем любому из нас хотелось бы.
T>>>На pure C я вполне могу справиться с достаточно большим проектом (gcc) с помощью mc и понять, что там к чему. T>>Хорошо структуированный прроект в понятной предметной области читается с листа даже на не очень знакомом языке. T>Tell me that about gcc once more, ага. Уровень вхождения в gcc очень высок, по словам товарищей, которые за это деньги получают.
Думаю им можно верить.
Одно дело исправить ошибку или добавить незначительную фичу какую-нибудь, а другое — реализовать что-нибудь существенно новое.
Язык, например.
Или вон уже который год для мингвы нормальную обработку исключений сделать не могут. И реализацию SEH-а.
T>>>>> Других проблем вполне достаточно. T>>>>Кроме исключений и динамического приведения вроде больше никто ничего не приводил. T>>>Ты их не счёл проблемами. T>>Они таковыми и не являются. T>Итак, поскольку ты не считаешь мои проблемы проблемами, я могу не считать проблемами твои.
Ну так и доказательств никаких небыло, ежели ты о скорости выполнения.
Был выделено 3 бесспорных недетерминированных свойства:
1. Внешние вызовы (работа с памятью сюдаже);
2. Исключения;
3. Динамическое приведение.
Два последних решили не рассматривать. Осталось одна.
Да, забыли виртуальность:
Если у нас где-то вызывается виртуальный метод (деструктор) мы не можем сказать сколько вызов займёт времени, потому как реально может произойти вызов любой из реализаций метода.
Опять же, на критических участках не нужно злоупотреблять виртуальностью.
Ни и моих проблем я тут как-то не высказывал.
П.С. То, что С++ сложен и временами монструозен я не отрицаю.
Хотя по мне ему сейчас не хватает 2х вещей:
1. Возможность статически итерировать по членам класса/структуры/области видимости.
2. Диспач и фильтрация по типу? члена при итерации.
Частично 2е входит в tr1 и новый сандарт.
Если к этому добавиь возможность изменяь состав этих членов, то макросистема получится очень мощная.
Здравствуйте, thesz, Вы писали:
T>>>В случае арен ты эту структуру вообще не освобождаешь. ВООБЩЕ. Это раз. В C++ такой практики не встречал ни разу. Слыхом не слыхивал. E>>Элементарно реализуется в C++: роль арены выполняет placement new, с помощью которого создаются структуры без деструкторов. Что-то вроде: E>>
Вот пример. Это самая тривиальная демонстрационная реализация. В настоящей реализации нужно будет еще сделать выравнивание указателей, т.к. на некоторых платформах это черезвычайно важно. Если реализация методов арены через виртуальные методы смущает, то это легко устраняется путем написания своего operator new для каждого типа конкретной арены.
T>2) не отменяет того, что арены в C++ слегка менее часто используются.
Бытие определяет сознание.
В свое время механизм placement new был краеугольным камнем многих коммерческих ООБД (iirc, Versant, Objectivity, Poet). Какие-то из них (iirc, Versant и Objectivity) шли еще дальше. Они держали в памяти только часть страниц с загруженными из БД объектов. Когда нужно было загрузить новую страницу, они выбрасывали какую-то из уже загруженных ранее страниц. При этом перехватывались исключения, вызванные обращениями по неверным адресам и автоматически подкачивались выброшенные ранее из памяти страницы.
T>Нет, чтобы писать, как проще.
Каждый мнит себя стратегом, видя бой со стороны
E>>Просто в качестве ремарки. Никогда не встречал языка, от которого бы люди плевались больше, чем от C++.
T>Я тут Java изучаю...
Java точно не вызывает у людей затем потом такого отвращения, как C++.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали: T>>Я тут Java изучаю... E>Java точно не вызывает у людей затем потом такого отвращения, как C++.
Интересно почему так?
Я вот изучал Java уже после того, как довольно хорошо освоил плюсы.
Ощущение — так себе. Есть интересные решения и сахар, но в основном Java изрядно сильнее ограничивает.
Поэтому пересесть не захотелось.
[и тут выхожу я — весь в белом ]
E>Я тоже программирован на Java после плюсов. Впечатления двойственные. С одной стороны, ловил себя на мыслях, что пишу многословный тупой код. Там, где на C++ можно было обойтись шаблонами или указателями на функции/методы, в Java нужно было делать интерфейсы, классы-наследники и пр. лабуду (правда я пользовался Java еще до введения в нее generic-ов). Зато в Java не нужно было думать об освобождении памяти. И никогда не было моментов, когда бы я не понимал где программа сломалась. Stack trace -- великая сила! А в C++ скомпилированная в релизе программа ломается через три недели непрерывной работы -- и все. Сиди и думай, где, как и почему, никаких следов.
а теперь отгадаем с одного раза — какой язык сочетает преимущества их обоих?
Всего лишь побочный эффект cps.
