Sun сотрудничает с Haskell.org

Да, новость конечно запоздала :) Тем не менее приятно, что она тут вылезла. GHC со своими легковесными потоками и T2 прямо таки созданы друг для друга :) Удачи им с оптимизацией!

> Я потому и _интересуюсь_,

Ты неправильно интересуешься. Правильный путь - сначала прочитать про язык в первоисточниках, а потом просить уже местных Рабиновичей напеть.

Если изучить любой язык с ходу и не очень просто, то как минимум понять, что язык из себя представляет, можно довольно быстро.

Начать можно отсюда: http://www.haskell.org/haskellwiki/Introduction

Неплохое представление о языке можно получить тут: http://www.willamette.edu/~fruehr/haskell/evolution.html

Это хоть и прикол, но полезный, и если разбираться с ним вдумчиво, то много чему полезному научиться можно - не только связанному с Хаскеллем, а в математике и в computer science вообще.

>А без разницы. Попробуй ДОКАЗАТЬ свой код формально

вообще это унылая тема для флейма, неоднократно поднимавшаяся на LtU. оба подхода хороши :)

>В качестве еще более жестокого примера - посмотри на реализации структур данных Криса Окасаки. На C++ такое сделать можно, конечно же, но сложно, некрасиво и неподдерживаемо

прочитал и задумался. на кой чёрт в императивном ЯП функциональные структуры данных? или в C++ данные вдруг стали persistant?

>если разбираться с ним вдумчиво, то...

...можно сломать мозг ;)

> прочитал и задумался. на кой чёрт в императивном ЯП функциональные структуры данных? или в C++ данные вдруг стали persistant?

> такое сделать можно, конечно же, но сложно, некрасиво и неподдерживаемо

Спасибо за ссылки, весьма познавательно. Что касается этого http://www.willamette.edu/~fruehr/haskell/evolution.html , то могу сказать одно - даже _очень_ большая программа на Си++ не вызывала у меня такого страха как эти маленькие :) Сколько лет надо учиться такому языку?

"GHC compiles Haskell code either by using an intermediate C compiler (GCC), or by generating native code on some platforms." т.е. его можно использовать на любой архитектуре процессора? А с Си++ программами оно стыкуется?

хм. в ghc вполне работают русские имена функций. или вы не про то?

> А с Си++ программами оно стыкуется?

Угу, вполне. Правда, этим лучше не злоупотреблять. Функциональная парадигма не очень хорошо вяжется с императивными языками.

> прочитал и задумался. на кой чёрт в императивном ЯП функциональные структуры данных? или в C++ данные вдруг стали persistant?

Как это на кой? Для транзакционности и персистентности. А мусор и смарт-поинтеры подберут, всё равно циклические структуры там не нужны.

Персистентность она как бы ортогональна функциональности, она и в императивном окружении не помешает.

> то могу сказать одно - даже _очень_ большая программа на Си++ не вызывала у меня такого страха как эти маленькие :)

Ты не видел победителей Obfuscated C contest.

А так - язык как язык, довольно простой, если понимать лежащую в его основе математику. Для адекватного понимания C++ тоже очень много чего фундаментального знать надо, просто тут другой набор базовых понятий.

> Сколько лет надо учиться такому языку?

Если мозги есть, то и за пару недель разобраться можно. Главное - понять, что такое алгебраические типы данных, что такое ленивые вычисления, что такое карринг и замыкания. Потом, пусть даже интуитивно, понять монады. И всё, остальное само приложится.

> т.е. его можно использовать на любой архитектуре процессора?

В теории - да.

> А с Си++ программами оно стыкуется?

Вполне.

он слишком строгий чтобы с него начинать если ничего не писал на функциональных языках.

>Если мозги есть, то и за пару недель разобраться можно

на этой фразе мне стало очень грустно: от начала обучения до первых серьёзных программ на Haskell у меня ушло около года. хотя возможно виновато тяжкое насление C++ в мозгу

собственно оно и виновато - точнее годы императивщины

простой пример - в процессе обучения обучаемый неизбежно напишет программу с ошибкой в первый же день. Как опытный императивщик он захочет вставить туда print в середине - и тут его ждет первая большая засада...

