Комментарии 46
Проголосовал-таки за «Parallel and Concurrent Programming in Haskell» чисто чтобы посмотреть, как на этот раз поиздеваются над терминологией, ибо там ее много. В целом считаю, что техническая литература годится только в оригинале.
Программист, не знающий английского — это как менеджер, не умеющий Косынку раскладывать. Серьёзно. Как он будет функции называть? Как он будет понимать, как пользоваться сотнями библиотек, что неизбежно? Профессиональный мир общается исключительно на английском. И это всё помимо того, что перевод неизбежно коверкает оригинал.
Не нужен перевод. Не считаю, что на этом возможно заработать или принести этим какую-либо пользу.
Не нужен перевод. Не считаю, что на этом возможно заработать или принести этим какую-либо пользу.
Пользуяь случаем, передаю вам пожелание издать какую-нибудь книгу по C++/Boost. Например Introduction to the Boost C++ Libraries в двух томах. Еще неплохо было бы книгу по LLVM, но их даже на английском нет в природе.
Есть же аж три бесплатных туториала по LLVM в PDF — для C++, OCaml и Haskell.
Ну так и по Хаскелю туториалы бесплатные есть:) Но туториал и книга — это ИМХО все-же разные вещи.
А есть и книга бесплатная — anton-k.github.io/ru-haskell-book/book/home.html
При этом очень неплохая.
При этом очень неплохая.
Я тут пытался вспомнить и углубить свой цацкель, начал читать эту книгу, но бросил, когда там сразу после очевидных примеров начался ад с теорией категорий. В качестве первой книги точно нет.
Я раскачался перечитав LYAH, но после него имеет смысл читать сразу RWH. В общем это труд достойный уважения, безусловно, но рекомендовать эту книгу я бы не рискнул.
Я раскачался перечитав LYAH, но после него имеет смысл читать сразу RWH. В общем это труд достойный уважения, безусловно, но рекомендовать эту книгу я бы не рискнул.
Не то что не плохая, а просто лучшее из того, что я читал на русском. И на мой взгляд не хуже многих английских. Даже, осмелюсь сказать, с культовой RWH вровень идет.
НЛО прилетело и опубликовало эту надпись здесь
Я за Beginning Haskell, потому что 1) считаю что Learn You a Haskell for Great Good — плохая книга, 2) чем продвинутее книга, тем более продвинутому народу она нужна, тем скорее ее могут и в оригинале прочесть. Цель должна быть завлечь в секту Хаскеля побольше новичков в программировании.
Чем же плоха LYAH? Мне вот наоборот, начинал с RWH, но уже к какой-то 6й главе понял, что «сложновато», остановился, прочитал LYAH и вернулся к RWH. Как по мне — LYAH прекраснейшаа книга, особенно для начинающего. Примеры простые и более классические (алгоритмы и структуры данных), нежели в RWH с его простынями «настоящего» кода.
В любом случае считаю, что если что-то переводить на русский — то лучше что-то более начинающего уровня. Если люди хотят продвинутый уровень — всё равно английский должны хорошо знать, ну как минимум чтоб Paper'ы читать (которых в хаскеле много).
В любом случае считаю, что если что-то переводить на русский — то лучше что-то более начинающего уровня. Если люди хотят продвинутый уровень — всё равно английский должны хорошо знать, ну как минимум чтоб Paper'ы читать (которых в хаскеле много).
Ну, в том-то и дело, что в моём понимании для начинающего вникать в хаскель мне три ваших пункта кажутся скорее плюсами, чем минусами. Конечно, я согласен, что LYAH на хоть какую-то полноту понимания не претендует вообще, да я и не знаю в целом, возможно ли это с хаскелем, такое количество всего я читал и продолжаю в wiki, paper'ах и прочих местах.
Вот отличная книга: Учебник по Haskell
Ну не знаю. Вот последний абзац README.md:
Кто-н разбирается в тонкостях ST? Привожу пример с быстрой сортировкой в главе 7, но она получается крайне медленной, что-то не так, я чего-то не понимаю, не могли бы вы объяснить мне проблему.
Извините, что немного не в тему haskell, но может у вас получится захватить книгу по ocaml — Real World OCaml?
Эта книга имхо ни на что не годится. Примерно 70% посвящено синтаксису языка. Половина из оставшегося — всяким кишкам, и еще половина — всяким глупостям типа «как посчитать md5». Нет ни об Lwt, ни об Ocsigen. Переводить такую книгу — натуральная работа на корзину.
Вот если мы заговорили о других языках, я бы посоветовал перевести второе издание Programming Erlang Армстронга. Лучшая книга об Erlang из всех мне известных. Намного лучше, чем у Чезарини и Томпсона. Понравилось, что есть даже про rebar, Cowboy и (!) возможностях Erlang R17, который даже сейчас еще не совсем вышел (имеет статус RC), не говоря о времени появления книги.
Вот если мы заговорили о других языках, я бы посоветовал перевести второе издание Programming Erlang Армстронга. Лучшая книга об Erlang из всех мне известных. Намного лучше, чем у Чезарини и Томпсона. Понравилось, что есть даже про rebar, Cowboy и (!) возможностях Erlang R17, который даже сейчас еще не совсем вышел (имеет статус RC), не говоря о времени появления книги.
Real World Haskell, к сожалению, местами довольно устарела. Например, глава об обработке исключений совершенно не актуальна. Вместо HDBC нынче также есть более хорошие пакеты.
The Craft of Functional Programming не читал, ничего не могу сказать
Beginning Haskell только вчера начал читать, но первые впечатления (и судя по оглавлению), что она просто прекрасна. На мой взгляд однозначно нужно переводить ее!
Parallel and Concurrent Programming in Haskell очень, очень хороша. Но требует неплохого уровня знания Haskell и несколько специфична. На мой взгляд, ее нужно переводить, но после Beginning Haskell.
The Craft of Functional Programming не читал, ничего не могу сказать
Beginning Haskell только вчера начал читать, но первые впечатления (и судя по оглавлению), что она просто прекрасна. На мой взгляд однозначно нужно переводить ее!
Parallel and Concurrent Programming in Haskell очень, очень хороша. Но требует неплохого уровня знания Haskell и несколько специфична. На мой взгляд, ее нужно переводить, но после Beginning Haskell.
Как один из переводчиков LYAH (спасибо за отзыв!) и тех, кто мало мальски знаком с Haskell, скажу, что смысла инвестировать в Real World Haskell особого нет — книга, как уже отметил afiskon, давно устарела, а читатель не сможет воспроизвести значительное количество примеров кода из неё, не сплясав перед этим с бубном, потому как в GHC с тех пор многое что изменилось.
Остальные книги не читал.
Parallel and Concurrent Programming in Haskell полистал, выглядит очень серьёзно, и потом у неё хорошие отзывы на Amazon. Но за неё недавно взялись ДМК-Пресс (на всякий случай уточните у Дмитрия Мовчана).
Мне кажется, полезными были бы книги о таких продуктах, как, например, Yesod, Happstack, Snap Framework — т. е. которые позволяют решать прикладные задачи (веб-программирование в данном случае).
Ещё где-то краем глаза видел, что энтузиасты готовят перевод книги Криса Окасаки «Чисто функциональные структуры данных» (а, вот здесь, Юра Бронников, переводчик SICP) — эти структуры как раз можно реализовать и применять в функциональных языках вроде Haskell, Scheme, Erlang, LISP и т. д. Возможно, им нужен издатель.
Остальные книги не читал.
Parallel and Concurrent Programming in Haskell полистал, выглядит очень серьёзно, и потом у неё хорошие отзывы на Amazon. Но за неё недавно взялись ДМК-Пресс (на всякий случай уточните у Дмитрия Мовчана).
Мне кажется, полезными были бы книги о таких продуктах, как, например, Yesod, Happstack, Snap Framework — т. е. которые позволяют решать прикладные задачи (веб-программирование в данном случае).
Ещё где-то краем глаза видел, что энтузиасты готовят перевод книги Криса Окасаки «Чисто функциональные структуры данных» (а, вот здесь, Юра Бронников, переводчик SICP) — эти структуры как раз можно реализовать и применять в функциональных языках вроде Haskell, Scheme, Erlang, LISP и т. д. Возможно, им нужен издатель.
Книга о Yesod уже полностью переведена и ждет издателя. Предполагалось договориться с ДМК-Пресс, но вот что-то печатной книжки все нет. Текущее состояние дел может рассказать darkus, он с ними общался. У этой книги однако есть проблема, что автор ее постоянно дописывает.
Когда я читал про Haskell, мне всё время не хватало нормальной информации по массивам. Везде описываются списки, но совершенно очевидно, что во многих случаях массивам они не замена. Из вышеперечисленных книг я только в Parallel and Concurrent Programming in Haskell нашёл упоминание Repa, но она какая-то уж больно специфическая. А массивов в Haskell уже придумали бог знает сколько, и новичку вовсе не очевидно, какой из них использовать. Это далеко не Java, где есть только массивы и ArrayList, выбор между которыми гораздо проще.
А ещё не хватает объяснения вот таких простых вещей, как выход из вложенного цикла, например. Это можно делать, конечно, и с помощью нескольких функций, но получится уже не так элегантно. А ситуация довольно банальная.
Проголосую, наверное, за Beginning Haskell. Там вроде бы неплохой обзор возможностей языка. Кроме того, там, я вижу, затрагиваются расширения GHC, без которых, как я постепенно выяснил к своему сожалению, никто ничего серьёзного не пишет, хотя в стандарт они не включены.
А ещё не хватает объяснения вот таких простых вещей, как выход из вложенного цикла, например. Это можно делать, конечно, и с помощью нескольких функций, но получится уже не так элегантно. А ситуация довольно банальная.
Проголосую, наверное, за Beginning Haskell. Там вроде бы неплохой обзор возможностей языка. Кроме того, там, я вижу, затрагиваются расширения GHC, без которых, как я постепенно выяснил к своему сожалению, никто ничего серьёзного не пишет, хотя в стандарт они не включены.
Массивы сделаны специально такими убогими, чтобы их никто не использовал. Потому что непонятно, зачем писать на Хаскеле, если нужны олдскульно-изменяемые массивы. А если нужны какие-то поточные операции, типа map/replaceAll/zip, то 1) списки не так уж катастрофически плохи, 2) уже нужен фреймворк типа Repa. Я согласен, что Repa выкручивает руки своими типами данных. (Как и моя библиотека вместо Repa, которую я тут пиарил почти год назад.) Проблема там в том, что что как минимум до GHC 7.6 было невозможно написать обобщенный быстрый код для любых массиво-подобных типов. (Может и до сих пор невозможно, я просто не смотрел.) Можно было написать только что-то, едва ли более быстрое, чем те же списки.
Всё равно нужны же структуры данных, в которых доступ к любому элементу делается за постоянное время, а не линейное, как при чтении, так и при записи. С таким подходом, что если они требуются, то и писать на Haskell не стоит, ничего удивительного, что люди будут предпочитать более универсальные языки.
Почти любые алгоритмы, которые мы привыкли лабать на массивах в Си-подобных языках, если подумать, можно выразить в функциональном стиле. А если невозможно — таки да, это не ниша Хаскеля.
Речь-то не столько об алгоритмах, сколько о структурах данных. Приблизиться к сложности обычных структур можно с чисто функциональными, но достичь нет. Я, кстати, как раз только что нашёл книгу, в которой автор об этом пишет.
А ещё я не знаю, учитываются ли операции по записи в память, когда проводится весь этот анализ. Компилятор тут что-то оптимизирует, но шут его знает, насколько GHC хорошо с этим справляется, и вообще до какого предела всё оптимизируется с теоретической точки зрения.
А ещё я не знаю, учитываются ли операции по записи в память, когда проводится весь этот анализ. Компилятор тут что-то оптимизирует, но шут его знает, насколько GHC хорошо с этим справляется, и вообще до какого предела всё оптимизируется с теоретической точки зрения.
А что не так с массивами? Есть же они в стандартной библиотеке. Там надо-то обычно две операции — заполнить его, и взять элемент по индексу.
Взять-то да, а если нужно записывать? В случае неизменяемых массивов нужно их пересоздавать, и тогда уже неизвестно, насколько оптимальный код выдаст компилятор. А изменяемые массивы — это не чисто функциональные структуры, да и работать с ними неудобно в Haskell. Причём, настолько неудобно, что кто-то даже придумал препроцессор, чтобы это делать.
В том что «массивы в ФП не нужны» — есть доля правды, потому что нужно сначала пересмотреть подходы к алгоритмам, а потом уже разбираться где все-таки mutable-массивы нужны и как их использовать.
Как пример — в C# с появлением LINQ, массивы, кроме как immutable-буфер, в прикладном коде используются крайне редко.
Можешь, кстати, привести пример задачи где ты думаешь что без массивов будет плохо?
Как пример — в C# с появлением LINQ, массивы, кроме как immutable-буфер, в прикладном коде используются крайне редко.
Можешь, кстати, привести пример задачи где ты думаешь что без массивов будет плохо?
Там, где хэш-таблицы нужны, например. Они реализованы на основе массивов, а в Haskell придётся их реализовывать деревьями, так что некоторые потери будут.
Я так и думал, что вы хеш-таблицы имеете ввиду. Ну так они уже есть в библиотеках, не надо самому писать.
Есть, как раз с теми проблемами, что я и описал: чисто функциональная версия строится не на массивах, а на деревьях. Я не обязательно имел в виду хэш-таблицы. Просто это хороший пример, потому что это то, что всем знакомо, когда требуется запись в случайную ячейку массива, а не подряд. А так-то массив — это настолько базовая структура данных, что такие случаи — это вовсе не что-то из ряда вон выходящее.
Если на деревьях — то значит это не хеш-таблица :) Смотрите hackage.haskell.org/package/hashtables — тут операции insert — с состоянием IO или ST, значит это самые обычные хеш-таблицы, пишушие в один и тот же массив под капотом.
Так раз там IO или ST, то это уже не чисто функциональный код. Это «олдскульно-изменяемые массивы», и «непонятно, зачем писать на Хаскеле, если [они] нужны».
Вы хотите и рыбку съесть, и чисто функциональные хеш-таблицы? Так не бывает. Тут претензий к Хаскелю и его библиотекам быть не может. Но они, как минимум, 1) уже написаны 2) не убоги, в отличие от массивов, минимально сложны для своей функциональности 3) даже не очень распространяются, что под капотом — массивы.
Я сам от хэш-таблиц ничего не хочу. Меня спросили, где массивы нужны — я и привёл доступный и очевидный для всех пример. Естественно, в силу распространённости этой структуры данных работу по укрощению массивов для неё конкретно уже кто-то провёл (причём, в функциональной версии от них решили отказаться). Но этим примером же всё применение массивов не ограничивается.
А ещё не хватает объяснения вот таких простых вещей, как выход из вложенного цикла, например.
По поводу приведенной выше статьи, кто-нибудь может мне объяснить, где лежит монада EitherT? Я уже весь интернет излазил — где-то пишут, что он лежит в Control.Monad.Either, кто-то пишет, что в Control.Monad.Trans.Either. В моей версии хаскеля (Haskell Platform 2013.2.0.0) его нет нигде. Его выкинули из стандартной библиотеки? Если да, то зачем? Что мне делать, если я хочу EitherT вместо дибильного ErrorT?
Я считаю, что русскоязычные книги по Haskell нужны. Да, большинство из нас знает английский на уровне чтения. Однако при прочих равных читать на родном языке всё-таки приятнее.
Тем более что нужда в хороших книгах по Haskell имеется. Посмотрите, сколько есть книг на русском языке по тому же C++? Сотни. А сколько по Haskell? И десятка не набрать…
Тем более что нужда в хороших книгах по Haskell имеется. Посмотрите, сколько есть книг на русском языке по тому же C++? Сотни. А сколько по Haskell? И десятка не набрать…
Мы рады сообщить, что, в том числе и благодаря реакции на этот пост, принято положительное решение об издании книги Beginning Haskell: A Project-Based Approach.
Всем спасибо за участие в опросе и дискуссии!
Всем спасибо за участие в опросе и дискуссии!
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.
Новая книга по Haskell на русском?