Здравствуйте, pgregory, Вы писали: P>В случае с хаскелем это неверно. Практически невозможно написать сколько-нибудь нетривиальную программу, не зная, что такое монада. That's the whole point.
Часто достаточно понимания монады как соглашения об интерфейсе (для которого в языке предусмотрен сахар).
Здравствуйте, pgregory, Вы писали: P>С первым не согласен. Continuations — это жесть, по аналогии с монадами. Мне это не нравится.
А тут-то что сложного? Всего лишь побочный эффект cps.
P>Не знаю, почему, но то, что мне не нравятся сложные языки программирования
Такое ощущение, что Вы готовы признать сложным все, выходящее за рамки сегодняшнего мейнстрима. Потому как Ваших критериев сложности яп я пока не понимаю.
Здравствуйте, pgregory, Вы писали:
P>Здравствуйте, EvilChild, Вы в числе прочих меня критиковали.
P>Я считаю, что окружающую реальность довольно легко представить в виде объектов, имеющих состояние, и изменяющих его при выполнении некоторых действий. На лингвистическом уровне — вроде существительных, прилагательных и глаголов.
Окружающую действительность довольно легко представить в виде объектов, над которыми можно произвести действия, и самих действий, в которых участвуют от 0 до нескольких объектов. Действие меняет состояние этих объектов. Более того, действию как правило нужно какое-то конкретное представление объекта (например телевизор в конкретном действии участвует только как параллепипед с массой).
Но это не ООП.
Тут нет объектов, обменивающихся сообщениями, тут нет наследования и полиморфизма, и даже инкапсуляции.
Тут есть объекты, которые в зависимости от ситуации надо представить так или иначе, а это в чистом виде либо преобразование в другой объект, либо type classes.
Тут есть действия, которые работают с _несколькими_ объектами в общем случае, а это функция от нескольких объектов, возвращающая новые состояния этих объектов, а не метод одного из них.
Я не вижу ООП.
Вот если бы можно было написать (man1, man2).поприветствовать(), тогда другое дело. Это действительно калька с реальности. А man1.поприветствовать(man2), это непойми что. Ну правда. Надо ведь (man1, man2, man3, man4).всем_привет().
Здравствуйте, 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>Но мы ещё посмотрим.
Здравствуйте, FR, Вы писали:
FR>Но ML ветка функциональщины и современный мейнстримный ООП по сути ровесники, ты можешь объяснить почему FR>только сейчас есть робкие попытки проникновения ФП в мейнстрим?
Мне кажется, все может быть совершенно банально, если рассматривать языки не в платоновском смысле, а смотреть также на их реализации и рантайм. До середины 90-х у языков, требующих сборку мусора (а все упомянутые тут ФЯ без нее невозможны), просто не было шансов в мейнстриме. Развитие шло от железа: ассемблер — кроссплатформенный ассемблер (С) — кроссплатформенный ассемблер с доп. фишками (С++). Когда же развитие аппаратуры сделало GC доступным, 99% программистов привыкли думать в том же императивном стиле, и обучение новых программистов по-прежнему продолжается в том же ключе. Индустрия сегодня определяется навыками ее членов, те — образованием, которое определяется индустрией прошлого, которая была привязана к ограничениям железа. Хаскель — идеальный язык, ему нужен идеальный компьютер, а не наши ограниченные железки с парой гигов памяти.
Здравствуйте, 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.
А как множественное наследование классов связано с ОО?
Нследование ортогонально ОО, множественное в особенности.
Всего лишь побочный эффект cps.
А у людей, их прочитавших, тут же загораются глаза, и они кидаются искать у себя в коде монады. Ведь код без монад — не код. Ты сколько нашел, кроме стандартных? Не поделишься результатами применения этого мощнейшего механизма абстракции?