"Хаскелль - лучший императивный язык" (c) С. П. Джонс

Ок, добавлю - если есть мозги и мотивация, то за пару недель можно разобраться. Без сильной мотивации и при наличии вредных привычек от C++ и компании освоение может затянуться.

Лучшая мотивация - необходимость работать в проекте, где язык уже используют, и это не обсуждается.

> захочет вставить туда print в середине - и тут его ждет первая большая засада...

do
  x <- doSomething
  print x -- нет никакой засады!
  doSomethingElse

Я скорее про обработку интернациональных символов (тот же парсинг текстов и анализ данных).

Про интерфейс (консольный, нэтивный, wx) для случаев, когда надо сделать что-то по-быстрому и не делить на разные модули, реализуемые на разных языках.

угу. Можешь провести экперимент - возьми программу с первых страниц тутора сделай там ошибку и посмотри за какое время человек не знающий хаскеля ее найдет

У Хаскеля все в побайтовом юникоде если кто не в курсе. И все отлично там работает.

> Как опытный императивщик он захочет вставить туда print в середине - и тут его ждет первая большая засада...

это будет нужно разве только в do - но тогда ничто не мешает ему поставить print. А вне do всегда есть ghci - ошибки локализуются моментально.

Таким людям надо давать Helium, у него гораздо более внятные сообщения об ошибках.

Ну, как бы сказать. В большинстве случаев сообщения хаскеля информативнее чем сообщения gcc.

вы кидаетесь в какието чстности. Я говорю о том что мозгу пропитанному императивщиной тяжело будет перестроиться и вменить стиль разработки, а вы про интерактив запустить и сообщения информативнее. Да он принт не сможет вставить в строгом язычке типа хаскеля чтобы вывести значение чеголибо пока ненаучится как это правильно делать....В этом смысле та же окамла попроще.

> Чудесно. Может наконец в Хаскеле юникод будет. А то как-то тоскливо без него :(

Лол. Покажите мне хаскель без уникода

> простой пример - в процессе обучения обучаемый неизбежно напишет программу с ошибкой в первый же день

Смотря с чего начинать изучать. Можно начать с книжки, а там не будет вначале IO как такового

Вово. И как это изучать например сиводу который привык обычно чуть что так файл аоткрывать и чето там парсить и переписывать - а тут ему сферических коней в вакууме подсунули:)

О, да.. Это внушает.. ;-) Посмотрим, что с того получится.

и что сложного с этим в Haskell?

parseFile :: (Show a) => Parser a -> String -> IO [a]
parseFile parser filename = 
    bracket (openFile filename ReadMode) hClose (processLine [])
        where
          processLine list file = do
            eof <- hIsEOF file
            if eof
                then return list
                else do 
                  line <- hGetLine file
                  case (parse parser "" line) of
                    Left err -> do print err
                                   processLine list file
                    Right xs -> processLine (list ++ [xs]) file

>В большинстве случаев сообщения хаскеля информативнее чем сообщения gcc

однако после работы с отладчиком GCC в GHC приходится долго медитировать над ошибками вида "попытка вывести бесконечный тип", к примеру. со временем понимание приходит, но сходу срубает

> и что сложного с этим в Haskell?

Та млять ниче сложного - ты чтоб это написать хаскель сколько часов учишь? Спорим что человек в глаза не видевший питона руби или прочей хренотени императивной но пишущий на С напишет на упомянутых питонорубяперлах в течении часа это? И спорим что на хаскеле он это и за неделю не напишет если не имеет фпшного бекграунда - разве только что-то очень похожее передерет без понимания смысла?

О чем спор вообще?

Чтобы понять что ты там написал надо сначала хотя бы общее предствавление иметь о парсер-комбинаторах, паттерн матчинге, алгебраических типах, карринге и выводе типов. Человек который всю жизнь писал на манифестационной императивщине подобных знаний обычно не имеет.

Я вот смотрю, ребята спорят: какой язык лучше, у кого длиннее... А с чего вы взяли, что СУН выбрала ЛУЧШИЙ язык? Может, манегеру просто кофе на яйца пролили, он и выбрал хацкель! Тем более, что и деньги так себе, разовая зарплата.

