Это копия, сохраненная 23 ноября 2016 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Функционального программирования тред.
Пилите статьи для изучения, истории личного опыта, мысли о сабже.
Меня, и, думаю, анона тоже интересует все!
>не знаю ни о какой схемке
https://en.wikipedia.org/wiki/Scheme_(programming_language)
>а норм функциональные языки появились уже после миранды
ML-параша штоле?
Функциональное программирование - хуета и не нужно.
Ты даун?
Конечно, братуха! https://wiki.haskell.org/Android#How_to_develop_Android_software_in_Haskell
Правда придётся JNI или NDK пердолить, а так ок. (нет)
Так если хошь писать максимально близко к предметной области, то ООП тебе в руки. ФП декомпозицая только для решения математических задач пригодна, за их пределами придется подстраивать как и к машкоду.
Только что за щеку тебе попал))))
Нет, это цитата создателя TempleOS. ЕМНИП на /g/ форчонга её пришопили к Биллу.
Ты наверное сможешь юзать какие-то бычные функциональные языки, но зависимые типы это редкая фича, ее даже в хачкеле не было (по крайней мере до недавнего времни)
Наблюдается в основном в пруф ассистантах.
Не будет ничего на планшетик в готовом виде, думаю
Ничего страшного, они тут же костыли замутили, чтобы ее вернуть.
Никаких контрольных структур не существует, if и все циклы это ебаные функции.
Доступ к элементу массива это функция с параметром.
Арифметические операции это функции.
Даже присвоение и получение значения это фунции.
Давайте уже хотя бы Idris или Curry.
Что именно ты хочешь? Куда давайте?
Борщаны!
Помогите написать напишите мне короткую прогу/функцию/функтор/монаду на Хоскилле, которая будет выводить/возвращать в stdout «Мамку твою ипал! Азаза», но чтобы код был лаконичен и из него нельзя было сразу угадать вывод. Хочу напечатать на футболке.
Если ты сам не можешь написать, то у тебя морального права выёбываться нет. Купи себе футболку "Секс-инструктор".
Ты чё базаришь?! Ди сюда, пёс!
Я вообще не знаю, кем надо быть чтобы считать числа Фибоначчи рекурсивно, если есть не рекурсивная формула.
>>807273
Если тебе так чешется - возьми и запили ядро для IPython/Jupyter на Idris. Как это делать - есть в соотв. вики.
>>822252
В чем фишка скалы?
>В чем фишка скалы?
Scala формально поддерживает кучу ёб, но на практике это отсутсвие сколько-либо вменяемого вывода типов (даже линзы толком сделать нельзя), тормоза, костыли на костылях (тайпклассы через имплициты, фьюжен через views), отсутсвие ссылчной прозрачности, тяжелое наследине jvm, тормозной компилятор с невменяемыми сообщениями об ошибках, протекающие абстракции. В итоге вроде всё есть, но всё сделано очень хуёво.
Динамикодрисня. Ну и утилитаристкий подход Рича, когда сломанные абстракции, вроде трансдюсеров, добивают костылями, лишь бы хоть как-то сделать быстрые композиции комбинаторов коллекций.
Но некоторые её стороны: простота, минимализм, гибкость, открытость - хорошо подходят для определённых предметных областей, когда тебе нужна не надёжность, а хуяк-хуяк и в продакшн.
И сколько лет у тебя опыт комерческой разработки на скале?
по-моему этот recur это непонятная херь вводящая в заблуждение
Рекурсивный вызов вижу, но нихуя при этом не меняется. На каком значении рекурсия закончится? У меня просто браузер зависнет?
естественно
нужна база рекурсии
function factorial(n) {
if (n === 0) {
return 1;
}
// This is it! Recursion!!
return n * factorial(n - 1);
}
здесь база n === 0
Всё же у хаскеля в основе лямбда-исчисления, так как сам процесс вычисления это по сути редукция термов. ЧРФ немного другое.
Лисп никакого отношения к лямбда-исчислению не имеет. Он именно под рекурсивные функции делался.
Что-то не видно в нём не ПРФ, не ЧРФ. Лямбда-исчисления же проглядывают, правда неклюже. Я вообще не уверен есть ли языки основанные на ЧРФ именно в их матиматическом понимании. Может свой написать?
не пиздеть. именно на основе лямба вычислений основан лисп.
(define (x) (+ x 2))
однако можно к этой лямбе дать имя
(define foo (x) (+ x 2))
в кложе например вовсе так
(defn foo [x] (+ x 2))
defn - просто макрос:
(def foo #(+ % 2))
как то так
Брешешь же. Вот тебе цитатка из вики:
λ-исчисление может рассматриваться как семейство прототипных языков программирования. Их основная особенность состоит в том, что они являются языками высших порядков. Тем самым обеспечивается систематический подход к исследованию операторов, аргументами которых могут быть другие операторы, а значением также может быть оператор. Языки в этом семействе являются функциональными, поскольку они основаны на представлении о функции или операторе, включая функциональную аппликацию и функциональную абстракцию. λ-исчисление реализовано Джоном Маккарти в языке Лисп. Вначале реализация идеи λ-исчисления была весьма громоздкой. Но по мере развития Лисп-технологии (прошедшей этап аппаратной реализации в виде Лисп-машины) идеи получили ясную и четкую реализацию.
Источник этого вранья там сколько миллиардов дней уже не указан?
Не, в ААА нужны всякие байтоёбские оптимизации, потому что там задача не просто работать с графикой, а работать с графикой в условиях ограниченного времени/ресурсов.
С парализацией там проблем особо нет, всё делает GPU которая итак дохуя параллельна, но только на векторных операциях. Основной затык там скорее в передаче данных у CPU, memory и GPU. Да и к тому же ФП как бы подразумевает мусоросборник, а игры на таких платформах выглядят как майнкрафт ещё и лагать умудряются.
>в ААА нужны всякие байтоёбские оптимизации
Для которых прекрасно подходит Idris. Просто почитай диссер Edwin Brady: https://eb.host.cs.st-andrews.ac.uk/writings/thesis.pdf
Там тебе и стрим фьюжн, и какава с чаем. Просто пиши игры на идрис, а компилятор тебе сам все соптимизирует.
Чтобы Идрис довести до продакн-реди состояния, туда надо въебать ещё лет 20 разработки, а так да, проектик интересный.
что за бред ты несешь? тебе зачем jvm? почему не common lisp для начала? Читай Пола Грэма, учись сынок
оп пик напомнил мне мой первый проект(
я не просто так сказал, что мне нужен jvm, у меня основной проект на java вертится, и в рамках эксперимента я хочу один из новых модулей написать на clojure. я немного гуглил как организовывать интероп между ждава кодом и кложа кодом, всё выглядит довольно просто.
а с коммон лиспом как мне это сделать?
типичная реакция быдло-школьника, иди выёбывайся в свой двор
Заебешься писать на AST
Без документации ъуй разберешь что функиция принимает, что возвращает, где разворачивается макрос, а где выполняется функция и все вот такое.
clojure/clojurescript макака
если использовать популярные библиотеки/фреймворки с этим тоже будут такие проблемы?
Тогда надеюсь избежать таких проблем. Спасибо за ответ!
Язык для обучения LISP'у и чтения SICP'а, очевидно же. Сугубо академический проект.
пикрил - у меня шишка встала
А что тут говорить об этом говнище?
Кто-нибудь может понятно объяснить, что такое монада?
Это то, что между будок твоей мамаши, не?
Тип-обертка f с парой функций: bind, return. Первая позволяет применить к f a функцию, которая принимает a и возвращает f b, вторая из a делает f a.
недавно был классный доклад по монадам на какой-то конференции, не могу найти ссылку, погугли
Ну да.
All told, a monad in X is just a monoid in the category of endofunctors of X, with product × replaced by composition of endofunctors and unit set by the identity endofunctor.
Наоборот: массив/список - это монада, потому что bind = concatMap, return x = [x].
proigral
Хуйня для "вычислений в контексте".
Проще на типы функций посмотреть, там сразу всё понятно. А эти объяснения на словах только запутывают.
>Хуйня для "вычислений в контексте".
Хотя не. Это функтор для этого. Хотя, т.к. монада это функтор, то. Ну ты понел.
В маняфантазиях
Наука, тот же Clasp посмотри.
Аноны, поясните в чем суть ФП?
Вот щас читаю гайд по хаскелу - и тот же блять питон, только синтаксис уебищней.
Дошел только до tuple.
Хочу задачку какую-нибудь решить, на ум приходит только клиент серверное приложение. Хотелось бы что-нибудь охуенное сделать
пиздец он чертила. Обычно про яп рассказывают толстенькие няшки в очках, а тут какой-то бывший солист глэм метал группы
В чем проблема? JS позволяет очень многое, а ты не способен рассмотреть язык в отрыве от тех задач, которые он решает.
Позволяет делать библиотеки уровня isArray.js?
>в чем суть ФП
Понятия не имею.
Ты лучше лямбда-Алеф учи. В жизни, может, пригодится:
http://www.leafpetersen.com/leaf/publications/dtp2013/lambda-aleph-overview.pdf
Ты долбоеб что ли? Частично рекурсивные функции работают только с натуральными числами. Ты готов все данные представлять в виде натуральных чисел? Лол. Вот дебилы, блядь.
Ну вас всех нахуй. Один Михаил лучше, чем 100 таких, как вы.
Лисп-ок, из ML семейста лучше Хачкиль всё-таки, но и Фшарп пойдёт. Поиграйся с обоими. Но Лисп не полностью функциональный и проще для новичка, тем более ЖСера.
>Частично рекурсивные функции работают только с натуральными числами.
С любым сочетанием букв, знаков и символов любого конечного алфавита/алфавитов. Натуральные числа - только один из примеров.
>А вот интересно, есть ли ЯП, пусть даже эзотерические, которые содержат в качестве основы другой подход к проблеме вычислимости, а именно ЧРФ?
ЧРФ и лямбда-исчисление это немного разные подходы к одному и тому же. Любой язык с зависимыми типами - это язык с ЧРФ, а одновременно и машина Тьюринга и каноническая система Поста и алгорифмы Маркова.
Это не для людей было сделано. Окамл - это тот случай, когда совсем без тулинга было бы лучше, чем с ним. Сирисли, даже в крестах не так всё плохо.
Готовлюсь тут к экзамену по функциональному программированию и помимо прочего застряла на таком задание... Haskell->Lambda Calculus. На самом деле оно лёгкое, но вот момент, что у меня "\x y" меня смущает, не знаю как это разруливается. Была б одна вариабла, всё окей. Может кто-то может пример ради разложить мне всё по полочкам? Спасибо!
Прилагаю фотки правил преобразования и задания!
>меня "\x y" меня смущает, не знаю как это разруливается. Была б одна вариабла, всё ок
Так оно так же пишется, только с двумя переменными. То есть quot = λxy.if x bla bla bla y.
А не отбой, не увидел, что там на дойче шпрахе
Няяя!!!
обосрался с подливой
ты знаешь ваще что-нибудь кроме джаваскрипта? Что ты из этого делал кроме саетов, щегол?
Я джава/питон господин. Но то, что js сейчас дико популярен и подходит практически для всего - это факт. Загугли например react native
Ну, не-таких-как-все не может же быть миллионы, по определению. А ты в серьёз думаешь, что употребление этой дебильной фразы, несёт какой то смысл и не помножает на 0 твой бред выше?
Обрати внимание - я мимо проходил и видел только 3 последних коммента. Особенное внимание обратил на твой интеллектуальный высер, о чём с радостью и поспешил отписаться
Спасибо, оставлю тебе эту маленькую радость.
>и подходит практически для всего
и почти везде сосёт не разгибаясь, кроме браузера, там пока тупо нет альтернатив, хотя нормальные люди пишут на каком нибудь ClojureScript'е, ScalaJS, чтоб избежать жс-петушения
>дико популярен
То, что много идиотов используют идиотские языки, говорит лишь о том, что идиотов много.
Удваиваю этого.
Добавлю, что многие пишут на ЖС из-за денег, потом что это самый выгодный язык по соотношению сложность/зарплата.
Вот мне интересно в чем заключется петушение?
Я не из того хомячка которое кричит что ЖС можно везде использовать, можно да, но не нужно. Даже платы ардуино с ЖС есть, но согласен что это крайность.
Вот только в чем петушение использовать инструмент по назначению?
>ООП тебе в руки
Но ООП не формализовано. Строго рассуждать о предметной области не получится.
Ну чо, как, сдал?
Так в его формализации даже определения композиции нет. Вообще проводить формализацию через теорию множеств было очень глупо.
Окружающий мир - мир процессов, а не мир объектов, и для его адекватного описания нужен язык процессов. "Динамическое" видение мира требует отличный от теоретико-множественного архетип мышления. Если в теории множеств конструкция отображения, или функции, является не первичной и вспомогательной по отношению к самим множествам, то в теории категорий преобразования объектов (объекты – аналоги множеств, преобразования – аналоги отображений) входят в аксиоматическое определение категории наравне с объектами.
Более того, объекты оказываются частным, предельным случаем преобразований. Таким образом, при категорно-функторном описании систем акцент переносится с "застывших", "мертвых" состояний объектов на различные формы их движений и преобразований. Предметом исследования становятся не столько состояния систем, сколько совокупности способов их преобразований (вспомним, что постоянное обновление, смена, преобразование составляющего субстрата – это существеннейшие черты практически всех естественных и антропных систем). Две особенности теоретико-категорного описания систем позволяют думать, что язык теории категорий более адекватен миру, нежели язык теории множеств. Первая особенность –
возможность оперировать сразу всей совокупностью одинаково структурированных множеств, что позволяет отождествить эту совокупность с пространством всех возможных состояний системы.
Вторая особенность – та, что в категорию наряду со структурированными объектами равноправно и обязательно входят все допустимые их структурой способы изменения объектов, т.е. преобразования состояний системы. Это позволяет заменить теоретико-множественное идеализированное представление мира в виде "застывших" объектов на адекватное миру представление его процессами. Теоретико-категорный язык богаче языка теории множеств. Для одного и того же набора множеств – объектов категории – может существовать много различающихся наборов морфизмов, т.е. преобразований этих множеств. Но категории c одинаковыми объектами, но различающимися морфизмами – это различные категории: неразличимые как множества объекты в них– это различные по возможностям преобразований объекты.
Так в его формализации даже определения композиции нет. Вообще проводить формализацию через теорию множеств было очень глупо.
Окружающий мир - мир процессов, а не мир объектов, и для его адекватного описания нужен язык процессов. "Динамическое" видение мира требует отличный от теоретико-множественного архетип мышления. Если в теории множеств конструкция отображения, или функции, является не первичной и вспомогательной по отношению к самим множествам, то в теории категорий преобразования объектов (объекты – аналоги множеств, преобразования – аналоги отображений) входят в аксиоматическое определение категории наравне с объектами.
Более того, объекты оказываются частным, предельным случаем преобразований. Таким образом, при категорно-функторном описании систем акцент переносится с "застывших", "мертвых" состояний объектов на различные формы их движений и преобразований. Предметом исследования становятся не столько состояния систем, сколько совокупности способов их преобразований (вспомним, что постоянное обновление, смена, преобразование составляющего субстрата – это существеннейшие черты практически всех естественных и антропных систем). Две особенности теоретико-категорного описания систем позволяют думать, что язык теории категорий более адекватен миру, нежели язык теории множеств. Первая особенность –
возможность оперировать сразу всей совокупностью одинаково структурированных множеств, что позволяет отождествить эту совокупность с пространством всех возможных состояний системы.
Вторая особенность – та, что в категорию наряду со структурированными объектами равноправно и обязательно входят все допустимые их структурой способы изменения объектов, т.е. преобразования состояний системы. Это позволяет заменить теоретико-множественное идеализированное представление мира в виде "застывших" объектов на адекватное миру представление его процессами. Теоретико-категорный язык богаче языка теории множеств. Для одного и того же набора множеств – объектов категории – может существовать много различающихся наборов морфизмов, т.е. преобразований этих множеств. Но категории c одинаковыми объектами, но различающимися морфизмами – это различные категории: неразличимые как множества объекты в них– это различные по возможностям преобразований объекты.
За ЧРФ не скажу, но есть стековый функциональный joy, и там нет лямбда исчисления.
Ну вот, теперь ты Робина обидел
Теория категорий /= теория множеств
>Learning functional programming is like starting from scratch
Ок, нашёл этот ваш scratch - https://scratch.mit.edu/
Это и есть ваше функциональное программирование? Пиздец, ну и говно.
Лал, дебил не может в язык для 5летних детей.
Толсто
Audrey Tang и Bodil Stokke для примера.
Нинужно. Работает как приманка для людей определённого склада ума, но они потом либо всю жизнь будут писать всякое нинужное говно на хаскеле, либо сьебутся из кодинга, поняв, что это нинужно, а всё нужное им неинтересно. То есть толку ваще никакого, просто нереально жесткие проёбы времени и разбитые судьбы.
Петушином.
РЕФАЛ (судя по названию, мопед не мой).
в чем по твоему суть функционального программирования, что ты так смело заверяешь что оно не нужно? На том же хаскеле можно делать те же самые ебаные сайты, декларативная парадигма компактее и быстрее в обучении чем любой объектный фреймворк.
>декларативная парадигма компактее и быстрее в обучении чем любой объектный фреймворк.
Почему тогда функциональные языки в промышленном программирование занимают мизерную нишу? Что-то не сходится.
сам не понимаю, хуйня какая-то. Я думаю из-за того что в головах людей популярен миф о том что декларативная парадигма это сложно, сам можешь проверить, найди того кто говорит что это сложно и спроси, пробовал ли он? Скорее всего нет.
Не сложно, скорее непривычно наверное ну и нужно изначально уметь мыслить более абстрактно .
Есть же куча очевидных причин:
1. Легаси. Как идейное, так и техническое. Пишем на машкодах — пишем на ассемблере — пишем на сишке — пишем на жабе. Каждый шаг вносит простое, понятное и легкоинтегрируемое изменение. Пишем на жабе — пишем на хаскелле — глубокая смена парадигрмы и жесткая порнуха с FFI.
2. Малое распространение. Если языка нет на рынке — его не учат. Nuff said.
3. Другое мышление. Большинство языков являются "инженерными". Тип — это область в памяти, используемая определенным образом, значение — набор байтов в этой области. Даже в высокоуровневом языке типы проще всего воспринимать именно так. Функциональщина же в лице цацкеллей требует понимать, что монада — не массив, а функтор, а функтор как объект может и не существовать. Это ломает мозг.
Так что никакого противоречия между эффективностью/компактностью/надежностью функциональщины и ее малой распространенностью нет, есть лишь сложившееся положение вещей.
Ну вот кстати котлин может в этом помочь, он достаточно функционален, но не так сильно оторван от джавы и ее экосистемы, как скала например
>Функциональщина же в лице цацкеллей требует понимать, что монада — не массив
Но ведь мондада - мосив.
Мне кажется, что наслаивание функциональщины на традиционные языки лишь мешает развитию чистой функциональщины. "Зачем переходить на цацкель, если в жабе уже есть лямбды?" — разумный вопрос прагматичного программиста. А понять всю мощь и пользу хорошей системы типов ему не удастся, пока он не изучит систему типов, которую он изучать не станет, ведь в жабе уже есть лямбды.
Я думаю, функциональщина проникнет в мейнстрим совсем с другой стороны. Недавно я открыл для себя PureScript. В отличие от бесполезного(для меня) цацкеля, PS позволяет создавать реакт-приложения даже удобнее, чем JS. При этом все приложение можно записывать единым кодом: разметка — на PS, методы — на PS, стили — на PS, небо, аллах — все на PS. С обычным же веб-приложением приходится обмазываться синтаксисом CSS, JS, JSX, HTML и еще хуй знает чего. В такой ситуации может получиться, что новички, глядя на единообразие и целостность нового подхода, просто поленятся учить десяток взаимозависимых технологий и предпочтут освоить одну всеобъемлющую.
Кстати а, что можно про типы почитать? Ты же про теорию типов математическую?
Загляни в этот тред: http://2ch.hk/pr/res/697835.html (М)
Я не настолько крут в математике, чтобы давать советы. Мне и самому во многом не хватает знаний и интуиции.
Ок, спасибо
>сделайте фибоначей для отрицательных чисел
>поинтегрируйте тут немного методом трапеций
>прошла лишь половина первого модуля
Ага, просто охуеть можно, какой годный курс.
Спасибо за ссылку, начал смотреть.
Ну содержательно пока ничего не было, просто синтаксис в основном.
Впрочем, уже представляю каково будет какого-нибудь питонщика или перловика на это переучивать.
int_of_float, string_of_bool, лал. Ну это ладно, может и правильно так (хотя сомневаюсь, неужели нельзя было например string_of_float и string_of_int сделать одной полиморфной функцией).
Но вот отмазка что отсутствие неявной конвертации int/float якобы делает возможным вывод типов и вообще "это фича" кажется странной. В хаскеле и вывод типов и (3.14 + 3) нормально посчитается.
Сами же говорят, даже в сраном си это есть. А как же "наименьшее удивление"? Если позиционировать верблюда как более простую альтернативу хаскелю то вот это будет явно отталкивать аудиторию.
Арифметические операторы с точкой на конце это тоже кек. Если такие пуритане, почему один и тот же оператор сравнения можно применять к разным типам?
В плюс можно сказать что код красиво выглядит (посмотрел пару проектов на гитхабе), кажется что освовшись с языком можно его очень легко читать. Минимум закорючек и иероглифов.
Решил посмотреть чё там у хаскилитов в плане бытового скриптинга, как оно щас: такой же ебучий случай как раньше, или полехче.
Получилось такое: https://gist.github.com/aemxdp/76de37aabcd9fe1b1b45d98b39abd0c9
Начну с позитивных моментов:
- Появился stack и stackage и теперь все либы в lts совместимы друг с другом, без проблем устанавливаются, и просто работают даже на винде
- Появился wreq с хорошей документацией и линзовым апи, на котором относительно удобно можно слать запросы и разбирать ответы http://www.serpentine.com/wreq/tutorial.html
А теперь негативчик:
- Ёбаный ужас со строками: есть String = [Char], есть ленивые и энергичные ByteString, есть Text, и всё это везде используется вперемешку, и постоянно приходится конвертировать из одного в другое
- Импорты забирают дохуя времени: даже самые нужные базовые вещи раскиданы по десяткам пакетов и неймспейсов, приходится постоянно гуглить, сёрфать всю эту хуйню, подключать
- В 2016 в хаскеле до сих пор нет интерполяции строк искаробки, и хоть это давно сделано в либах на темплейт хаскель квазиквотерах, но я ебал каждый раз их качать и подвязывать
- Ебля с типами и перезаворачиванием монадок
О линзах можно рассказывать бесконечно, но влом. Лучше приведу простейший пример использования линз как get из js/lodash:
> r ^? responseBody . key "collection" . nth 0 . key "track" . key "id" . _Integer
> _.get(r, ['responseBody', 'collection', '0', 'track', 'id'], default)
https://lodash.com/docs/4.16.2#get
В линзовом решении, если на каком-то уровне будет пусто, вернёт Nothing, иначе Just result.
Что касается производительности и прожорливости скрипта в целом, думаю, дела неплохи но я ебал тестировать.
Для разбора хтмл ради интереса юзнул низкоуровневый tagsoup, который стримит хтмл, а не держит целиком в памяти,
и, как ни странно, даже для такого байтоёбского подхода выцепить нужные теги получилось более-менее красиво и удобно:
https://gist.github.com/aemxdp/76de37aabcd9fe1b1b45d98b39abd0c9#file-2ch-mus-soundcloud-reposter-hs-L80
Короче, на хаскеле можно скриптовать, но это всё ещё для маньяков и самураев, на питоне или жс я бы написал то же самое быстрее.
Пока что хаскель как и раньше лучше всего подходит для экзотических стратегий вычисления и метаязыкового колдовства в духе едсл на (p)hoas.
Решил посмотреть чё там у хаскилитов в плане бытового скриптинга, как оно щас: такой же ебучий случай как раньше, или полехче.
Получилось такое: https://gist.github.com/aemxdp/76de37aabcd9fe1b1b45d98b39abd0c9
Начну с позитивных моментов:
- Появился stack и stackage и теперь все либы в lts совместимы друг с другом, без проблем устанавливаются, и просто работают даже на винде
- Появился wreq с хорошей документацией и линзовым апи, на котором относительно удобно можно слать запросы и разбирать ответы http://www.serpentine.com/wreq/tutorial.html
А теперь негативчик:
- Ёбаный ужас со строками: есть String = [Char], есть ленивые и энергичные ByteString, есть Text, и всё это везде используется вперемешку, и постоянно приходится конвертировать из одного в другое
- Импорты забирают дохуя времени: даже самые нужные базовые вещи раскиданы по десяткам пакетов и неймспейсов, приходится постоянно гуглить, сёрфать всю эту хуйню, подключать
- В 2016 в хаскеле до сих пор нет интерполяции строк искаробки, и хоть это давно сделано в либах на темплейт хаскель квазиквотерах, но я ебал каждый раз их качать и подвязывать
- Ебля с типами и перезаворачиванием монадок
О линзах можно рассказывать бесконечно, но влом. Лучше приведу простейший пример использования линз как get из js/lodash:
> r ^? responseBody . key "collection" . nth 0 . key "track" . key "id" . _Integer
> _.get(r, ['responseBody', 'collection', '0', 'track', 'id'], default)
https://lodash.com/docs/4.16.2#get
В линзовом решении, если на каком-то уровне будет пусто, вернёт Nothing, иначе Just result.
Что касается производительности и прожорливости скрипта в целом, думаю, дела неплохи но я ебал тестировать.
Для разбора хтмл ради интереса юзнул низкоуровневый tagsoup, который стримит хтмл, а не держит целиком в памяти,
и, как ни странно, даже для такого байтоёбского подхода выцепить нужные теги получилось более-менее красиво и удобно:
https://gist.github.com/aemxdp/76de37aabcd9fe1b1b45d98b39abd0c9#file-2ch-mus-soundcloud-reposter-hs-L80
Короче, на хаскеле можно скриптовать, но это всё ещё для маньяков и самураев, на питоне или жс я бы написал то же самое быстрее.
Пока что хаскель как и раньше лучше всего подходит для экзотических стратегий вычисления и метаязыкового колдовства в духе едсл на (p)hoas.
>string_of_float и string_of_int
Тут вопрос, скорее, почему это нельзя было сделать в соответствующих модулях. String.of_float, String.to_float етц. А вообще, флоат и инт по-разному выглядят в битах, поэтому одной функцией тут нельзя. Разве только для сахару, но это почти бессмысленно.
>почему один и тот же оператор сравнения можно применять к разным типам
Потому что оператор сравнения - это хак, лол.
>(3.14 + 3)
>Арифметические операторы с точкой
То ли не осилили, то ли раньше это было нельзя, а теперь совместимость не даёт - хрен его знает.
>код красиво выглядит
Ага. Только нельзя форвард-референсить модули (функции и типы можно, если объявить через and, а для модулей не завезли), поэтому файлы по 6к+ строк кода тут нормальное явление.
> вообще, флоат и инт по-разному выглядят в битах, поэтому одной функцией тут нельзя
Что-то мешает делать 2 побитовые проверки? Built-in впилить в крайнем случае, или в окамле не принято?
> Потому что оператор сравнения - это хак, лол.
Почему? Ну в смысле наверное оно не реализовано на самом окамле, ты об этом?
> нельзя форвард-референсить модули
Я правильно понял что это относится к ситуации когда у тебя несколько модулей в одном файле, то есть чтобы использовать модуль ты должен определять его где-то выше по коду?
Случайно наебнул старый гист, перезалито с квазикокококами:
https://gist.github.com/aemxdp/f92edd57a7db979529a4d56f3d766220
Окамлодаунов вообще не слушайте. Хаскель хоть и неюзабельное говно для поехавших, но окамл ЕЩЁ хуже и неюзабельнее.
И что самое смешное - что в нём ещё и нету ничего принципиально нового по сравнению с любым обоссаным скриптом из близжайшей помойки.
>>848096
Haskell - язык для вдумчивого top-down проектирования и неспешной тырпрайз-разработки. Чтобы по-быстрому хуярить есть жс и пайтон для быдла и кложа для людей.
> вдумчивого top-down проектирования
Нужно только для средств разработки.
> тырпрайз
Ненужно. Заменяется микросервисами, каждый из которых - скрипт, написанный за пару дней.
> кложа для людей
Лиспы для аутистов, которые стремятся к однообразию и конформизму ради конформизма даже в синтаксисе. Причём чаще всего эти люди и макросы-то писать толком не умеют, и на лиспе пишут как на питоне или жс тока со скобками и без либ. Это люди с переразвитым прикладным мышлением, и недоразвитым абстрактным. И сам Рич Хики - ярчайший пример этого типажа. Короче нахуй, это задроторабы, противоположность элите. Это как раз те люди, которых можно целиком заменить роботами, и которые сами же их и построят.
каким образом ты сравниваешь ЯП и какой-то абстрактный скрипт, и на каком языке этот скрипт написан (польский? фарси? клингонский? турбопаскаль)?
чем тебя не устраивает обычный вводный курс в фп, почему тебе зудит что он на окамле?
чего ты вообще такой дерганый-то, сосачер что ли?
> и какой-то абстрактный скрипт, и на каком языке этот скрипт написан
Вот ещё пример убогого аутиста, который даже не смог сообразить, что в том контексте "скрипт" = "скриптовый язык".
> что именно не надо слушать?
Похуй что, я думаешь читать стану ваши простыни про говно верблюда и фильтровать, что "слушать" а что нет?
> чем тебя не устраивает обычный вводный курс в фп, почему тебе зудит что он на окамле?
Да похуй, я просто на всякий случай написал, что окамл ещё хуже хаскеля и не заслуживает внимания.
Я не вникаю чё вы там пишете, пропаганду этой хуйни или обсуждение курсов.
Что касается последних, ни разу не видел курса, который не был бы проёбом времени по сравнению с 'почитать самому' или 'разобраться на ходу'.
>Ненужно. Заменяется микросервисами
Нет конечно, как ты это себе представляешь? Там тонны интегрирующихся друг в друга слоёв бизнес-логики, с совершенно ебанутыми и причудливейшими связями и зависимостями, что даже в рамках одной монолитной среды почти невозможно провести декомпозицию, не превратив всё в безконсистентную нечитаемую горизонтальную лапшу. А ты предлагаешь ещё и на сервисы дробить, лол. Это можно делать когда у тебя есть чётко выделенные автономные подсистемы, а в тырпрайзе, если и можно таковые выделить, они всё равно огромны, чаще всего непропорциональны (85% кор, 15% периферия) и неделимы в том смысле, что ты насосёшься при попытке их разбить, так как: а) меняешь нативные средства композиции в рамках одной среды (на уровне примитивов языка) на менее удобные средства композиции на уровне протоколов взаимодействия между узлами и абстракциями над ними - внося ещё больше сложности и усугубляя и без основную главную проблему, б) понижаешь производительность системы: в тырпрайзе имея даже линейный рост объектов декомпозиции у тебя будет экспоненциальный рост связей между ними, и там где в рамках монолитной среды это не стоило бы ничего (разве что небольшой abstraction penalty), в рамках сервисов ты везде тратишь на I/O, в) повышаешь хрупкость системы, г) усложняешь отладку.
По большому счёту микросервисы - это ещё один базворд хайпнутых долбоёбов типа гоудибилов, думающих что простыми средствами можно решать сложные задачи. Так то их можно применять для всякой чисто инфраструктурной хуиты или, что чаще, для хипстерских перделок, но не более.
>задроторабы
Даже не знаю кто больше задрот, тот кто побырику на минималистичной кложе решает задачку, продавая её в красивой упаковке и в срок, или хачкеребёнок, пердолющийся с типами ради типов и выдумывающий неделями очередной йобаморфизм, когда НУЖЕН ВОООН ТОТ ОТЧЁТ СЕЙЧАС БЛЯТЬ.
> думающих что простыми средствами можно решать сложные задачи
Так и делается всеми кроме тырпрайз алтфаков, выдумывающих себе оправдания, что их огромная монолитная параша нужна.
> Даже не знаю кто больше задрот
Я позиционирую негативным не задротство само-по-себе, а именно сферу его применения.
>выдумывающих себе оправдания
Это опять же в стиле хипсторов и гоудетей - непризнание самого существования проблемы (что говорит в первую очередь об отсутствии опыта в этой сфере) тогда, когда она есть, это общеизвестно, и очевидно, что её решение не может быть простым. Вот хаскель как раз идеальный инструмент для её решения: продвинутые, по сравнению с другими языками, средства композиции и абстракции - это самое то для хитровыебанного тырпрайза, в то время как хипстосервисы это деградация даже по сравнению с классической жабой 90х-00х.
>а именно сферу его применения
А какая тут сфера? Решать реальные задачи? Вообще среди лисперов куча таких же фриков как в хаскеле, галлюцинирующих целыми днями над абстрактной ничего не делающей хуйнёй, только первые пердолятся с метапарсерами метаконфигов, вторые с трансформациями йобаморфизмов. Конкретно кложа должна была вернуть витающих в небесах долбоёбов на землю и заставить их решать задачи, желательно компактно. Естественно язык пропитан чисто утилитарным подходом во всём, взять те же трансдюсеры - если вдаваться в теоретические размышления это сломанная абстракция, но похуй, она работает и приносит много пользы.
Хорошо бы что-то хаскелеподобное подвезли с такой же философией, так как на данный из подобного есть только Elm, но этож веб онли да и сырое к тому же.
1. Допустим, игрок ушёл от монстра, и получилось так, что монстр его даже не видит. Но у монстра игрок всё ещё на предыдущей позиции, поэтому он его атакует и убивает.
2. Допустим, монстр А решил подойти к игроку поближе, и монстр Б решил подойти к игроку поближе. Они стояли рядом, поэтому в результате оказались на одной клетке. Допустим, что второе по весу действие было кастовать в игрока какой-нибудь опасной магией. То есть, если мы сейчас разнесём монстров на разные клетки, то получится, что они оба сходили, хотя должен был идти лишь один, а второй должен был увидеть, что прохода нет (допустим, там корридор), и атаковать игрока магией.
3. Допустим, у нас есть монстр с 5 хп. Он выпивает зелье лечения и получает 15 хп (итого 20). Допустим, есть второй монстр, который стрелял в игрока (или сам игрок) и промахнулся, попав в первого монстра и нанеся ему 6 очков повреждений. Должен ли первый монстр умереть? Должно ли с него упасть зелье лечения?
4. Допустим, игрок сделал ход, который очень длинный по времени. Это даёт монстрам возможность сделать 2.3 хода. Монстр А встаёт на соседнюю незанятую клетку и подбирает с неё зелье лечения. Монстр Б встаёт на соседнюю незанятую клетку и подбирает с неё зелье лечения. Так получилось, что оба они встали на одну клетку. What do?
Почему вообще функциональщина ставит подобные вопросы, когда то же самое на какой-нибудь убогой сишке просто работает?
> А какая тут сфера? Решать реальные задачи?
Именно. Если ты вкладываешь хоть частичку души в решение реальных задач чьих-то бизнесов, ты ты хуесос, аутист, и задротораб. Хорошее задротство должно быть направлено на развлечение себя и окружающих. Вообще, работа должна исчезнуть. Сначала все постепенно перекатятся в сферу развлечений, всякий там стриминг игор и ведение пабликов в социалках, а потом и вовсе перейдут на безусловный доход. На обслуживание всей реально нужной инфраструктуры мира хватит тех немногочисленных людей, которые даже в таких условиях захотят вьябывать ради вьябывания, просто потому что у них аутизм.
Вот кложура - это именно плохое задротство. А если взять питон или жс - в прикладном программировании на них задротства нет вообще, ты ни к чему заранее не готовишься, импровизируешь, пишешь на отьебись, и не заморачиваешься. С хаскелем особый шик: даже со стороны очевидно, что он космически задротский, но хуй ты на нём решишь задачи чьих-то бизнесов, даже если попытаешься. Это замаскированное под аутизм развлечение. С одной стороны, программы не имеют самоценности и не являются истинным искусством, потому встаёт вопрос, нахуй такое надо, но с социальной стороны хаскель и подобные ему языки - это настоящее адское пламя, падшие ангелы, всадники апокалипсиса, двигатель эволюции и перестройки сознания. В каждой сфере это нужно, в большинстве это уже есть, но именно в программировании его инкарнация такова. Некоторых это приводит к осознанности, остальных просто готовит к переходу на следующий уровень.
>>848367
> Допустим, ...
Ты пишешь какую-то лютую хуйню. Если надо, чтобы действия обрабатывались одновременно, обрабатывай одновременно, если надо чтоб последовательно - обрабатывай последовательно.
Например, обработка хода юнита имеет вид:
processTurn :: (MonadState World m) => Unit -> Action -> m ()
Тогда для последовательной обработки, все ходы по очереди в цикле процессятся, и каждый потенциально меняет стейт, каждый следующий работает уже с новым стейтом:
forM_ turns $ \(unit, action) -> processTurn unit action
Если надо параллельно, то
mapM (\(unit, action) -> processTurn unit action >> get) turns >>= put . merge
где
merge :: [World] -> World
> выпивает зелье лечения и получает 15 хп (итого 20). Допустим, есть второй монстр, который стрелял в игрока (или сам игрок) и промахнулся, попав в первого монстра и нанеся ему 6 очков повреждений. Должен ли первый монстр умереть? Должно ли с него упасть зелье лечения?
Это, кстати, вопросы уровня геймдизайна и игровой механики, а не их реализации. Реализовать можно и так и сяк, в зависимости от того, что нужно.
> А какая тут сфера? Решать реальные задачи?
Именно. Если ты вкладываешь хоть частичку души в решение реальных задач чьих-то бизнесов, ты ты хуесос, аутист, и задротораб. Хорошее задротство должно быть направлено на развлечение себя и окружающих. Вообще, работа должна исчезнуть. Сначала все постепенно перекатятся в сферу развлечений, всякий там стриминг игор и ведение пабликов в социалках, а потом и вовсе перейдут на безусловный доход. На обслуживание всей реально нужной инфраструктуры мира хватит тех немногочисленных людей, которые даже в таких условиях захотят вьябывать ради вьябывания, просто потому что у них аутизм.
Вот кложура - это именно плохое задротство. А если взять питон или жс - в прикладном программировании на них задротства нет вообще, ты ни к чему заранее не готовишься, импровизируешь, пишешь на отьебись, и не заморачиваешься. С хаскелем особый шик: даже со стороны очевидно, что он космически задротский, но хуй ты на нём решишь задачи чьих-то бизнесов, даже если попытаешься. Это замаскированное под аутизм развлечение. С одной стороны, программы не имеют самоценности и не являются истинным искусством, потому встаёт вопрос, нахуй такое надо, но с социальной стороны хаскель и подобные ему языки - это настоящее адское пламя, падшие ангелы, всадники апокалипсиса, двигатель эволюции и перестройки сознания. В каждой сфере это нужно, в большинстве это уже есть, но именно в программировании его инкарнация такова. Некоторых это приводит к осознанности, остальных просто готовит к переходу на следующий уровень.
>>848367
> Допустим, ...
Ты пишешь какую-то лютую хуйню. Если надо, чтобы действия обрабатывались одновременно, обрабатывай одновременно, если надо чтоб последовательно - обрабатывай последовательно.
Например, обработка хода юнита имеет вид:
processTurn :: (MonadState World m) => Unit -> Action -> m ()
Тогда для последовательной обработки, все ходы по очереди в цикле процессятся, и каждый потенциально меняет стейт, каждый следующий работает уже с новым стейтом:
forM_ turns $ \(unit, action) -> processTurn unit action
Если надо параллельно, то
mapM (\(unit, action) -> processTurn unit action >> get) turns >>= put . merge
где
merge :: [World] -> World
> выпивает зелье лечения и получает 15 хп (итого 20). Допустим, есть второй монстр, который стрелял в игрока (или сам игрок) и промахнулся, попав в первого монстра и нанеся ему 6 очков повреждений. Должен ли первый монстр умереть? Должно ли с него упасть зелье лечения?
Это, кстати, вопросы уровня геймдизайна и игровой механики, а не их реализации. Реализовать можно и так и сяк, в зависимости от того, что нужно.
get >>= \s -> mapM (\(unit, action) -> execState (processTurn unit action) s) turns >>= put . merge
>Вот кложура - это именно плохое задротство.
Кложа это именно фановая и быстрая разработка без задротсва, именно от неё и пошли мемасы типа хуяк-хуяк и в продакшн. Такими же по духу являются руби и эликсир. А вот пистон - задротство, питонисты - дисциплинированные кндровцы, ходят строем, чтут прилежание и аккуратность - человек другого склада на этом васике, разумеется, писать просто не сможет. JS - сам по себе просто бесконсистентная дрисня, где весело первые тысячу строк, а потом ебля моргенштерном в жеппу. Чтобы решить эту проблему - есть фремворки, которые лепят из жса что им вздумается: англяр - джяву, реакт - что-то фпешное, т.е. просто копируют имеющийся мейнстрим.
А хаскель - это замаскированный под развлечение аутизм, изощрённая форма эскапизма. То есть обычный ноулфайфер сливает жизнь на ануиму, сериалы и игоры, продвинутый ноулайфер в какую-то хуиту типа хаскеля.
Кложура пытается в пюр фп, но у неё для этого нет абстракций, и сами кложурасы-прикладники настолько не могут в абстракции, что у них даже абстрактного синтаксиса нет - только конкретный, в списках. В результате этого всего на кложуре писать ещё сложнее чем на других лиспах. Не надо коко, это задротство ещё то.
> питонисты - дисциплинированные кндровцы, ходят строем, чтут прилежание и аккуратность - человек другого склада на этом васике, разумеется, писать просто не сможет
Если речь о людях, которые двигают сам язык и либы, может быть, но прикладной кодинг на питоне совсем другой. Это единственный язык, который я вообще не учил, а просто скачал рантайм, либ, и написал за пару вечеров прикольную хуйню с вебсервисами, дата сцайнсом, графами, пикчами, не зная вообще ничего по ни языку, ни по либам, ни по матчасти. Даже с ноджс нет такой лафы.
> руби
Руби, питон, жс - это всё примерно одна хуйня, только чуть по разному сделано.
> эликсир
Это ж альтернативный синтаксис для эрланга? Походу конкуретный фп аутизм похуже кложуры.
>Кложура пытается в пюр фп
Вообще мимо. Ты её хоть видел-то?
>скобки
>только конкретный синтаксис
/0
>на кложуре писать ещё сложнее чем на других лиспах
Нет конечно. Там вся сложность была из-за JVM, тому что либ овердохуя, а идиоматичных лисп-лайк враперов - нихуя, но это уже преодолённый этап. Так-то писать на ней проще и быстрее, чем на любом лиспе.
По поводу аналогии с эликсиром и рубями, я имел ввиду подход "вернуть фан в повседневное программирование", которым эти три языка насквозь пропитаны.
> Почему еще никто не сказал про ELM? Такая то годнота! Функциональщина для для фронтенда, да еще и с нормальным синтаксисом.
Да в любое подобное обсуждение функциональные петухи неизменно затаскивают ELM, типа вот вам ф.язык с практическим применением. На самом же деле это дерьмо, как и любая надстройка над HTML+CSS+JS. К сожалению, все, что транслируется в ХТМЛ и ЖС априори хуже, чем то, что написано на этих языках. А уж ELM с его изъебствами никак не может быть проще/лучше этих весьма простых языков. И еще там рантайм пиздец какой большой, вроде бы 500к сразу прилетает, ну и странички грузятся прямо с заметным подвисанием, что можно заметить даже на самом сайте ELM'а. Короче, выглядит это изнутри примерно как сохраненная в Word 2003 в формате HTML страница с некоторыми интерактивными плюхами. Работает и дебажится это примерно так же, т.е. Write-only.
> Вообще мимо. Ты её хоть видел-то?
Немного видел, лютый пиздец и задроч.
> скобки
> только конкретный синтаксис
> /0
Как раз наоборот. Во всех языках есть, как минимум в кишках компилятора, представление кода на этом языке в виде данных. Только вот большинство языков от этих данных пользователей абстрагируют, предоставляя им удобный синтаксис, а в лиспах есть только эти данные и пользователи пишут код прямо в виде литералов этих данных.
> фан
> эликсир, руби, кложура
Мда.
>>848406
>>848443
мда всё с тобой кукаретиком ясно
ни в музыку не можешь ни в языки
одна просьба - не снимай трип нигде плиз
спс
В музыку не могу (кроме слушания), а программирование просто не люблю.
Пытаюсь всеми силами полюбить обратно, потому что сука денег надо дохуя, но никак не выходит.
Особенно ненавижу программистов, сука мрази ёбаные пидоры блядь убогие безвкусные услужливые вши недоразвитые рабы божии нахуй.
http://www.well-typed.com/blog/2016/09/sharing-conduit/
https://www.reddit.com/r/haskell/comments/550wsj/new_blog_post_sharing_memory_leaks_and_conduit/
https://www.reddit.com/r/haskell/comments/55xk4z/erratum_to_sharing_memory_leaks_and_conduit_and/
В отличие от всякой окамло-параши, регулярно постят нескучные статейки в лучших традициях хаскиля
http://z.caudate.me/why-clojure-zip-sucks/
Ой, чувак наконец-то открыл для себя свободные монады
http://degoes.net/articles/modern-fp
http://degoes.net/articles/modern-fp-part-2
Как у них там с производительностью, получше уже? Никто Олежину статью 15го года не читал (я не осилил)?
> Как у них там с производительностью
Как у интерпретации AST в рантайме, небось. По-моему, грамотное их использование - трансляция/компиляция реализуемых ими edsl во что-нибудь другое.
ну с таким подходом у тебя не получица я думаю, надо любить эту залупу, тогда и денех будет дохуя и борщ мамин будет наваристый
Или вот охуительнейшая мандадка Reader. Представь себе, анончик, в неё можно завернуть значение! А потом можно написать специальную функцию! Которая будет принимать функцию, которая будет обрабатывать значение внутри этой мандадки. Охуенно же? Что? "Зачем нужна эта акробатика, если можно к значению применять функции напрямую?" Да ты чтоооооо? Да как тебе вообще в голову такое пришлооооо!!!!!? Это же мандадки!!!!!!! Люби мандадки, пидор!!!!
Фишка Reader в том, что она автоматизирует эту передачу значения.
Благодаря ей тебе не надо контекст вручную передавать в каждую функцию параметром.
haskell как вариант
Без разницы какой. Какой тебе удобнее, тот и выбирай. Шарп немного пованивает, но если тебе удобнее - бери его. В последующем тебе придется ознакомиться со стандартным эм-эль, кложурой, скалкой и хаскелем энивей.
data Примитив = ОпределеноСмещение Смещение Координаты | ОпределеноНапряжение Напряжение Координаты | ОпределеныОба Смещение Напряжение Координаты
>запилю по приколу новый язык с новой парадихмой, не решающей практических задач
>буду продвигать в массы, говорить что збс и ваще
ебанутый? она ж на с написана...
Какой рантайм, дебил? Он же в жс компилится
>почему среди адептов функционального программирования так много трансгендеров?
Не знаю. А почему среди тех кто топит за ООП так много геев и они даже не пытаются это скрывать? Один из джава господ прямо оче толстые намеки делал по пьяне, говорил что-то про вариант съебать в Финляндию с ним.
Мимо ФП господин
Среди байтоёбов годные геи, мне кажется, взять МакКузика хотя бы.
ЖС-пидорки с чёлками, которые в толчках мака отсасывают тимлидам.
Лол, перечитал своё сообщение.
Я имел в виду, как программер он годный, Gay Person, даже пидором не назовёшь его.
Да ладно, тут все свои, можешь не скрывать собственные предпочтения.
Олдскульные маскулинные геи > современные смазливые пидорки.
http://blog.tweag.io/posts/2016-10-17-inline-java.html
Заебись, ждём когда завезут шпринг, хибернат и AbstractSingletonProxyFactoryBean
джва года жду такой хаскел
На хаскеле трамплины очень удобно едслно эмбедятся свободной монадой через гадт.
Туда ли ты зашёл, бесполезная свинья?
Кроме этого треда ещё пикрил, жжшки, твиттор.
Книги - для теоретиков. Хочешь полезного - ищи готовые рецепты и заклинания.
Не, это про математику. Мне нужно что-то более цсное. А хотт пусть конструктивист читает.
>>861933
Я не совсем понял, что ты имел в виду под рецептами и заклинаниями. Я понимаю, что кроме этого треда много всего есть, но там везде нужно регистрироваться. А некоторые еще и телефон просят!
Я имел в виду, что если хочешь понимать суть, то читай бесполезную теорию. Если хочешь полезного, тебе понимать суть не надо, иди читать блогпосты в духе "идиоматично пишем гостевуху на фпязыкнейм". Reddit - идеальный агрегатор ссылок на подобные блогпосты.
> везде нужно регистрироваться
Либо регистрация, никнеймы, и кармочка, либо жри говно на анонимной параше. Тут тебя накормят чем угодно.
Спасибо, жрал говно, жру и буду жрать. Йей, говно! С этим мы разобрались.
В общем я полистал дцпл - не, его тоже обидно читать без компилятора, хочется по ходу и писать это все. Есть еще некое "введение в функциональное программирование", даже с хорошим переводом. Уж раз перевели, значит годная книжка?
Сложно найти лишп хуже комонлишпа. Ракеты, схемы, кложура - всё это гораздо лучше ёбнутых cadadr/mapc петухов.
Комонлишп появился в 94, а нормальные рантаймы для него - ваще в последние лет 5, и то, не очень нормальные.
Комонлишп никогда не был популярен и не использовался никем, кроме душевнобольных уровня lor/0chan/2ch.
Но комонлишп являлся лишь стандартизацией уже существовавших лет десять к тому моменту лишпов.
Алсо, комонлишп использовался тем реднеком, который хакерньюс запилил :3
> Функциональное программирование
> В коде на оп пике есть переприсвоение переменных и вызов деструктивных методов.
currentTotal меняется, arr тоже меняется #shift-ом
Думаю, тс специально делал такой оппик, чтобы потроллить
мимо
>чтобы потроллить
Кто ж так тралит? Вот как надо! Скомпилить на ghc и запустить
http://pastebin.com/9qN13LX8
лучше от реализации начинай курить
Любую книжку по теории типов, смотря что тебя нужно, можно сильно угареть по математике можно не очень
Пирс Теория типов в языках программирования - ничего, про вывод ты там узнаешь
Скорее странный лисп: более функциональный, но без оптимизации хвостовой рекурсии, но с этим, скорее у JVM проблемы.
Она там есть, заебали. Просто делается через специальное ключевое слово. И это правильно, кстати, так и должно быть. А еще это совершенно неважно, блядь, потому что никто не пишет руками рекурсивные функции, але.
substrIndex :: String -> String -> Maybe Int
substrIndex x str = findIndex (x `isPrefixOf`) (tails str)
Я пока мало на Кложуре писал, в основном на Эрланге и Общелиспе, так там довольно часто рекурсивные функции пишу. Расскажи подробнее или кинь, что почитать, без ненависти.
Статья в тему: http://gilesbowkett.blogspot.ru/2015/01/one-major-difference-between-clojure.html
автор статьи в языке как-то не разобрался
А) его первый пример (который не самый быстрый, можно было значительно проще
[code lang="programming_laugnage"]
(defn build [list-1 list-2]
(when-let [[x & xs] list-1]
(concat (map #(list x %) list-2)
(build xs list-2))))
[/code]
Б) с нормальной рекурсией задача решается практически так же, просто рекурсия будет не внутри функции, а внутри loop
[code lang="programming_laugnage"]
(defn build [list-1 list-2]
(loop [result (list)
[x & xs] list-1]
(if x
(recur (concat result (map #(list x %) list-2)) xs)
result)))
[/code]
Ну и можно еще красивее через "thread-last" (на самом деле не уверен, стало ли реально лучше)
http://pastebin.com/6wWjs8b8
Но вообще конечно через for проще писать, называть его "нелиспом" из-за такой хуйни - идиотизм
Скачай купи programming clojure или какой-нибудь practical clojure. Как прочитаешь книжку - можно и блоги читать. Вообще, есть же сайтик learning-clojure.com или как-то так (погугли, я не помню точного адреса), там все материалы собраны и разложены по полочкам.
Рекурсивные функции сами по себе очень редко используются, потому что в стандартной библиотеке есть куча функций, комбинации которых хватает почти для любого преобразования. А если не хватает, то обычно используют редьюс. Ну или луп, если уж без явной рекурсии совсем никак.
тысячи их
на самом деле я надеялся что может попишу для веба глядя на purescript и elm
попробовал - оба говно
но на purescript помоему вообще нельзя ничего сделать
>>862764
ну почище да
но вот как можно чище это не чего мне хотелось в этом случае
было бы оно юзабельным
( функциональщину я так то очень люблю :( )
Но говном-то перед этим обмазался?
https://www.youtube.com/watch?v=sEfn_x245mE
>безточечном
substrIndex x str = findIndex (x `isPrefixOf`) (tails str)
Написал, теперь точек нет
Почему никто ещё не сделал хачкель с нормальным синтаксисом?
substrIndex :: String -> String -> Maybe[Int]
substrIndex(govno -> mocha) = mocha.tails.findIndex(govno.isPrefixOf)
Факториалоребёнку неприятно.
Scala же.
Erlang, Ocaml/SML/F#.
Из Лиспов: Racket.
Если уже есть опыт и знания в области программирования, то можешь для начала попробовать "щадящий" вариант, а именно, язык, в котором есть более-менее развитые средства ФП, но не настаивающий на функциональном стиле (Kotlin, D, Rust...).
Эт не я просил.
А эти точки композицию обозначают.
substrIndex :: String -> String -> Maybe Int
substrIndex = (. tails) . findIndex . isPrefixOf
Видишь, там нигде не упоминаются переменные? Это и есть point-free.
- Agda. Костыльное говно, на винде не ставится, на глинуксе тоже не ставится (зависимость - некая программа alex, ставится версия 3.2.1, агде нужно чтобы версия была выше 2.1, но ниже 2.2).
- Idris. На винде ставится, но не работает, не может подгрузить написанный хеловорлд. Возможно, лечится добавлением пути к екзешникам в PATH.
Итого, остается один Кок.
1) Ищешь там, куда поставил идрис libwinpthread-1.dll
2) Кладешь рядом со сконпелированным идрисом екзешником
3) Все работает
Да, окамлоговно - это та же жавапараша, но без либ и без работы.
У кложи, кстати, самое охуенное комьюнити из всех перечисленных тобой языков, лол.
Ты не сказал, для чего тебе язык нужен. Если чисто теоретический интерес - сперва рэкет, потом стандартный мл.
Значит ты его куда-то не туда тыкал, дружок.
> У кложи, кстати, самое охуенное комьюнити
Конечно нет, кложурас.
> Ты не сказал, для чего тебе язык нужен. Если чисто теоретический интерес - сперва рэкет, потом стандартный мл.
Он же сказал, что кложурасье комьюнити слишком маленькое. Ну так у рекета с еменьней оно тоже небольшое.
Эм, тебя стриггерило, или что? При чем тут комьюнити эмэля и ракетки? Я же сказал: они для обучения. Комьюнити тут не нужно, тут нужны книжки и пейперы, а их есть и много.
Из трех перечисленных им языков у кложи самое доброжелательное и хэлпфул для новичков комьюнити. Я это знаю, потому что сравнивал.
Он написал вот что:
"С одной стороны хаски, но это скорее как Smalltalk, не применяется, зато является стандартом ФП. С другой стороны скала, хоть и гибридный, но в продакшене. Есть Clojure, но тут слишком маленькое комьюнити."
Вроде очевидно, что размер комьюнити он считает недостатком, и просит что-то функциональное, но популярное.
Правда у всех ФЯ комьюнити еще меньше, чем у перечисленных им хаскеля-скалы-кложуры, так что посоветовать ему нечего.
БОЖЕ
КАК
ЖЕ
ХОРОШО
Ну так я ему в ответ на это и задаю вопрос: а ты с какой целью вообще интересуешься? Ясно ведь, что человек пытается судить по каким-то внешним признакам вроде какой-то "популярности", и это обычно не самый логичный и эффективный способ. Ну если человек пишет, что х-ль не применяется в продакшене, значит он совсем не в теме, и надо сперва выяснить, какие у него ожидания, и тогда потом можно будет что-то посоветовать по делу.
Мы друг друга поняли? Алсо, если уж совсем занудствовать, то популярность и размер комьюнити - далеко не одно и то же.
статикодаун, плес.
Ну не у пхпшников же спрашивать.
>>867737
Спасибо. Правда я потыкался-потыкался, но так и не нашел у него конкретной статьи на тему того, как это происходит в общих чертах. Ты какую-то конкретную статью имел в виду или нет?
Кстати, он кложей плотно упарывался, приятный сюрприз.
VS Code с подсветкой онли. Есть какие-то интеграции и комплишны, но мне лень было разбираться.
Поставил еще Komodo Edit, Atom, VS Code. Как ни странно IDEA пошустрей оказалась. Но вообще грустно, что IDE-шку нормальную не завезли.
Так можно там MLTT сделать или нет?
>Komodo Edit, Atom, VS Code, IDEA
Почему ты не можешь использовать Emacs/Vim? Плагины есть для любого языка. Можно сразу ставить, к примеру, Spacemacs, если лень час над конфигом посидеть.
>Spacemacs
Спасибо, попробую. Sublime вроде тоже неплох.
И подскажите как это говно победить. На двух машинах такая хрень, под локальным админом. Path-ы вроде все прописаны. Где логи конфугра смотреть, как узнать чего не хватает-то?
>Configuring network-2.6.3.1...
>cabal.exe: The package has a './configure' script. If you are on Windows, This requires a Unix compatibility toolchain such as MinGW+MSYS or Cygwin. If you are not on Windows, ensure that an 'sh' command is discoverable in your path.
>Используй stack.
Я это и пытаюсь сделать. Сразу и начну, как только смогу его установить, но для этого надо победить эту ошибку.
>Ну не у пхпшников же спрашивать
Тоже верно.
>>866056
Джерри Вайнберг, "The Secrets of Consulting"
Ага, спасиб, поставил. Теперь другая трабла, ставлю стаком hsdev, говорит нужен haskell-src-exts. Ставлю стаком haskell-src-exts, говорит такого пакейджа нет!!! Ставлю кабалом - ок. Стак опять говорит что его нет. Это норма?
Кабал и стек ставят пакеты в разные места.
Начинающему лучше вообще кабал-инстол лучше установленным не иметь, меньше проблем будет.
Ставь hsdev так:
stack --resolver=nightly-2016-11-02 install hsdev
если посреди долгого конпеляния он до тебя доебется, а ты не вполне понимаешь что ему надо повтори команду, он скорее всего продолжит с того места на котором остановился.
Но лучше бы не выебываться и использовать обычный ghc-mod с атомным или идейным плугином
Спасибо, бро. Я так понимаю мне достаточно было только stack поставить, а собственно stack-ом и GCH со всеми зависимостями и пакейджы все необходимые доставить\обновить всегда можно.
Ocaml - это даже не скала, это тайпскрипт с очень хуёвым синтаксисом, очень хуёвым рантаймом и без либ. Насчёт F# не особо понятно, нахуй он нужен, когда есть C# и тайпскрипт. Все эти эмели и лиспы не позволяют делать то, за что любят хаскель. Нахуя это делать - другой вопрос.
Не знаю, братишка, сам с SML начинал. Тогда было норм. А лисп не заходил. В скалке хуево что алгоритм хинди-милнера не воркает, потмоу что обекто-ориентированость. Хуво сделали - руцями приходится писать типы. Колекции еще ковариативные-контрвариатинвные-инвариативны сложна, чето.
Нет, петушок, просто ты не шаришь. Вот если б в окамле хотя бы имплиситы были, это была бы вполне себе скала с плохим синтаксисом и без либ.
>>869018
> руцями приходится писать типы
Там где в скале пишут руками типы (вещи уровня scalaz) - то в окамле вообще не делают никак.
Спасибо!
В скале их вообще везде пишут, там вывод типов на уровне "нихачу утиную типизацию".
>>869038
>Нет, петушок, просто ты не шаришь. Вот если б в окамле хотя бы имплиситы были, это была бы вполне себе скала с плохим синтаксисом и без либ.
Что-то проиграл. Ты хоть видел как Option в скале реализовывается, синтаксис хуёвый?
И да - всё точно до наоборот, это скала без имплиситов была бы ближе к окамлу, тк её создатели вдохновлялись именно им.
> В скале их вообще везде пишут
Ну хуй знает, я юзал скалу на работе как-то, не было у нас такой хуйни.
> Option в скале
option.filter(_.age > 16).map(_.vk)
vs
option |> OptionExt.filter (fun o -> o#age > 16) |> Option.map (fun o -> o#vk)
Причём filter для Option даже нету в стандартной либе окамла потому надо самому писать всякие OptionExt.
http://keinkeinkein.livejournal.com/110772.html
чем он лучше хаскелла?
Погугли про prolog.
> божественый OCaml
Ебанько, говна без чистоты и лени и так дохуя, какой смысл в окмлопараше, если это тот же жавакрестобейсик только без либ и без работы?
> и F#
Завидую тебе, не жравшему этого говна а только кукарекающего о нем в чатике. Желаю тебе хлебнуть полный рот саймопоноса. Ты будешь визжать, сучка, когда эфсярп доберется до твоего ануса.
В джаву уже завезли вывод типов и иммутабельнлсть по умолчанию?
Максималисты такие максималисты.
В окамле нету "иммутабельности по-умолчанию", даже если бы какой-то смысл в этой шизофазии и был. Вот когда строки сделают обязательно иммутабельными, через пару-тройку версий, это уже будет не так смешно.
Но то, что писать постоянно всякие консты и файналы не нужно - это хорошо, конечно. Синтаксис в окамле вообще не такой хуевый как в среднем языке.
Вывод типов - тоже плюс.
Но этого мало для того чтоб компенсировать убогость окамловских библиотек, тулов, рантайма и прочего.
В хаскеле хоть понятно ради чего ебешься со всякими кабалами и гхц-модами, а в окамле?
Ну да, окамлоговно с горчичкой и его вроде как легче жрать, но зачем, если есть варианты получше?
Тем более что говно наяривать придется забесплатно, работы на окамле нет.
Я не собираюсь тебя ни в чем убеждать, мне неинтересно. Ты сказал, что окамл - этот та же джава\кресты, я указал на ошибочку. В дальнейшем диалоге лично я не заинтересован, извини. Может кто-то другой захочет тебе ответить.
Ну разумеется, окамл - это не жава и окамл это не кресты. Но разница между окамлом и жавой где-то такая-же, как между жавой и крестами.
В дикие лохматые годы, когда не было в языках лямбд и даже самой уебищной реконструкции типов окамл еще как-то выделялся, но сейчас-то все языки такие говно-ФЯ, он один из многих, хотя и, обычно, более убогих чем он, так ради чего с ним связываться-то? Есть более интересные варианты.
Нет, не понятно. В хаскелле ебёшься со всем этим просто ради ебли - есть хоть один реальный пример (кроме хэловорда или хуиты с бесконечной рекурсией) где та же ленивость не была бы якорем? причём зачастую текучим и убивающим нахождение этой самой утечки Или нахуя чистота именно в самом языке? Чтобы костылировать очевидные вещи?
Окамл как раз ничем не ограничивает и не имеет миллиард языковых фич просто ради усложнения кода - что, несомненно, плюс. инб4: ну ты конечно же можешь расширить синтаксис как захочешь - такого удовольствия особых гурманов не лишить
Работы на других функциональных яп тоже нету мы все прекрасно знаем как используют скалу в продакшенах, и не будет просто потому что обучить человека без нормального багажа знаний макаку слишком затратно.
Алсо, единственная убогая часть тулинга - как не удивительно, поддержка винды. Нет, скомпилировать софт и даже абсолютное большинство библиотек можно - только вот завести какой нибудь utop или софт работающий с тредами - это пройти все круги ада.
>>869261
Если нужен просто более крутой язык ФЯ для разминки мозгов - варианты поинтересней конечно есть. А так он вне конкуренции - либо параша с анально ограниченной виртуалкой, либо хаскель, либо академпараша.
Поясни за минусы F#.
Я на нем любую C#-йобу переписываю гораздо компактнее, да и менять потом легче.
На работе все скрипты в linqpad давно пишу на F#
Сборку мелких проектов делаю на FAKE.
Асинхронность в модуле Async гораздо юзабельнее TPL, а если Hopac использовать, то вообще космос.
Да и комьюнити по активности только скаловскому уступает (среди функциональных языков).
Скоро тайпклассы завезут (работающий прототип проплывал с месяц назад).
> Вот когда строки сделают обязательно иммутабельными, через пару-тройку версий, это уже будет не так смешно.
Уже года 2 как, если не раньше.
Это единственный практически применимый МЛ. Я не знаю, в каком мире ты живешь, а в наш мир еще не завезли его аналогов, чтоб он был "одним из многих".
> комьюнити
Раст? Кложа? Не? Что-то ты с плеча рубанул про комьюнити, имхо. Вот я не пишу на эфшарпе и ВООБЩЕ НИХУЯ о нем не слышал. А про кложу, раст, эликсир и даже элм с пюрескриптом, прости хоспоти, слышу постоянно.
Ах, ну и про х-ль я даже не заикаюсь, разумеется.
>>869276
> работы ... нету
Опчть же, на кложе и х-ле каждую неделю вакансиями в ленту спамят, я хуй знает с какой вы планеты.
>с плеча рубанул про комьюнити
Тут ты прав, я погорячился.
Прост подписан на fsharp digest, и там постоянно то докладики, то презенташки интересные. А хаскелисты какие-то пейперы монохромные пилят.
> Нет, не понятно. В хаскелле ебёшься со всем этим просто ради ебли -
В хачкеле удобно писать функционально. Спокойно хуяришь комбинации комбинаторов. Можно, конечно, поспорить с тем, что ФП это хорошо, но последовательную защиту говноФЯ без ленивости и контроля за эффектами на этом не построить.
> есть хоть один реальный пример (кроме хэловорда или хуиты с бесконечной рекурсией) где та же ленивость не была бы якорем?
Да любые функции со списками работающие. В окамлапарашах типа батареек какие только изъебы не придумывают чтоб map в один проход написать, кастят консы к мутабельным структурам, чтоб хвост наместе переписывать, например (привет, "иммутабельность по-умолчанию").
> причём зачастую текучим и убивающим нахождение этой самой утечки
Ну да, в ФП другие лучшие практики и другие навыки нужны. Но если ты хочешь писать как деды завещали, тебе можно только позавидовать, такого говна навалом и именно в этом окамл от жавакрестов ничем не отличается.
> Или нахуя чистота именно в самом языке? Чтобы костылировать очевидные вещи?
Чтоб можно было оптимизировать и рефакторить ФП код, не боясь все поломать. Чтоб СТМ нормально пользоваться и т.д.
> Окамл как раз ничем не ограничивает
Если контроль за эффектами считать ограничением, так и типизация тогда ограничение.
> и не имеет миллиард языковых фич просто ради усложнения кода - что, несомненно, плюс.
Да ты ебанулся. В окамле самая навороченная система модулей вообще из всех существующих языков, ебенический негуманоидный ООП и ГАДТы.
Но это-то как раз хорошо, фич должно быть много. То, что предпочтительно даже в 90% случаев в 10% является говном, а если смешать 9кг варенья с 1кг говна получится 10кг говна. Говноеды, типа Гвиды, не понимают этого нихуя, но на то они и говноеды: разницы между говном и вареньем не видят. Нормальный человек понимает: всегда должны быть разные способы делать одно и то же. К счастью, в разработке хачкеля влияние обсуждаемых гей-нацистов минимально, это не высер бесноватого фюрерка, а комитетский язык в котором почти всегда есть минимум два способа сделать что-то.
Подход "жри что есть, пидор" более характерен для эмелепетушни, но в эмелепараше и не могут иметь хороших вещей из-за еще меньших трудовых ресурсов. Когда они вдруг могут позволить себе крутую фичу - они сразу забывают что только что кукарекали "НИНУЖНО!!111". Отличиный свежий пример ф-лямбда. четверть века окамлоконпелятор нихуя не оптимизировал, и окамлисты визжали о том, что продвинутые оптимизации не нужны, ведь они ухудшают предсказуемость результата (без оптимизаций производительность предсказуемо хуевая, а так может и нехуевой внезапно оказаться). Но как только оптимизации вроде уменьшения абстракшн пеналти от модулей худо-бедно запилили - этот, как его, джейнстритник выступил с программным блогпостом о том, что оптимизации, оказывается, были нужны!
> Алсо, единственная убогая часть тулинга - как не удивительно, поддержка винды. Нет, скомпилировать софт и даже абсолютное большинство библиотек можно - только вот завести какой нибудь utop или софт работающий с тредами - это пройти все круги ада.
Да весь тулинг убогий, не обманывай себя. Сравни с более-менее популярными языками.
>Если нужен просто более крутой язык ФЯ для разминки мозгов - варианты поинтересней конечно есть. А так он вне конкуренции - либо параша с анально ограниченной виртуалкой, либо хаскель, либо академпараша.
Ну вот хаскель и делает окамл полностью бессмысленным (особо упорный окамлодибил может теперь даже включить какой-нибудь LANGUAGE Strict, и пердолиться строгостью во все дыры, ему конечно придется свою энергичную прелюдию написать, но эмелистам писать стандартные библиотеки самим не привыкать). Единственная причина окамл изучать, это посмотреть как модули делали в 90-е и поебаться с ехал-функтор-через-функтор, для общего развития. Т.е. это как раз ниша разминки мозгов, идрисни всякой, просто повинтажнее и поолдскульнее.
> Нет, не понятно. В хаскелле ебёшься со всем этим просто ради ебли -
В хачкеле удобно писать функционально. Спокойно хуяришь комбинации комбинаторов. Можно, конечно, поспорить с тем, что ФП это хорошо, но последовательную защиту говноФЯ без ленивости и контроля за эффектами на этом не построить.
> есть хоть один реальный пример (кроме хэловорда или хуиты с бесконечной рекурсией) где та же ленивость не была бы якорем?
Да любые функции со списками работающие. В окамлапарашах типа батареек какие только изъебы не придумывают чтоб map в один проход написать, кастят консы к мутабельным структурам, чтоб хвост наместе переписывать, например (привет, "иммутабельность по-умолчанию").
> причём зачастую текучим и убивающим нахождение этой самой утечки
Ну да, в ФП другие лучшие практики и другие навыки нужны. Но если ты хочешь писать как деды завещали, тебе можно только позавидовать, такого говна навалом и именно в этом окамл от жавакрестов ничем не отличается.
> Или нахуя чистота именно в самом языке? Чтобы костылировать очевидные вещи?
Чтоб можно было оптимизировать и рефакторить ФП код, не боясь все поломать. Чтоб СТМ нормально пользоваться и т.д.
> Окамл как раз ничем не ограничивает
Если контроль за эффектами считать ограничением, так и типизация тогда ограничение.
> и не имеет миллиард языковых фич просто ради усложнения кода - что, несомненно, плюс.
Да ты ебанулся. В окамле самая навороченная система модулей вообще из всех существующих языков, ебенический негуманоидный ООП и ГАДТы.
Но это-то как раз хорошо, фич должно быть много. То, что предпочтительно даже в 90% случаев в 10% является говном, а если смешать 9кг варенья с 1кг говна получится 10кг говна. Говноеды, типа Гвиды, не понимают этого нихуя, но на то они и говноеды: разницы между говном и вареньем не видят. Нормальный человек понимает: всегда должны быть разные способы делать одно и то же. К счастью, в разработке хачкеля влияние обсуждаемых гей-нацистов минимально, это не высер бесноватого фюрерка, а комитетский язык в котором почти всегда есть минимум два способа сделать что-то.
Подход "жри что есть, пидор" более характерен для эмелепетушни, но в эмелепараше и не могут иметь хороших вещей из-за еще меньших трудовых ресурсов. Когда они вдруг могут позволить себе крутую фичу - они сразу забывают что только что кукарекали "НИНУЖНО!!111". Отличиный свежий пример ф-лямбда. четверть века окамлоконпелятор нихуя не оптимизировал, и окамлисты визжали о том, что продвинутые оптимизации не нужны, ведь они ухудшают предсказуемость результата (без оптимизаций производительность предсказуемо хуевая, а так может и нехуевой внезапно оказаться). Но как только оптимизации вроде уменьшения абстракшн пеналти от модулей худо-бедно запилили - этот, как его, джейнстритник выступил с программным блогпостом о том, что оптимизации, оказывается, были нужны!
> Алсо, единственная убогая часть тулинга - как не удивительно, поддержка винды. Нет, скомпилировать софт и даже абсолютное большинство библиотек можно - только вот завести какой нибудь utop или софт работающий с тредами - это пройти все круги ада.
Да весь тулинг убогий, не обманывай себя. Сравни с более-менее популярными языками.
>Если нужен просто более крутой язык ФЯ для разминки мозгов - варианты поинтересней конечно есть. А так он вне конкуренции - либо параша с анально ограниченной виртуалкой, либо хаскель, либо академпараша.
Ну вот хаскель и делает окамл полностью бессмысленным (особо упорный окамлодибил может теперь даже включить какой-нибудь LANGUAGE Strict, и пердолиться строгостью во все дыры, ему конечно придется свою энергичную прелюдию написать, но эмелистам писать стандартные библиотеки самим не привыкать). Единственная причина окамл изучать, это посмотреть как модули делали в 90-е и поебаться с ехал-функтор-через-функтор, для общего развития. Т.е. это как раз ниша разминки мозгов, идрисни всякой, просто повинтажнее и поолдскульнее.
Это необязательная фича, энфорсить иммутабельность строк они именно только через 2-3 версии собираются
Когда говорят о практической применимости F# обычно имеют в виду то, что на нем можно писать как на C# и использовать библиотеки, написанные на и для C#-а. В качестве же именно ФЯ - F# абсурдно неполноценен и убог.
Имеющий опыт использования какого-то ФЯ обнаружит, что практики из этого языка перенести в F# нельзя и опыт бесполезен потому, что:
1) Выразительные средства из более-менее сносных ФЯ вроде тайпклассов и параметризуемых модулей в F# отсутствуют - как будто не было последних 30 лет. Есть только ООП-средства. Отсюда невероятные для ФЯ проблемы с обобщением и повторным использованием.
2) ФП код, обычно, не может быть типизирован - из-за отсутствия возможности абстрагироваться от конструктора и отсутствия Rank-N и полиморфной рекурсии (про какие-нибудь GADT я и не говорю).
Система типов в F# точно самая убогая из всех ФЯ, но вывод типов для нее все равно нормально не работает. Вместо него убогая реконструкция и даже не двухсторонняя, а слева на право. Даже в некоторых языках с завтипами реконструкция работает лучше, а главное есть удобные способы подсказать тип.
3) Если вам все-таки повезло и ФП код типизируется - он будет адово тормозить, ведь оптимизировать ФП код не нужно - можно же заставить программиста как на C#-е (Фортране) писать.
Нужно отметить, что есть некоторые приятные фишки, но они являются ложкой меда в бочке дегтя и выглядят, скорее, как издевательство.
Некоторые из этих проблем встречаются в других ФЯ, но нигде не собрано такого полного комплекта и нигде не достигнут такой совершенный, в своем роде, апофеоз убогости. Даже Скала не настолько убога (у нее все-таки развитая система типов, хотя удобной эту систему типов, конечно, не назовешь).
Подытоживая: ни для программиста на SML, ни на каком другом ФЯ F#, конечно, не может быть полноценной заменой уже известного инструмента. F# - это скорее C# с человеческим лицом для программистов на C# окончательно измученных этим нарзаном, и если вдруг программист пробовал что-то слаще морковки - "человеческое лицо" превращается в звериный оскал.
tl;dr пасты: по сравнению с C# может и охуенно, но это крайне низкая планка по меркам ФЯ.
> Скоро тайпклассы завезут (работающий прототип проплывал с месяц назад)
Без когерентности инстансов и особенно HKT от тайпклассов толку нету. Ну и синтаксически там пиздец тот еще.
Когда говорят о практической применимости F# обычно имеют в виду то, что на нем можно писать как на C# и использовать библиотеки, написанные на и для C#-а. В качестве же именно ФЯ - F# абсурдно неполноценен и убог.
Имеющий опыт использования какого-то ФЯ обнаружит, что практики из этого языка перенести в F# нельзя и опыт бесполезен потому, что:
1) Выразительные средства из более-менее сносных ФЯ вроде тайпклассов и параметризуемых модулей в F# отсутствуют - как будто не было последних 30 лет. Есть только ООП-средства. Отсюда невероятные для ФЯ проблемы с обобщением и повторным использованием.
2) ФП код, обычно, не может быть типизирован - из-за отсутствия возможности абстрагироваться от конструктора и отсутствия Rank-N и полиморфной рекурсии (про какие-нибудь GADT я и не говорю).
Система типов в F# точно самая убогая из всех ФЯ, но вывод типов для нее все равно нормально не работает. Вместо него убогая реконструкция и даже не двухсторонняя, а слева на право. Даже в некоторых языках с завтипами реконструкция работает лучше, а главное есть удобные способы подсказать тип.
3) Если вам все-таки повезло и ФП код типизируется - он будет адово тормозить, ведь оптимизировать ФП код не нужно - можно же заставить программиста как на C#-е (Фортране) писать.
Нужно отметить, что есть некоторые приятные фишки, но они являются ложкой меда в бочке дегтя и выглядят, скорее, как издевательство.
Некоторые из этих проблем встречаются в других ФЯ, но нигде не собрано такого полного комплекта и нигде не достигнут такой совершенный, в своем роде, апофеоз убогости. Даже Скала не настолько убога (у нее все-таки развитая система типов, хотя удобной эту систему типов, конечно, не назовешь).
Подытоживая: ни для программиста на SML, ни на каком другом ФЯ F#, конечно, не может быть полноценной заменой уже известного инструмента. F# - это скорее C# с человеческим лицом для программистов на C# окончательно измученных этим нарзаном, и если вдруг программист пробовал что-то слаще морковки - "человеческое лицо" превращается в звериный оскал.
tl;dr пасты: по сравнению с C# может и охуенно, но это крайне низкая планка по меркам ФЯ.
> Скоро тайпклассы завезут (работающий прототип проплывал с месяц назад)
Без когерентности инстансов и особенно HKT от тайпклассов толку нету. Ну и синтаксически там пиздец тот еще.
Как узнать длину списка?
стандартные, которые String - односвязный список, Text - массив или односвязный список массивов (Lazy версия).
Эм, ну а на каком-нибудь пхп сколько вакансий того же уровня с теми же деньгами в неделю открывается? Три, четыре? Ну охуеть теперь.
Хах из твоего поста я только п. 1 понял, да могу первую часть tldr подтвердить. Но я из функиональщины только на схемке/common lisp'е да на эрланге писал, так что не избалован.
А что именно ты считаешь "приятными фишками"?
> А что именно ты считаешь "приятными фишками"?
К примеру в окамле нету нормального структурного равенства как в F#, там динамический хак как в скриптопараше, который просто падает в рантайме если ты сравниваешь то, что он сравнивать не умеет. В эмелях кроме F# обычно нету "монадного" синтаксиса, хотя для окамла написано несколько макрокостылей для этого и т.д.
Ну и F# чуть ли не единственный эмель с нормальным рантаймом с смп.
А что с ним не так-то (с рантаймом)? Языку хуй знает сколько лет, почему там чего-то до сих пор не запилили?
другойанон
>Опчть же, на кложе и х-ле каждую неделю вакансиями в ленту спамят, я хуй знает с какой вы планет
Каждый раз когда такое вижу, вспоминаю историю про эйчарку которая хайрила скалистов: скалы у них вообще не было, но логика была такая что знает скалу => умный => надо брать.
>>869103
Сорян, просто если вбить в гугл "ocaml option" первой ссылкой вылетает дока extlib.
Нашёл core ( https://ocaml.janestreet.com/ocaml-core/109.12.00/doc/core/Option.html ), ну ок:
option.filter(_.age > 16).map(_.vk)
vs
option |> Option.filter (fun o -> o#age > 16) |> Option.map (fun o -> o#vk)
/0
Всё очень плохо.
Scala:
sealed trait Option[+T]
case class Some[T](value: T) extends Option[T]
case object None extends Option[Nothing]
OCaml:
type 'a Option = Some 'a | None
Это хорошая и правильная логика. Если такие вакансии считать, то приплюсовывай еще половину джавистов, ага.
Но я говорю про другое. Подпишись на планету кложи или хаскеля, на фанкшнлджобс. Там нормальные люди, никаких эйчарок.
>>869390
Ну, и что? Ты же один и тот же код два раза написал. Тебе синтаксис не нравится, или что? Деьсктй сад, ей-богу.
Какая те нахуй разница, додик? Ты пишешь прикладной код, а не либы.
Лучше чтобы код либ было писать сложней, а прикладной проще, чем наоборот,
потому что либы пишутся один раз, а потом юзаются в 100500 прикладных приложений.
> Тебе синтаксис не нравится, или что?
У нас дискусия о моём утверждении, что если в окамл добавить имплиситы, то получится скала с плохим синтаксисом.
Это хуевая логика и путь к хуевым работодателям. Собственно, это зонтичное определение функциональных ваканский.
_ means that we don't care what we'll draw from the list anyway so instead of writing a variable name that we'll never use, we just write _. This function replaces every element of a list with 1 and then sums that up. This means that the resulting sum will be the length of our list.
Не очень понял, _ это как ', то есть просто всратый символ, которые не используется в самом языке, так что можно использовать в переменных? Я могу назвать функцию _?
Или нет, это особенный символ?
Скала, сделанная под влиянием верблюжатины без имплиситов и скобочек превратится в верблюжатину с чудовищным адт, без кошерных модулей и тд, никак не наоборот.
>>869404
Да ладно, обосрался 2 раза, подумаешь. Не гори так.
>>869403
Только вот этот самый ум со знаниями фп ничем не помогут когда посадят ковырятся в легасиговне со стёком наследование в 2 тыщи классов.
Лол, ебать ты дурачок.
>>869406
Почему хуевая? Не понимаю. Вот например тебя на собеседовании просят решать олимпиадные задачки не потому, что ты будешь решать на работе олимпиадные задачки, а потому что хотят удостовериться, что ты норм.
Или ты говоришь о том, что они в вакансии пишут, что ищут лид-девелопера на скала-проект, а потом оказывается, что тебе придетсч писать сайтики на пхп? Ну так это просто вранье, фп тут не при делах.
>>869410
Бог дал тебе репл и хагс, но нет, не хочу взять и попробовать, хочу идти на мейлрач и спрашивать у анонов.
Кому-то помогут, кому-то не помогут. Не вижу проблемы в том, что работодатель хочет более умного и трендового девелопера.
Мы из Грозного, скажи "скала круто".
Тебе палили уже годноту https://functionaljobs.com
>ДС
Как-то пол года назад в девзене помогали хайрить куда-то в дс хаскеллиста, причём сделали это крайне торжественно — видимо крайне редкое явление. Вот и считай сколько у нас тут таких вакансий.
>>869420
Перефразирую: смысл искать человека со знанием технологии, которую вы один хуй никогда юзать не будете? Просто повыпендриваться перед заказчиками?
>Почему хуевая? Не понимаю. Вот например тебя на собеседовании просят решать олимпиадные задачки не потому, что ты будешь решать на работе олимпиадные задачки, а потому что хотят удостовериться, что ты норм.
Это тоже хуевая логика. Наберут аутистов, а потом ебутся с оверинжинирингом.
Как бы не было забавно, но оверинжиниринг — прерогатива в первую очередь именно ООП-макакенов.
Я же вроде объяснил, не? Работодатель считает, что Существует корреляция между знанием технологии и сообразительностью. Вот и выбирают людей со знанием технологии. (Плюс это модно и иногда позволяет поднять энтузиазм работника.)
>>869439
Лучше оверинжиниринг, чем говномакакинг!
Правильно, лучше сразу искать умных девелоперов и писать нормальный код, а не ооп макак.
> Скала, сделанная под влиянием верблюжатины без имплиситов и скобочек превратится в верблюжатину с чудовищным адт, без кошерных модулей и тд, никак не наоборот.
В скале всё это модульное петушение есть и сделано логичнее безо всяких лишних синтетических абстракций: ты просто можешь в любом скоупе сделать 'import luboyObjekt._'
Подписан на такое (автопоиск):
"https://hh.ru/search/vacancy?text=(f#+or+ocaml+or+sml+or+haskell+or+lisp+or+clojure)+and+(not+diasoft)&area=1"
Сейчас есть 19 вакансий в ДС, из которых 5 относительно интересные. Скалу в поиск не включил потому что там штук 50 вакансий.
Раз в месяц появляется что-нибудь новенькое.
Ну все-таки в основном это из оперы "будет плюсом знание одного из следующих языков". Но вакансии интересные действительно есть, да, хоть и для сеньоров все.
А джуниорам надо просто искать стартапы через знакомых и делать хуяк-хуяк-и-в-продакшен, как мне кажется.
Triggered. Если выбрать устновку, то шде-то на шестом-седьмом пакаджде выдезет ошибка, и ты соснёшь хуйца. Такая вот охуенная стандартная либа. Ладно бы про batteries сказал, они, конечно, говно, но хотя бы устанавливаются.
Это особенный символ для паттерн-матчинга. По сути-то, обычная переменная, только потом использовать нельзя (в некоторых языках можно, потому что создателям было лень делать отдельный кейс для неё).
Ебало завали, пидор, блеать.
хачкел (и его друзья) немного меняют стиль программирования на других языках, учить стоит хотя бы один реально фп-язык
Я поражаюсь почему на бордах до сих пор не додумались выделить отдельную категорию ЯП, ориентированных на метапрограммирование.
Forth/Factor, Lisp/Scheme/Racket/Clojure, Rebol, TCL - это всё языки из одной семейки.
В плане ФП лиспы то же самое, что и сишарпы, джавы, жс, пхп и тд.
Да нихуя они не меняют. Ну, понимаешь мап и фильтр, и сосёшь хуй, потому что в твоём языке их нет/тормозят/мусорят. Потом понимаешь, что foreach это тот же мап, только вручную, и продолжаешь писать, как писал. Ещё проникаешься алгебраическими типами и паттерн-матчингом, и продолжаешь писать классы с говном, потому что в твоём языке их нет, а запилить самому - будет хуже, чем без них. Ах, да, есть ещё Maybe, которая охуенна, но в твоём языке не поддерживается, и ну ты понел.
А, композиция функций ещё. Но тут несколько проблем сразу:
1. Так пишут только хаскилисты.
2. Хуёво отлаживать и читать.
3. В твоём языке не поддерживаются (они и в окамле с фешарпом не поддерживаются нормально, что уж про твоё говно говорить).
Спасибо Балмеру за это! А у меня все работает.
Последнее утверждение неверное. По-твоему фп - это типы и манатки? Или чистота? Ну-ну. Если ты форт и кложу пихаешь в одну группу, то ты просто ни на том, ни на другом ничего не писал, ну признайся честно, будь мужиком.
>Ах, да, есть ещё Maybe, которая охуенна, но в твоём языке не поддерживается, и ну ты понел.
Она есть даже в 8 жяве, хоть и кривая как обычно, лол. Что говорить о других языках.
>фешарп
Так это кусок ООП-нутого верблюдоговна, там это самое фп заканчивается на fold и map.
Кложа - это единственный лисп, в котором в плане ФП кроме лямбд, которые есть везде, есть ещё немного анальной дисциплины и стремления к иммутабельности.
Но это фигня по сравнению с тем, что он лисп с такими-то макросами. Суть в том, что "ФП=лямбды" - неинтересно, "ФП=лямбды+иммутабельность" - неинтересно,
"МЕТА=макросы" - интересно, "ФП=программирование на типах" - интересно.
> понимаешь мап и фильтр, и сосёшь хуй, потому что в твоём языке их нет/тормозят/мусорят
Ты ебанутый? Это бля стандарт, это везде есть и везде используют.
Мапают в сишарп, мапают в пхп, мапают в жс, мапают в джаве8+.
На чём ты пишешь, что тя в языке мап и фильтр "нет/тормозят/мусорят"?
Ну так вот я и не согласен с тем, что фп=лямбды плюс иммутабельность - неинтересно.
Кстати, каждый год среди кложе-комьюнити проводятся опросы, и там один из пунктов - что для вас наиболее важно и полезно в кложе. Так вот, на первом месте там всегда была та самая иммутабельность и ориеннтированность на данные. А макросы - это скорее приятное дополнение, чем главная фича.
Главная фича кложи - это то, что она data-oriented. Парадигма у нее своя, она располагает к определенному стилю проектирования. И именно поэтому она фп и интересна, а не из-за макросов или чего-то еще. Вот х-ль - язык про типы, раст - про защищенный секс с байтами, а кложа - про данные. И все, кто ее реально испольщуют в продакшене, в один голос об этом и говорят. Так что у тебя акценты расставлены немного, как бы сказать, ну как у человека без опыта работы с тем, о чем ты судишь, как мне кажется.
Я согласен, что фп - очень размытое и довольно субъективное и интуитивное понятие, но у той же кложи с х-лем общего гораздо больше, чем с фактором, например. Про форт я уж и вовсе молчу, гхм.
Короче, надеюсь у меня получилось объяснить, что я имел в виду.
Привыкаешь со временем. Потом действительно понимаешь, что все эти мап фильтры по сути глорифаед for loop. Писать конечно больше приходится, но щито поделать. Зато идиоматичненько, да.
> Потом действительно понимаешь, что все эти мап фильтры по сути глорифаед for loop
Да это и так очевидно. Но обычные мапы и фильтры - это самый энтрилевел.
Интересно что гобляди будут делать когда им понадобится что-то вроде
https://github.com/developit/asyncro
Начнут стандартный аутотренинг что нинужна и пишите всё руками, как обычно.
>>870251
>фп - очень размытое и довольно субъективное и интуитивное понятие
Так если посмотреть на парадигмы программирования то конкретно сказать "что же это именно такое" можно только про процедурщину.
>секс с байтами, а кложа - про данные
Внезапно вообще всё на компутере - ни что иное как "секс с байтами". Даже в суперабстрагированной легко выпотрошить кишки вроде NPE.
>Парадигма у нее своя, она располагает к определенному стилю проектирования. И именно поэтому она фп и интересна, а не из-за макросов или чего-то еще.
Вот именно что у неё своя парадигма, зачем мешать её с фп? Это что-то из разряда рассуждений мешающих все неимперативные языки в одну кашу и называя это дело "ФП" с интонацией "нинужное говно". Мне вот например странна сама мысль что функциональный язык может не обладать кошерной системой типов.
Ну я бы делал примерно так. Я собственно так и делаю обычно. Мне тоже очень нравятся async\await и вообще направление в котором движется js, но это совершенно не имеет никакого отношения к теме маппинга. В смысле тоже самое можно провернуть используя forEach. И нет совершенно нкиакой разницы между 'энтрилевел' маппингом и твоим примером, в разрере самой концепции map\reduce\filter.
Про парадигмы согласен, угу.
Про секс с байтами - ну ты же понял, что я имел в виду, ну чо ты, ну.
Мешают ее с фп затем, что ее парадигма входит в фп. Как бы первый функциональный язык был динамически типизированным, ты разве забыл? А то, что некоторые под "фп" начали последнее время подразумевать "мл-лайк\хль-инспайред" - слушай, ну так это уж их личные проблемы, объективных оснований для этого тащем-та нет, согласись.
Ладно, очевидная AkkaHTTP очевидна
То что ты сделал - это аналог serial или parallel?
Если я понял синтаксис то нет.
Первое это t.
Второе это функция (лямбда) которая принимает ноль аргументов и возвращает t. Т.е
t != (->t), но
t == (-> t)()
И в чем разница?
Какие еще скобочки? Вот смотри, пусть у нас есть одноаргументная функция ф. Тогда (ф 1) должно прикарривать аргумент к функции. То есть получается, что (ф 1) возвращает нуль-арную функцию, раз у нас карринг есть. Но на деле-то оно возвращает значение. Значит значение и нуль-арная функция - одно и то же?
Или нет? Покажи пример, когда это не так и мы можем телл тхе дифференс. Я не могу придумать.
legpol 0 x = 1;
legpol 1 x = x;
legpol n x = (2n-1)/nx legpol x (n-1) -(n-1)/nlegpol x (n-2);
Это рекурсивное вычисление полиномов Лежандра. А вот это никак не работает как первую строку не еби
legpol :: (Int n, Float x)=>n->x->a;
legpol 0 x = 1;
legpol 1 x = x;
legpol n x = (2n-1)/nx legpol x (n-1) -(n-1)/nlegpol x (n-2);
Что с первой строкой сделать, чтоб первая переменная была инт, вторая флоат а функция дабл?
Как же блядь оно меня за-е-ба-ло!
Зря я сказал про ноль аргументов. Ладно, давай вот на окамле посмотрим пример (в хаскеле и подобных ЯП то же самое в принципе).
let g = fun () -> 2;;
g = 2;; выдаст ошибку - разные типы, сравнить нельзя.
g () = 2;; вернет true
Что такое эта ебучая пустая скобка ()? Это элемент типа unit.
Вообще, мое понимание сейчас что в окамле, в хаскеле и подобных ЯП не бывает функций с 0 аргументами.
То есть любая функция всегда принимает по крайней мере этот самый юнит.
Теорию множеств проходил в вузе/школе?
Если интересно то почитай у Lawvere, книга которая conceptual mathematics в начале. Могу своими словами попробовать.
Вот у тебя множество A = {a,b,c}.
И есть множество U = {u}.
Давай смотреть на функции из U в A. Сколько их всего? Столько же сколько элементов в A. Первая (назовем ее f) отображает u в a, вторая отображает u в b...
То есть f(u)=a. Но при этом разумеется f и a это не одно и то же. f это функция из U в A. a это элемент A.
Если типы тупо рассмотривать как множества, то тип unit в окамле - это и есть множество U.
Как и у множества U, у него единственный представитель, называется ().
g из примера выше это функция которая переводит () в 2.
Чтобы получить 2 из g надо скормить ей ().
Возвращаясь к твоему примеру, (->t) на окамле бы записалось как fun ()->t.
Даешь (), получаешь t. По крайней мере как-то так это надо воспринимать математически, как там это реализовано я хз.
Зависит от языка.
В чистом — да, одно и то же.
Без чистоты — нет, это разные функции, потому что в нечистых языках n-арная функция — это (n+1)-арная чистая функция с неявным параметром глобального состояния и неявным возвращаемым полем измененного глобального состояния.
>legpol x (n-1)
>legpol x (n-2)
Ты вставляешь флоат в первый параметр функции легпол, а там должен быть инт. Почему ты это делаешь?
Бамп вопросу. Есть ли хоть один весомый аргумент в пользу учения этих языков? Смогу ли я писать на этом что-то сложнее калькулятора из командной строки?
>Смогу ли...
Ты - конечно нет.
>Есть ли весомый аргумент...
Если у тебя возник такой вопрос - проходи мимо.
А адекватные люди тут есть?
Ну, в вебдеве сейчас активно фп юзается. На той же кложе охуенно писать фронтенд (сейчас модно писать реактивный UI, reagent с frp тут заходит). Теоретически и бэкенд тоже, не пробовал (да и смысла особо не вижу, разве что если для расшаривания кода между бэком и фронтом).
Погугли проекты на кложе, скале, эрланге, окамле и даже х-ле — и сам реши. Всё зависит только от тебя.
> Есть ли смысл учить ваши хачкели для чего-либо кроме дрочинга математических задач и интеллектуальной мастурбации?
Нет
> Они применяются хоть где-либо за пределами курсов обучения?
Нет.
>На них реально писать реальные проекты?
Нет.
>>870707
> Есть ли хоть один весомый аргумент в пользу учения этих языков?
Нет.
> Смогу ли я писать на этом что-то сложнее калькулятора из командной строки?
Нет.
Хачкиль сделан для развлечения.
Ты же, блядь, пошутил сейчас, да?
с вводом и выводом у всех все заебись, у кого плохо с вводом и выводом? Как фп мешает вводу и выводу? Если ты про чистые языки то надо быть не долбоебом и въехать в монады. В не чистых динамических все с вводом и выводом ниебаца как круто.
В гугол я и сам умею. Там другая программа.
Короч похоже здесь только спорят "быть ФП или не быть".
Не, чувак, ты не про то вообще. Юнит - это обычное значение\тип. Очевидно, что функция из юнит (или любого другого типа) в а - это одноаргументная функция. Я про другое совсем.
>>870705
Спасибо. Мне нужно подумать.
Смотри, так. Ты говоришь, что это разные функции. Тогда какой у них тип в импюре языке с явным выписыванием состояния (ну то есть в пюре на самом деле, нутыпонел)?
(-> t) ==> World -> World, t
t ==> World -> World, t
???
Я не понимаю, в чем разница, если и то, и другое считать функциями. Фишка же должна быть в том, что просто т гарантированно возвращает тот же самый ворлд, что взяла, а тханк т - может вернуть измененный ворлд. То есть в обычном хм это не закодировать типами? Или как это должно выглядеть?
И вообще, если у меня импюре язык с обычной системой типов и каррингом, то с точки зрения системы типов это будет одно и то же? Или нет? Если нет - к каким противоречиям это приведет, можешь пример показать? Помоги разобраться, будь няшка.
Ты ебанутый, не можешь сформулировать ни проблему, ни вопрос. Кусок кода, который ты привел и сказал работает, не работает, так как функция принимает первым аргументом порядок полинома, а вторым x, а в формуле передаешь х, а вторым аргументом - порядок. Тебе на это уже указали выше, но ты даже формулу не можешь правильно записать. И типы данных не понимаешь.
%Мимо-третий-день-в-Хаскеле%
>Тогда какой у них тип в импюре языке с явным выписыванием состояния
(-> t) :: World -> (World, Result)
t :: Result
t не принимает никаких параметров, вообще никаких. t можно называть и значением, и чистой nullary функцией — в денотационной семантике нам незачем различать "вычислияемые" и "заданные" значения.
>если у меня импюре язык с обычной системой типов и каррингом, то с точки зрения системы типов это будет одно и то же?
Да, одно и то же, ведь в системе типов языка без чистоты нет способа выразить разницу между ними.
я привык к определению "компонент = функция", так же я пишу и на react + redux; и reagent дает мне именно то, что мне нужно. Причем сам reagent крайне простой, re-frame еще проще. Om же, как я вижу по гхвики, говорит делать полноценные stateful компоненты, что мне не очень нравится.
дополнение
В общем, реагент выглядит более кложуришным, а на Om я вижу код, который как на js, только на clojure. Можно тогда уже и на js писать, че уж там.
> ориентированность на данные
> кложа про данные
Объясните плез, что вы под этим понимаете, что чуть ни на уровень своей особой парадигмы тянет?
Чем кложура более ориентирована на данные, чем какой-нибудь js?
Может есть примеры кода где-то на гитхабе как это примерно выглядит?
Прост я сюда писал заёбанным и обосрался, да. Стал менять местами первый и второй аргумент и не поменяв до концы сбросил. Вот что я имел в виду. Спасибо, что помог. Теперь всё работает.
В свете того, что корни у них общие, и литералов столько же (и даже для объектов есть литералы) - ничем.
Слушай, у тебя первый и второй абзац друг другу противоречат, разве нет? В первом ты говоришь, что это разные вещи точнее говоришь, что одинаковые, но тип-то пишешь разный!, во втором - что одинаковые.
Если у нас т:резалт получается после переписывания всей программы с явным использованием Ворлд, то мы же этот ворлд на таком т теряем, нет? То есть получается, что у тебя тогда в правилах нужно явно различать и писать разные кейсы для значений и для функций (и тогда получается, что значение - это не нуллари функция). Да, кстати: я же под т и (-> т) подразумевал типы, а под ==> - пасс компилятора, в котором мы преобразуем программу в аналогичную, но с явным протаскиваниес Ворлд, если грубо говорить.
> ...без чистоты нет способа выразить разницу между ними
Разве? Так ведь если у нас нечистый язык, то как раз путем разделения т и (->т) мы эту разницу и выражаем! Первое без эффектов, второе с эффектами. Я не понял, что ты здесь имел в виду. Я-то спрашивал о таком случае, что мы вот говорим: "ок, пусть это будут разные вещи" (или наоборот, одинаковые), а потом берем какую-то разумную программу, и она не типизируется так, как должна, из-за того, что мы сказали, что это разные вещи. Вот, я пример такой программы просил привести, если можешь.
Если что, меня это интересует именно с точки зрения возможных преобразований, ну и разных вариантов реализации этой идеи. Ну давай для конкретики возьмем хаскель, например. В нем все функции - одноаргументные, при карринге после присобачивания последнего аргумента мы получаем значение: (Х -> У) х => у:У. При этом это "значение" на самом деле под капотом является неэвалюированным тханком - но это деталь реализации (рантайма), система типов ничего об этом не знает.
Теперь давай придумаем хаскель-штрих, в котором эти тханки вынесены из рантайма в систему типов. Теперь у нас есть еще и нулларные функции: (Х -> У) х => (-> У) => у:У. То есть применение последнего аргумента все еще возвращает функцию, ну а потом она уже как-то там вычисляется в обычное значение.
Вопрос: поломается у нас все от такого? Что нужно изменить в обычном хаскеле, чтобы превратить его в хаскель-штрих? Можно ли пойти дальше и сделать хаскель-два-штриха, в котором уже вообще не будет обычных значений, а только нуллари ф-ии?
Слушай, у тебя первый и второй абзац друг другу противоречат, разве нет? В первом ты говоришь, что это разные вещи точнее говоришь, что одинаковые, но тип-то пишешь разный!, во втором - что одинаковые.
Если у нас т:резалт получается после переписывания всей программы с явным использованием Ворлд, то мы же этот ворлд на таком т теряем, нет? То есть получается, что у тебя тогда в правилах нужно явно различать и писать разные кейсы для значений и для функций (и тогда получается, что значение - это не нуллари функция). Да, кстати: я же под т и (-> т) подразумевал типы, а под ==> - пасс компилятора, в котором мы преобразуем программу в аналогичную, но с явным протаскиваниес Ворлд, если грубо говорить.
> ...без чистоты нет способа выразить разницу между ними
Разве? Так ведь если у нас нечистый язык, то как раз путем разделения т и (->т) мы эту разницу и выражаем! Первое без эффектов, второе с эффектами. Я не понял, что ты здесь имел в виду. Я-то спрашивал о таком случае, что мы вот говорим: "ок, пусть это будут разные вещи" (или наоборот, одинаковые), а потом берем какую-то разумную программу, и она не типизируется так, как должна, из-за того, что мы сказали, что это разные вещи. Вот, я пример такой программы просил привести, если можешь.
Если что, меня это интересует именно с точки зрения возможных преобразований, ну и разных вариантов реализации этой идеи. Ну давай для конкретики возьмем хаскель, например. В нем все функции - одноаргументные, при карринге после присобачивания последнего аргумента мы получаем значение: (Х -> У) х => у:У. При этом это "значение" на самом деле под капотом является неэвалюированным тханком - но это деталь реализации (рантайма), система типов ничего об этом не знает.
Теперь давай придумаем хаскель-штрих, в котором эти тханки вынесены из рантайма в систему типов. Теперь у нас есть еще и нулларные функции: (Х -> У) х => (-> У) => у:У. То есть применение последнего аргумента все еще возвращает функцию, ну а потом она уже как-то там вычисляется в обычное значение.
Вопрос: поломается у нас все от такого? Что нужно изменить в обычном хаскеле, чтобы превратить его в хаскель-штрих? Можно ли пойти дальше и сделать хаскель-два-штриха, в котором уже вообще не будет обычных значений, а только нуллари ф-ии?
Чувак, ты на просто ом смотрел наверное, там есть локал-стейт у компонентов, как в реакте, да. Это не значит, что он полноценный стейт предлагает в компонентах хранить, кстати, это именно про локальный для компонентов стейт, а не апп стейт: https://github.com/omcljs/om/wiki/Conceptual-overview#components
Я же про ом.некст говорю. Посмотри вот эту презенташку, чтобы был контекст, откуда и зачем это все: https://youtu.be/-jwQ3sGoiXg
И загугли youtube david nolan om next, там есть несколько презенташек, где он подробно объясняет, что, как, зачем, чем это отличается от предыдущей версии ом и какие пробдемы оно решает лучше, чем все существующие решения.
>>871142
Чуууваааак, лол, как бы ом пишет тот же человек, который пишет кложурскрипт. Мне кажется, он должен быть в курсе, как делать более кложуришные вещи, лол.
Корни у них не общие (ну, если ты только не имеешь в виду лисп Маккарти, лол).
Литералов у них не столько же, хоть бы доки прочитал для начала.
Ну и это все не имеет отношения к вопросу того анона как бы, лол.
>>871328
В жс иммутабельности по умолчанию нет, так что он по определению не может быть дата-ориентед. Там переменные и объекты, это противоположность кложурному подходу. Если коротко, то идея в том, что стейт не размазан по всему коду, а хранится отдельно и централизованно, и изменяется в строго ограниченных местах, плюс шейп данных выступает в качестве контракта. То есть в джаве или даже х-ле контрактом обычно является тип, да? Это круто, но работает только в рамках одной программы. А если нам нужно соединить несколько программ, то что у нас выступает в качестве контракта? Описание данных! Рест-хуест, какой ендпоинт, какие поля в жсоне, в каком порядке байты идут, что в качестве разделителя используется и т.п. То есть это более универсальный контракт но его сложновато статически чекать, увы. Вот, и тут идея в том, что между частями программы - хоть функциями, хоть модулями - контракт состоит тоже в данных, а не в типах, описывающих поведение. То есть данные > поведения.
Как-то так. Вообще, это сложно объяснить, потому что это такой очень размытый концепт - это же вопрос стиля проектирования, то есть что-то интуитивное, а не формальное. Нужно полгодика повариться в этом, чтобы врубиться, как мне кажется. Но если по пунктам, то - на мой личный взгляд - получается так:
- иммутабельность
- централизованное хранение данных
- лучше иметь сто функций на один тип данных, чем десять функций на десять типов данных
- шейп данных - это контракт, это межмодульный интерфейс
> шейп данных - это контракт, это межмодульный интерфейс
Это называется duck typing, есть во всех динамически-типизированных языках и некоторых статически типизированных.
Нет, это не дак тайпинг. Либо я плохо объяснил, либо ты плохо прочитал. Вместо дак тайпинга в кложе протоколы. https://en.m.wikipedia.org/wiki/Duck_typing#Protocols_and_Interfaces
Дак тайпинг - про поведение. Крякает как утка, плавает как утка - значит утка и есть. А я говорил про данные. There is no duck.
Более того, дак тайпинг - это про рантаймовые чеки, а шейп данных может чекаться и статически, и динамически (см. typed clojure), суть от этого не поменяется.
Теперь понял?
Мне сложновато понять, потому что у меня в жс неясно чем одно от другого отличается.
Вот это дак тайпинг:
const f = (duck) => duck.quack();
А вот это шейп данных:
const f = (point) => console.log(point.x, point.y);
Правильно?
Блин, дак тайпинг - это средство полиморфизма. Я понимаю, что в жс пихаешь в хэшмап функции и получается поведение, так что это как будто одно и то же, но это все-таки разное. Блин, мне теперь уже самому интересно сформулировать так, чтоб было понятно, сейчас попробую.
Вот смотри, надо тебе сделать утку, которая может квакать свое имя, да? В жс ты пишешь конструктор дак(нейм), например, сохраняешь имя, потом пихаешь в прототип Квак() и там квакаешь, верно? У тебя объект, мутабельный объект, ты ему присваиваешь значения в this, функции в него пихаешь, это объект. В клж тоже так можно сделать, но никто так не делает. В клж ты бы написал "конструктор" (если захотел бы, конечно) так:
(defn duck [name] {:duck/name name})
Видишь, это обычная функция, которая возвращает обычный иммутабельный хэшмап, который никак не связан с этой функцией. Нет никаких this, мы просто возвращаем кусок данных. Потом пишем другую функцию, квак, - и вот здесь становится очень похоже на дак тайпинг: она принимает любой хэшмап, в котором есть ключ :duck/name, и что-то там с ним делает. Но! Во-первых, она не метод у объекта дергает, эта функция. Нет никаких объектов и методов, она просто перемалывает данные, как если бы у тебя функции по хттп-рест протоколу общались. Она не может ничего со своим аргументом сделать, ей не приходит "ссылка" на него, ей приходит просто кусок данных, на основе которого она возвращает новые данные.
Во-вторых, вот представь, что у нас в системе есть человек-паук и человек-утка. И есть две подсистемы, написанные другими людьми, одна из которых работает с людьми, а другая - с животными. И нам надо человека-утку прогнать по обоим системам. Тогда мы создаем такой хэшмап:
(defn duckman [animal-name real-name] {:duck/name animal-name, :person/name real-name})
- и отдаем его подсистемам. То есть смотри, если бы у нас были объекты с дактайпингом, то нам пришлось бы, например, создавать композитный объект, включающий два объекта с одинаковыми методами, да? Потому что у нас бы метод нейм объекта дак был бы привязан к объекту дак, а метод нейм объекта пёрсун был бы привязан к объекту персун, да? А здесь у нас нет никакой вот этой связи, у нас тупо данные: хэшмап, в котором кейворды в ключах и строки в значениях. И совершенро пофиг, откуда и как они в нашей мапе появились и кому они "принадлежат" - это тупо данные, они никому не принадлежат, они просто лежат и все.
Вот, надеюсь, удачный пример получился. Можешь еще посмотреть на хттп-стек кложурный - там в общем-то та же идея. Есть куча разных серверов и провайдеров. В джаве, например, они все должны были бы реализовывать какие-то стандартные интерфейсы, чтобы можно было один на другой заменить, да? А здесь просто есть единая спека, которая оговаривает, какие данные должны лежать в реквесте и какие данные должны приниматься в качестве респонса - и вот это и есть интерфейс, который реализуют все кложурные хттп-серверы. Или, например, есть куча тулз для шаблонизации или генерации разметки. И все они работают с одной и той же структурой данных: [:html [:h1 "saussi hooee"] ...] - видишь, это даже не хэшмап, это дерево из векторов. Ну ты же не назовешь это "дактайпингом", согласись?
Короче, блядь. Надо блог начать писать, а то это пиздец какой-то, столько букв на мейлруче нахуяривать.
Блин, дак тайпинг - это средство полиморфизма. Я понимаю, что в жс пихаешь в хэшмап функции и получается поведение, так что это как будто одно и то же, но это все-таки разное. Блин, мне теперь уже самому интересно сформулировать так, чтоб было понятно, сейчас попробую.
Вот смотри, надо тебе сделать утку, которая может квакать свое имя, да? В жс ты пишешь конструктор дак(нейм), например, сохраняешь имя, потом пихаешь в прототип Квак() и там квакаешь, верно? У тебя объект, мутабельный объект, ты ему присваиваешь значения в this, функции в него пихаешь, это объект. В клж тоже так можно сделать, но никто так не делает. В клж ты бы написал "конструктор" (если захотел бы, конечно) так:
(defn duck [name] {:duck/name name})
Видишь, это обычная функция, которая возвращает обычный иммутабельный хэшмап, который никак не связан с этой функцией. Нет никаких this, мы просто возвращаем кусок данных. Потом пишем другую функцию, квак, - и вот здесь становится очень похоже на дак тайпинг: она принимает любой хэшмап, в котором есть ключ :duck/name, и что-то там с ним делает. Но! Во-первых, она не метод у объекта дергает, эта функция. Нет никаких объектов и методов, она просто перемалывает данные, как если бы у тебя функции по хттп-рест протоколу общались. Она не может ничего со своим аргументом сделать, ей не приходит "ссылка" на него, ей приходит просто кусок данных, на основе которого она возвращает новые данные.
Во-вторых, вот представь, что у нас в системе есть человек-паук и человек-утка. И есть две подсистемы, написанные другими людьми, одна из которых работает с людьми, а другая - с животными. И нам надо человека-утку прогнать по обоим системам. Тогда мы создаем такой хэшмап:
(defn duckman [animal-name real-name] {:duck/name animal-name, :person/name real-name})
- и отдаем его подсистемам. То есть смотри, если бы у нас были объекты с дактайпингом, то нам пришлось бы, например, создавать композитный объект, включающий два объекта с одинаковыми методами, да? Потому что у нас бы метод нейм объекта дак был бы привязан к объекту дак, а метод нейм объекта пёрсун был бы привязан к объекту персун, да? А здесь у нас нет никакой вот этой связи, у нас тупо данные: хэшмап, в котором кейворды в ключах и строки в значениях. И совершенро пофиг, откуда и как они в нашей мапе появились и кому они "принадлежат" - это тупо данные, они никому не принадлежат, они просто лежат и все.
Вот, надеюсь, удачный пример получился. Можешь еще посмотреть на хттп-стек кложурный - там в общем-то та же идея. Есть куча разных серверов и провайдеров. В джаве, например, они все должны были бы реализовывать какие-то стандартные интерфейсы, чтобы можно было один на другой заменить, да? А здесь просто есть единая спека, которая оговаривает, какие данные должны лежать в реквесте и какие данные должны приниматься в качестве респонса - и вот это и есть интерфейс, который реализуют все кложурные хттп-серверы. Или, например, есть куча тулз для шаблонизации или генерации разметки. И все они работают с одной и той же структурой данных: [:html [:h1 "saussi hooee"] ...] - видишь, это даже не хэшмап, это дерево из векторов. Ну ты же не назовешь это "дактайпингом", согласись?
Короче, блядь. Надо блог начать писать, а то это пиздец какой-то, столько букв на мейлруче нахуяривать.
это все довольно круто, но ом все равно выглядит многословным и страшным.
Вот пример с видео на re-frame. Первый - более красивый вариант, второй - больше похож на то, что в видео.
Я конечно таки прочитаю про ом/некст, когда буду делать следующий проект
Не, ом - для HUUUGE проектов, он труднее и сложнее для изучения, тут даже говорить нечего, это факт. Но он и дает больше. Я не говорю, что реагент\рефрейм не очень, они тоже охуенные. Просто изначально же анон что-то спизданул про то, что х-ль круче кложи в плане реакта, а на самом деле ом.некст - это вообще самый блидин ейдж из всего, что сейчас есть в клиент-сайде, такие дела.
Ну это явно мимо меня, лол. Я пишу магазин, которому и реакт-то не нужен в принципе, мне просто делать нечего. А найти работу на кложе в своем РБ мне не светит никогда.
а так я пока смогу использовать clojure лишь в фриланс-проектах, ибо заказчику в принципе похер, что там под капотом (этот магазин - тоже фриланс проект).
немного знаю parsec.
Ну зато смотри, если набьешь опыта с омом - можешь смело вписывать в резюме REACT FLUX RELAY FALCOR GRAPHQL INSERTАNOTHERBUZZWORDHERE, лол.
> :duck/name
> :person/name
В кложуре так реально делают, или ты для примера придумал?
В жс можно выдумать себе конвенцию: все поля и методы префиксируем названием класса.
тогда будет
var Duck = function (name) { this.duck_name = name; }
Duck.prototype = { duck_quack: function () {...} }
var Man = function (name) { this.man_name = name; }
Man.prototype = { man_introduce: function () {...} }
и потом сделать function mix(obj1, obj2), которая смешивает поля двух объектов, и смешивает прототипы двух объектов, и устанавливает новому объекту прототипом полученную смесь. Понятно, что смесь прототипов можно кешировать потому что каждый вызов mix для объектов одних и тех же классов будет использовать одинаковый гибридный прототип. Но на жс по дефолту такую конвенцию именования полей и методов никто не использует, потому сработает только в рамках своего мирка - в лучшем случае фреймворка и его экосистемы.
> В жс можно выдумать себе конвенцию
Ну как бы можно и срать, не снимая свитер, только так никто не делает, сам понимаешь. Алсо, мой поинт был не в том, что мы какие-то особые имена используем, а в том, что нет никакой утки - а у тебя даже со сраньем через свитер дак_нейм - это метод дака, угу?
В кложуре так реально делают, да, это официальный(тм) правильный(с) рекомендованный способ. Недавно выпустили (точнее скоро выпустят) такую штуку, как clojure spec, которая позволяет очень гибко описывать эту самую форму данных, о которой я говорю, и потом генерировать на ее основе документацию, рантаймовые контракты\ассерты, валидаторы, делать преобразования (типа парсинга строки с числом в инт), ну и самое главное - генерировать тесты на основе спецификации. Это довольно охуенно, если честно. Если бы я не использовал генеративное тестирование раньше, у меня бы голова взорвалась от охуения, лол.
Ну и там как бы с самого начала был удобный сахар для этого, типа если пишешь ::keyword, то это разворачивается в :my.ns/keyword, ну и подобные штуки. Плюс датомик тоже очень heavy использовал эту модель, а он пару лет назад появился. Ну, разумеется не надо каждый кейворд префиксировать неймспейсом, если у тебя по определению задачи не может быть пересечений и вообще нет разных энтитей, то нафига лишние буквы писать? В хттп стеке, например, без префиксов, просто :request-method, :uri и все такое прочее.
>В жс иммутабельности по умолчанию нет, так что он по определению не может быть дата-ориентед.
Очень странное утверждение.
Ээ... окей, держи нас в курсе? Я не знаю, что тут содержательного можно ответить - ты просто выразил очень туманное мнение, ничего не сказав по сути. Ты не стесняйся, говори, если что, гхм.
Ну ты бы мог развернуть свою мысль. Держу в курсе: я не понимаю как связаны датаориентируемость и иммутабельность.
Собственно туманное мнение и выражает это непонимание.
Ну, если нет иммутабельности, то нет данных. 1 - это число. Нельзя изменить 1, дазнт мейк сенс. Можно только взять другое число. Это данные. [1 2 3] - это данные. Нельзя изменить [1 2 3]. Можно взять другой вектор с другими числами, но нельзя изменить число или вектор чисел, дазнт мейк сенс. Это данные. {:name "rich"} - это данные. Нельзя изменить данные, можно только выкинуть одни данные и поставить на их место новые. Идентити, вот это все. Икс равно один. Потом икс равно два. Мы не меняли единицу, мы просто привязали имя к новому значению. Даннын иммутабельны.
Мейкс сенс?
В смысле, понятно что иммутабельность устраняет целый класс ошибок, но и без неё возможно писать датаориентированные программы.
Если в языке есть мутабельность, это не значит, что обязательно всё мутировать.
В реакте (с редуксом) вон всё построено на иммутабельных редюсерах и норм.
Ну так иммутабельное подмножество жс может быть дата-ориентед. Или жс, в котором по умолчанию используются иммутабельные структуры. Только это уже не то, что обычно подразумевают под словом "жс", угу? Алсо, не путай "можно не мутировать" и "нельзя мутировать". Это разные вещи, концептуально.
Короче, если еще остались какие-то непонятки - посмотри talk Рича, rich hickey value of values youtube. По-моему так называется, если не путаю. Да или любой другой посмотри, они все достойные и полезные, если у тебя есть пара-тройка лет экспириенса.
https://tezos.com/
https://github.com/tezos/tezos
ocaml, bitcoin, democracy, concatenative, formal verificafion
Да, потому что крайне удобно вертеть коллекциями и вообще любыми данными. Можешь выбрать из этих двух, да + F#, Scala ещё, вроде популярны в этих областях.
Неплохи, но специализированные ЯП вроде R и Octave - лучше, потому что они прямо заточены под это. Там и матрички удобно по всякому складывать и перемножать друг с другом, с векторами и скалярами, и куча всяких встроенных алгоритмов, численных и символьных методов.
1. Я правильно понимаю, что функции в ФП имеют только локальные переменные, это и есть основная суть?
2. В ФП внутри функций можно создавать функции, и будут ли внутренние функции строго локальными?
3. Если п1 верен, то получается что на многих языках можно свести все детали программы к функциям, так?
4. Могут ли функции открывать и менять внешние файлы, можно ли прописать в них такие инструкции, и как это соотносится с П.1?
Ну так раз ты решил осваивать хаскель, то возьми книжку про хаскель и прочитай ее, ээ? У тебя совсем детские вопросы, не вижу смысла отвечать, если честно. Возьми и прочитай книжку, если что по ходу дела непонятно будет - спрашивай тут.
Ну, разве что по четвертому пункту скажу. Если грубо, то твоя программа просто составляет рецепт: сходи туда-то, возьми такой-то файл, что-то с ним сделай, положи обратно. То есть она сама ничего не делает как бы, она просто составляет список указаний. А потом рантайм уже берет эти указания и что-то там делает с реальным миром. Поэтому твоя программа как бы не при делах, она остается чистой. Это один из подходов, есть и другие.
Но еще раз - возьми и прочитай книжку, не трать время попусту.
ФП хороши только для двух вещей, для веб-фронтэнда и пидорашенься деревьев (компиляторов, например). МЛ/ДЛ к этому не относятся вообще никак.
>Но еще раз - возьми и прочитай книжку, не трать время попусту.
Книжки это хорошо, тольку какую книжку-то? Эта http://anton-k.github.io/ru-haskell-book/book/home.html норм?Я с learnyouahaskell начал, поэтому и возникают вопросы весьма примтивные, сам не совсем понимаю что там происходит.
Тебе на русском то есть надо? Был же вроде перевод, который "изучай хаскель во имя добра", попробуй ее.
1. переменных нет, только переменные-термы. Суть - в бета-редукциях термов (т.е. подстановках).
2. что значит 'создавать функции'?
3. ничего не понятно.
4. как и обычно - функцция выводит информацию в файл.
1. Никаких переменных вообще не существует, забудь про них. Вся информацию в функциях хранится в аргументах, которые она передает другим функциям, в том числе и себе, иначе тут никак. Создается неплохая аналогия с засовыванием собственного члена себе же в анус.
2. Ничего не создается, там все "определяется", как в математике. Можешь внутри функций определять другие функции, и их имена будут доступны только в пределах определения этой функции. Чаще всего используются анонимные (задроты-математики называют их "лямбда") функции, когда определяешь и используешь функцию на месте, без имен.
3. Не верен. Не понятно, что ты имеешь в виду. Процедурные языки и так состоят из "функций" на своем понимании, главно является какая-нибудь main. Просто в императивных языках функция - это последовательность действий, а тут это имеет более математический смысл.
4. Не понял вопроса. Тут все является функцией, иначе и никак.
>>872319
Дочитывай learn you a haskell, потом можешь попробовать real world haskell, если решишь, что это тебе нужно. Хрюсских переводов опасайся: имел опыт наблюдать, как из переведенной версии какой-то книжки вырезали все задачи и кучу дополнительного материала.
По-моему LYaHfGG не очень хорошая книжка. Лучше читать Language Report и Real world haskell.
Там очень примитивно и дружелюбно азы рассказываются. Мне она помогла влиться в эту функциональную содомию, ибо все остальные книжки нихуя не понятны были. К тому же маленькая, как раз для введения и решения, нужно оно человеку или нет.
Просто ты сказал "не совсем понимаю, что там происходит", и ссылку на русский текст дал, вот я и подумал, то ты не понимаешь из-за того, что с английским не очень... нутыпонелкорочи.
>>872365
Человек только вкатывается в функциональное программирование вообще, а тв ему репорт советуешь читать. Не надо так.
Yup, сходу R вспоминается, там этого apply и вариаций lapply, sapply - жопой ешь.
Почему логичнее? Суть мапа же — отобразить одно множество в другое, используя данную функцию, а не применить функцию ко всем элементам множества.
отображение ващето
Ну, во-первых - именно что применить функцию ко всем элементам. Отобразить одно множество в другое, использую заданную функцию, - это ф(м).
Во-вторых, мап лифтит функцию в монаду же, а там уже никаких множеств и элементов нет, так что слово "мап" (или фмап) выглядит вообще не в тему.
Вот читаю я данные (продукции) из .txt вида
First -> one Foo
Foo -> bar one two
Идентификаторы сущностей (назовём их Symbol) для дальнейшей обработки мне не важны, но их нужно хранить для ввода/вывода.
Сами Symbol'ы будут двух видов (Term, NonTerm), при чтении вид определяется сразу (по кейсу первого символа идентификатора например).
Так вот, как хранить это всё? В императивщине я бы заносил идентификаторы в "словарик" и во внутреннем представлении заменял их на Int/Byte.
В Хаскеле аналогом наверное будет
data Symbol = Term Int | NonTerm Int
+ "словарик" Map.
Только похоже что если заменить Int на String то словарик не понадобиться, на сами алгоритмы обработки это не повлияет, только работать всё будет медленнее.
"->" в исходном .txt никакого отношение к синтаксису Хаскеля не имеет, если что.
Внутреннее представление для одной строки "First -> one Foo" будет что-то вроде
data Product = Product Symbol [Symbol]
Вопрос в том как правильнее хранить Symbol - как строку (+ конструктор над ней) или переводить в Int + словарик для ввода/вывода.
Или ещё что-то.
Я не понимаю, откуда ты инты взял? Если у тебя там любаы строка может быть - то это, очевидно, строка. Если у тебя там конечный фиксированный набор идентификаторов - то это Foo | Bar | Baz...
>как правильнее
Никак. Это зависит от того, что и в каком объеме ты будешь с этим говном делать. Простой ответ - сделай и так, и эдак, протестируй что тебе там надо. А в остальном коде поменьше используй внутренности этого типа, определи пару "комбинаторов" для простых операций, меньше потом переписывать придется (но все равно придется).
Он, по всей видимости, хочет занумеровать попадающиеся строки, хранить в Product только инты и спрашивает, будет ли так быстрее.
</телепат-моде>
Просто в той же сишечке перевод в Int был бы тупо необходим, ибо с строками многие операции выполнять было бы проблематично.
>>872800
На самом деле это https://en.wikipedia.org/wiki/Context-free_grammar
>>872802
Занумеровать попадающиеся слова.
Ну я тоже так подумал, но не увидел в этом смысла и решил, что причина в чем-то другом. Вообще, если у него файл меньше десяти гигов, то об оптимизации думать, наверное, не следует.
Там где тотальность (всюду определённость) и завершимость всех процедур/функций Тьюринг-полноты нет. А вам что - приспичило?
И какие операции ты можешь выполнить с инт, но не можешь выполнить с поинтером, а?
>>872812
А, ну так бы и сказал, что ключи у тебя могут повторяться - из твоего первого поста это никак не следует же. Тогда список пар из строки и списка строк, не?
Х-ль не требует тотальных функций, в идрис ты тоже вполне можешь пользоваться не тотальными функциями, так что в общем случае да. Про кук/агду не знаю ничего.
По-моему самые популярные языки тут - хаскель и кложур. Может добавить материалов по ним? Ну и на теорию ссылок накидать.
М.б. не так выразился. Мне интересно, сводимы ли системы типов, лежащие в основе таких языков (MLTT, CoC), к машине Тьюринга, т.е. можно ли реализовать их на машине Тьюринга?
https://www.youtube.com/watch?v=FTSAiF9AHN4
>И какие операции ты можешь выполнить с инт, но не можешь выполнить с поинтером, а?
Хм, и правда ведь. Впрочем массив уникальных строк и поинтеры в качестве ключа - это и будет словарик.
>>872817
>А, ну так бы и сказал, что ключи у тебя могут повторяться - из твоего первого поста
Не уверен что понимаю что ты подразумеваешь под "ключами".
Один и тот же <Symbol> (точнее в левой части может быть только подтип <NonTerm>) может стоять в левой части нескольких продукций, да.
А как бы их по-твоему написали, все эти агды и идрисы, если бы их было нельзя реализовать на машине Тьюринга? Ты что-то другое хочешь спросить или сильно тупишь.
Ты поаккуратнее с такими картинками. Не забывай, что харкач теперь принадлежит мейл ру. Забыл, что началось в ВК, когда тот перешел во власть этой фирмы? Тонкая подсказка: 282.
>Ты что-то другое хочешь спросить или сильно тупишь.
1) Вот это https://en.wikipedia.org/wiki/Intuitionistic_type_theory можно рассматривать как простой набор правил для машины Тьюринга?
2) Или наоборот, машина Тьюринга частный случай этого?
Или пункты 1 и 2 равнозначны?
Надо бы еще лиспопетушиных сепаратистов обратно аннексировать. А то хули, язык их на три порядка менее популярный, чем ниспосланный свыше божественный Хаскелл, а в свой отдельный тред укатились.
>ниспосланный свыше божественный Хаскелл
Который зашкварили любители мыслительного онанизма, засрав его тоннами бесполезных сущностей и тем самым отпугнув вменяемую часть сообщества.
Я с телефона, нормально оформить не смогу, извиняюсь.
>>872877
Ну все-таки коммон лисп и елисп к фп имеют весьма опосредованное отношение, а там обсуждают в основном их. Так что мне кажется, что все правильно: кложурь тут, коммон лисп там. Так удобнее.
>>872967
Не рад там только один шизик. Это ты, нет?
> Я с телефона, нормально оформить не смогу, извиняюсь.
Скинь все что у тебя есть, что можно добавить в шапку краткое описание, факью, ссылки и тп
А почему? На основе MLTT же есть языки с зависимыми типами - Agda там, вот это все.
Короче, надо добавить книжки, переведенные нашим русскоязычным фп-сообществом. Это sicp, tapl, введение в функциональное программирование. Еще надо добавить htdp в качестве лайтовой альтернативы сикпу. Еще dcpl для тех, кто интересуется теорией.
Дальше, неплохо было бы перечислить основные легендарные пейперы. Functional programming with bananas and lenses, On implementation of functional languages, On expressiveness and universality of fold... еще тот пейпер про тайпклассы, еще тот пейпер про fl Бэкуса. Why functional programming matters, Why concatenative programming matters. Я пишу по памяти, без ссылок и точных названий, извини. Если ты правда готов этим заняться, то придется загуглить пейпернейм пдф, все скачать, ввложить на ргхост какой-нибудь, а в шапке сделать раздел Пейперы - и там поставить ссылку на ргхост\гуглдиск и перечислить названия и авторов. Алсо, почти все пдфки от Вадлера можно туда запихнуть, имхо.
Вот, это в целом про парадигму и программирование. Дальше про языки. То есть разделы: книги про фп, пейперы, окамл, хаскель, кложур.
Про хаскель - 1. Ради добра 2. Риал-ворлд хаскель 3. Лангуаж репорт 4. За всеми остальными вопросами - хаскклвики и стаковерфлоу. Тут по-моему все согласны, да? Еще http://homepages.cwi.nl/~jve/HR/ для математиков и интересующихся.
Про окамл - блин, вот там сложнее искать литературу, и у меня были сохранены все книжки, но с собой их нет и ближайшее время не будет, блин. Короче, там тоже есть real world ocaml для практиков и какая-то книжка типа роад ту лоджик, матхс енд програминг, но у нее я название забыл. Есть еще practical ocaml, это скорее справочник, чем последовательное повествование. И есть несколько интродакшенов, я их не смотрел даже, может кто еще посоветует, какой лучше. Короче, основная книжка - риалворлд окамл. Да, и надо указать, что окамл без джецнстрит/коре или баттерис - не окамл. И еще надо написать, как дев енвайронмент развернуть, мерлины вот эти все, ой, пиздец короче. Хуй с ним, потом как-нибудь, главное - риал ворлд окамл и джейнстрит коре.
Кложур, ох, я писать уже устал, попозже постараюсь продолжить.
Короче, надо добавить книжки, переведенные нашим русскоязычным фп-сообществом. Это sicp, tapl, введение в функциональное программирование. Еще надо добавить htdp в качестве лайтовой альтернативы сикпу. Еще dcpl для тех, кто интересуется теорией.
Дальше, неплохо было бы перечислить основные легендарные пейперы. Functional programming with bananas and lenses, On implementation of functional languages, On expressiveness and universality of fold... еще тот пейпер про тайпклассы, еще тот пейпер про fl Бэкуса. Why functional programming matters, Why concatenative programming matters. Я пишу по памяти, без ссылок и точных названий, извини. Если ты правда готов этим заняться, то придется загуглить пейпернейм пдф, все скачать, ввложить на ргхост какой-нибудь, а в шапке сделать раздел Пейперы - и там поставить ссылку на ргхост\гуглдиск и перечислить названия и авторов. Алсо, почти все пдфки от Вадлера можно туда запихнуть, имхо.
Вот, это в целом про парадигму и программирование. Дальше про языки. То есть разделы: книги про фп, пейперы, окамл, хаскель, кложур.
Про хаскель - 1. Ради добра 2. Риал-ворлд хаскель 3. Лангуаж репорт 4. За всеми остальными вопросами - хаскклвики и стаковерфлоу. Тут по-моему все согласны, да? Еще http://homepages.cwi.nl/~jve/HR/ для математиков и интересующихся.
Про окамл - блин, вот там сложнее искать литературу, и у меня были сохранены все книжки, но с собой их нет и ближайшее время не будет, блин. Короче, там тоже есть real world ocaml для практиков и какая-то книжка типа роад ту лоджик, матхс енд програминг, но у нее я название забыл. Есть еще practical ocaml, это скорее справочник, чем последовательное повествование. И есть несколько интродакшенов, я их не смотрел даже, может кто еще посоветует, какой лучше. Короче, основная книжка - риалворлд окамл. Да, и надо указать, что окамл без джецнстрит/коре или баттерис - не окамл. И еще надо написать, как дев енвайронмент развернуть, мерлины вот эти все, ой, пиздец короче. Хуй с ним, потом как-нибудь, главное - риал ворлд окамл и джейнстрит коре.
Кложур, ох, я писать уже устал, попозже постараюсь продолжить.
>tapl
>sicp
>htdp
Толсто.
>Why functional programming matters
Читал. Было много факториалов и фибоначчей, а вот почему functional programming matters - это автор рассказать забыл.
>real world ocaml
That's a fucking joke.
>надо добавить книжки, переведенные нашим русскоязычным фп-сообществом.
Тебе сюда, пидорахен → >>872359
>Хрюсских переводов опасайся: имел опыт наблюдать, как из переведенной версии какой-то книжки вырезали все задачи и кучу дополнительного материала.
Я лично читаю книги на языке оригинала. Это раз.
Пидорахен - это ты. Ты хамло и быдло, неспособное в логику и понимание текста. Типичный пидорахен. Это два.
Если из одной книжки что-то там вырезали, то это не значит, что во всех переведенных книжках что-то вырезают. Ошибка. Это три.
Наконец, раз ты не в курсе, кто и как переводил эти книги и почему они местами даже лучше оригиналов, тебе следует либо заткнуться и учиться, либо проследовать в другой тред. Без обид.
Алсо, ты >>873046-анон?
Если рекомендовать tapl, тогда уж и Барендрегта нужно тоже.
И вот ещё, стоит ли рекомендовать "Параллельное и конкурентное программирование на языке Haskell"?
Поясните за монаду. Это класс типов или экземляр класса типов или тип данных или что?
Вот есть класс типов - объявленные функции без их реализации привязанной к конкретному типу данных (хотя да, можно определить реализацию функций по умолчанию). Если мы хотим, чтобы наш тип данных принадлежал к этому классу типов, мы для нашего типа должны реализовать все функции, объявленные в этом классе типов. Вроде я нигде не обосрался, ок. Есть класс типов Monad, в нем объявлены четыре функции, ок. Тогда, допустим, монада IO - это экземляр класса типов Monad для типа данных IO, то есть фактически реализация функций, объявленных в классе типов Monad для типа данных IO? Тогда что есть тип данных IO? И собственно где реализация этих функций класса типов Monad для типа данных IO?
Барендрега что? Про лямбда-исчисление? Она "введением в фп" Харриса не покрывается разве?
"Параллельное..." я не читал, если честно. Стоит или необязательно? Для новичков, наверное, это не очень нужно, а неновичок и сам найдет... но слышал много хороших отзывов о ней, так что почему бы и не добавить, угу. Баззворды к тому же.
>>873082
Ну так и нахера ты тогда спрашиваешь совета, если не способен его воспринять? Ты же понимаешь, что лично мне похуй, шапка тут или хуяпка, но если человек просит помощи, то мне совершенно несложно поделиться опытом. Так что ты уж определись, хочешь ты что-то полезное запилить или как малолетка какашками перекидываться.
Ой. Я того, дико извиняюсь, в глаза ебусь немного. Тыщу лет ванильного сосача не видел, вот и проебался. Сорри.
Монада - это моноид в категории эндофункторов, очевидно же!
Все правильно, да. Реализация - ну тип вот:
https://hackage.haskell.org/package/base-4.9.0.0/docs/src/GHC.Base.html#line-1093
- наслаждайся!
Ну потому что это разные вещи. Какой еще "набор правил для машины Тьюринга"? Есть тьюринг-полнота. Если какая-то система тьюринг-полна, то это не значит, что она является "набором правил для машины тьюринга". Это значит, что это другая система с той же выразительной силой. То есть для любой программы, которую можно написать на машине тьюринга, есть аналогичная программа в этой другой системе. В частности, обычный способ доказать, что твоя система тьюринг-полна - это написать на ней реализацию машины тьюринга. Но если твоя система тьюринг-полна, то ты сможешь написать в ней такую программу, которая никогда не завершится, и ты никак не узнаешь, зависла она или все еще что-то делает. То есть это как бы плохонько.
Агда и кок, насколько я знаю, не тьюринг полны - именно по этой причине. То есть там любая программа гарантированно завершается и не виснет, если она скомпилировалась. Это, разумеется, сознательный выбор, а не какая-то проблема или ограничение.
Ты это хотел спросить? Так понятно?
Поправьте это дерьмо кто-нибудь, плиз.
На скрине просто лигатуры, но это к вопросу не относится.
Я посмотрел исходники подсветки - там этого реально нету. Дело не в юникоде.
https://youtu.be/IOiZatlZtGU - еще вот этот talk надо обязательно добавить, сразу разъясняет новичкам что это, зачем это и почему это так, да и вообще расширяет сознание не хуже лсд. К тому же Вадлер - прекрасный лектор.
>Не рад там только один шизик.
Судя по переписке, вас там всего двое шизиков. Либо один шизик-семён.
Да не, там и вопросы иногда задают.
Добавь "Developing Applications With Objective Caml", стандарт описывается старый, но для ознакомления пойдет. Тем более, есть перевод на русский.
Ну и официальная документация.
http://caml.inria.fr/pub/docs/manual-ocaml/
>real world ocaml
Это скорее real world janestreet
> real world janestreet
Ну так риал ворлд окамл без риал ворлд джейнстрит невозможен, без риал ворлд джейн стрит окамл получается совсем не риалворлд. Так что все ок. К тому же "а где стдлиб?!" - самый частозадаваемый камловопрос.
Вот, уже нормально так книжек по камлу в целом получается, кстати.
>Ну так риал ворлд окамл без риал ворлд джейнстрит невозможен
Ты плохо знаешь "риал ворлд" окамля, janestreetовские библиотеки далеко не все намного меньше, чем может показаться используют
Как бы там Минский не петушился, но реал ворлд - это 90% десктопов на винде. У них же просто большая программа, под которую они могут покупать железо и подбирать систему. Это одна программа, для одной системы, заточенная под определённые условия. Пусть и огромная. Это не риал ворлд даже близко. Более того, сама книга должна была называться "смотрите, мы сделали ещё одну стдлибу, потому что нативная окамловская бесикалли нонэкзистент". Да и он сам же плакался, что даже на линуксах всё хуёво, например, с гуями, и они их вынуждены делать на ncurses.
Хуёво там всё. Нормальных объектов так и не завезли за всё это время. Методов нет, приватных полей нет, наследование через жопу и так далее. Настолько устаревшее говно ещё поискать.
Ну это неправда. Туда каждый релиз ghc завозят кучу всякой новой астральной хуйни - всё что угодно, только не записи/объекты. Уже вон скоро модуле/сигнатуры (Backpack) добавят, но только не объекты. Просто SPJ походу бесят записи и объекты в любом виде и он всеми силами подавляет это дело. А лично меня ещё больше чем отсутсвие нормальных записей/объектов бесит пиздец со строками. Когда в ёбаном скрипте на 50 строчек раз 20 конвертить между Text, ByteString.Strict, ByteString.Lazy, String.
Найс, порадовал зелёный. На всякий случай, если ты не толстишь, и действительно глуп, хачкель и создаёт новые тенденции, которые
> раз в три года
перенимают всякие кресты, расты и жабы
>Если какая-то система тьюринг-полна, то это не значит, что она является "набором правил для машины тьюринга". Это значит, что это другая система с той же выразительной силой.
Разве то, что система тьюринг-полна не означает, что эту систему можно построить в виде соответствующей ей машины Тьюринга, задав соответствующие правила? Мне вот этот момент непонятен.
>То есть для любой программы, которую можно написать на машине тьюринга, есть аналогичная программа в этой другой системе.
Даже из такого твоего определения прямо следует, что система равна по возможностям машине Тьюринга, если на ней можно сделать то же, что и собственно на машине Тьюринга. Разве нет?
>Агда и кок, насколько я знаю, не тьюринг полны - именно по этой причине. То есть там любая программа гарантированно завершается и не виснет, если она скомпилировалась.
Т.е. такие языки можно реализовать на машине Тьюринга?
В 2010 году вышел последний стандарт языка. Все новые фичи добавляются в качестве расширений компиляторов, и уж потом, через несколько лет, если они докажут свою полезность и незаменимость, их добавляют в стандарт - обязательный минимум, который должен реализовать компилятор, чтобы называться компилятором хаскеля.
А последний релиз основного уомпилятора, гхц, состоялся в мае этого года. И да, действительно: хаскель - де-факто стандартный современный язык ученых\логиков\математиков, которые занимаются языками программирования. Так что да, хаскель во многом и создает новые тенденции. Впрочем, кложурь и даже раст тоже в какой-то мере могут этим похвастаться - правда, на более прикладном уровне.
> система равна по возможностям... если на ней можно сделать то же (самое)
Привет, КО! Тебе это утверждение не кажется тавтологичным?
> такие языки можно реализовать
НУ ТАК ЕСЛИ ИХ КОМПАЙЛЕРЫ НА КОМПЬЮТЕРЕ НАПИСАЛИ И СДЕЛАЛИ И ОНИ РАБОТАЮТ ТО САМ ТО ТЫ КАК ДУМАЕШЬ А?!!!!!12111? Тебе ведь еще несколькими постами выше ответили на этот вопрос.
Там пишут, что идрис и агда тьюринг-полные!
>>873479
Но выше предыдущий оратор >>873045 пишет, что MLTT нельзя свести к правилам для машины Тьюринга. Таки ведь можно же, раз эта ебулда на камплюктере работает, в виде той же агды или кука (хотя там и СоС, но в целом сорта же).
>Привет, КО! Тебе это утверждение не кажется тавтологичным?
Мне вполне очевидно, что это одно и то же. Однако, тот кому я отвечаю, так не думает.
Ты бы хоть прочитал ответ-то по этой своей. Там пишут, что Идрис тьюринг-комплит (про идрис итт никто не говорил), а петух - нет. Читай внимательнее.
>>873485
Ты мне отвечаешь, але. И я тебе как бы намекаю, что ты сказал "масло масляное, если оно масляное". И теперь ты мне говоришь, что я так не думаю. Чего вообще блядь?!
В >>872845-посте ты спросил фигню, вот тебе и ответили на ту фигню, которую ты спросил, а не на то, что ты хотел спросить. Является ли itt набором правил для мт? Ээ, нет, не является. Является ли табуретка диваном из-за того, что на них обоих можно сидеть, а еще можно разобрать диван и сделать из него табуретку? Выше тебе это уже объяснили и очень подробно. Давай, не ленись и прочитай ответы внимательно.
>Является ли itt набором правил для мт? Ээ, нет, не является.
Но сводима же к таким правилам при желании? Выразима же в виде набора правил для машины Тьюринга? Я об этом. А то что это разные вещи, я понимаю.
Так тебе ведь уже три раза сказали, что да, выразима, на машине тьюринга можно написать программу, которая принимает на вход программу на петухе и выполняет ее. Если бы этого нельзя было сделать, то у нас и петуха не было бы, и агды, и всего остального, а оно у нас есть, да?
А, кстати: >>873390 - вот, про тьюринг-полноту ты тут все перепутал, потому что не прочитал внимательно пост, на который отвечал (прочитай). Если что-то можно реализовать на мт, то это что-то от этого не становится тьюринг-полным, ээ. На мт можно реализовать программу, которая всегда возвращает 1. По-твоему получается, что из-за этого любая система, которая берет на вход что угодно и возвращает 1 тьюринг-полна. Очевидная ошибка, не? А вот если ты на своей системе можешь написать реализацию мт, то она тьюринг-полна. Ок?
>По-твоему получается, что из-за этого любая система, которая берет на вход что угодно и возвращает 1 тьюринг-полна. Очевидная ошибка, не?
По-моему получается, что такая программа есть частный случай машины Тьюринга, т.к. реализуема на ней в виде набора правил. То, что такая программа не тьюринг-полна, это я понял, ок.
>Так тебе ведь уже три раза сказали, что да, выразима, на машине тьюринга можно написать программу, которая принимает на вход программу на петухе и выполняет ее. Если бы этого нельзя было сделать, то у нас и петуха не было бы, и агды, и всего остального, а оно у нас есть, да?
Т.е. тут имеем случай, аналогичный предыдущему в этом посте - на машине Тьюринга реализуется нечто, не являющееся тьюринг-полным, но зато являющееся реализуемым на машине Тьюринга. В данном случае это что-то - MLTT. Так? Меня вот этот >>873045 пост смутил, я его понял как утверждение о невозможности свести MLTT к набору правил для машины Тьюринга.
>такая программа есть частный случай машины Тьюринга
Есть машина Тьюринга - это некий закодированный по определённым правилам алгоритм, который что-то делает. Например, записывает на ленту (возвращает) единицу и останавливается. А есть универсальная машина Тьюринга - это тоже алгоритм, но сам он лишь принимает описание других машин Тьюринга и выполняет их. Можешь считать её мт высшего порядка. Так вот, Тьюринг-полнота - оно про последнее.
> Тыщу лет ванильного сосача не видел
Через апи капчуешь? Алсо можно в шапку эту https://habrahabr.ru/post/142351/ статью дабавить как введение в фп
Главный хаскельный компилятор/интерпретатор хорошо документирован. Думаю, стоит добавить
https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/index.html
Меня напрягла одна функция:
select :: [Integer] -> [(Integer, [Integer])]
select [] = []
select (x:xs) = (x,xs) : [ (y,x:ys) | (y,ys) <- select xs]
select [1..3] даёт [(1,[2,3]),(2,[1,3]),(3,[1,2])]
Я понимаю, что первый элемент будет (1, [2, 3]), далее будет
(2,[1, 3]), но никак не могу понять, откуда в (3,[1,2]) появилась двойка. Когда пытался расписать рекурсию на листике, получилось (y, ys) = (3, []), откуда следует, что
третий элемент - (3, [1]).
Объясните вообщем
Ты же икс еще присобачиваешь к игрексам внутри компрехеншена. На втором вызове селекта этим иксом и будет твоя потерявшаяся двойка.
Не забывай, что селект возвращает список. Посмотри внимательно, что селект вернет для 2,3.
Ты не даун, я минут пять втыкал в этот код, лол. А разгадка одна: я пытался ее понять методом пристального взгляда, а потом сдался и просто мысленно протрейсил выполнение. Эх, а вот звали бы меня Саймоном, я бы мог просто посмотреть и осознать, как она работает.
Саймон Питон-Джонес, кавалер ордена английской королевы и автор хацкеля.
>>873057
tapl
ru: http://rgho.st/79l9wvVcQ
en: http://rgho.st/8tSBffPsH
sicp
ru: http://rgho.st/8MgrHrCcc
en: http://web.mit.edu/alexmv/6.037/sicp.pdf
Введение в функциональное программирование: http://rgho.st/7mf8HCkmx
Real World Haskell
en: http://book.realworldhaskell.org/
Learn You a Haskell for Great Good:
ru: http://rgho.st/8sLlHXn6G
en: http://rgho.st/6QLkJb5jT http://learnyouahaskell.com/
Clojure Programming
en: http://rgho.st/7wGxqJj54
The Joy of Clojure
en: http://rgho.st/6dyRBG9rg
Книги
tapl
ru: http://rgho.st/79l9wvVcQ
en: http://rgho.st/8tSBffPsH
sicp
ru: http://rgho.st/8MgrHrCcc
en: http://web.mit.edu/alexmv/6.037/sicp.pdf
Введение в функциональное программирование
ru: http://rgho.st/7mf8HCkmx
Haskell
Библиотеки https://hackage.haskell.org/
Вики https://wiki.haskell.org/Haskell
Книги
Real World Haskell
en: http://book.realworldhaskell.org/
Learn You a Haskell for Great Good
ru: http://rgho.st/8sLlHXn6G
en: http://learnyouahaskell.com/ http://rgho.st/6QLkJb5jT
Учебник по Haskell
ru: https://anton-k.github.io/ru-haskell-book/book/home.html
Clojure
О Clojure: https://www.ibm.com/developerworks/ru/library/os-eclipse-clojure/index.html
Книги
Clojure Programming
en: http://rgho.st/7wGxqJj54
The Joy of Clojure
en: http://rgho.st/6dyRBG9rg
Пойдет?
Книги
tapl
ru: http://rgho.st/79l9wvVcQ
en: http://rgho.st/8tSBffPsH
sicp
ru: http://rgho.st/8MgrHrCcc
en: http://web.mit.edu/alexmv/6.037/sicp.pdf
Введение в функциональное программирование
ru: http://rgho.st/7mf8HCkmx
Haskell
Библиотеки https://hackage.haskell.org/
Вики https://wiki.haskell.org/Haskell
Книги
Real World Haskell
en: http://book.realworldhaskell.org/
Learn You a Haskell for Great Good
ru: http://rgho.st/8sLlHXn6G
en: http://learnyouahaskell.com/ http://rgho.st/6QLkJb5jT
Учебник по Haskell
ru: https://anton-k.github.io/ru-haskell-book/book/home.html
Clojure
О Clojure: https://www.ibm.com/developerworks/ru/library/os-eclipse-clojure/index.html
Книги
Clojure Programming
en: http://rgho.st/7wGxqJj54
The Joy of Clojure
en: http://rgho.st/6dyRBG9rg
Пойдет?
Слишком мало пустых строк, добавь еще. Это сарказм, если че. И где Alejandro Serrano Mena Beginning Haskell: A Project-Based Approach? Уже есть переовод в электронной версии
> Слишком мало пустых строк, добавь еще. Это сарказм, если че
Нибейте Я просто полусонный все это собирал, вот и получилось коряво.
> И где Alejandro Serrano Mena Beginning Haskell: A Project-Based Approach? Уже есть переовод в электронной версии
У меня кстати он есть, потом залью
>>875315
> динамикодрисню
> Haskell
Real World OCaml
en: http://rgho.st/6gCfxmLyy
Это все что я нашел по этому языку
Кстати Haskell ради добра оказался только фрагментом, а не полной книгой Сори
> lejandro Serrano Mena Beginning Haskell
http://rgho.st/8pG4TYdnp
Перевода пока не нашел
>>875573
> Haskell ради добра
ru: http://rgho.st/6NzMmnvDS
Даже половины >>873057-поста нет, зато хуева куча отступов. Не, брат, не пойдет. Да хотя похуй, перекатывай уже с любой, просто добавь тот пост на гистгитхаб, например.
Алсо, уберите статью с айбмэм про кложурь, там говно.
http://clojure.org/
http://clojurescript.org/
http://www.learn-clojure.com/
http://www.braveclojure.com/
https://youtube.com/user/ClojureTV
https://clojuregazette.com/
Книги
Types and Programming Languages ru: http://rgho.st/79l9wvVcQ en: http://rgho.st/8tSBffPsH
Structure and Interpretation of Computer Programs ru: http://rgho.st/8MgrHrCcc en: http://web.mit.edu/alexmv/6.037/sicp.pdf
Introduction to Functional Programming ru: http://rgho.st/7mf8HCkmx
Haskell
Библиотеки https://hackage.haskell.org/
Вики https://wiki.haskell.org/Haskell
Документация https://www.haskell.org/documentation
Книги
Real World Haskell en: http://book.realworldhaskell.org/
Learn You a Haskell for Great Good ru: http://rgho.st/6NzMmnvDS en: http://learnyouahaskell.com/ http://rgho.st/6QLkJb5jT
Учебник по Haskell https://anton-k.github.io/ru-haskell-book/book/home.html
Beginning Haskell en: http://rgho.st/8pG4TYdnp
Clojure
О Clojure
http://clojure.org/
http://clojurescript.org/
http://www.learn-clojure.com/
http://www.braveclojure.com/
https://youtube.com/user/ClojureTV
https://clojuregazette.com/
Книги
Clojure Programming http://rgho.st/7wGxqJj54
The Joy of Clojure http://rgho.st/6dyRBG9rg
OCaml
Документация
http://caml.inria.fr/pub/docs/manual-ocaml/
https://ocaml.org/docs/
Книги
Real World OCaml en: http://rgho.st/6gCfxmLyy
Архив тредов
1. https://arhivach.org/thread/214184/
А так норм?
Книги
Types and Programming Languages ru: http://rgho.st/79l9wvVcQ en: http://rgho.st/8tSBffPsH
Structure and Interpretation of Computer Programs ru: http://rgho.st/8MgrHrCcc en: http://web.mit.edu/alexmv/6.037/sicp.pdf
Introduction to Functional Programming ru: http://rgho.st/7mf8HCkmx
Haskell
Библиотеки https://hackage.haskell.org/
Вики https://wiki.haskell.org/Haskell
Документация https://www.haskell.org/documentation
Книги
Real World Haskell en: http://book.realworldhaskell.org/
Learn You a Haskell for Great Good ru: http://rgho.st/6NzMmnvDS en: http://learnyouahaskell.com/ http://rgho.st/6QLkJb5jT
Учебник по Haskell https://anton-k.github.io/ru-haskell-book/book/home.html
Beginning Haskell en: http://rgho.st/8pG4TYdnp
Clojure
О Clojure
http://clojure.org/
http://clojurescript.org/
http://www.learn-clojure.com/
http://www.braveclojure.com/
https://youtube.com/user/ClojureTV
https://clojuregazette.com/
Книги
Clojure Programming http://rgho.st/7wGxqJj54
The Joy of Clojure http://rgho.st/6dyRBG9rg
OCaml
Документация
http://caml.inria.fr/pub/docs/manual-ocaml/
https://ocaml.org/docs/
Книги
Real World OCaml en: http://rgho.st/6gCfxmLyy
Архив тредов
1. https://arhivach.org/thread/214184/
А так норм?
Это копия, сохраненная 23 ноября 2016 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.