Литература по ФП и годные языки

Вот и я говорю, нужно учить clojure/scala а к ней в довесок oracle db и езжать в поло альто зарабатывать баблище.

Вот и я говорю, нужно учить clojure/scala а к ней в довесок oracle db и езжать в поло альто зарабатывать баблище.

Не взлетит.

Будет альтернативой когда нибудь Рефал.

А пока только Haskell.

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

Автор лучших книжкек по Haskell - Душкин. Жаль все его книжки распроданы. При его участии вышел перевод недавно Вышел русский перевод «Learn You a Haskell for Great Good!»

Тираж обозначен в выходных данных того экземпляра что у меня 500экз. Очень мало! Но зато шикарная белая бумага. Так держать.

Качество отлично и картинок и самого перевода.

По теории отличная книга в трердом переплете на белой бумаге в издательстве Академия Сергиевский ФП и ЛП http://www.academia-moscow.ru/catalogue/sale/mathematics_computer_science/com...

Авторы знают тему, пишут сложным языком, но лучше книги нет.

Хотите использовать уже сейчас Haskell, тогда без не проходите мимо веб-серверов на Haskell, не пройдите мино blaze-html, Hamlet, lambdascript в особенности https://github.com/valderman/lambdascript.

И конечно же не пропустите готовый вики-движок gitit с интергрированными pandoc и mathjax

Если интересна тема ФП, то почему не начать использовать и развивать молодой проект NixOS, тот же Linux, но скрипы и конфиги в котором, а также порты, пакеты и все все, обоернуто в функциональный язык nix, причем в чем то родственник Haskell полагаю.

Автор лучших книжкек по Haskell - Душкин.

Только пишет он так, что к следующей странице уже забудешь, что читал на предыдущей.

Автор лучших книжкек по Haskell - Душкин.

Душкин, перелогиньтесь.

http://projecteuler.net/ же. Насчёт других языков - clean, который очень похож на haskell, но с побочными эффектами там обращаются по-другому. Не знаю его.

И так в любой книге по математике.

о, спасибо!

И так в любой книге по математике.

И так в любой _хреновой_ книге по математике.

Fixed.

Очень запоздалый вопрос - что такое MLTT и CIC?

Вот и я говорю, нужно учить clojure/scala а к ней в довесок oracle db и езжать в поло альто зарабатывать баблище.

О, Java-кодеры эволюционируют.

Programming Erlang: Software for a Concurrent World очень годная и лёгкая для новичков.

Без серьезной системы типов такой подход ни к чему кроме кучи рантайм-ошибок не приведет.

А с серьезной системой типов это не приведет ни к чему кроме кучи тайп-левел ошибок. что совершенно ничем не отличается от кучи ошибок в рантайме. Нет, вру - ошибки в рантайме искать и исправлят значительно проще).

Поэтому, в лиспе им пользуются достаточно осторожно...

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

В хаскеле же альтернатив аппликативному прграммированию нет

Ну почему это нет? Есть. Совсем прижало — пиши на C и подключай по FFI. А лисп — да, макрогенератор машинного кода.

приведет ни к чему кроме кучи тайп-левел ошибок

Ты опять сводишь систему типов к х... Посмотри в том же hackage: ну масса же библиотек, где типов больше чем «кода».

лисп — да, макрогенератор машинного кода.

Это хорошо или плохо?

ну масса же библиотек, где типов больше чем «кода».

Это хорошо или плохо?

Ну почему это нет? Есть. Совсем прижало — пиши на C и подключай по FFI.

Но это уже будет С, а не хаскель.

А лисп — да, макрогенератор машинного кода.

Для лисп-машин, да.

Ты опять сводишь систему типов к х...

Я ничего ни к чему не свожу. Напоминаю твой тезис - во всяких лиспах аппликативное программировнаие не используют, т.к. будет много рантайм ошибок. Но совершенно очевидно два факта: 1. В хаскеле на каждую рантайм ошибку лиспа будет тайплевел ошибка в том же коде 2. Исправление рантайм-ошибок типов ничем не отличается от исправления компайл-тайм ошибок типов (да, иногда - удобнее исправлять в рантайме, иногда- в компайлтайме, но в среднем - разницы нет, в крайнем случае можно добавить контракты). То есть оверхед при аппликативном стиле и динамической типизации соответствует оверхеду при апплкативном стиле и статической типизации. А значит, причина использования аппликативного стиля в хаскеле и неиспользования в лиспе в чем-то другом. Я предположил - в том, что в хаскеле из-за чистоты и ленивости другие стили по-просту становятся менее удобны (это тоже очевидно). А аппликативный стиль становтися более удобен - относительно. Главная проблема, конечно же, чистота - если бы она была реализована полноценно (как в Clean), то проблем было бы гораздо меньше. К сожалению, монады значительно менее удобны и значительно менее выразительны, чем уникальные типы.

Посмотри в том же hackage: ну масса же библиотек, где типов больше чем «кода».

Не совсем понял, к чему этот тезис, пояснишь?

плохая поддержка IDE

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

Хрена вы двое тут на ЛОРе делаете, ущербные?

Для лисп-машин, да.

Для любых. Был, например, muLisp под DOS, там был inline assembly. Удобно было нативный код им генерить.

Так оно вроде не ФП, а логический?