Хацкель - язык забавный, но не для продакшена. Да, можно быстро написать алгоритм быстрой сортировки, наворотить всяких монад. А кто помимо автора это поймёт?? Нужен другой, ТАКОГО ЖЕ УРОВНЯ профи, чтобы поддерживать чужую систему.

И ещё: я не понимаю, что все зациклились на функциональщине? Что, кроме неё никто и не умеет работать параллельно? Чушь! Разруби алгоритм, натрави заточенный компилер и будет ТАКОЙ ЖЕ распараллеленный код. Причём на более простом(ПОНЯТНОМ) языке.

> могу сказать одно - даже _очень_ большая программа на Си++ не вызывала у меня такого страха как эти маленькие :)

:)))) +128.

Чем больше закопано внутри, тем труднее видеть это снаружи. Плюс неочевидные взаимодействия элементов языка. Тот же Паскаль после Васика учится на раз-два. А в Хацкель нужно входить как в нирвану - годами медитируя над цветком лотоса. ВНИМАНИЕ: И всё это ради пары случаев изъебнуться и передать функцию как аргумент функции, чтобы сократить код на 10 строк. Оно мне надо? (учитывая, что все задачи фактически императивны и исполняются строго по шагам)

А ведь здесь ещё не упомянули Эрланг, Схему, Пролог.... :) Просто диву даёшься, как народ быстро реагирует на всяких маргинальных выскочек: "А вот! А у нас быстрая сортировка в одну строку!". Ну и пусть сортируют до старости! А караван идёт...

> А с чего вы взяли, что СУН выбрала ЛУЧШИЙ язык? Может, манегеру просто кофе на яйца пролили, он и выбрал хацкель!

Поясняю для неграмотных. У Sun есть крутые железки, которые пока никто не умеет использовать в полную мощь. С параллельным программированием вообще сейчас дела обстоят очень туго, адекватных средств разработки как не было, так и нет до сих пор. При этом, такие языки, как Haskell, хотя бы обещают некоторый потенциал развития в этом направлении, тогда как всяким Java и C++ тут расти просто некуда, дизайн не позволяет. Вот и хватаются, бедные, за последнюю соломинку, пытаются хотя бы из функциональщины вырастить хорошие средства параллельного программирования.

> Нужен другой, ТАКОГО ЖЕ УРОВНЯ профи, чтобы поддерживать чужую систему.

Вот тут ты просто лжешь. Нужен просто человек, понимающий язык. Да, простая обезьянка его не поймет, потому что тренирована на другой набор примитивов. Но абсолютно ничто не мешает натренировать обезьянку на мышление в функциональном стиле, он реально проще императивного. Я видел огромное множество обезьянок, органически не способных понять указатели в C++, и при этом простейшую функциональщину понять способны были почти все.

> Разруби алгоритм, натрави заточенный компилер и будет ТАКОЙ ЖЕ распараллеленный код.

Речь не человека, но дебила. Который не понимает, о чем говорит.

> Причём на более простом(ПОНЯТНОМ) языке.

Не "простом(ПОНЯТНОМ)", а привычном серым массам. Ну так массы показали прекрасную обучаемость, между прочим. Даже переход на структурное программирование прошел весьма гладко (всего лишь со сменой одного поколения, что для технологий - мелочи).

> Чем больше закопано внутри,

Там ничего внутри нет, в отличии от того же C++.

> тем труднее видеть это снаружи. Плюс неочевидные взаимодействия элементов языка.

Нет никаких "неочевидных" взаимодействий. Семантика языка гораздо проще, содержит намного меньше сущностей, чем для любого императивного языка. Главная сложность всяких там Паскалей (именно для начинающих, знаю это прекрасно по опыту преподавания) - различие между операторами и выражениями. В функциональных языках разницы нет, любая конструкция - это выражение, имеющее значение.

> А в Хацкель нужно входить как в нирвану - годами медитируя над цветком лотоса.

Ну, это если ты быдло. Но если ты - быдло, то тебе не надо браться за программирование. Программировать должны люди, которые хорошо знают и понимают математику, а для них Хаскелль на порядки проще, чем Паскаль (поскольку легче формализуется, и вообще ближе к математической привычной нотации).

