Так если хошь писать максимально близко к предметной области, то ООП тебе в руки. ФП декомпозицая только для решения математических задач пригодна, за их пределами придется подстраивать как и к машкоду.
>>807273 Ты наверное сможешь юзать какие-то бычные функциональные языки, но зависимые типы это редкая фича, ее даже в хачкеле не было (по крайней мере до недавнего времни) Наблюдается в основном в пруф ассистантах. Не будет ничего на планшетик в готовом виде, думаю
Никаких контрольных структур не существует, if и все циклы это ебаные функции. Доступ к элементу массива это функция с параметром. Арифметические операции это функции. Даже присвоение и получение значения это фунции.
Сейчас функциональные фичи в каждый язык пихают, нет смысла, нечем выёбываться в зк. Даже на хачкеле каждое второе быдло писало. Давайте уже хотя бы Idris или Curry.
>>804682 (OP) Борщаны! Помогите написать напишите мне короткую прогу/функцию/функтор/монаду на Хоскилле, которая будет выводить/возвращать в stdout «Мамку твою ипал! Азаза», но чтобы код был лаконичен и из него нельзя было сразу угадать вывод. Хочу напечатать на футболке.
>>822335 >В чем фишка скалы? Scala формально поддерживает кучу ёб, но на практике это отсутсвие сколько-либо вменяемого вывода типов (даже линзы толком сделать нельзя), тормоза, костыли на костылях (тайпклассы через имплициты, фьюжен через views), отсутсвие ссылчной прозрачности, тяжелое наследине jvm, тормозной компилятор с невменяемыми сообщениями об ошибках, протекающие абстракции. В итоге вроде всё есть, но всё сделано очень хуёво.
>>822475 Динамикодрисня. Ну и утилитаристкий подход Рича, когда сломанные абстракции, вроде трансдюсеров, добивают костылями, лишь бы хоть как-то сделать быстрые композиции комбинаторов коллекций.
Но некоторые её стороны: простота, минимализм, гибкость, открытость - хорошо подходят для определённых предметных областей, когда тебе нужна не надёжность, а хуяк-хуяк и в продакшн.
Ананоны, вот возник вопрос. Как известно большинство современных функциональных языков программирования выстроены на основе лямбда-исчислений, которые были созданы для решения проблем вычислимости. А вот интересно, есть ли ЯП, пусть даже эзотерические, которые содержат в качестве основы другой подход к проблеме вычислимости, а именно ЧРФ?
>>822762 Что-то не видно в нём не ПРФ, не ЧРФ. Лямбда-исчисления же проглядывают, правда неклюже. Я вообще не уверен есть ли языки основанные на ЧРФ именно в их матиматическом понимании. Может свой написать?
λ-исчисление может рассматриваться как семейство прототипных языков программирования. Их основная особенность состоит в том, что они являются языками высших порядков. Тем самым обеспечивается систематический подход к исследованию операторов, аргументами которых могут быть другие операторы, а значением также может быть оператор. Языки в этом семействе являются функциональными, поскольку они основаны на представлении о функции или операторе, включая функциональную аппликацию и функциональную абстракцию. λ-исчисление реализовано Джоном Маккарти в языке Лисп. Вначале реализация идеи λ-исчисления была весьма громоздкой. Но по мере развития Лисп-технологии (прошедшей этап аппаратной реализации в виде Лисп-машины) идеи получили ясную и четкую реализацию.
Анон, поясните почему ФП не вкатилось в гей-мдев, ведь ААА игры по любому должны проседать в плане параллелизма, а сейчас всяких игрушек овердохуя, да и меньше их становиться не будет + активно развивается VR.
>>823072 Не, в ААА нужны всякие байтоёбские оптимизации, потому что там задача не просто работать с графикой, а работать с графикой в условиях ограниченного времени/ресурсов.
С парализацией там проблем особо нет, всё делает GPU которая итак дохуя параллельна, но только на векторных операциях. Основной затык там скорее в передаче данных у CPU, memory и GPU. Да и к тому же ФП как бы подразумевает мусоросборник, а игры на таких платформах выглядят как майнкрафт ещё и лагать умудряются.
>>823100 >в ААА нужны всякие байтоёбские оптимизации Для которых прекрасно подходит Idris. Просто почитай диссер Edwin Brady: https://eb.host.cs.st-andrews.ac.uk/writings/thesis.pdf Там тебе и стрим фьюжн, и какава с чаем. Просто пиши игры на идрис, а компилятор тебе сам все соптимизирует.
>>823833 я не просто так сказал, что мне нужен jvm, у меня основной проект на java вертится, и в рамках эксперимента я хочу один из новых модулей написать на clojure. я немного гуглил как организовывать интероп между ждава кодом и кложа кодом, всё выглядит довольно просто.
а с коммон лиспом как мне это сделать?
типичная реакция быдло-школьника, иди выёбывайся в свой двор
>>823648 Заебешься писать на AST Без документации ъуй разберешь что функиция принимает, что возвращает, где разворачивается макрос, а где выполняется функция и все вот такое.
>>824756 Тип-обертка f с парой функций: bind, return. Первая позволяет применить к f a функцию, которая принимает a и возвращает f b, вторая из a делает f a.
>>824756 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.
Функционалобоги, хочу осовить Haskell на практической задаче. Необходимо описать некий примитив - отрезок в двумерном пространстве. Характеризуется начальными и конечными координатами. А также вектором смещений и вектором напряжений. При этом могут быть определны либо оба вектора либо только один из них. При этом каждый вектор может быть определен как проекция на глобальную систему координат, либо как проекция на локальную систему координат (где центр системы совпадает с центром отрезка, ось y - нормаль к отрезку). Вроде-бы должно быть изящное и лаконичное описание, но вот сижу и туплю и даже не знаю с какой стороны подходить. Halp, короче.
>>804682 (OP) Аноны, поясните в чем суть ФП? Вот щас читаю гайд по хаскелу - и тот же блять питон, только синтаксис уебищней. Дошел только до tuple. Хочу задачку какую-нибудь решить, на ум приходит только клиент серверное приложение. Хотелось бы что-нибудь охуенное сделать
>>822748 Ты долбоеб что ли? Частично рекурсивные функции работают только с натуральными числами. Ты готов все данные представлять в виде натуральных чисел? Лол. Вот дебилы, блядь.
Ну вас всех нахуй. Один Михаил лучше, чем 100 таких, как вы.
>>834901 Лисп-ок, из ML семейста лучше Хачкиль всё-таки, но и Фшарп пойдёт. Поиграйся с обоими. Но Лисп не полностью функциональный и проще для новичка, тем более ЖСера.
>>830917 >Частично рекурсивные функции работают только с натуральными числами. С любым сочетанием букв, знаков и символов любого конечного алфавита/алфавитов. Натуральные числа - только один из примеров.
>>822748 >А вот интересно, есть ли ЯП, пусть даже эзотерические, которые содержат в качестве основы другой подход к проблеме вычислимости, а именно ЧРФ? ЧРФ и лямбда-исчисление это немного разные подходы к одному и тому же. Любой язык с зависимыми типами - это язык с ЧРФ, а одновременно и машина Тьюринга и каноническая система Поста и алгорифмы Маркова.
Ну охуеть, ocamlfind исчез. Позавчера ещё билдил с ним, а сегодня not found. Опам говорит, что он есть, шелл не согласен. После opam reinstall (попутно снеся половину либ) всё ещё not found. И что мне теперь с этим делать?
>>835098 Это не для людей было сделано. Окамл - это тот случай, когда совсем без тулинга было бы лучше, чем с ним. Сирисли, даже в крестах не так всё плохо.
Привет! Готовлюсь тут к экзамену по функциональному программированию и помимо прочего застряла на таком задание... Haskell->Lambda Calculus. На самом деле оно лёгкое, но вот момент, что у меня "\x y" меня смущает, не знаю как это разруливается. Была б одна вариабла, всё окей. Может кто-то может пример ради разложить мне всё по полочкам? Спасибо! Прилагаю фотки правил преобразования и задания!
>>839697 Ну, не-таких-как-все не может же быть миллионы, по определению. А ты в серьёз думаешь, что употребление этой дебильной фразы, несёт какой то смысл и не помножает на 0 твой бред выше?
Обрати внимание - я мимо проходил и видел только 3 последних коммента. Особенное внимание обратил на твой интеллектуальный высер, о чём с радостью и поспешил отписаться
>>839104 >и подходит практически для всего и почти везде сосёт не разгибаясь, кроме браузера, там пока тупо нет альтернатив, хотя нормальные люди пишут на каком нибудь ClojureScript'е, ScalaJS, чтоб избежать жс-петушения >дико популярен То, что много идиотов используют идиотские языки, говорит лишь о том, что идиотов много.
>>839902 Вот мне интересно в чем заключется петушение? Я не из того хомячка которое кричит что ЖС можно везде использовать, можно да, но не нужно. Даже платы ардуино с ЖС есть, но согласен что это крайность. Вот только в чем петушение использовать инструмент по назначению?
>>835031 >>835031 Собственно, ты это просто разные подходы к формализации понятия вычислимости. Тюринг-машини используют для исследования и доказательств свойств императивных ЯП, а лямбда-исчисление — для функциональных. Можно и наоборот, но будет очень геморойно.
>>840030 Так в его формализации даже определения композиции нет. Вообще проводить формализацию через теорию множеств было очень глупо.
Окружающий мир - мир процессов, а не мир объектов, и для его адекватного описания нужен язык процессов. "Динамическое" видение мира требует отличный от теоретико-множественного архетип мышления. Если в теории множеств конструкция отображения, или функции, является не первичной и вспомогательной по отношению к самим множествам, то в теории категорий преобразования объектов (объекты – аналоги множеств, преобразования – аналоги отображений) входят в аксиоматическое определение категории наравне с объектами.
Более того, объекты оказываются частным, предельным случаем преобразований. Таким образом, при категорно-функторном описании систем акцент переносится с "застывших", "мертвых" состояний объектов на различные формы их движений и преобразований. Предметом исследования становятся не столько состояния систем, сколько совокупности способов их преобразований (вспомним, что постоянное обновление, смена, преобразование составляющего субстрата – это существеннейшие черты практически всех естественных и антропных систем). Две особенности теоретико-категорного описания систем позволяют думать, что язык теории категорий более адекватен миру, нежели язык теории множеств. Первая особенность – возможность оперировать сразу всей совокупностью одинаково структурированных множеств, что позволяет отождествить эту совокупность с пространством всех возможных состояний системы. Вторая особенность – та, что в категорию наряду со структурированными объектами равноправно и обязательно входят все допустимые их структурой способы изменения объектов, т.е. преобразования состояний системы. Это позволяет заменить теоретико-множественное идеализированное представление мира в виде "застывших" объектов на адекватное миру представление его процессами. Теоретико-категорный язык богаче языка теории множеств. Для одного и того же набора множеств – объектов категории – может существовать много различающихся наборов морфизмов, т.е. преобразований этих множеств. Но категории c одинаковыми объектами, но различающимися морфизмами – это различные категории: неразличимые как множества объекты в них– это различные по возможностям преобразований объекты.
>Learning functional programming is like starting from scratch Ок, нашёл этот ваш scratch - https://scratch.mit.edu/ Это и есть ваше функциональное программирование? Пиздец, ну и говно.
>>843912 Нинужно. Работает как приманка для людей определённого склада ума, но они потом либо всю жизнь будут писать всякое нинужное говно на хаскеле, либо сьебутся из кодинга, поняв, что это нинужно, а всё нужное им неинтересно. То есть толку ваще никакого, просто нереально жесткие проёбы времени и разбитые судьбы.
>>843993 в чем по твоему суть функционального программирования, что ты так смело заверяешь что оно не нужно? На том же хаскеле можно делать те же самые ебаные сайты, декларативная парадигма компактее и быстрее в обучении чем любой объектный фреймворк.
>>845847 сам не понимаю, хуйня какая-то. Я думаю из-за того что в головах людей популярен миф о том что декларативная парадигма это сложно, сам можешь проверить, найди того кто говорит что это сложно и спроси, пробовал ли он? Скорее всего нет.
>>845847 Есть же куча очевидных причин: 1. Легаси. Как идейное, так и техническое. Пишем на машкодах — пишем на ассемблере — пишем на сишке — пишем на жабе. Каждый шаг вносит простое, понятное и легкоинтегрируемое изменение. Пишем на жабе — пишем на хаскелле — глубокая смена парадигрмы и жесткая порнуха с FFI. 2. Малое распространение. Если языка нет на рынке — его не учат. Nuff said. 3. Другое мышление. Большинство языков являются "инженерными". Тип — это область в памяти, используемая определенным образом, значение — набор байтов в этой области. Даже в высокоуровневом языке типы проще всего воспринимать именно так. Функциональщина же в лице цацкеллей требует понимать, что монада — не массив, а функтор, а функтор как объект может и не существовать. Это ломает мозг.
Так что никакого противоречия между эффективностью/компактностью/надежностью функциональщины и ее малой распространенностью нет, есть лишь сложившееся положение вещей.
>>846657 Мне кажется, что наслаивание функциональщины на традиционные языки лишь мешает развитию чистой функциональщины. "Зачем переходить на цацкель, если в жабе уже есть лямбды?" — разумный вопрос прагматичного программиста. А понять всю мощь и пользу хорошей системы типов ему не удастся, пока он не изучит систему типов, которую он изучать не станет, ведь в жабе уже есть лямбды.
Я думаю, функциональщина проникнет в мейнстрим совсем с другой стороны. Недавно я открыл для себя PureScript. В отличие от бесполезного(для меня) цацкеля, PS позволяет создавать реакт-приложения даже удобнее, чем JS. При этом все приложение можно записывать единым кодом: разметка — на PS, методы — на PS, стили — на PS, небо, аллах — все на PS. С обычным же веб-приложением приходится обмазываться синтаксисом CSS, JS, JSX, HTML и еще хуй знает чего. В такой ситуации может получиться, что новички, глядя на единообразие и целостность нового подхода, просто поленятся учить десяток взаимозависимых технологий и предпочтут освоить одну всеобъемлющую.
>>846666 Загляни в этот тред: http://2ch.hk/pr/res/697835.html Я не настолько крут в математике, чтобы давать советы. Мне и самому во многом не хватает знаний и интуиции.
>>847271 >сделайте фибоначей для отрицательных чисел >поинтегрируйте тут немного методом трапеций >прошла лишь половина первого модуля Ага, просто охуеть можно, какой годный курс.
>>847268 Спасибо за ссылку, начал смотреть. Ну содержательно пока ничего не было, просто синтаксис в основном. Впрочем, уже представляю каково будет какого-нибудь питонщика или перловика на это переучивать. int_of_float, string_of_bool, лал. Ну это ладно, может и правильно так (хотя сомневаюсь, неужели нельзя было например string_of_float и string_of_int сделать одной полиморфной функцией). Но вот отмазка что отсутствие неявной конвертации int/float якобы делает возможным вывод типов и вообще "это фича" кажется странной. В хаскеле и вывод типов и (3.14 + 3) нормально посчитается. Сами же говорят, даже в сраном си это есть. А как же "наименьшее удивление"? Если позиционировать верблюда как более простую альтернативу хаскелю то вот это будет явно отталкивать аудиторию. Арифметические операторы с точкой на конце это тоже кек. Если такие пуритане, почему один и тот же оператор сравнения можно применять к разным типам? В плюс можно сказать что код красиво выглядит (посмотрел пару проектов на гитхабе), кажется что освовшись с языком можно его очень легко читать. Минимум закорючек и иероглифов.
Haskell Web Scripting 2016Аноним!!a7u.XEsVf628/09/16 Срд 03:03:52#186№847936
В о б щ е м захотелось написать скрипт для репостинга треков на soundcloud по ссылкам, постимым двачирами в одном треде в /mus/. Решил посмотреть чё там у хаскилитов в плане бытового скриптинга, как оно щас: такой же ебучий случай как раньше, или полехче. Получилось такое: 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.
>>847922 >string_of_float и string_of_int Тут вопрос, скорее, почему это нельзя было сделать в соответствующих модулях. String.of_float, String.to_float етц. А вообще, флоат и инт по-разному выглядят в битах, поэтому одной функцией тут нельзя. Разве только для сахару, но это почти бессмысленно. >почему один и тот же оператор сравнения можно применять к разным типам Потому что оператор сравнения - это хак, лол. >(3.14 + 3) >Арифметические операторы с точкой То ли не осилили, то ли раньше это было нельзя, а теперь совместимость не даёт - хрен его знает. >код красиво выглядит Ага. Только нельзя форвард-референсить модули (функции и типы можно, если объявить через and, а для модулей не завезли), поэтому файлы по 6к+ строк кода тут нормальное явление.
>>847939 > вообще, флоат и инт по-разному выглядят в битах, поэтому одной функцией тут нельзя Что-то мешает делать 2 побитовые проверки? Built-in впилить в крайнем случае, или в окамле не принято? > Потому что оператор сравнения - это хак, лол. Почему? Ну в смысле наверное оно не реализовано на самом окамле, ты об этом? > нельзя форвард-референсить модули Я правильно понял что это относится к ситуации когда у тебя несколько модулей в одном файле, то есть чтобы использовать модуль ты должен определять его где-то выше по коду?
>>847936 Случайно наебнул старый гист, перезалито с квазикокококами: https://gist.github.com/aemxdp/f92edd57a7db979529a4d56f3d766220 Окамлодаунов вообще не слушайте. Хаскель хоть и неюзабельное говно для поехавших, но окамл ЕЩЁ хуже и неюзабельнее. И что самое смешное - что в нём ещё и нету ничего принципиально нового по сравнению с любым обоссаным скриптом из близжайшей помойки.
>>847936 >>848096 Haskell - язык для вдумчивого top-down проектирования и неспешной тырпрайз-разработки. Чтобы по-быстрому хуярить есть жс и пайтон для быдла и кложа для людей.
>>848193 > вдумчивого top-down проектирования Нужно только для средств разработки. > тырпрайз Ненужно. Заменяется микросервисами, каждый из которых - скрипт, написанный за пару дней. > кложа для людей Лиспы для аутистов, которые стремятся к однообразию и конформизму ради конформизма даже в синтаксисе. Причём чаще всего эти люди и макросы-то писать толком не умеют, и на лиспе пишут как на питоне или жс тока со скобками и без либ. Это люди с переразвитым прикладным мышлением, и недоразвитым абстрактным. И сам Рич Хики - ярчайший пример этого типажа. Короче нахуй, это задроторабы, противоположность элите. Это как раз те люди, которых можно целиком заменить роботами, и которые сами же их и построят.
что именно не надо слушать? каким образом ты сравниваешь ЯП и какой-то абстрактный скрипт, и на каком языке этот скрипт написан (польский? фарси? клингонский? турбопаскаль)? чем тебя не устраивает обычный вводный курс в фп, почему тебе зудит что он на окамле? чего ты вообще такой дерганый-то, сосачер что ли?
>>848204 > и какой-то абстрактный скрипт, и на каком языке этот скрипт написан Вот ещё пример убогого аутиста, который даже не смог сообразить, что в том контексте "скрипт" = "скриптовый язык". > что именно не надо слушать? Похуй что, я думаешь читать стану ваши простыни про говно верблюда и фильтровать, что "слушать" а что нет? > чем тебя не устраивает обычный вводный курс в фп, почему тебе зудит что он на окамле? Да похуй, я просто на всякий случай написал, что окамл ещё хуже хаскеля и не заслуживает внимания. Я не вникаю чё вы там пишете, пропаганду этой хуйни или обсуждение курсов. Что касается последних, ни разу не видел курса, который не был бы проёбом времени по сравнению с 'почитать самому' или 'разобраться на ходу'.
>>848202 >Ненужно. Заменяется микросервисами Нет конечно, как ты это себе представляешь? Там тонны интегрирующихся друг в друга слоёв бизнес-логики, с совершенно ебанутыми и причудливейшими связями и зависимостями, что даже в рамках одной монолитной среды почти невозможно провести декомпозицию, не превратив всё в безконсистентную нечитаемую горизонтальную лапшу. А ты предлагаешь ещё и на сервисы дробить, лол. Это можно делать когда у тебя есть чётко выделенные автономные подсистемы, а в тырпрайзе, если и можно таковые выделить, они всё равно огромны, чаще всего непропорциональны (85% кор, 15% периферия) и неделимы в том смысле, что ты насосёшься при попытке их разбить, так как: а) меняешь нативные средства композиции в рамках одной среды (на уровне примитивов языка) на менее удобные средства композиции на уровне протоколов взаимодействия между узлами и абстракциями над ними - внося ещё больше сложности и усугубляя и без основную главную проблему, б) понижаешь производительность системы: в тырпрайзе имея даже линейный рост объектов декомпозиции у тебя будет экспоненциальный рост связей между ними, и там где в рамках монолитной среды это не стоило бы ничего (разве что небольшой abstraction penalty), в рамках сервисов ты везде тратишь на I/O, в) повышаешь хрупкость системы, г) усложняешь отладку. По большому счёту микросервисы - это ещё один базворд хайпнутых долбоёбов типа гоудибилов, думающих что простыми средствами можно решать сложные задачи. Так то их можно применять для всякой чисто инфраструктурной хуиты или, что чаще, для хипстерских перделок, но не более.
>задроторабы Даже не знаю кто больше задрот, тот кто побырику на минималистичной кложе решает задачку, продавая её в красивой упаковке и в срок, или хачкеребёнок, пердолющийся с типами ради типов и выдумывающий неделями очередной йобаморфизм, когда НУЖЕН ВОООН ТОТ ОТЧЁТ СЕЙЧАС БЛЯТЬ.
>>848239 > думающих что простыми средствами можно решать сложные задачи Так и делается всеми кроме тырпрайз алтфаков, выдумывающих себе оправдания, что их огромная монолитная параша нужна. > Даже не знаю кто больше задрот Я позиционирую негативным не задротство само-по-себе, а именно сферу его применения.
>>848242 >выдумывающих себе оправдания Это опять же в стиле хипсторов и гоудетей - непризнание самого существования проблемы (что говорит в первую очередь об отсутствии опыта в этой сфере) тогда, когда она есть, это общеизвестно, и очевидно, что её решение не может быть простым. Вот хаскель как раз идеальный инструмент для её решения: продвинутые, по сравнению с другими языками, средства композиции и абстракции - это самое то для хитровыебанного тырпрайза, в то время как хипстосервисы это деградация даже по сравнению с классической жабой 90х-00х.
>а именно сферу его применения А какая тут сфера? Решать реальные задачи? Вообще среди лисперов куча таких же фриков как в хаскеле, галлюцинирующих целыми днями над абстрактной ничего не делающей хуйнёй, только первые пердолятся с метапарсерами метаконфигов, вторые с трансформациями йобаморфизмов. Конкретно кложа должна была вернуть витающих в небесах долбоёбов на землю и заставить их решать задачи, желательно компактно. Естественно язык пропитан чисто утилитарным подходом во всём, взять те же трансдюсеры - если вдаваться в теоретические размышления это сломанная абстракция, но похуй, она работает и приносит много пользы. Хорошо бы что-то хаскелеподобное подвезли с такой же философией, так как на данный из подобного есть только Elm, но этож веб онли да и сырое к тому же.
А давайте немного отвлечёмся от комбинаторов абстрактных дслей и поговорим чуть-чуть о реальном мире. Допустим, у нас есть функциональный язык. Допустим, у нас есть желание быть настолько чистым, насколько возможно. Допустим, мы пишем рогалик. В рогалике перемещение дискретное, поэтому (игровое) время между ходами там проходит довольно большое. Обновляем мы геймстейт, конечно же, через map, поэтому все действия происходят как бы одновременно, и каждый объект видит состояние мира на начало хода. Проблемы: 1. Допустим, игрок ушёл от монстра, и получилось так, что монстр его даже не видит. Но у монстра игрок всё ещё на предыдущей позиции, поэтому он его атакует и убивает. 2. Допустим, монстр А решил подойти к игроку поближе, и монстр Б решил подойти к игроку поближе. Они стояли рядом, поэтому в результате оказались на одной клетке. Допустим, что второе по весу действие было кастовать в игрока какой-нибудь опасной магией. То есть, если мы сейчас разнесём монстров на разные клетки, то получится, что они оба сходили, хотя должен был идти лишь один, а второй должен был увидеть, что прохода нет (допустим, там корридор), и атаковать игрока магией. 3. Допустим, у нас есть монстр с 5 хп. Он выпивает зелье лечения и получает 15 хп (итого 20). Допустим, есть второй монстр, который стрелял в игрока (или сам игрок) и промахнулся, попав в первого монстра и нанеся ему 6 очков повреждений. Должен ли первый монстр умереть? Должно ли с него упасть зелье лечения? 4. Допустим, игрок сделал ход, который очень длинный по времени. Это даёт монстрам возможность сделать 2.3 хода. Монстр А встаёт на соседнюю незанятую клетку и подбирает с неё зелье лечения. Монстр Б встаёт на соседнюю незанятую клетку и подбирает с неё зелье лечения. Так получилось, что оба они встали на одну клетку. What do? Почему вообще функциональщина ставит подобные вопросы, когда то же самое на какой-нибудь убогой сишке просто работает?
>>848305 > А какая тут сфера? Решать реальные задачи? Именно. Если ты вкладываешь хоть частичку души в решение реальных задач чьих-то бизнесов, ты ты хуесос, аутист, и задротораб. Хорошее задротство должно быть направлено на развлечение себя и окружающих. Вообще, работа должна исчезнуть. Сначала все постепенно перекатятся в сферу развлечений, всякий там стриминг игор и ведение пабликов в социалках, а потом и вовсе перейдут на безусловный доход. На обслуживание всей реально нужной инфраструктуры мира хватит тех немногочисленных людей, которые даже в таких условиях захотят вьябывать ради вьябывания, просто потому что у них аутизм. Вот кложура - это именно плохое задротство. А если взять питон или жс - в прикладном программировании на них задротства нет вообще, ты ни к чему заранее не готовишься, импровизируешь, пишешь на отьебись, и не заморачиваешься. С хаскелем особый шик: даже со стороны очевидно, что он космически задротский, но хуй ты на нём решишь задачи чьих-то бизнесов, даже если попытаешься. Это замаскированное под аутизм развлечение. С одной стороны, программы не имеют самоценности и не являются истинным искусством, потому встаёт вопрос, нахуй такое надо, но с социальной стороны хаскель и подобные ему языки - это настоящее адское пламя, падшие ангелы, всадники апокалипсиса, двигатель эволюции и перестройки сознания. В каждой сфере это нужно, в большинстве это уже есть, но именно в программировании его инкарнация такова. Некоторых это приводит к осознанности, остальных просто готовит к переходу на следующий уровень. >>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
>>848406 >Вот кложура - это именно плохое задротство. Кложа это именно фановая и быстрая разработка без задротсва, именно от неё и пошли мемасы типа хуяк-хуяк и в продакшн. Такими же по духу являются руби и эликсир. А вот пистон - задротство, питонисты - дисциплинированные кндровцы, ходят строем, чтут прилежание и аккуратность - человек другого склада на этом васике, разумеется, писать просто не сможет. JS - сам по себе просто бесконсистентная дрисня, где весело первые тысячу строк, а потом ебля моргенштерном в жеппу. Чтобы решить эту проблему - есть фремворки, которые лепят из жса что им вздумается: англяр - джяву, реакт - что-то фпешное, т.е. просто копируют имеющийся мейнстрим.
А хаскель - это замаскированный под развлечение аутизм, изощрённая форма эскапизма. То есть обычный ноулфайфер сливает жизнь на ануиму, сериалы и игоры, продвинутый ноулайфер в какую-то хуиту типа хаскеля.
>>848427 Кложура пытается в пюр фп, но у неё для этого нет абстракций, и сами кложурасы-прикладники настолько не могут в абстракции, что у них даже абстрактного синтаксиса нет - только конкретный, в списках. В результате этого всего на кложуре писать ещё сложнее чем на других лиспах. Не надо коко, это задротство ещё то. > питонисты - дисциплинированные кндровцы, ходят строем, чтут прилежание и аккуратность - человек другого склада на этом васике, разумеется, писать просто не сможет Если речь о людях, которые двигают сам язык и либы, может быть, но прикладной кодинг на питоне совсем другой. Это единственный язык, который я вообще не учил, а просто скачал рантайм, либ, и написал за пару вечеров прикольную хуйню с вебсервисами, дата сцайнсом, графами, пикчами, не зная вообще ничего по ни языку, ни по либам, ни по матчасти. Даже с ноджс нет такой лафы. > руби Руби, питон, жс - это всё примерно одна хуйня, только чуть по разному сделано. > эликсир Это ж альтернативный синтаксис для эрланга? Походу конкуретный фп аутизм похуже кложуры.
>>848429 >Кложура пытается в пюр фп Вообще мимо. Ты её хоть видел-то?
>скобки >только конкретный синтаксис /0
>на кложуре писать ещё сложнее чем на других лиспах Нет конечно. Там вся сложность была из-за JVM, тому что либ овердохуя, а идиоматичных лисп-лайк враперов - нихуя, но это уже преодолённый этап. Так-то писать на ней проще и быстрее, чем на любом лиспе.
По поводу аналогии с эликсиром и рубями, я имел ввиду подход "вернуть фан в повседневное программирование", которым эти три языка насквозь пропитаны.
>>824712 > Почему еще никто не сказал про ELM? Такая то годнота! Функциональщина для для фронтенда, да еще и с нормальным синтаксисом. Да в любое подобное обсуждение функциональные петухи неизменно затаскивают ELM, типа вот вам ф.язык с практическим применением. На самом же деле это дерьмо, как и любая надстройка над HTML+CSS+JS. К сожалению, все, что транслируется в ХТМЛ и ЖС априори хуже, чем то, что написано на этих языках. А уж ELM с его изъебствами никак не может быть проще/лучше этих весьма простых языков. И еще там рантайм пиздец какой большой, вроде бы 500к сразу прилетает, ну и странички грузятся прямо с заметным подвисанием, что можно заметить даже на самом сайте ELM'а. Короче, выглядит это изнутри примерно как сохраненная в Word 2003 в формате HTML страница с некоторыми интерактивными плюхами. Работает и дебажится это примерно так же, т.е. Write-only.
>>848433 > Вообще мимо. Ты её хоть видел-то? Немного видел, лютый пиздец и задроч. > скобки > только конкретный синтаксис > /0 Как раз наоборот. Во всех языках есть, как минимум в кишках компилятора, представление кода на этом языке в виде данных. Только вот большинство языков от этих данных пользователей абстрагируют, предоставляя им удобный синтаксис, а в лиспах есть только эти данные и пользователи пишут код прямо в виде литералов этих данных. > фан > эликсир, руби, кложура Мда.
>>848449 В музыку не могу (кроме слушания), а программирование просто не люблю. Пытаюсь всеми силами полюбить обратно, потому что сука денег надо дохуя, но никак не выходит. Особенно ненавижу программистов, сука мрази ёбаные пидоры блядь убогие безвкусные услужливые вши недоразвитые рабы божии нахуй.
>>851306 > Как у них там с производительностью Как у интерпретации AST в рантайме, небось. По-моему, грамотное их использование - трансляция/компиляция реализуемых ими edsl во что-нибудь другое.
Функциональщина просто охуенна. Вот есть у тебя функция, которая возвращает значение того же типа, что и принимает. Что с этой функцией можно сделать? Её можно назвать эндоморфизмом! Зачем? Ну, а как тогда пейперы-то писать без энтихморфизмов-то? Нельзя так. Надо назвать. Или вот охуительнейшая мандадка Reader. Представь себе, анончик, в неё можно завернуть значение! А потом можно написать специальную функцию! Которая будет принимать функцию, которая будет обрабатывать значение внутри этой мандадки. Охуенно же? Что? "Зачем нужна эта акробатика, если можно к значению применять функции напрямую?" Да ты чтоооооо? Да как тебе вообще в голову такое пришлооооо!!!!!? Это же мандадки!!!!!!! Люби мандадки, пидор!!!!
>>852572 Фишка Reader в том, что она автоматизирует эту передачу значения. Благодаря ей тебе не надо контекст вручную передавать в каждую функцию параметром.
Хочу приобщится к функциональному миру, какой язык выбрать? Хотелось бы нечто, что имеет, или потенциально будет иметь в будущем вакансии. Сам я шарпер, естественно присматриваюсь к F#. Что скажете?
>>854808 Без разницы какой. Какой тебе удобнее, тот и выбирай. Шарп немного пованивает, но если тебе удобнее - бери его. В последующем тебе придется ознакомиться со стандартным эм-эль, кложурой, скалкой и хаскелем энивей.
Что скажете за такой язык как AUTOMATH де Брейна де Брёйна де Брюйна де Бройна де Брауна? Актуален ли, какие есть (если есть) реализации? Нужен или не нужен и почему?
>>843950 >почему среди адептов функционального программирования так много трансгендеров? Не знаю. А почему среди тех кто топит за ООП так много геев и они даже не пытаются это скрывать? Один из джава господ прямо оче толстые намеки делал по пьяне, говорил что-то про вариант съебать в Финляндию с ним. Мимо ФП господин
>>861930 Не, это про математику. Мне нужно что-то более цсное. А хотт пусть конструктивист читает.
>>861933 Я не совсем понял, что ты имел в виду под рецептами и заклинаниями. Я понимаю, что кроме этого треда много всего есть, но там везде нужно регистрироваться. А некоторые еще и телефон просят!
>>861934 Я имел в виду, что если хочешь понимать суть, то читай бесполезную теорию. Если хочешь полезного, тебе понимать суть не надо, иди читать блогпосты в духе "идиоматично пишем гостевуху на фпязыкнейм". Reddit - идеальный агрегатор ссылок на подобные блогпосты. > везде нужно регистрироваться Либо регистрация, никнеймы, и кармочка, либо жри говно на анонимной параше. Тут тебя накормят чем угодно.
>>861935 Спасибо, жрал говно, жру и буду жрать. Йей, говно! С этим мы разобрались.
В общем я полистал дцпл - не, его тоже обидно читать без компилятора, хочется по ходу и писать это все. Есть еще некое "введение в функциональное программирование", даже с хорошим переводом. Уж раз перевели, значит годная книжка?
Комонлишп - это мертворождённое недоразумение, которое сейчас ебут пару десятков поехавших фриков на планете. Сложно найти лишп хуже комонлишпа. Ракеты, схемы, кложура - всё это гораздо лучше ёбнутых cadadr/mapc петухов.
>>862308 Комонлишп появился в 94, а нормальные рантаймы для него - ваще в последние лет 5, и то, не очень нормальные. Комонлишп никогда не был популярен и не использовался никем, кроме душевнобольных уровня lor/0chan/2ch.
>>862805 Она там есть, заебали. Просто делается через специальное ключевое слово. И это правильно, кстати, так и должно быть. А еще это совершенно неважно, блядь, потому что никто не пишет руками рекурсивные функции, але.
>>862883 автор статьи в языке как-то не разобрался
А) его первый пример (который не самый быстрый, можно было значительно проще [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]
>>862883 Скачай купи programming clojure или какой-нибудь practical clojure. Как прочитаешь книжку - можно и блоги читать. Вообще, есть же сайтик learning-clojure.com или как-то так (погугли, я не помню точного адреса), там все материалы собраны и разложены по полочкам.
Рекурсивные функции сами по себе очень редко используются, потому что в стандартной библиотеке есть куча функций, комбинации которых хватает почти для любого преобразования. А если не хватает, то обычно используют редьюс. Ну или луп, если уж без явной рекурсии совсем никак.
>>862899 >>862905 Посоны, не юзайте пастебин.ком, пожалуйста. Есть же гитхаб, гостбин, да просто тыщи других нормальных пастебинов без рекламы и говна.
>>862785 тысячи их на самом деле я надеялся что может попишу для веба глядя на purescript и elm попробовал - оба говно но на purescript помоему вообще нельзя ничего сделать
>>862764 ну почище да но вот как можно чище это не чего мне хотелось в этом случае было бы оно юзабельным
>>862871 Почему никто ещё не сделал хачкель с нормальным синтаксисом? substrIndex :: String -> String -> Maybe[Int] substrIndex(govno -> mocha) = mocha.tails.findIndex(govno.isPrefixOf)
Поясните за вкатывание в ФП. Нужно определиться с языком. С одной стороны хаски, но это скорее как Smalltalk, не применяется, зато является стандартом ФП. С другой стороны скала, хоть и гибридный, но в продакшене. Есть Clojure, но тут слишком маленькое комьюнити. Может быть я что-то упустил?
>>865610 Erlang, Ocaml/SML/F#. Из Лиспов: Racket. Если уже есть опыт и знания в области программирования, то можешь для начала попробовать "щадящий" вариант, а именно, язык, в котором есть более-менее развитые средства ФП, но не настаивающий на функциональном стиле (Kotlin, D, Rust...).
Посмотрел в сторону языков с зависимыми типами, что увидел: - Agda. Костыльное говно, на винде не ставится, на глинуксе тоже не ставится (зависимость - некая программа alex, ставится версия 3.2.1, агде нужно чтобы версия была выше 2.1, но ниже 2.2). - Idris. На винде ставится, но не работает, не может подгрузить написанный хеловорлд. Возможно, лечится добавлением пути к екзешникам в PATH. Итого, остается один Кок.
>>865913 Эм, тебя стриггерило, или что? При чем тут комьюнити эмэля и ракетки? Я же сказал: они для обучения. Комьюнити тут не нужно, тут нужны книжки и пейперы, а их есть и много.
Из трех перечисленных им языков у кложи самое доброжелательное и хэлпфул для новичков комьюнити. Я это знаю, потому что сравнивал.
"С одной стороны хаски, но это скорее как Smalltalk, не применяется, зато является стандартом ФП. С другой стороны скала, хоть и гибридный, но в продакшене. Есть Clojure, но тут слишком маленькое комьюнити."
Вроде очевидно, что размер комьюнити он считает недостатком, и просит что-то функциональное, но популярное.
Правда у всех ФЯ комьюнити еще меньше, чем у перечисленных им хаскеля-скалы-кложуры, так что посоветовать ему нечего.
>>865939 Ну так я ему в ответ на это и задаю вопрос: а ты с какой целью вообще интересуешься? Ясно ведь, что человек пытается судить по каким-то внешним признакам вроде какой-то "популярности", и это обычно не самый логичный и эффективный способ. Ну если человек пишет, что х-ль не применяется в продакшене, значит он совсем не в теме, и надо сперва выяснить, какие у него ожидания, и тогда потом можно будет что-то посоветовать по делу.
Мы друг друга поняли? Алсо, если уж совсем занудствовать, то популярность и размер комьюнити - далеко не одно и то же.
>>867737 Спасибо. Правда я потыкался-потыкался, но так и не нашел у него конкретной статьи на тему того, как это происходит в общих чертах. Ты какую-то конкретную статью имел в виду или нет?
Кстати, он кложей плотно упарывался, приятный сюрприз.
>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.
>>868794 Ага, спасиб, поставил. Теперь другая трабла, ставлю стаком hsdev, говорит нужен haskell-src-exts. Ставлю стаком haskell-src-exts, говорит такого пакейджа нет!!! Ставлю кабалом - ок. Стак опять говорит что его нет. Это норма?
Кабал и стек ставят пакеты в разные места. Начинающему лучше вообще кабал-инстол лучше установленным не иметь, меньше проблем будет.
Ставь hsdev так:
stack --resolver=nightly-2016-11-02 install hsdev
если посреди долгого конпеляния он до тебя доебется, а ты не вполне понимаешь что ему надо повтори команду, он скорее всего продолжит с того места на котором остановился.
Но лучше бы не выебываться и использовать обычный ghc-mod с атомным или идейным плугином
>>868844 Спасибо, бро. Я так понимаю мне достаточно было только stack поставить, а собственно stack-ом и GCH со всеми зависимостями и пакейджы все необходимые доставить\обновить всегда можно.
>>868992 Ocaml - это даже не скала, это тайпскрипт с очень хуёвым синтаксисом, очень хуёвым рантаймом и без либ. Насчёт F# не особо понятно, нахуй он нужен, когда есть C# и тайпскрипт. Все эти эмели и лиспы не позволяют делать то, за что любят хаскель. Нахуя это делать - другой вопрос.
>>869000 Не знаю, братишка, сам с SML начинал. Тогда было норм. А лисп не заходил. В скалке хуево что алгоритм хинди-милнера не воркает, потмоу что обекто-ориентированость. Хуво сделали - руцями приходится писать типы. Колекции еще ковариативные-контрвариатинвные-инвариативны сложна, чето.
>>869005 Нет, петушок, просто ты не шаришь. Вот если б в окамле хотя бы имплиситы были, это была бы вполне себе скала с плохим синтаксисом и без либ. >>869018 > руцями приходится писать типы Там где в скале пишут руками типы (вещи уровня scalaz) - то в окамле вообще не делают никак.
>>869038 В скале их вообще везде пишут, там вывод типов на уровне "нихачу утиную типизацию". >>869038 >Нет, петушок, просто ты не шаришь. Вот если б в окамле хотя бы имплиситы были, это была бы вполне себе скала с плохим синтаксисом и без либ. Что-то проиграл. Ты хоть видел как Option в скале реализовывается, синтаксис хуёвый? И да - всё точно до наоборот, это скала без имплиситов была бы ближе к окамлу, тк её создатели вдохновлялись именно им.
>>869042 > В скале их вообще везде пишут Ну хуй знает, я юзал скалу на работе как-то, не было у нас такой хуйни. > 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.
Ебанько, говна без чистоты и лени и так дохуя, какой смысл в окмлопараше, если это тот же жавакрестобейсик только без либ и без работы?
> и F#
Завидую тебе, не жравшему этого говна а только кукарекающего о нем в чатике. Желаю тебе хлебнуть полный рот саймопоноса. Ты будешь визжать, сучка, когда эфсярп доберется до твоего ануса.
>>869235 В окамле нету "иммутабельности по-умолчанию", даже если бы какой-то смысл в этой шизофазии и был. Вот когда строки сделают обязательно иммутабельными, через пару-тройку версий, это уже будет не так смешно. Но то, что писать постоянно всякие консты и файналы не нужно - это хорошо, конечно. Синтаксис в окамле вообще не такой хуевый как в среднем языке. Вывод типов - тоже плюс.
Но этого мало для того чтоб компенсировать убогость окамловских библиотек, тулов, рантайма и прочего. В хаскеле хоть понятно ради чего ебешься со всякими кабалами и гхц-модами, а в окамле? Ну да, окамлоговно с горчичкой и его вроде как легче жрать, но зачем, если есть варианты получше?
Тем более что говно наяривать придется забесплатно, работы на окамле нет.
>>869247 Я не собираюсь тебя ни в чем убеждать, мне неинтересно. Ты сказал, что окамл - этот та же джава\кресты, я указал на ошибочку. В дальнейшем диалоге лично я не заинтересован, извини. Может кто-то другой захочет тебе ответить.
>>869253 Ну разумеется, окамл - это не жава и окамл это не кресты. Но разница между окамлом и жавой где-то такая-же, как между жавой и крестами. В дикие лохматые годы, когда не было в языках лямбд и даже самой уебищной реконструкции типов окамл еще как-то выделялся, но сейчас-то все языки такие говно-ФЯ, он один из многих, хотя и, обычно, более убогих чем он, так ради чего с ним связываться-то? Есть более интересные варианты.
>>869247 Нет, не понятно. В хаскелле ебёшься со всем этим просто ради ебли - есть хоть один реальный пример (кроме хэловорда или хуиты с бесконечной рекурсией) где та же ленивость не была бы якорем? причём зачастую текучим и убивающим нахождение этой самой утечки Или нахуя чистота именно в самом языке? Чтобы костылировать очевидные вещи?
Окамл как раз ничем не ограничивает и не имеет миллиард языковых фич просто ради усложнения кода - что, несомненно, плюс. инб4: ну ты конечно же можешь расширить синтаксис как захочешь - такого удовольствия особых гурманов не лишить
Работы на других функциональных яп тоже нету мы все прекрасно знаем как используют скалу в продакшенах, и не будет просто потому что обучить человека без нормального багажа знаний макаку слишком затратно.
Алсо, единственная убогая часть тулинга - как не удивительно, поддержка винды. Нет, скомпилировать софт и даже абсолютное большинство библиотек можно - только вот завести какой нибудь utop или софт работающий с тредами - это пройти все круги ада.
>>869261 Если нужен просто более крутой язык ФЯ для разминки мозгов - варианты поинтересней конечно есть. А так он вне конкуренции - либо параша с анально ограниченной виртуалкой, либо хаскель, либо академпараша.
Что такое ФП и чем он отличается от ООП?Аноним03/11/16 Чтв 20:42:41#350№869279
Я на нем любую C#-йобу переписываю гораздо компактнее, да и менять потом легче. На работе все скрипты в linqpad давно пишу на F# Сборку мелких проектов делаю на FAKE. Асинхронность в модуле Async гораздо юзабельнее TPL, а если Hopac использовать, то вообще космос. Да и комьюнити по активности только скаловскому уступает (среди функциональных языков).
Скоро тайпклассы завезут (работающий прототип проплывал с месяц назад).
>>869261 Это единственный практически применимый МЛ. Я не знаю, в каком мире ты живешь, а в наш мир еще не завезли его аналогов, чтоб он был "одним из многих".
>>869282 > комьюнити Раст? Кложа? Не? Что-то ты с плеча рубанул про комьюнити, имхо. Вот я не пишу на эфшарпе и ВООБЩЕ НИХУЯ о нем не слышал. А про кложу, раст, эликсир и даже элм с пюрескриптом, прости хоспоти, слышу постоянно.
Ах, ну и про х-ль я даже не заикаюсь, разумеется.
>>869276 > работы ... нету Опчть же, на кложе и х-ле каждую неделю вакансиями в ленту спамят, я хуй знает с какой вы планеты.
>>869298 >с плеча рубанул про комьюнити Тут ты прав, я погорячился. Прост подписан на fsharp digest, и там постоянно то докладики, то презенташки интересные. А хаскелисты какие-то пейперы монохромные пилят.
>>869276 > Нет, не понятно. В хаскелле ебёшься со всем этим просто ради ебли -
В хачкеле удобно писать функционально. Спокойно хуяришь комбинации комбинаторов. Можно, конечно, поспорить с тем, что ФП это хорошо, но последовательную защиту говноФЯ без ленивости и контроля за эффектами на этом не построить.
> есть хоть один реальный пример (кроме хэловорда или хуиты с бесконечной рекурсией) где та же ленивость не была бы якорем?
Да любые функции со списками работающие. В окамлапарашах типа батареек какие только изъебы не придумывают чтоб map в один проход написать, кастят консы к мутабельным структурам, чтоб хвост наместе переписывать, например (привет, "иммутабельность по-умолчанию").
> причём зачастую текучим и убивающим нахождение этой самой утечки
Ну да, в ФП другие лучшие практики и другие навыки нужны. Но если ты хочешь писать как деды завещали, тебе можно только позавидовать, такого говна навалом и именно в этом окамл от жавакрестов ничем не отличается.
> Или нахуя чистота именно в самом языке? Чтобы костылировать очевидные вещи?
Чтоб можно было оптимизировать и рефакторить ФП код, не боясь все поломать. Чтоб СТМ нормально пользоваться и т.д.
> Окамл как раз ничем не ограничивает
Если контроль за эффектами считать ограничением, так и типизация тогда ограничение.
> и не имеет миллиард языковых фич просто ради усложнения кода - что, несомненно, плюс.
Да ты ебанулся. В окамле самая навороченная система модулей вообще из всех существующих языков, ебенический негуманоидный ООП и ГАДТы. Но это-то как раз хорошо, фич должно быть много. То, что предпочтительно даже в 90% случаев в 10% является говном, а если смешать 9кг варенья с 1кг говна получится 10кг говна. Говноеды, типа Гвиды, не понимают этого нихуя, но на то они и говноеды: разницы между говном и вареньем не видят. Нормальный человек понимает: всегда должны быть разные способы делать одно и то же. К счастью, в разработке хачкеля влияние обсуждаемых гей-нацистов минимально, это не высер бесноватого фюрерка, а комитетский язык в котором почти всегда есть минимум два способа сделать что-то. Подход "жри что есть, пидор" более характерен для эмелепетушни, но в эмелепараше и не могут иметь хороших вещей из-за еще меньших трудовых ресурсов. Когда они вдруг могут позволить себе крутую фичу - они сразу забывают что только что кукарекали "НИНУЖНО!!111". Отличиный свежий пример ф-лямбда. четверть века окамлоконпелятор нихуя не оптимизировал, и окамлисты визжали о том, что продвинутые оптимизации не нужны, ведь они ухудшают предсказуемость результата (без оптимизаций производительность предсказуемо хуевая, а так может и нехуевой внезапно оказаться). Но как только оптимизации вроде уменьшения абстракшн пеналти от модулей худо-бедно запилили - этот, как его, джейнстритник выступил с программным блогпостом о том, что оптимизации, оказывается, были нужны!
> Алсо, единственная убогая часть тулинга - как не удивительно, поддержка винды. Нет, скомпилировать софт и даже абсолютное большинство библиотек можно - только вот завести какой нибудь utop или софт работающий с тредами - это пройти все круги ада.
Да весь тулинг убогий, не обманывай себя. Сравни с более-менее популярными языками.
>Если нужен просто более крутой язык ФЯ для разминки мозгов - варианты поинтересней конечно есть. А так он вне конкуренции - либо параша с анально ограниченной виртуалкой, либо хаскель, либо академпараша.
Ну вот хаскель и делает окамл полностью бессмысленным (особо упорный окамлодибил может теперь даже включить какой-нибудь LANGUAGE Strict, и пердолиться строгостью во все дыры, ему конечно придется свою энергичную прелюдию написать, но эмелистам писать стандартные библиотеки самим не привыкать). Единственная причина окамл изучать, это посмотреть как модули делали в 90-е и поебаться с ехал-функтор-через-функтор, для общего развития. Т.е. это как раз ниша разминки мозгов, идрисни всякой, просто повинтажнее и поолдскульнее.
>>869282 Когда говорят о практической применимости F# обычно имеют в виду то, что на нем можно писать как на C# и использовать библиотеки, написанные на и для C#-а. В качестве же именно ФЯ - F# абсурдно неполноценен и убог. Имеющий опыт использования какого-то ФЯ обнаружит, что практики из этого языка перенести в F# нельзя и опыт бесполезен потому, что: 1) Выразительные средства из более-менее сносных ФЯ вроде тайпклассов и параметризуемых модулей в F# отсутствуют - как будто не было последних 30 лет. Есть только ООП-средства. Отсюда невероятные для ФЯ проблемы с обобщением и повторным использованием. 2) ФП код, обычно, не может быть типизирован - из-за отсутствия возможности абстрагироваться от конструктора и отсутствия Rank-N и полиморфной рекурсии (про какие-нибудь GADT я и не говорю). Система типов в F# точно самая убогая из всех ФЯ, но вывод типов для нее все равно нормально не работает. Вместо него убогая реконструкция и даже не двухсторонняя, а слева на право. Даже в некоторых языках с завтипами реконструкция работает лучше, а главное есть удобные способы подсказать тип. 3) Если вам все-таки повезло и ФП код типизируется - он будет адово тормозить, ведь оптимизировать ФП код не нужно - можно же заставить программиста как на C#-е (Фортране) писать.
Нужно отметить, что есть некоторые приятные фишки, но они являются ложкой меда в бочке дегтя и выглядят, скорее, как издевательство.
Некоторые из этих проблем встречаются в других ФЯ, но нигде не собрано такого полного комплекта и нигде не достигнут такой совершенный, в своем роде, апофеоз убогости. Даже Скала не настолько убога (у нее все-таки развитая система типов, хотя удобной эту систему типов, конечно, не назовешь).
Подытоживая: ни для программиста на SML, ни на каком другом ФЯ F#, конечно, не может быть полноценной заменой уже известного инструмента. F# - это скорее C# с человеческим лицом для программистов на C# окончательно измученных этим нарзаном, и если вдруг программист пробовал что-то слаще морковки - "человеческое лицо" превращается в звериный оскал.
tl;dr пасты: по сравнению с C# может и охуенно, но это крайне низкая планка по меркам ФЯ.
> Скоро тайпклассы завезут (работающий прототип проплывал с месяц назад)
Без когерентности инстансов и особенно HKT от тайпклассов толку нету. Ну и синтаксически там пиздец тот еще.
>>869343 Хах из твоего поста я только п. 1 понял, да могу первую часть tldr подтвердить. Но я из функиональщины только на схемке/common lisp'е да на эрланге писал, так что не избалован.
>>869367 > А что именно ты считаешь "приятными фишками"?
К примеру в окамле нету нормального структурного равенства как в F#, там динамический хак как в скриптопараше, который просто падает в рантайме если ты сравниваешь то, что он сравнивать не умеет. В эмелях кроме F# обычно нету "монадного" синтаксиса, хотя для окамла написано несколько макрокостылей для этого и т.д. Ну и F# чуть ли не единственный эмель с нормальным рантаймом с смп.
>>869298 >Опчть же, на кложе и х-ле каждую неделю вакансиями в ленту спамят, я хуй знает с какой вы планет Каждый раз когда такое вижу, вспоминаю историю про эйчарку которая хайрила скалистов: скалы у них вообще не было, но логика была такая что знает скалу => умный => надо брать.
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
>>869394 Какая те нахуй разница, додик? Ты пишешь прикладной код, а не либы. Лучше чтобы код либ было писать сложней, а прикладной проще, чем наоборот, потому что либы пишутся один раз, а потом юзаются в 100500 прикладных приложений.
>>869403 > Тебе синтаксис не нравится, или что? У нас дискусия о моём утверждении, что если в окамл добавить имплиситы, то получится скала с плохим синтаксисом.
length' xs = sum [1 | _ <- xs] _ 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.
Не очень понял, _ это как ', то есть просто всратый символ, которые не используется в самом языке, так что можно использовать в переменных? Я могу назвать функцию _? Или нет, это особенный символ?
>>869405 Скала, сделанная под влиянием верблюжатины без имплиситов и скобочек превратится в верблюжатину с чудовищным адт, без кошерных модулей и тд, никак не наоборот. >>869404 Да ладно, обосрался 2 раза, подумаешь. Не гори так. >>869403 Только вот этот самый ум со знаниями фп ничем не помогут когда посадят ковырятся в легасиговне со стёком наследование в 2 тыщи классов.
>>869406 Почему хуевая? Не понимаю. Вот например тебя на собеседовании просят решать олимпиадные задачки не потому, что ты будешь решать на работе олимпиадные задачки, а потому что хотят удостовериться, что ты норм.
Или ты говоришь о том, что они в вакансии пишут, что ищут лид-девелопера на скала-проект, а потом оказывается, что тебе придетсч писать сайтики на пхп? Ну так это просто вранье, фп тут не при делах.
>>869410 Бог дал тебе репл и хагс, но нет, не хочу взять и попробовать, хочу идти на мейлрач и спрашивать у анонов.
>>869419 Тебе палили уже годноту https://functionaljobs.com >ДС Как-то пол года назад в девзене помогали хайрить куда-то в дс хаскеллиста, причём сделали это крайне торжественно — видимо крайне редкое явление. Вот и считай сколько у нас тут таких вакансий. >>869420 Перефразирую: смысл искать человека со знанием технологии, которую вы один хуй никогда юзать не будете? Просто повыпендриваться перед заказчиками?
>>869418 >Почему хуевая? Не понимаю. Вот например тебя на собеседовании просят решать олимпиадные задачки не потому, что ты будешь решать на работе олимпиадные задачки, а потому что хотят удостовериться, что ты норм. Это тоже хуевая логика. Наберут аутистов, а потом ебутся с оверинжинирингом.
>>869425 Я же вроде объяснил, не? Работодатель считает, что Существует корреляция между знанием технологии и сообразительностью. Вот и выбирают людей со знанием технологии. (Плюс это модно и иногда позволяет поднять энтузиазм работника.)
>>869411 > Скала, сделанная под влиянием верблюжатины без имплиситов и скобочек превратится в верблюжатину с чудовищным адт, без кошерных модулей и тд, никак не наоборот. В скале всё это модульное петушение есть и сделано логичнее безо всяких лишних синтетических абстракций: ты просто можешь в любом скоупе сделать 'import luboyObjekt._'
Сейчас есть 19 вакансий в ДС, из которых 5 относительно интересные. Скалу в поиск не включил потому что там штук 50 вакансий. Раз в месяц появляется что-нибудь новенькое.
>>869461 Ну все-таки в основном это из оперы "будет плюсом знание одного из следующих языков". Но вакансии интересные действительно есть, да, хоть и для сеньоров все.
А джуниорам надо просто искать стартапы через знакомых и делать хуяк-хуяк-и-в-продакшен, как мне кажется.
>>869098 Triggered. Если выбрать устновку, то шде-то на шестом-седьмом пакаджде выдезет ошибка, и ты соснёшь хуйца. Такая вот охуенная стандартная либа. Ладно бы про batteries сказал, они, конечно, говно, но хотя бы устанавливаются.
>>869410 Это особенный символ для паттерн-матчинга. По сути-то, обычная переменная, только потом использовать нельзя (в некоторых языках можно, потому что создателям было лень делать отдельный кейс для неё).
Есть ли смысл учить ваши хачкели для чего-либо кроме дрочинга математических задач и интеллектуальной мастурбации? Они применяются хоть где-либо за пределами курсов обучения? На них реально писать реальные проекты?
>>870139 Я поражаюсь почему на бордах до сих пор не додумались выделить отдельную категорию ЯП, ориентированных на метапрограммирование. Forth/Factor, Lisp/Scheme/Racket/Clojure, Rebol, TCL - это всё языки из одной семейки. В плане ФП лиспы то же самое, что и сишарпы, джавы, жс, пхп и тд.
>>870058 Да нихуя они не меняют. Ну, понимаешь мап и фильтр, и сосёшь хуй, потому что в твоём языке их нет/тормозят/мусорят. Потом понимаешь, что foreach это тот же мап, только вручную, и продолжаешь писать, как писал. Ещё проникаешься алгебраическими типами и паттерн-матчингом, и продолжаешь писать классы с говном, потому что в твоём языке их нет, а запилить самому - будет хуже, чем без них. Ах, да, есть ещё Maybe, которая охуенна, но в твоём языке не поддерживается, и ну ты понел. А, композиция функций ещё. Но тут несколько проблем сразу: 1. Так пишут только хаскилисты. 2. Хуёво отлаживать и читать. 3. В твоём языке не поддерживаются (они и в окамле с фешарпом не поддерживаются нормально, что уж про твоё говно говорить).
>>870151 Последнее утверждение неверное. По-твоему фп - это типы и манатки? Или чистота? Ну-ну. Если ты форт и кложу пихаешь в одну группу, то ты просто ни на том, ни на другом ничего не писал, ну признайся честно, будь мужиком.
>>870160 >Ах, да, есть ещё Maybe, которая охуенна, но в твоём языке не поддерживается, и ну ты понел. Она есть даже в 8 жяве, хоть и кривая как обычно, лол. Что говорить о других языках. >фешарп Так это кусок ООП-нутого верблюдоговна, там это самое фп заканчивается на fold и map.
>>870178 Кложа - это единственный лисп, в котором в плане ФП кроме лямбд, которые есть везде, есть ещё немного анальной дисциплины и стремления к иммутабельности. Но это фигня по сравнению с тем, что он лисп с такими-то макросами. Суть в том, что "ФП=лямбды" - неинтересно, "ФП=лямбды+иммутабельность" - неинтересно, "МЕТА=макросы" - интересно, "ФП=программирование на типах" - интересно.
>>870160 > понимаешь мап и фильтр, и сосёшь хуй, потому что в твоём языке их нет/тормозят/мусорят Ты ебанутый? Это бля стандарт, это везде есть и везде используют. Мапают в сишарп, мапают в пхп, мапают в жс, мапают в джаве8+. На чём ты пишешь, что тя в языке мап и фильтр "нет/тормозят/мусорят"?
Сосач, быстро подскажи мне REST/WebSocket (микро)фреймворк для Скалы. Хочется чего-то похожего на Tornado, но нахуй этот питон с динамикой. Задачи - сбор статистики с клиентских эндпоинтов (что-то вроде гугл аналитик)
>>870203 Ну так вот я и не согласен с тем, что фп=лямбды плюс иммутабельность - неинтересно.
Кстати, каждый год среди кложе-комьюнити проводятся опросы, и там один из пунктов - что для вас наиболее важно и полезно в кложе. Так вот, на первом месте там всегда была та самая иммутабельность и ориеннтированность на данные. А макросы - это скорее приятное дополнение, чем главная фича.
Главная фича кложи - это то, что она data-oriented. Парадигма у нее своя, она располагает к определенному стилю проектирования. И именно поэтому она фп и интересна, а не из-за макросов или чего-то еще. Вот х-ль - язык про типы, раст - про защищенный секс с байтами, а кложа - про данные. И все, кто ее реально испольщуют в продакшене, в один голос об этом и говорят. Так что у тебя акценты расставлены немного, как бы сказать, ну как у человека без опыта работы с тем, о чем ты судишь, как мне кажется.
Я согласен, что фп - очень размытое и довольно субъективное и интуитивное понятие, но у той же кложи с х-лем общего гораздо больше, чем с фактором, например. Про форт я уж и вовсе молчу, гхм.
Короче, надеюсь у меня получилось объяснить, что я имел в виду.
>>870233 Привыкаешь со временем. Потом действительно понимаешь, что все эти мап фильтры по сути глорифаед for loop. Писать конечно больше приходится, но щито поделать. Зато идиоматичненько, да.
>>870256 > Потом действительно понимаешь, что все эти мап фильтры по сути глорифаед for loop Да это и так очевидно. Но обычные мапы и фильтры - это самый энтрилевел. Интересно что гобляди будут делать когда им понадобится что-то вроде https://github.com/developit/asyncro
>>870299 Начнут стандартный аутотренинг что нинужна и пишите всё руками, как обычно. >>870251 >фп - очень размытое и довольно субъективное и интуитивное понятие Так если посмотреть на парадигмы программирования то конкретно сказать "что же это именно такое" можно только про процедурщину. >секс с байтами, а кложа - про данные Внезапно вообще всё на компутере - ни что иное как "секс с байтами". Даже в суперабстрагированной легко выпотрошить кишки вроде NPE. >Парадигма у нее своя, она располагает к определенному стилю проектирования. И именно поэтому она фп и интересна, а не из-за макросов или чего-то еще. Вот именно что у неё своя парадигма, зачем мешать её с фп? Это что-то из разряда рассуждений мешающих все неимперативные языки в одну кашу и называя это дело "ФП" с интонацией "нинужное говно". Мне вот например странна сама мысль что функциональный язык может не обладать кошерной системой типов.
>>870299 Ну я бы делал примерно так. Я собственно так и делаю обычно. Мне тоже очень нравятся async\await и вообще направление в котором движется js, но это совершенно не имеет никакого отношения к теме маппинга. В смысле тоже самое можно провернуть используя forEach. И нет совершенно нкиакой разницы между 'энтрилевел' маппингом и твоим примером, в разрере самой концепции map\reduce\filter.
Про секс с байтами - ну ты же понял, что я имел в виду, ну чо ты, ну.
Мешают ее с фп затем, что ее парадигма входит в фп. Как бы первый функциональный язык был динамически типизированным, ты разве забыл? А то, что некоторые под "фп" начали последнее время подразумевать "мл-лайк\хль-инспайред" - слушай, ну так это уж их личные проблемы, объективных оснований для этого тащем-та нет, согласись.
>>870404 Если я понял синтаксис то нет. Первое это 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);
Что с первой строкой сделать, чтоб первая переменная была инт, вторая флоат а функция дабл?
>>870606 Зря я сказал про ноль аргументов. Ладно, давай вот на окамле посмотрим пример (в хаскеле и подобных ЯП то же самое в принципе). 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. По крайней мере как-то так это надо воспринимать математически, как там это реализовано я хз.
>>870404 Зависит от языка. В чистом — да, одно и то же. Без чистоты — нет, это разные функции, потому что в нечистых языках n-арная функция — это (n+1)-арная чистая функция с неявным параметром глобального состояния и неявным возвращаемым полем измененного глобального состояния.
>>869841 Бамп вопросу. Есть ли хоть один весомый аргумент в пользу учения этих языков? Смогу ли я писать на этом что-то сложнее калькулятора из командной строки?
>>870707 Ну, в вебдеве сейчас активно фп юзается. На той же кложе охуенно писать фронтенд (сейчас модно писать реактивный UI, reagent с frp тут заходит). Теоретически и бэкенд тоже, не пробовал (да и смысла особо не вижу, разве что если для расшаривания кода между бэком и фронтом).
>>869841 > Есть ли смысл учить ваши хачкели для чего-либо кроме дрочинга математических задач и интеллектуальной мастурбации? Нет > Они применяются хоть где-либо за пределами курсов обучения? Нет. >На них реально писать реальные проекты? Нет. >>870707 > Есть ли хоть один весомый аргумент в пользу учения этих языков? Нет. > Смогу ли я писать на этом что-то сложнее калькулятора из командной строки? Нет.
>>870771 с вводом и выводом у всех все заебись, у кого плохо с вводом и выводом? Как фп мешает вводу и выводу? Если ты про чистые языки то надо быть не долбоебом и въехать в монады. В не чистых динамических все с вводом и выводом ниебаца как круто.
>>870664 Не, чувак, ты не про то вообще. Юнит - это обычное значение\тип. Очевидно, что функция из юнит (или любого другого типа) в а - это одноаргументная функция. Я про другое совсем.
Смотри, так. Ты говоришь, что это разные функции. Тогда какой у них тип в импюре языке с явным выписыванием состояния (ну то есть в пюре на самом деле, нутыпонел)?
(-> t) ==> World -> World, t t ==> World -> World, t ???
Я не понимаю, в чем разница, если и то, и другое считать функциями. Фишка же должна быть в том, что просто т гарантированно возвращает тот же самый ворлд, что взяла, а тханк т - может вернуть измененный ворлд. То есть в обычном хм это не закодировать типами? Или как это должно выглядеть?
И вообще, если у меня импюре язык с обычной системой типов и каррингом, то с точки зрения системы типов это будет одно и то же? Или нет? Если нет - к каким противоречиям это приведет, можешь пример показать? Помоги разобраться, будь няшка.
>>871104 Ты ебанутый, не можешь сформулировать ни проблему, ни вопрос. Кусок кода, который ты привел и сказал работает, не работает, так как функция принимает первым аргументом порядок полинома, а вторым x, а в формуле передаешь х, а вторым аргументом - порядок. Тебе на это уже указали выше, но ты даже формулу не можешь правильно записать. И типы данных не понимаешь. %Мимо-третий-день-в-Хаскеле%
>>871114 >Тогда какой у них тип в импюре языке с явным выписыванием состояния (-> t) :: World -> (World, Result) t :: Result t не принимает никаких параметров, вообще никаких. t можно называть и значением, и чистой nullary функцией — в денотационной семантике нам незачем различать "вычислияемые" и "заданные" значения.
>если у меня импюре язык с обычной системой типов и каррингом, то с точки зрения системы типов это будет одно и то же? Да, одно и то же, ведь в системе типов языка без чистоты нет способа выразить разницу между ними.
>>871115 я привык к определению "компонент = функция", так же я пишу и на react + redux; и reagent дает мне именно то, что мне нужно. Причем сам reagent крайне простой, re-frame еще проще. Om же, как я вижу по гхвики, говорит делать полноценные stateful компоненты, что мне не очень нравится.
>>871141 дополнение В общем, реагент выглядит более кложуришным, а на Om я вижу код, который как на js, только на clojure. Можно тогда уже и на js писать, че уж там.
> ориентированность на данные > кложа про данные Объясните плез, что вы под этим понимаете, что чуть ни на уровень своей особой парадигмы тянет? Чем кложура более ориентирована на данные, чем какой-нибудь js? Может есть примеры кода где-то на гитхабе как это примерно выглядит?
Прост я сюда писал заёбанным и обосрался, да. Стал менять местами первый и второй аргумент и не поменяв до концы сбросил. Вот что я имел в виду. Спасибо, что помог. Теперь всё работает.
>>871139 Слушай, у тебя первый и второй абзац друг другу противоречат, разве нет? В первом ты говоришь, что это разные вещи точнее говоришь, что одинаковые, но тип-то пишешь разный!, во втором - что одинаковые.
Если у нас т:резалт получается после переписывания всей программы с явным использованием Ворлд, то мы же этот ворлд на таком т теряем, нет? То есть получается, что у тебя тогда в правилах нужно явно различать и писать разные кейсы для значений и для функций (и тогда получается, что значение - это не нуллари функция). Да, кстати: я же под т и (-> т) подразумевал типы, а под ==> - пасс компилятора, в котором мы преобразуем программу в аналогичную, но с явным протаскиваниес Ворлд, если грубо говорить.
> ...без чистоты нет способа выразить разницу между ними Разве? Так ведь если у нас нечистый язык, то как раз путем разделения т и (->т) мы эту разницу и выражаем! Первое без эффектов, второе с эффектами. Я не понял, что ты здесь имел в виду. Я-то спрашивал о таком случае, что мы вот говорим: "ок, пусть это будут разные вещи" (или наоборот, одинаковые), а потом берем какую-то разумную программу, и она не типизируется так, как должна, из-за того, что мы сказали, что это разные вещи. Вот, я пример такой программы просил привести, если можешь.
Если что, меня это интересует именно с точки зрения возможных преобразований, ну и разных вариантов реализации этой идеи. Ну давай для конкретики возьмем хаскель, например. В нем все функции - одноаргументные, при карринге после присобачивания последнего аргумента мы получаем значение: (Х -> У) х => у:У. При этом это "значение" на самом деле под капотом является неэвалюированным тханком - но это деталь реализации (рантайма), система типов ничего об этом не знает.
Теперь давай придумаем хаскель-штрих, в котором эти тханки вынесены из рантайма в систему типов. Теперь у нас есть еще и нулларные функции: (Х -> У) х => (-> У) => у:У. То есть применение последнего аргумента все еще возвращает функцию, ну а потом она уже как-то там вычисляется в обычное значение.
Вопрос: поломается у нас все от такого? Что нужно изменить в обычном хаскеле, чтобы превратить его в хаскель-штрих? Можно ли пойти дальше и сделать хаскель-два-штриха, в котором уже вообще не будет обычных значений, а только нуллари ф-ии?
>>871141 Чувак, ты на просто ом смотрел наверное, там есть локал-стейт у компонентов, как в реакте, да. Это не значит, что он полноценный стейт предлагает в компонентах хранить, кстати, это именно про локальный для компонентов стейт, а не апп стейт: https://github.com/omcljs/om/wiki/Conceptual-overview#components
Я же про ом.некст говорю. Посмотри вот эту презенташку, чтобы был контекст, откуда и зачем это все: https://youtu.be/-jwQ3sGoiXg И загугли youtube david nolan om next, там есть несколько презенташек, где он подробно объясняет, что, как, зачем, чем это отличается от предыдущей версии ом и какие пробдемы оно решает лучше, чем все существующие решения.
>>871142 Чуууваааак, лол, как бы ом пишет тот же человек, который пишет кложурскрипт. Мне кажется, он должен быть в курсе, как делать более кложуришные вещи, лол.
>>871494 Корни у них не общие (ну, если ты только не имеешь в виду лисп Маккарти, лол). Литералов у них не столько же, хоть бы доки прочитал для начала. Ну и это все не имеет отношения к вопросу того анона как бы, лол.
>>871328 В жс иммутабельности по умолчанию нет, так что он по определению не может быть дата-ориентед. Там переменные и объекты, это противоположность кложурному подходу. Если коротко, то идея в том, что стейт не размазан по всему коду, а хранится отдельно и централизованно, и изменяется в строго ограниченных местах, плюс шейп данных выступает в качестве контракта. То есть в джаве или даже х-ле контрактом обычно является тип, да? Это круто, но работает только в рамках одной программы. А если нам нужно соединить несколько программ, то что у нас выступает в качестве контракта? Описание данных! Рест-хуест, какой ендпоинт, какие поля в жсоне, в каком порядке байты идут, что в качестве разделителя используется и т.п. То есть это более универсальный контракт но его сложновато статически чекать, увы. Вот, и тут идея в том, что между частями программы - хоть функциями, хоть модулями - контракт состоит тоже в данных, а не в типах, описывающих поведение. То есть данные > поведения.
Как-то так. Вообще, это сложно объяснить, потому что это такой очень размытый концепт - это же вопрос стиля проектирования, то есть что-то интуитивное, а не формальное. Нужно полгодика повариться в этом, чтобы врубиться, как мне кажется. Но если по пунктам, то - на мой личный взгляд - получается так: - иммутабельность - централизованное хранение данных - лучше иметь сто функций на один тип данных, чем десять функций на десять типов данных - шейп данных - это контракт, это межмодульный интерфейс
>>871600 > шейп данных - это контракт, это межмодульный интерфейс Это называется duck typing, есть во всех динамически-типизированных языках и некоторых статически типизированных.
Дак тайпинг - про поведение. Крякает как утка, плавает как утка - значит утка и есть. А я говорил про данные. There is no duck.
Более того, дак тайпинг - это про рантаймовые чеки, а шейп данных может чекаться и статически, и динамически (см. typed clojure), суть от этого не поменяется.
>>871631 Мне сложновато понять, потому что у меня в жс неясно чем одно от другого отличается. Вот это дак тайпинг: const f = (duck) => duck.quack(); А вот это шейп данных: const f = (point) => console.log(point.x, point.y); Правильно?
>>871644 Блин, дак тайпинг - это средство полиморфизма. Я понимаю, что в жс пихаешь в хэшмап функции и получается поведение, так что это как будто одно и то же, но это все-таки разное. Блин, мне теперь уже самому интересно сформулировать так, чтоб было понятно, сейчас попробую.
Вот смотри, надо тебе сделать утку, которая может квакать свое имя, да? В жс ты пишешь конструктор дак(нейм), например, сохраняешь имя, потом пихаешь в прототип Квак() и там квакаешь, верно? У тебя объект, мутабельный объект, ты ему присваиваешь значения в this, функции в него пихаешь, это объект. В клж тоже так можно сделать, но никто так не делает. В клж ты бы написал "конструктор" (если захотел бы, конечно) так:
(defn duck [name] {:duck/name name})
Видишь, это обычная функция, которая возвращает обычный иммутабельный хэшмап, который никак не связан с этой функцией. Нет никаких this, мы просто возвращаем кусок данных. Потом пишем другую функцию, квак, - и вот здесь становится очень похоже на дак тайпинг: она принимает любой хэшмап, в котором есть ключ :duck/name, и что-то там с ним делает. Но! Во-первых, она не метод у объекта дергает, эта функция. Нет никаких объектов и методов, она просто перемалывает данные, как если бы у тебя функции по хттп-рест протоколу общались. Она не может ничего со своим аргументом сделать, ей не приходит "ссылка" на него, ей приходит просто кусок данных, на основе которого она возвращает новые данные.
Во-вторых, вот представь, что у нас в системе есть человек-паук и человек-утка. И есть две подсистемы, написанные другими людьми, одна из которых работает с людьми, а другая - с животными. И нам надо человека-утку прогнать по обоим системам. Тогда мы создаем такой хэшмап:
- и отдаем его подсистемам. То есть смотри, если бы у нас были объекты с дактайпингом, то нам пришлось бы, например, создавать композитный объект, включающий два объекта с одинаковыми методами, да? Потому что у нас бы метод нейм объекта дак был бы привязан к объекту дак, а метод нейм объекта пёрсун был бы привязан к объекту персун, да? А здесь у нас нет никакой вот этой связи, у нас тупо данные: хэшмап, в котором кейворды в ключах и строки в значениях. И совершенро пофиг, откуда и как они в нашей мапе появились и кому они "принадлежат" - это тупо данные, они никому не принадлежат, они просто лежат и все.
Вот, надеюсь, удачный пример получился. Можешь еще посмотреть на хттп-стек кложурный - там в общем-то та же идея. Есть куча разных серверов и провайдеров. В джаве, например, они все должны были бы реализовывать какие-то стандартные интерфейсы, чтобы можно было один на другой заменить, да? А здесь просто есть единая спека, которая оговаривает, какие данные должны лежать в реквесте и какие данные должны приниматься в качестве респонса - и вот это и есть интерфейс, который реализуют все кложурные хттп-серверы. Или, например, есть куча тулз для шаблонизации или генерации разметки. И все они работают с одной и той же структурой данных: [:html [:h1 "saussi hooee"] ...] - видишь, это даже не хэшмап, это дерево из векторов. Ну ты же не назовешь это "дактайпингом", согласись?
Короче, блядь. Надо блог начать писать, а то это пиздец какой-то, столько букв на мейлруче нахуяривать.
>>871585 это все довольно круто, но ом все равно выглядит многословным и страшным. Вот пример с видео на re-frame. Первый - более красивый вариант, второй - больше похож на то, что в видео. Я конечно таки прочитаю про ом/некст, когда буду делать следующий проект
>>871700 Не, ом - для HUUUGE проектов, он труднее и сложнее для изучения, тут даже говорить нечего, это факт. Но он и дает больше. Я не говорю, что реагент\рефрейм не очень, они тоже охуенные. Просто изначально же анон что-то спизданул про то, что х-ль круче кложи в плане реакта, а на самом деле ом.некст - это вообще самый блидин ейдж из всего, что сейчас есть в клиент-сайде, такие дела.
>>871748 Ну это явно мимо меня, лол. Я пишу магазин, которому и реакт-то не нужен в принципе, мне просто делать нечего. А найти работу на кложе в своем РБ мне не светит никогда.
>>871753 а так я пока смогу использовать clojure лишь в фриланс-проектах, ибо заказчику в принципе похер, что там под капотом (этот магазин - тоже фриланс проект).
писал на Scheme симуляцию дейсвтий агентов генетическими алгоритмами. интересно продолжить в процессе перейдя на haskell, для его практики. посоветуйте материалов/библиотек по подобному. что-то вроде генетических алгоритмов над dsl. немного знаю parsec.
>>871692 > :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 для объектов одних и тех же классов будет использовать одинаковый гибридный прототип. Но на жс по дефолту такую конвенцию именования полей и методов никто не использует, потому сработает только в рамках своего мирка - в лучшем случае фреймворка и его экосистемы.
>>871781 > В жс можно выдумать себе конвенцию Ну как бы можно и срать, не снимая свитер, только так никто не делает, сам понимаешь. Алсо, мой поинт был не в том, что мы какие-то особые имена используем, а в том, что нет никакой утки - а у тебя даже со сраньем через свитер дак_нейм - это метод дака, угу?
В кложуре так реально делают, да, это официальный(тм) правильный(с) рекомендованный способ. Недавно выпустили (точнее скоро выпустят) такую штуку, как clojure spec, которая позволяет очень гибко описывать эту самую форму данных, о которой я говорю, и потом генерировать на ее основе документацию, рантаймовые контракты\ассерты, валидаторы, делать преобразования (типа парсинга строки с числом в инт), ну и самое главное - генерировать тесты на основе спецификации. Это довольно охуенно, если честно. Если бы я не использовал генеративное тестирование раньше, у меня бы голова взорвалась от охуения, лол.
Ну и там как бы с самого начала был удобный сахар для этого, типа если пишешь ::keyword, то это разворачивается в :my.ns/keyword, ну и подобные штуки. Плюс датомик тоже очень heavy использовал эту модель, а он пару лет назад появился. Ну, разумеется не надо каждый кейворд префиксировать неймспейсом, если у тебя по определению задачи не может быть пересечений и вообще нет разных энтитей, то нафига лишние буквы писать? В хттп стеке, например, без префиксов, просто :request-method, :uri и все такое прочее.
>>871851 Ээ... окей, держи нас в курсе? Я не знаю, что тут содержательного можно ответить - ты просто выразил очень туманное мнение, ничего не сказав по сути. Ты не стесняйся, говори, если что, гхм.
>>871889 Ну, если нет иммутабельности, то нет данных. 1 - это число. Нельзя изменить 1, дазнт мейк сенс. Можно только взять другое число. Это данные. [1 2 3] - это данные. Нельзя изменить [1 2 3]. Можно взять другой вектор с другими числами, но нельзя изменить число или вектор чисел, дазнт мейк сенс. Это данные. {:name "rich"} - это данные. Нельзя изменить данные, можно только выкинуть одни данные и поставить на их место новые. Идентити, вот это все. Икс равно один. Потом икс равно два. Мы не меняли единицу, мы просто привязали имя к новому значению. Даннын иммутабельны.
>>871903 Если в языке есть мутабельность, это не значит, что обязательно всё мутировать. В реакте (с редуксом) вон всё построено на иммутабельных редюсерах и норм.
>>871916 Ну так иммутабельное подмножество жс может быть дата-ориентед. Или жс, в котором по умолчанию используются иммутабельные структуры. Только это уже не то, что обычно подразумевают под словом "жс", угу? Алсо, не путай "можно не мутировать" и "нельзя мутировать". Это разные вещи, концептуально.
Короче, если еще остались какие-то непонятки - посмотри talk Рича, rich hickey value of values youtube. По-моему так называется, если не путаю. Да или любой другой посмотри, они все достойные и полезные, если у тебя есть пара-тройка лет экспириенса.
Хороши ли функциональные языки для машинного/глубокого обучения и подобного? Если да, то на какой язык стоит обратить внимание, возможно clojure или haskell?
>>872201 Да, потому что крайне удобно вертеть коллекциями и вообще любыми данными. Можешь выбрать из этих двух, да + F#, Scala ещё, вроде популярны в этих областях.
>>872201 Неплохи, но специализированные ЯП вроде R и Octave - лучше, потому что они прямо заточены под это. Там и матрички удобно по всякому складывать и перемножать друг с другом, с векторами и скалярами, и куча всяких встроенных алгоритмов, численных и символьных методов.
Вопросы по ФП. (В основном по Хаскелу). 1. Я правильно понимаю, что функции в ФП имеют только локальные переменные, это и есть основная суть? 2. В ФП внутри функций можно создавать функции, и будут ли внутренние функции строго локальными? 3. Если п1 верен, то получается что на многих языках можно свести все детали программы к функциям, так? 4. Могут ли функции открывать и менять внешние файлы, можно ли прописать в них такие инструкции, и как это соотносится с П.1?
>>872231 Ну так раз ты решил осваивать хаскель, то возьми книжку про хаскель и прочитай ее, ээ? У тебя совсем детские вопросы, не вижу смысла отвечать, если честно. Возьми и прочитай книжку, если что по ходу дела непонятно будет - спрашивай тут.
Ну, разве что по четвертому пункту скажу. Если грубо, то твоя программа просто составляет рецепт: сходи туда-то, возьми такой-то файл, что-то с ним сделай, положи обратно. То есть она сама ничего не делает как бы, она просто составляет список указаний. А потом рантайм уже берет эти указания и что-то там делает с реальным миром. Поэтому твоя программа как бы не при делах, она остается чистой. Это один из подходов, есть и другие.
Но еще раз - возьми и прочитай книжку, не трать время попусту.
>>872246 >Но еще раз - возьми и прочитай книжку, не трать время попусту.
Книжки это хорошо, тольку какую книжку-то? Эта http://anton-k.github.io/ru-haskell-book/book/home.html норм?Я с learnyouahaskell начал, поэтому и возникают вопросы весьма примтивные, сам не совсем понимаю что там происходит.
>>872231 1. переменных нет, только переменные-термы. Суть - в бета-редукциях термов (т.е. подстановках). 2. что значит 'создавать функции'? 3. ничего не понятно. 4. как и обычно - функцция выводит информацию в файл.
>>872231 1. Никаких переменных вообще не существует, забудь про них. Вся информацию в функциях хранится в аргументах, которые она передает другим функциям, в том числе и себе, иначе тут никак. Создается неплохая аналогия с засовыванием собственного члена себе же в анус. 2. Ничего не создается, там все "определяется", как в математике. Можешь внутри функций определять другие функции, и их имена будут доступны только в пределах определения этой функции. Чаще всего используются анонимные (задроты-математики называют их "лямбда") функции, когда определяешь и используешь функцию на месте, без имен. 3. Не верен. Не понятно, что ты имеешь в виду. Процедурные языки и так состоят из "функций" на своем понимании, главно является какая-нибудь main. Просто в императивных языках функция - это последовательность действий, а тут это имеет более математический смысл. 4. Не понял вопроса. Тут все является функцией, иначе и никак.
>>872319 Дочитывай learn you a haskell, потом можешь попробовать real world haskell, если решишь, что это тебе нужно. Хрюсских переводов опасайся: имел опыт наблюдать, как из переведенной версии какой-то книжки вырезали все задачи и кучу дополнительного материала.
>>872365 Там очень примитивно и дружелюбно азы рассказываются. Мне она помогла влиться в эту функциональную содомию, ибо все остальные книжки нихуя не понятны были. К тому же маленькая, как раз для введения и решения, нужно оно человеку или нет.
>>872364 Просто ты сказал "не совсем понимаю, что там происходит", и ссылку на русский текст дал, вот я и подумал, то ты не понимаешь из-за того, что с английским не очень... нутыпонелкорочи.
>>872365 Человек только вкатывается в функциональное программирование вообще, а тв ему репорт советуешь читать. Не надо так.
>>872579 Нихуя себе! А мужики и не знали, спасибо тебе брат!!
>>872577 О, точняк, спасибо. Хм. Правда у меня такое ощущение, что там вся эта лабуда идет от какого-ибудь апл, нет? А у категорных чуваков что, у всех мапы?
>>872541 Почему логичнее? Суть мапа же — отобразить одно множество в другое, используя данную функцию, а не применить функцию ко всем элементам множества.
Юный хачкелист вкатился. Вот читаю я данные (продукции) из .txt вида First -> one Foo Foo -> bar one two Идентификаторы сущностей (назовём их Symbol) для дальнейшей обработки мне не важны, но их нужно хранить для ввода/вывода. Сами Symbol'ы будут двух видов (Term, NonTerm), при чтении вид определяется сразу (по кейсу первого символа идентификатора например). Так вот, как хранить это всё? В императивщине я бы заносил идентификаторы в "словарик" и во внутреннем представлении заменял их на Int/Byte. В Хаскеле аналогом наверное будет data Symbol = Term Int | NonTerm Int + "словарик" Map. Только похоже что если заменить Int на String то словарик не понадобиться, на сами алгоритмы обработки это не повлияет, только работать всё будет медленнее.
>>872771 "->" в исходном .txt никакого отношение к синтаксису Хаскеля не имеет, если что. Внутреннее представление для одной строки "First -> one Foo" будет что-то вроде data Product = Product Symbol [Symbol] Вопрос в том как правильнее хранить Symbol - как строку (+ конструктор над ней) или переводить в Int + словарик для ввода/вывода. Или ещё что-то.
>>872781 Я не понимаю, откуда ты инты взял? Если у тебя там любаы строка может быть - то это, очевидно, строка. Если у тебя там конечный фиксированный набор идентификаторов - то это Foo | Bar | Baz...
>>872781 >как правильнее Никак. Это зависит от того, что и в каком объеме ты будешь с этим говном делать. Простой ответ - сделай и так, и эдак, протестируй что тебе там надо. А в остальном коде поменьше используй внутренности этого типа, определи пару "комбинаторов" для простых операций, меньше потом переписывать придется (но все равно придется).
И я про стрелку ничго такого и не думал, блин, про хаскель и его синтаксис я вообще ничего не имел в виду. Ты нарисовал хэшмап из строк (ключи) в списки строк (значения). Я это имел в виду.
>>872797 Он, по всей видимости, хочет занумеровать попадающиеся строки, хранить в Product только инты и спрашивает, будет ли так быстрее. </телепат-моде>
>>872802 Ну я тоже так подумал, но не увидел в этом смысла и решил, что причина в чем-то другом. Вообще, если у него файл меньше десяти гигов, то об оптимизации думать, наверное, не следует.
>>872812 И какие операции ты можешь выполнить с инт, но не можешь выполнить с поинтером, а?
>>872812 А, ну так бы и сказал, что ключи у тебя могут повторяться - из твоего первого поста это никак не следует же. Тогда список пар из строки и списка строк, не?
>>872810 Х-ль не требует тотальных функций, в идрис ты тоже вполне можешь пользоваться не тотальными функциями, так что в общем случае да. Про кук/агду не знаю ничего.
>>872817 >И какие операции ты можешь выполнить с инт, но не можешь выполнить с поинтером, а? Хм, и правда ведь. Впрочем массив уникальных строк и поинтеры в качестве ключа - это и будет словарик. >>872817 >А, ну так бы и сказал, что ключи у тебя могут повторяться - из твоего первого поста Не уверен что понимаю что ты подразумеваешь под "ключами". Один и тот же <Symbol> (точнее в левой части может быть только подтип <NonTerm>) может стоять в левой части нескольких продукций, да.
>>872827 А как бы их по-твоему написали, все эти агды и идрисы, если бы их было нельзя реализовать на машине Тьюринга? Ты что-то другое хочешь спросить или сильно тупишь.
>>872781 Ты поаккуратнее с такими картинками. Не забывай, что харкач теперь принадлежит мейл ру. Забыл, что началось в ВК, когда тот перешел во власть этой фирмы? Тонкая подсказка: 282.
>>872838 >Ты что-то другое хочешь спросить или сильно тупишь. 1) Вот это https://en.wikipedia.org/wiki/Intuitionistic_type_theory можно рассматривать как простой набор правил для машины Тьюринга? 2) Или наоборот, машина Тьюринга частный случай этого? Или пункты 1 и 2 равнозначны?
>>872823 Надо бы еще лиспопетушиных сепаратистов обратно аннексировать. А то хули, язык их на три порядка менее популярный, чем ниспосланный свыше божественный Хаскелл, а в свой отдельный тред укатились.
>>872877 >ниспосланный свыше божественный Хаскелл Который зашкварили любители мыслительного онанизма, засрав его тоннами бесполезных сущностей и тем самым отпугнув вменяемую часть сообщества.
>>872872 Я с телефона, нормально оформить не смогу, извиняюсь.
>>872877 Ну все-таки коммон лисп и елисп к фп имеют весьма опосредованное отношение, а там обсуждают в основном их. Так что мне кажется, что все правильно: кложурь тут, коммон лисп там. Так удобнее.
>>872967 Не рад там только один шизик. Это ты, нет?
>>873046 Короче, надо добавить книжки, переведенные нашим русскоязычным фп-сообществом. Это 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, это скорее справочник, чем последовательное повествование. И есть несколько интродакшенов, я их не смотрел даже, может кто еще посоветует, какой лучше. Короче, основная книжка - риалворлд окамл. Да, и надо указать, что окамл без джецнстрит/коре или баттерис - не окамл. И еще надо написать, как дев енвайронмент развернуть, мерлины вот эти все, ой, пиздец короче. Хуй с ним, потом как-нибудь, главное - риал ворлд окамл и джейнстрит коре.
Кложур, ох, я писать уже устал, попозже постараюсь продолжить.
>>873057 >tapl >sicp >htdp Толсто. >Why functional programming matters Читал. Было много факториалов и фибоначчей, а вот почему functional programming matters - это автор рассказать забыл. >real world ocaml That's a fucking joke.
>>873057 >надо добавить книжки, переведенные нашим русскоязычным фп-сообществом. Тебе сюда, пидорахен → >>872359 >Хрюсских переводов опасайся: имел опыт наблюдать, как из переведенной версии какой-то книжки вырезали все задачи и кучу дополнительного материала.
>>873070 Я лично читаю книги на языке оригинала. Это раз. Пидорахен - это ты. Ты хамло и быдло, неспособное в логику и понимание текста. Типичный пидорахен. Это два. Если из одной книжки что-то там вырезали, то это не значит, что во всех переведенных книжках что-то вырезают. Ошибка. Это три. Наконец, раз ты не в курсе, кто и как переводил эти книги и почему они местами даже лучше оригиналов, тебе следует либо заткнуться и учиться, либо проследовать в другой тред. Без обид.
>>873057 Если рекомендовать tapl, тогда уж и Барендрегта нужно тоже. И вот ещё, стоит ли рекомендовать "Параллельное и конкурентное программирование на языке Haskell"?
>>873057 Поясните за монаду. Это класс типов или экземляр класса типов или тип данных или что? Вот есть класс типов - объявленные функции без их реализации привязанной к конкретному типу данных (хотя да, можно определить реализацию функций по умолчанию). Если мы хотим, чтобы наш тип данных принадлежал к этому классу типов, мы для нашего типа должны реализовать все функции, объявленные в этом классе типов. Вроде я нигде не обосрался, ок. Есть класс типов Monad, в нем объявлены четыре функции, ок. Тогда, допустим, монада IO - это экземляр класса типов Monad для типа данных IO, то есть фактически реализация функций, объявленных в классе типов Monad для типа данных IO? Тогда что есть тип данных IO? И собственно где реализация этих функций класса типов Monad для типа данных IO?
>>873078 Барендрега что? Про лямбда-исчисление? Она "введением в фп" Харриса не покрывается разве?
"Параллельное..." я не читал, если честно. Стоит или необязательно? Для новичков, наверное, это не очень нужно, а неновичок и сам найдет... но слышал много хороших отзывов о ней, так что почему бы и не добавить, угу. Баззворды к тому же.
>>873082 Ну так и нахера ты тогда спрашиваешь совета, если не способен его воспринять? Ты же понимаешь, что лично мне похуй, шапка тут или хуяпка, но если человек просит помощи, то мне совершенно несложно поделиться опытом. Так что ты уж определись, хочешь ты что-то полезное запилить или как малолетка какашками перекидываться.
>>873053 Ну потому что это разные вещи. Какой еще "набор правил для машины Тьюринга"? Есть тьюринг-полнота. Если какая-то система тьюринг-полна, то это не значит, что она является "набором правил для машины тьюринга". Это значит, что это другая система с той же выразительной силой. То есть для любой программы, которую можно написать на машине тьюринга, есть аналогичная программа в этой другой системе. В частности, обычный способ доказать, что твоя система тьюринг-полна - это написать на ней реализацию машины тьюринга. Но если твоя система тьюринг-полна, то ты сможешь написать в ней такую программу, которая никогда не завершится, и ты никак не узнаешь, зависла она или все еще что-то делает. То есть это как бы плохонько.
Агда и кок, насколько я знаю, не тьюринг полны - именно по этой причине. То есть там любая программа гарантированно завершается и не виснет, если она скомпилировалась. Это, разумеется, сознательный выбор, а не какая-то проблема или ограничение.
Блять, только хотел обмазаться красивым кодом с юникодными операторами и тут хуяк - оказалось что в Атоме подсветка не выделяет инфиксные дата-конструкторы. Поправьте это дерьмо кто-нибудь, плиз.
>>873046 https://youtu.be/IOiZatlZtGU - еще вот этот talk надо обязательно добавить, сразу разъясняет новичкам что это, зачем это и почему это так, да и вообще расширяет сознание не хуже лсд. К тому же Вадлер - прекрасный лектор.
>>873057 Добавь "Developing Applications With Objective Caml", стандарт описывается старый, но для ознакомления пойдет. Тем более, есть перевод на русский. Ну и официальная документация. http://caml.inria.fr/pub/docs/manual-ocaml/ >real world ocaml Это скорее real world janestreet
>>873308 > real world janestreet Ну так риал ворлд окамл без риал ворлд джейнстрит невозможен, без риал ворлд джейн стрит окамл получается совсем не риалворлд. Так что все ок. К тому же "а где стдлиб?!" - самый частозадаваемый камловопрос.
Вот, уже нормально так книжек по камлу в целом получается, кстати.
>>873325 >Ну так риал ворлд окамл без риал ворлд джейнстрит невозможен Ты плохо знаешь "риал ворлд" окамля, janestreetовские библиотеки далеко не все намного меньше, чем может показаться используют
>>873325 Как бы там Минский не петушился, но реал ворлд - это 90% десктопов на винде. У них же просто большая программа, под которую они могут покупать железо и подбирать систему. Это одна программа, для одной системы, заточенная под определённые условия. Пусть и огромная. Это не риал ворлд даже близко. Более того, сама книга должна была называться "смотрите, мы сделали ещё одну стдлибу, потому что нативная окамловская бесикалли нонэкзистент". Да и он сам же плакался, что даже на линуксах всё хуёво, например, с гуями, и они их вынуждены делать на ncurses.
По поводу Haskell. Язык относительно старый(релиз 1990 год). Так вот, насколько быстро его развивают разработчики, успевает ли он за новыми тенденциями комп. наук. Я вот на вики посмотрел, что ласт релиз состоялся в 2010 году, 6 лет назад. Если взять cpp, то там обновления выходят раз в три года. Извините, что-то у меня не особо нагуглилось, пожалуйста, не пишите, что я тупой, а просто опишите текущее положение вещей(развитие Haskell'a)
>>873352 Хуёво там всё. Нормальных объектов так и не завезли за всё это время. Методов нет, приватных полей нет, наследование через жопу и так далее. Настолько устаревшее говно ещё поискать.
>>873356 Ну это неправда. Туда каждый релиз ghc завозят кучу всякой новой астральной хуйни - всё что угодно, только не записи/объекты. Уже вон скоро модуле/сигнатуры (Backpack) добавят, но только не объекты. Просто SPJ походу бесят записи и объекты в любом виде и он всеми силами подавляет это дело. А лично меня ещё больше чем отсутсвие нормальных записей/объектов бесит пиздец со строками. Когда в ёбаном скрипте на 50 строчек раз 20 конвертить между Text, ByteString.Strict, ByteString.Lazy, String.
>>873352 Найс, порадовал зелёный. На всякий случай, если ты не толстишь, и действительно глуп, хачкель и создаёт новые тенденции, которые > раз в три года перенимают всякие кресты, расты и жабы
>>873133 >Если какая-то система тьюринг-полна, то это не значит, что она является "набором правил для машины тьюринга". Это значит, что это другая система с той же выразительной силой. Разве то, что система тьюринг-полна не означает, что эту систему можно построить в виде соответствующей ей машины Тьюринга, задав соответствующие правила? Мне вот этот момент непонятен. >То есть для любой программы, которую можно написать на машине тьюринга, есть аналогичная программа в этой другой системе. Даже из такого твоего определения прямо следует, что система равна по возможностям машине Тьюринга, если на ней можно сделать то же, что и собственно на машине Тьюринга. Разве нет? >Агда и кок, насколько я знаю, не тьюринг полны - именно по этой причине. То есть там любая программа гарантированно завершается и не виснет, если она скомпилировалась. Т.е. такие языки можно реализовать на машине Тьюринга?
>>873352 В 2010 году вышел последний стандарт языка. Все новые фичи добавляются в качестве расширений компиляторов, и уж потом, через несколько лет, если они докажут свою полезность и незаменимость, их добавляют в стандарт - обязательный минимум, который должен реализовать компилятор, чтобы называться компилятором хаскеля.
А последний релиз основного уомпилятора, гхц, состоялся в мае этого года. И да, действительно: хаскель - де-факто стандартный современный язык ученых\логиков\математиков, которые занимаются языками программирования. Так что да, хаскель во многом и создает новые тенденции. Впрочем, кложурь и даже раст тоже в какой-то мере могут этим похвастаться - правда, на более прикладном уровне.
>>873390 > система равна по возможностям... если на ней можно сделать то же (самое) Привет, КО! Тебе это утверждение не кажется тавтологичным?
> такие языки можно реализовать НУ ТАК ЕСЛИ ИХ КОМПАЙЛЕРЫ НА КОМПЬЮТЕРЕ НАПИСАЛИ И СДЕЛАЛИ И ОНИ РАБОТАЮТ ТО САМ ТО ТЫ КАК ДУМАЕШЬ А?!!!!!12111? Тебе ведь еще несколькими постами выше ответили на этот вопрос.
Я, короче, уже вообще запутался. http://cs.stackexchange.com/questions/19577/what-can-idris-not-do-by-giving-up-turing-completeness Там пишут, что идрис и агда тьюринг-полные! >>873479 Но выше предыдущий оратор >>873045 пишет, что MLTT нельзя свести к правилам для машины Тьюринга. Таки ведь можно же, раз эта ебулда на камплюктере работает, в виде той же агды или кука (хотя там и СоС, но в целом сорта же). >Привет, КО! Тебе это утверждение не кажется тавтологичным? Мне вполне очевидно, что это одно и то же. Однако, тот кому я отвечаю, так не думает.
>>873485 Ты бы хоть прочитал ответ-то по этой своей. Там пишут, что Идрис тьюринг-комплит (про идрис итт никто не говорил), а петух - нет. Читай внимательнее.
>>873485 Ты мне отвечаешь, але. И я тебе как бы намекаю, что ты сказал "масло масляное, если оно масляное". И теперь ты мне говоришь, что я так не думаю. Чего вообще блядь?!
В >>872845-посте ты спросил фигню, вот тебе и ответили на ту фигню, которую ты спросил, а не на то, что ты хотел спросить. Является ли itt набором правил для мт? Ээ, нет, не является. Является ли табуретка диваном из-за того, что на них обоих можно сидеть, а еще можно разобрать диван и сделать из него табуретку? Выше тебе это уже объяснили и очень подробно. Давай, не ленись и прочитай ответы внимательно.
>>873498 >Является ли itt набором правил для мт? Ээ, нет, не является. Но сводима же к таким правилам при желании? Выразима же в виде набора правил для машины Тьюринга? Я об этом. А то что это разные вещи, я понимаю.
>>873504 Так тебе ведь уже три раза сказали, что да, выразима, на машине тьюринга можно написать программу, которая принимает на вход программу на петухе и выполняет ее. Если бы этого нельзя было сделать, то у нас и петуха не было бы, и агды, и всего остального, а оно у нас есть, да?
А, кстати: >>873390 - вот, про тьюринг-полноту ты тут все перепутал, потому что не прочитал внимательно пост, на который отвечал (прочитай). Если что-то можно реализовать на мт, то это что-то от этого не становится тьюринг-полным, ээ. На мт можно реализовать программу, которая всегда возвращает 1. По-твоему получается, что из-за этого любая система, которая берет на вход что угодно и возвращает 1 тьюринг-полна. Очевидная ошибка, не? А вот если ты на своей системе можешь написать реализацию мт, то она тьюринг-полна. Ок?
>>873509 >По-твоему получается, что из-за этого любая система, которая берет на вход что угодно и возвращает 1 тьюринг-полна. Очевидная ошибка, не? По-моему получается, что такая программа есть частный случай машины Тьюринга, т.к. реализуема на ней в виде набора правил. То, что такая программа не тьюринг-полна, это я понял, ок. >Так тебе ведь уже три раза сказали, что да, выразима, на машине тьюринга можно написать программу, которая принимает на вход программу на петухе и выполняет ее. Если бы этого нельзя было сделать, то у нас и петуха не было бы, и агды, и всего остального, а оно у нас есть, да? Т.е. тут имеем случай, аналогичный предыдущему в этом посте - на машине Тьюринга реализуется нечто, не являющееся тьюринг-полным, но зато являющееся реализуемым на машине Тьюринга. В данном случае это что-то - MLTT. Так? Меня вот этот >>873045 пост смутил, я его понял как утверждение о невозможности свести MLTT к набору правил для машины Тьюринга.
>>873515 >такая программа есть частный случай машины Тьюринга Есть машина Тьюринга - это некий закодированный по определённым правилам алгоритм, который что-то делает. Например, записывает на ленту (возвращает) единицу и останавливается. А есть универсальная машина Тьюринга - это тоже алгоритм, но сам он лишь принимает описание других машин Тьюринга и выполняет их. Можешь считать её мт высшего порядка. Так вот, Тьюринг-полнота - оно про последнее.
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]). Объясните вообщем
>>874524 Ты не даун, я минут пять втыкал в этот код, лол. А разгадка одна: я пытался ее понять методом пристального взгляда, а потом сдался и просто мысленно протрейсил выполнение. Эх, а вот звали бы меня Саймоном, я бы мог просто посмотреть и осознать, как она работает.
>>875301 Слишком мало пустых строк, добавь еще. Это сарказм, если че. И где Alejandro Serrano Mena Beginning Haskell: A Project-Based Approach? Уже есть переовод в электронной версии
>>875424 > Слишком мало пустых строк, добавь еще. Это сарказм, если че Нибейте Я просто полусонный все это собирал, вот и получилось коряво. > И где Alejandro Serrano Mena Beginning Haskell: A Project-Based Approach? Уже есть переовод в электронной версии У меня кстати он есть, потом залью >>875315 > динамикодрисню > Haskell Real World OCaml en: http://rgho.st/6gCfxmLyy Это все что я нашел по этому языку
Кстати Haskell ради добра оказался только фрагментом, а не полной книгой Сори
>>875301 Даже половины >>873057-поста нет, зато хуева куча отступов. Не, брат, не пойдет. Да хотя похуй, перекатывай уже с любой, просто добавь тот пост на гистгитхаб, например.
>>875573 > Это все что я нашел Тот пост + >>873308 еще. Короче, кто-нибудь, схороните эти посты на гист, а тред - в архивач, поставьте ссыдки в шапку, кто захочет - все найдет.
Функционального программирования тред.
Пилите статьи для изучения, истории личного опыта, мысли о сабже.
Меня, и, думаю, анона тоже интересует все!