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. Впрочем, ему можно и простить. Он так был занят "разворачиванием" всех и вся, что мог просто не заметить.
А конкретно вышеописанное преимущество на практике означает следущее: когда рассматривается вопрос, не использовать ли Хаскель в очередном проекте, следует задуматься, стоит ли выразительность языка того гемора, что будет при попытке обойти все эти и им подобные грабли. Причем не только в своем коде, а и во всех сторонних библиотеках.
Здравствуйте, VoidEx, Вы писали:
VE>Здравствуйте, pgregory, Вы писали:
P>>Отсюда я делаю вывод, что хорошесть программы абсолютно ортогональна хорошести яп, на котором она написана. VE>Вывод не меньшей наивности, чем был предложен.
С радостью откажусь от этого вывода, как только увижу реальные контрпримеры.
P>>И хотя хороший яп может помочь в написании хорошего софта (а может и помешать — сколько контрибьюторов имел бы git, будь он написан на хаскелле, а?), само по себе использование хорошего яп не дает ничего. Что мы очень явно видим на примере darcs vs. git. Хороший дизайн + плохой яп всегда победят плохой дизайн + хороший яп.
VE>Т.е. хороший ЧПУ станок не даёт ничего (выделить ещё курсивом). Мастер с инструментами всегда сделает лучше, чем студент на таком станке.
Как написано у Страуструпа, «Доказательство по аналогии — это обман» :-)
Нет никакого «т.е.». Есть объективная реальность и мой субъективный взгляд на нее. Безусловно, хаскель с друзями — очень крутые, мощные и высокоуровневые языки. Глупо с этим спорить. Но мой (думаю, не только мой) субъективный взгляд пока не видит в объективной реальности корреляции между крутостью хаскелла и хорошестью софта на нем.
Еще раз повторю, с радостью изменю этот мой взгляд. Было бы, от чего!
RD>>Да и большими объемами данных xmonad точно не ворочает. Вот если бы он прогонял через себя хотя бы мегабайт в секунду, да еще и вынужден был держать в себе сложную модель, объемом мегов в 100-100 и нетривиально ее обновлять, то была бы другая история.
T>Докажиземлюешь. T>Я серьёзно. Чего это ты выдвигаешь безосновательные тезисы? Получается игра в одни ворота: сторонники Хаскеля говорят, что он хорош и им надо это доказывать, а противники Хаскеля говорят, что он плох и это считается доказанным априори. T>Поэтому сказал А, говори и Б. Сказал, что у Хаскеля будет "другая история", предоставь use case, где это так.
Thesz, доказывать фанатикам вроде тебя бесполезно.
Если тебе говорят что-то, что не укладывается в твою картину мира, то ты орешь как недорезанный "разворачивай!" или твердишь что это не недостаток такой а крутейшая фича.
И в отличии от тебя, кричащего что "Хаскель крут ваще" я НЕ утверждаю что он не крут. Я просто показываю тебе на то, что пора снять розовые очки. Но видимо они вросли в кость.
А пример с xmonad был предложен как крупный софт, где все стабильно и нет утечек. Пример я не принимаю, т.к. софт небольшой. А меня бы заинтересовал именно БОЛЬШОЙ, перемалывающий кучу данных. И если это сможет так же стабильно работать как и xmonad — слава и хвала разработчикам. Но пока что такого примера не видел.
Здравствуйте, pgregory, Вы писали:
VE>>Т.е. хороший ЧПУ станок не даёт ничего (выделить ещё курсивом). Мастер с инструментами всегда сделает лучше, чем студент на таком станке.
P>Как написано у Страуструпа, «Доказательство по аналогии — это обман»
Как написано у Ожегова, доказательство и опровержение — это разные вещи.
Вы в одном предложении противоречите сами себе, я лишь это продемонстрировал.
Меня удивляет, как на каждое изобретение находится кто-то, кто говорит
— это что же ж, вечный двигатель штоля?
— нет конечно
— ну тогда нам и даром не нать
Вроде как давно уже порешили, что панацей не существует, а всё равно самым важным аргументом является, что сам по себе язык за вас проект не сделает. Ну это уж извините!
Прямо как будто в психологии у людей заложено панацею искать, хоть и знают, что нет её.
Здравствуйте, 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, Вы писали:
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. пока на то похоже