> (учитывая, что все задачи фактически императивны и исполняются строго по шагам)

И это тоже грязная брехня. За почти двадцать лет в индустрии я чисто императивных задач встречал весьма мало, большинство задач - декларативны. Особенно в любимом тут "ынтырпрайзе" - сплошные системы правил и констрейнов, так называемая "бизнес-логика".

> И спорим что на хаскеле он это и за неделю не напишет если не имеет фпшного бекграунда - разве только что-то очень похожее передерет без понимания смысла?

Да точно так же на Хаскелле и напишет, узнав про синтаксический сахар 'do', не поняв его внутренней природы, но справедливо соотнеся со знакомыми с деццва императивными конструкциями.

Я видел, как люди на Схеме пишут в Фортрановском привычном стиле, и ничего, не напрягаются. А уж на Хаскелле писать по-Паскалевски - вообще не проблема. На нем можно программировать, вообще не зная, что это функциональный язык.

> хотя бы общее предствавление иметь о парсер-комбинаторах

Любой хоть немного образованный программист знает, что такое recursive descent parsing (поскольку это самый тупой подход, этот велосипед каждый сам изобретает обычно сразу после переизобретения сортировки пузырьком). Любой программист знает, что такое регулярные выражения. Так что, зацепившись глазом за подобную конструкцию, смысл её он поймет обязательно. Ну а если он дурак, если даже самых базовых понятий не знает, то ему и на Питоне программировать пока рановато, а то и на Бейсике. Надо сначала теорию подкачать.

> Человек который всю жизнь писал на манифестационной императивщине подобных знаний обычно не имеет.

Любой современный программист прекрасно понимает алгебраические типы данных, потому что от этой дряни XML не скрыться уже нигде и никак. Вывода типов можно просто не заметить, если привык к динамическим языкам (а их, опять же, знает и понимает сейчас каждый).

>> Если мозги есть, то и за пару недель разобраться можно

> на этой фразе мне стало очень грустно: от начала обучения до первых серьёзных программ на Haskell у меня ушло около года. хотя возможно виновато тяжкое насление C++ в мозгу

+1 Даже после Erlang Haskell вызывает культурный шок у императивщиков (личный опыт).

С другой стороны, если попробовать объяснить юному математику, что функции в Си (Паскале, Питоне и т.д.) --- это вовсе и не функции, то начинаешь подозревать, что может и зря на мехмате начинают с Си преподавание информатики математикам...

> Любой программист знает, что такое регулярные выражения. Любой современный программист прекрасно понимает алгебраические типы данных, потому что от этой дряни XML не скрыться уже нигде и никак. Вывода типов можно просто не заметить, если привык к динамическим языкам (а их, опять же, знает и понимает сейчас каждый).

Плакал. "Хочу жить в Советском Союзе!"

> +1 Даже после Erlang Haskell вызывает культурный шок у императивщиков (личный опыт).

Есть очень простой способ объяснить Haskell (и вообще любой декларативный язык) императивщику - начать с его операционной семантики. Когда ты понимаешь, как конкретно настоящий, железный компьютер исполняет все эти конструкции (императивно, естественно), то не замечаешь их чуждости.

Я сам языки только так и изучал - через реализацию простеньких, игрушечных интерпретаторов или компиляторов этих языков. Это позволяет примирить императивное мышление низкоуровневого программиста с чуждой высокоуровневой семантикой сложных языков. Я того же Пролога не понимал до тех пор, пока интерпретатор WAM на Си не написал.

> С другой стороны, если попробовать объяснить юному математику, что функции в Си (Паскале, Питоне и т.д.) --- это вовсе и не функции, то начинаешь подозревать, что может и зря на мехмате начинают с Си преподавание информатики математикам...

Именно по этой причине во всяких там MITах и преподают Схему, а не Паскаль. Математикам гораздо проще её понимать.

Кстати, самая популярная (и IMHO самая мощная) система для математиков - Wolfram Mathematica, тоже строится на функциональном языке (и большинство пользователей об этом даже не знают - просто пользуются). Математикам это естественно, процедурный же язык их отпугивает.

Что, не получается найти программиста, имеющего хороший опыт с XML-технологиями? Не верю! Я за последние годы не видел ни одного, кто такого опыта бы не имел.

> Что, не получается найти программиста, имеющего хороший опыт с XML-технологиями? Не верю! Я за последние годы не видел ни одного, кто такого опыта бы не имел.

Они рождаются с таким опытом, что ли (не верю!) или в ВУЗе получают (если да, то ссылки на хорошие курсы есть)?

>Чтобы понять что ты там написал надо сначала хотя бы общее предствавление иметь о парсер-комбинаторах, паттерн матчинге, алгебраических типах, карринге и выводе типов. Человек который всю жизнь писал на манифестационной императивщине подобных знаний обычно не имеет

ну, я к тому что как раз этот момент в хаскеле не требует для понимания таких уж глубоких знаний по названным дисциплинам. мне приходилось приводить его в пример человеку, писавшему до этого только на C, и проблем с пониманием не было. другое дело что в общем я с тобой согласен - ФП-стиль программирования ломает мозг. однако в рамках IO на Haskell ты пишешь в императивном стиле. да, используются вещи, присущие как правило в ФП-языках, но сам поток выполнения описывается вручную

> Они рождаются с таким опытом, что ли (не верю!) или в ВУЗе получают (если да, то ссылки на хорошие курсы есть)?

Если уже есть опыт программирования на императивных, попсовых языках, то неизбежно будет опыт работы с XML. Ибо без него сейчас никак. Так что, если хотя бы год опыта работы есть у программиста, то он по XML спец, гарантированно. Про свежих выпускников ничего не знаю и знать не хочу, пусть с ними другие нянчатся.

> Если уже есть опыт программирования на императивных, попсовых языках, то неизбежно будет опыт работы с XML. Ибо без него сейчас никак. Так что, если хотя бы год опыта работы есть у программиста, то он по XML спец, гарантированно. Про свежих выпускников ничего не знаю и знать не хочу, пусть с ними другие нянчатся.

Ну да, это все равно что сказать "Если есть опыт программирования на императивных языках, значит есть опыт программирования различных флюид солверов, без них сейчас ну никак". Вам в голову не приходило, что XML нужен не всем?

Лично я вообще считаю, что XML на хер никому не нужен. Но, объективный факт - это говно сейчас везде. И корректно взаимодействовать с окружающим миром без знакомства с этой уродской технологией невозможно. Именно по этой причине нет ни одного программиста, с XML не знакомого. Да, я не считаю за программистов всяких школьников-студентов, ковыряющих себе дома всякие велосипеды-хеллоуворлды, говорю только о профессионалах.

> Лично я вообще считаю, что XML на хер никому не нужен. Но, объективный факт - это говно сейчас везде. И корректно взаимодействовать с окружающим миром без знакомства с этой уродской технологией невозможно. Именно по этой причине нет ни одного программиста, с XML не знакомого. Да, я не считаю за программистов всяких школьников-студентов, ковыряющих себе дома всякие велосипеды-хеллоуворлды, говорю только о профессионалах.

Т.е. я могу смело заявить, что программер, не имевший дела с программированием флюид солверов, динамики, графических движков - не является профессионалом?

Ты тупой? Не сравнивай XML с этими мелкими частностями. (похоже, я говорю со студентиком...)

> Ты тупой? Не сравнивай XML с этими мелкими частностями. (похоже, я говорю со студентиком...)

Похоже ты тупой. Если ты быдлокодер это не значит, что остальные быдлокодят под XML. Так понятнее?

А ещё что-нибудь смешное вякнешь, ничтожество?

Повторяю для тупых: сейчас абсолютно любое взаимодействие с окружающим миром завязано на XML. Мимо этого проходят только задротики, которые варятся в собственном соку и изобретают велосипеды, и конечно же ембеддщики. Но в ембеддщики с улицы не попадают, обычно это уже опытные и грамотные разработчики, у которых хватает опыта и в других областях.

Вот расскажи, студентишко, какой у тебя опыт, почему в нем нет XML, и какое ты имеешь на основании этого опыта право считать себя "профессионалом"?