Вроде же был где-то верблюдотред. Утонул что ли?
не нужон, ведь есть ф#
/thread
/thread
Как раз проприетарная пораша не нужна.
не траль, умоляю
Я не тралю. Серьезно, какого хуя я должен зависеть от конторы, которая по своему желанию развивает язык и инфраструктуру? Посмотри на ту же Джаву, как там годами проталкивают фичи, которые уже давно везде есть.
JS-макака ИТТ. Познакомился с языком в общих чертах ковыряя bucklescript, вкатился легко из-за знания SML. Люблю язык за паттерн матчинг, type inference и exhaustivenes check. Теперь пишу либы на OCaml и транспайлю в JS, брат жив, зависимость есть.
Подписался.
GIL до сих пор не выпилили?
>пишу либы на OCaml и транспайлю в JS
Пили кулстори. Для себя или нет? Как в контору протащил? Лид не бугуртит?
Вроде выпилили почтискороочень скоро
Еще вроде недавно добавили sequence api, как в кложе.
Кто его вообще в реальности юзает-то?
Французы всякие в рисечах своих. Ользо, на верблюде написан компилятор языка Haxe тоже французы пилят в основном.
Так я не про верблюд, а про решетку.
Не понимаю, почему он слабо распространен в индустрии. Поддерживает разные парадигмы, компилируется в быстрый код, вывод типов и куча других полезных вещей. Но код пишут на ебучей Джаве все равно.
Маркетинг же. Джава была создана, чтобы переманить армию крестомакак на сановский стек.
Я сам вынужден, к сожалению, на Джаве программировать, потому что на ней дохуя работы. Но сейчас изучаю верблюда и охуеваю, насколько он более продвинут. Джава - дно ебаное, новые фичи добавляют раз в 10 лет, вывода типов нормального нет, пишешь хуеву гору строчек, для чего в других языках надо написать одну-две.
Ну, по сравнению с крестами она была в свое время прорывом. При том, что common lisp и smalltalk уже вовсю были в 80-ые, да.
А с чем связана низкая популярность OCaml? Только в маркетинге дело? Или макаки слишком тупы, чтобы его осилить?
Для себя конечно. Я пока еще работаю не в вебе.
Ну я же вроде написал: - армию си-макак нужно было пересадить на кресты, потом на джаву, потом сисярпы всякие и заверте... Из-за этого в мейнстриме все с опозданием на четверть века идет.
Какие перспективы у сабжа?
Ну, последнее время динамика у него хорошая, вон даже фейсбук в него вложился со своим ризоном. Но мейнстримом он в ближайшие годы конечно не станет. Как минимум ознакомиться до уровня "могу читать код" однозначно стоит.
Фейсбук готовит большой камбек для OCaml, скоро увидим.
На джаваскрипт фронте весьма вероятно обойдет Elm, Purescript и ClojureScript по популярности.
>Elm, Purescript и ClojureScript
Они в сумме хотя бы десятую часть популярности react|angular|vue набирают?
Несколько раз пытался просто ради интереса начинать учить, но так и не понял зачем он нужен, при наличии Haskell, Scala, Rust, Erlang.
Они все используют реакт, кроме Elm
Просто усиленно рекламируют, а эльмами всякими никто особо не пользуется
https://ashleynolan.co.uk/blog/frontend-tooling-survey-2018-results#js-transpilers
Т.е. скорее будет еще одна секточка, а не конкурент typescript'у, как им хотелось бы.
Вряд ли кто-то реально верит что это конкурент TS. Цель скорее быть номером 3, после JS и TS
>Они в сумме хотя бы десятую часть популярности react|angular|vue набирают?
>Вряд ли кто-то реально верит что это конкурент TS.
По возможностям TS значительно уступает Elm.
У Elm только йоба-фп и крутая система типов.
А TS - это инфраструктура (definitely-typed, vscode) + поддержка от M$ + простота в освоении (можно импортить нетипизированный js) + охват аудитории (от тех, кому просто нужен intellisence до людей, заморачивающимися над типами - strictNullChecks, всякие типы-обертки Pick, Exclude и т.д.). Фактически это лесенка из нескольких языков от "просто js" до языка js-подобного с неплохой типизацией.
короче, рыночек порешал
стартовые позиции так себе - фактически reason привязан к одному фреймворку, пусть и самому популярному пока - но это может рано или поздно измениться, также они конкурируют с собственным flow - т.е. в результате кто-то, очевидно, заглохнет.
https://ahrefs.com/de/jobs/reasonml-developer
>Our frontend is implemented mostly in React.js with some ReasonML. As such, proficiency in ReasonML is very much appreciated, otherwise a strong inclination to intensively learn ReasonML in the short term will be required. Knowledge of other functional languages (OCaml, F#, Haskell, Scala, etc) or concepts will be helpful. (If you’d rather prefer working with functional language on the server-side, consider our OCaml position).
>Remote
>Singapore, modern office in CBD
>USA, San Francisco downtown
>Competitive salary oh boy...
>Our frontend is implemented mostly in React.js with some ReasonML. As such, proficiency in ReasonML is very much appreciated, otherwise a strong inclination to intensively learn ReasonML in the short term will be required. Knowledge of other functional languages (OCaml, F#, Haskell, Scala, etc) or concepts will be helpful. (If you’d rather prefer working with functional language on the server-side, consider our OCaml position).
>Remote
>Singapore, modern office in CBD
>USA, San Francisco downtown
>Competitive salary oh boy...
Он не привязан к фреймворку, просто у них один создатель. В любом случае это единственный нужный фреймворк.
Пиксель перфект верстка - сразу нахуй.
В чем прикол ReasonML? Какие отличия принципиальные от того же Elm?
>В чем прикол ReasonML?
Окамл с нескучным синтаксисом же.
Смысл от этого поделия на фронте? Типы выводить? Они там нафиг не нужны. У него есть киллерфичи как репл у кложаскрипта?
1. Изи интероп
2. Интуитивный маппинг модуля к модулю (дает возможность смешивать с JS и мигрировать по одному файлу)
3. Практичная нечистота.
4. Язык широкого применения (доступны server-side, системное программирование, компиляция в JS и машинный код).
5. ML модули
6. Быстрейший компилятор
>3. Практичная нечистота.
Вот тут поясни. Типа, Хаскель чистый, и там трудно изъебываться со структурами данных и алгоритмами?
Каким образом это киллер фича? У любого функционального языка есть REPL. Но в типизованных языках куда веселее и более "киллер фича" — это игры с тайпчекером.
>У любого функционального языка есть REPL.
Блять, да даже в жабу репл завезли нахуя только, непонятно.
Иметь нечистую реализацию за чистым интерфейсом — одна из киллер фич ML языков, Scala и друзей.
Твоя киллер фича не нужна на фронте, я спросил именно про фронт. И такого же пиздатого репла, как кложы я не видел ни у одного языка.
>И такого же пиздатого репла, как кложы я не видел ни у одного языка.
Что там такого пиздатого? Расскажи, я просто не в курсе.
Это Clojure не предлагает достаточно над JS, чтобы менять шило на мыло, а типы нужны.
>Смысл от этого поделия на фронте?
Действительно, не очень большой, если сравнить с кложей, но это гораздо лучше тех же тайпскриптов и прочих франкенштейнов. Да и окамл норм, чем больше у него платформ - тем лучше.
>1. Изи интероп
))
This is not the REPL you are looking for. Нормального репла в языках ML-семейства нет и не может быть в принципе, потому что модель выполнения не та. Настоящий репл подразумевает возможность подключиться к работающей программе и изменить любую часть ее состояния вживую. Сейчас просто все стали называть реплом любую хуйню, куда можно выражения вводить.
Чистота\нечистота в типах никак не отражается, так что никакой киллер фичи тут нет, не выдумывай хуйни, анон. Во все функциональных языках "нечистая реализация за чистым интерфейсом", Капитан Очевидность гарантирует это.
Не выдумывай хуйни. Тебе REPL расшифровать по буквам?
>гораздо лучше тех же тайпскриптов
Ваши доказательства?
RTFM.
Soundness.
Это уже не REPL
Она никогда не была прорывом, тоже писал на ней и двачую - это дно ебаное. Новые и нужные фичи добавляются медленно и в каком-то адовейше убогом виде, один functional interface или постоянный .equals вместо нормального оператора сравнения, чего стоят. Блядь, да она в 95 году появилась, после пистона, ровесник руби, как вообще можно было выпустить такое говно.
Зачем ты пиздишь, если не шаришь? Само слово "репл" пошло из лиспов, ну и далее все как я описал в предыдущем посте. Ртфм: https://en.wikipedia.org/wiki/Read%E2%80%93eval%E2%80%93print_loop
Не нашел ничего о твоих маняфантазиях про НАСТОЯЩИЙ РЕПЛ. Соси хуй, обосрыш.
>The term is most usually used to refer to programming interfaces similar to the classic Lisp machine interactive environment.
>https://en.wikipedia.org/wiki/Read%E2%80%93eval%E2%80%93print_loop#Lisp_specifics
Ну подучи английский, что ли. Можешь не отвечать на этот пост.
есть ли кстати хоть какой-нибудь редактор, где окамль можно дебажить брейкпоинтами?
смог нагуглить только
https://github.com/hackwaly/vscode-ocaml
но пока еще не пробовал, но судя по всему не очень удобно в больших проектах.
Да и от использования в больших проектах останавливает отсутствие мультиядерности.
Есть конечно
https://github.com/ocamllabs/ocaml-multicore
но интересно заработает ли вообще с ним ocamlldebug
>есть ли кстати хоть какой-нибудь редактор, где окамль можно дебажить брейкпоинтами?
Эм... Emacs. Ты так спрашиваешь, будто существует что-то еще.
Ты не поверишь, но emacs
А в виме что-нибудь есть?
В виме обычно все намного хуже с расширениями.
Просто поставь spacemacs, и у тебя будет искаропки готовый вим внутри имакса со всеми хоткеями первого и всеми расширениями второго.
>emacs
На секунду задумался, но посмотрел какой сегодня год и вспомнил сколько стоит час моего времени для заказчиков.
Видимо все таки f# на .net core единственный легитимный выбор. И мультиядерность есть.
>сколько стоит час моего времени для заказчиков
и сколько же? надеюсь, уже больше чем у стареющей шлюхи в русском мухосранске
Эм, тебе же постом выше написали, как называется настроенный искаропки имакс. Или под временем ты имел в виду изучение вимовских кейбиндингов?
Лол, кейбиндинги не нужно изучать, они должны въедаться в пальцы на бессознательном уровне. Вешаешь перед глазами распечатанный на A4 cheatsheet и вперёд пользоваться.
Зачем ты мне-то это написал? Постом не промазал?
Я аутист прост
bump
В чем преимущества по сравнению с Хаскелем?
Предсказуемое поведение в рантайме, нет подводных камней из-за ленивости.
А ленивость прям уж так эффективна? Ведь нихуя не понятно, что вычисляется, а что нет.
Я говорю: нет ленивости, следовательно нет вызванных ею подводных камней.
В теории ленивые вычисления объективно лучше и мощнее энергичных, но на практике лучше иметь энергичные вычисления по дефолту и ленивые там, где ты явно этого запрашиваешь (например, ленивые стандартные коллекции точно должны быть).
Простота. Большинство языка очень просто для того, чтобы начать на нем писать и понять любому человеку сходу.
Некоторые продвинутые фишки конечно имеются, но они опциональны и избегаются по умолчанию.
Почему тогда пишут на богомерзкой жабе?
Потому что в маркетинг джавы корпорациями вбухано больше денег.
Мультикор допилили?
Хаскель офигенен, но пороговый вход в Окамл ниже, а глубина потенциального погружения почти такая же. + почитайте статью pusher о gc Хаскеля - им пришлось зассать и перейти на go
What makes OCaml special is that it occupies a sweet spot in the space of programming language designs. It provides a combination of efficiency, expressiveness and practicality that is matched by no other language. That is in large part because OCaml is an elegant combination of a few key language features that have been developed over the last 40 years.
...
Some of you will know and love all of these features, and for others they will be largely new, but most of you will have seen some of them in other languages that you've used. As we'll demonstrate over the course of this book, there is something transformative about having them all together and able to interact in a single language. Despite their importance, these ideas have made only limited inroads into mainstream languages, and when they do arrive there, like first-class functions in C# or parametric polymorphism in Java, it's typically in a limited and awkward form. The only languages that completely embody these ideas are statically typed, functional programming languages like OCaml, F#, Haskell, Scala, and Standard ML.
...
The compiler has a straightforward compilation strategy that produces performant code without requiring heavy optimization and without the complexities of dynamic just-in-time (JIT) compilation. This, along with OCaml's strict evaluation model, makes runtime behavior easy to predict. The garbage collector is incremental, letting you avoid large garbage collection (GC)-related pauses, and precise, meaning it will collect all unreferenced data (unlike many reference-counting collectors), and the runtime is simple and highly portable.
https://v1.realworldocaml.org/v1/en/html/prologue.html#why-ocaml
...
Some of you will know and love all of these features, and for others they will be largely new, but most of you will have seen some of them in other languages that you've used. As we'll demonstrate over the course of this book, there is something transformative about having them all together and able to interact in a single language. Despite their importance, these ideas have made only limited inroads into mainstream languages, and when they do arrive there, like first-class functions in C# or parametric polymorphism in Java, it's typically in a limited and awkward form. The only languages that completely embody these ideas are statically typed, functional programming languages like OCaml, F#, Haskell, Scala, and Standard ML.
...
The compiler has a straightforward compilation strategy that produces performant code without requiring heavy optimization and without the complexities of dynamic just-in-time (JIT) compilation. This, along with OCaml's strict evaluation model, makes runtime behavior easy to predict. The garbage collector is incremental, letting you avoid large garbage collection (GC)-related pauses, and precise, meaning it will collect all unreferenced data (unlike many reference-counting collectors), and the runtime is simple and highly portable.
https://v1.realworldocaml.org/v1/en/html/prologue.html#why-ocaml
>The garbage collector is incremental, letting you avoid large garbage collection (GC)-related pauses, and precise, meaning it will collect all unreferenced data (unlike many reference-counting collectors), and the runtime is simple and highly portable.
То есть он компилирует в нативный код, и там при этом есть сборщик мусора?
>garbage collector is incremental
Поясните, чем такой сборщик отличает от того, что в Джаве.
>То есть он компилирует в нативный код, и там при этом есть сборщик мусора?
Да.
>Поясните, чем такой сборщик отличает от того, что в Джаве.
https://en.wikipedia.org/wiki/Tracing_garbage_collection#Stop-the-world_vs._incremental_vs._concurrent
В джаве тоже инкрементал.
То есть в Окамл сборщик мусора как бы встроен в каждую программу?
Эм, ну да, типа того.
Есть какие-нибудь годные плагины для Эклипса или Идеи? Вим, емакс не предлагайте, ну их нахуй, вот честно, заебался дрочить разные эзотерические кнопочки, нихуя не прикольно. Пробовал ставить Атом, но сразу же охуел от его убогости. Где код-то писать?
да, лол
>Где код-то писать?
Хз, я один раз лет 10 назад настроил имакс и с тех пор ни разу не задавался таким вопросом
>Вим, емакс не предлагайте
Предлагаю тебе выбросить компьютер нахуй и не кодировать никогда больше.
Мейлачую
>Предлагаю тебе выбросить компьютер нахуй и не кодировать никогда больше.
Тричую, две самых топовых IDE точнее, топовый текстовый редактор и топовую IDE не осилить - это дно полное.
В зк любой пиздеть горазд. А на деле вы сидите в Эклипсе/Идее/ВижуалСтудии, а вим используете для правки конфигов на сервере, когда припрет. Пиздоболы хуевы.
Сцука, под языки, на которых я пишу, нет готовых IDE. С чего ты вообще взял, что тебе пиздят? Ты думаешь, раз ты не умеешь пользоваться блядь текстовым редактором, то никто не умеет?
Как это все выучить? Ты серьезно дрочил все эти комбинации клавиш и конфиги, чтобы скомпилить хелло ворлд на Окамл?
Это не нужно учить, это въедается в мышечную память. Ты же не "учишь" велосипед?
>Это не нужно учить, это въедается в мышечную память.
Как? Я пробовал в Идее ставить вим-режим, через полчаса охуевания отключил его, все было пиздец как медленно.
>Как это все выучить?
А ты не пробовал потратить на обучение работе за компьютером больше получаса?
АХАХАХАХАХАА
Блядь, хипстерки уже настолько отупели что не способны открыть встроенный туториал в emacs
Ещё раз, учить не надо, просто начинаешь использовать. Что забываешь - смотришь в чит-шите, может быть полезно его напечатать и повесить за монитором. Чит-шит, я надеюсь, без нашей помощи нагуглишь но если что - обращайся
Сколько надо времени, чтобы выйти на нормальную продуктивность?
Хуй знает, я зашел в вим, прошел вимтутор, через те же полчаса-час основные комбинации в руках уже были но сейчас я уже все забыл, потому что я ненавижу вим, но если хочешь вим, то ставь хотя бы спейсмакс, сам по себе вим унылое говно. Ну и это в любом случае лучше, чем постоянно тратить время на потягушечки к стрелочкам и выделение кода мышкой, не?
А по емакс что посоветуешь? Или туториалы дрочить?
По емаксу вместе с туториалом ещё и мануал курить надо. Приятного прочтения!
У меня на то, чтобы перекатиться с vim на spacemacs, ушло недели две-три. А на то, чтобы освоить vim, несколько месяцев азаза
Да хуй знает, я помню в свое время Алекса Отта почитывал, ну и Xah Lee. А так - хз, вроде все сейчас просто ставят спейсмакс и все, у них там все доки свои есть.
Вижу, что потихоньку появляются вакансии по ReasonML. Заебок, наверное буду вкатываться, сейчас учу сам OCaml.
Да, сейчас есть спейсмакс. Там тебе и настроено все и на все случаи жизни, и документация есть.
Мне вот кажется, в Хаскелле поудобнее все сделано, ну то есть там пишешь map или fold и все, а тут надо дергать List.* постоянно.
Читаю Real World Ocaml, там используется Окамл старой версии, половина кода не компилится. Нашел Real World Ocaml версия 2, она в стадии беты сейчас. Может, кому-то будет полезно.
Где нашел-то? Вкидывай, хуль.
Какой профит от такой функции: let compose f g = fun x -> f (g x)
Где это применяется и зачем?
Где это применяется и зачем?
Композиция, фундаментальная операция над функциями. Вот числа можно же складывать? Вот и функции можно. Можешь написать map (fun x -> f (g x)) xs, а можешь написать map (f . g) xs - красивше ведь, не так ли?
>map (f . g) xs - красивше ведь, не так ли?
Красивше, только точка в Окамл не работает. Как вариант, можно такого уродца использовать: List.map (f x |> g |> h) xs.
>List.map (f x |> g |> h) xs
List.map (function x -> f x |> g |> h) xs
fix
Только пайпы - это про другое, к композиции функций они не имеют отношения.
Ну а как правильно делать композицию? И почему пайпы - это другое?
>И почему пайпы - это другое?
Эм, ну потому что пайпы - это применение функции к аргументу, а не композиция двух функций.
>Ну а как правильно делать композицию?
Не понял вопроса. Между compose f g и f . g никакой разницы нет, просто синтаксис разный (я в хаскель-синтаксисе написал). В окамле ты тоже можешь писать так же, если очень хочется: let (.) f g = ..., нутыпонел.
Алсо, рекомендую тебе взять и почитать какую-нибудь книжку по фп, чтобы с основами разобраться, ты сейчас немного плаваешь как мне кажется.
>какую-нибудь книжку по фп
Да я Окамл только недавно начал изучать, до самих концепций еще не дошел. Что посоветуешь почитать?
Короче, я понял, в чем разница.
# let ( << ) f g x = f (g x) ;;
val ( << ) : ('a -> 'b) -> ('c -> 'a) -> 'c -> 'b = <fun>
# let ( |> ) x f = f x ;;
val ( |> ) : 'a -> ('a -> 'b) -> 'b = <fun>
>Что посоветуешь почитать?
хтдп
Конкретно по окамлу и для ньюфагов не знаю (точнее знаю одну охуенную книжку, но она на французском, лол). Можешь какой-нибудь think ocaml навернуть наверное но лучше хтдп, а потом real world ocaml
Ну я и говорю, ага:
>пайпы - это применение функции к аргументу, а не композиция двух функций.
Охуенный типаж, я таким всегда на лицо кончаю, и им нравится. Думаю, эта не исключение.
>точнее знаю одну охуенную книжку, но она на французском, лол
Что за книжка?
llc
Спасибо!
let _ = bump "pr/1196220"
>"pr/1196220"
Нетипизированное говно, как тебе не стыдно такое писать?
Пишем функцию let summ x y = x + y
Самец выводит тип int -> int -> int
Как быть, если я хочу использовать float?
Самец выводит тип int -> int -> int
Как быть, если я хочу использовать float?
А, дошло, сорян
Как быть?
Использовать +.
Перегрузки не завезли?
Специальный полиморфизм. Говорите правильно.
А почему бы нам не пообсуждать type inference? На первый взгляд очень удобная вещь, после которой смотришь на языки где нужно самому устанавливать типы как на говно, но, наверняка, должны быть какие-то минусы о которых я не знаю. Итак, плюсы и минусы type inference го.
Минусы в том, что любые более-менее сложные системы типов суть undecidable, то есть для них не существует алгоритма вывода типов. В итоге у тебя может для простых случаев он и работает, а вот когда ты что-то написал и сам не уверен, то ли ты написал, оно перестает работать. Поэтому всегда есть дилемма: сохранить простоту системы типов, чтобы была выводимость, или добавить фич (т.е. увеличить количество типизирующихся программ), но потерять выводимость.
Ну и плюс типы все равно желательно писать для функций, просто в качестве документации.
>или добавить фич (т.е. увеличить количество часов на разгребание трехметровых шоблонов в цэпэпэшном стиле)
>https://realworldocaml.org
Ну что, кто-нибудь прочел? Есть ли смысл учить Core вместо стандартной библиотеки?
Чо, блядь?
Сore - это и есть стандартная библиотека. There is no standard library.
Сижу в vs code c vim модом.
Каково это - программировать с анальным зондом господина в заднице?
-> /s/
Нихуя она не стандартная, личное поделие Jane Street.
Пердоля, зачем ты порвался?
Jane Street - единственная (коммерческая) компания, которая поддерживает сабж. Это как говорить "личное поделие оракла" про джава-релейтед стафф. Де-факто это стандартная библиотека, есть еще всякие батарейки, но нахуй они ненужны.
->
Интроспективненько.
Интроспективненько.
о
SML дохуя?
Проиграл
Двачую, интероп очень легкодоступный.
Функторов нет, GADT нет, объектов нормальных нет, сырого полиморфизма нет, первоклассных модулей нет, эффектов нет, уноси свой фрешетка из моего лампового треда.
>почему он слабо распространен в индустрии
Почему слабо? У пейсбука штук пять крупных проектов на окамле, еще на нем пишут в janestreet, airbus, citrix, lexifi, блумберг, дассо, чуваки из tezos.
мимо пишу на окамле за дошираки
>есть ли кстати хоть какой-нибудь редактор, где окамль можно дебажить брейкпоинтами?
Любой с поддержкой DWARF?
>Jane Street - единственная (коммерческая) компания
Нет, достаточно открыть пулл реквесты и посмотреть, кто и откуда коммитит в компилятор.
>Де-факто это стандартная библиотека, есть еще всякие батарейки, но нахуй они ненужны.
Стандартная библиотека у окамла довольно годная и поставляется с компилятором. Нашлепки, вроде Base, Containers, Batteries и Core -- это все ныне не очень нужно, на самом деле.
>Нашлепки, вроде Base, Containers, Batteries и Core -- это все ныне не очень нужно, на самом деле.
Что почитать по стандарной либе, кроме офф доков? Пока читаю только эту книгу (https://caml.inria.fr/pub/docs/oreilly-book/ocaml-ora-book.pdf), но она старая.
Иммутабельные хэшмапы завезли уже?
>Что почитать по стандарной либе, кроме офф доков? Пока читаю только эту книгу (https://caml.inria.fr/pub/docs/oreilly-book/ocaml-ora-book.pdf), но она старая.
Зачем по ней что-то читать? Она маленькая, в ней только типы данных, awkward squad (эфемероны, слабые указатели), да кое какие интерфейсы к GC, OC, буферам в сишной и фортрановской компановке и профайлингу. Для остального берешь нужную либу из opam.
http://caml.inria.fr/pub/docs/manual-ocaml/stdlib.html
Можешь читать стандартные доки, они в принципе исчерпывающие.
Нет, конечно, есть нормальный персистентный Map и мутабильный Hashtbl.
>пишу на окамле
>за дошираки
Неплохо устроился, буржуй.
Что тебе мешает?
Не знаю.
Говорят Facebook хайпит ReasonML, который по-сути OCaml
Не пойму, неужели синтаксис Окамла такая неизучаемая вещь, что для этого нужно изобретать свой велосипед с семиколонами?
Это для того чтобы быдлоджаваскриптеров не так сильно отпугивало.
Фрилансю на окамле уже третий год для финансового стартапа. Платят ок, брат жив. Давеча босс прибегат, глаз дурной -- был, мол на Facebook meetup все про ReasonML говорят, наколбась демку на нем тыжеможешь.
Иду сюда https://reasonml.github.io/en/try влево вниз пишу OCaml -- слева вверху ReasonML генерится. Синтаксис тошнотворный (может и с непривычки просто) но вроде все работает. Что главное -- сразу во фронте. Занятно.
Там много кривого говна (типа двойных семиколонов такая-то ирония, кек, что ты называешь ризон велосипедом с семиколонами), так что смысл в этом с одной стороны есть, а с другой - не сказать, чтоб особо лучше получилось, кек
>Фрилансю на окамле уже третий год для финансового стартапа. Платят ок, брат жив.
Как вкатился? Что почитать посоветуешь? Сейчас курю Real World Ocamal, но как-то тяжело идет.
> Как вкатился?
Окамл выучил в универе -- на диплом надо было огромные символьные расчеты делать -- посоветовали глянуть.
Потом фрилансил на жаба/питон/жабаскрипт. По приколу вставил в профайле OCaml -- желающие нашлись быстро.
> Что почитать посоветуешь?
Я помню, что прочитал первую главу ocaml-refman и пошел сразу код писать. Вторая глава про модули с функторами -- тоже нужна, когда уже много наколбасил и надо организовывать. Объекты в OCaml практически не нужны -- третью главу сразу пропускаешь. Четвертая глава всяческие синтаксические плюшки полезные.
Также я очень проперся от Unix system programming in OCaml.
https://ocaml.github.io/ocamlunix/
Но это если ты в низкоурвневых юниксах ковырялся.
Если любишь онлайн курсы, то вот всем рекомендую:
https://www.fun-mooc.fr/courses/course-v1:parisdiderot+56002+session03/about
> Сейчас курю Real World Ocamal
Мне вообще не понравилась. По-мне главный минус что они пихают Core JaneStreetовский.
Двойные семиколоны они же только чтоб реплу сказать что ты кончил, не? В коде не нужны.
>Там много кривого говна (типа двойных семиколонов
В OCaml нет двойных семиколонов, они нужны реплу для того, чтоб указать, что ввод закончен.
Палю годный онлайн репл: https://sketch.sh/new/ml
>В OCaml нет двойных семиколонов
Иди ртфм, маня.
В коде почти никогда ненужны, да. К теме синтаксиса, кстати: https://caml.inria.fr/pub/docs/tutorial-camlp4/tutorial005.html
>почти никогда ненужны
Всегда ненужны. Я всю грамматику прочитал.
> https://caml.inria.fr/pub/docs/tutorial-camlp4/tutorial005.html
> camlp4
Протухло.
>Фрилансю на окамле уже третий год для финансового стартапа.
Скажи, из какой страны стартап если не деанон, конечно.
Штаты и UK
>По-мне главный минус что они пихают Core JaneStreetовский.
Мейлчую. Я из-за этого говна helloworld сконпелировать не мог три дня.
Верблюдики, а может кто внятно за ppx объяснить? Пишу иногда на нем, но дальше основ языка не надо было. А всякие гуру обмазываются ppx и, поговаривают, пахнуть вкусно. Что такое вообще?
Местная замена макросам. Трансляторы AST -> AST. Добавляют разный сахарок, легковесная замена для старого camlp4 препроцессора.
Лучше с ними не увлекаться, использовать только то, что реально нужно, например ppx_deriving/ppx_type_conv с плагинами для вывода функций для типа (аналог хаскилевского derive).
К слову о макросах есть еще metaocaml, когда-нибудь его вольют в транк.
Ага, как и modular implicits
>modular implicits
Иплиситы будут очень нескоро, ибо очень серьезные изменения (привет HKT и Dependent types и, как следствие, undecidable inference). metaocaml -- очень маленький патч поверх ванильного окамла, который может быть легко смерджен в любой момент, просто Олег еще не уверен, что это окончательный вариант.
А ты умный...
Чем GADT от депендет тайпов отличается?
Это проверка или ты сам не знаешь?
> Чем GADT от депендет тайпов отличается?
GADT не имеют никакого отношения к зависимым типам. Зависимые типы стирают границу между типом и значением, тип в ЯП с зависимыми типами -- то же значение, а значение -- тот же тип. GADT -- это просто relaxed версия алгебраических типов, позволяющая в произвольной форме задавать зависимость типа и его параметров от конструктора.
За счет этой свободы можно получить некоторые возможности из языков с зависимыми типами, в частности доказательство теорем с помощью соотношения Карри-Говарда. Классический пример -- коммутативность сложения:
type z = Z
type 'a s = S : 'a -> 'a s
type (_,_,_) add =
| Add_base : (z, 'a, 'a) add
| Add_step : ('n, 'm, 'q) add -> ('n s, 'm, 'q s) add
type (_,_) eq = Refl : ('a,'a) eq
let theorem_add_comm : type n m p q. (n, m, p) add -> (m, n, q) add -> (p, q) eq = fun _Hnm _Hmn -> ...
Кстати, язык модулей в окамле -- язык с зависимыми типами:
https://people.mpi-sws.org/~rossberg/1ml/1ml-jfp-draft.pdf
https://github.com/lpw25/girards-paradox/blob/master/girard.ml
Как оценивается выразительная сила типов окамла с GADT и (отдельно) с модулями?
Господа, есть вопрос. https://caml.inria.fr/pub/docs/manual-ocaml/libref/index_modules.html тут есть модуль Misc. А у меня он не открывается ни из программы, не из топлевела. ЧЯДНТ?
Ocaml 4.07, естественно
>https://caml.inria.fr/pub/docs/manual-ocaml/libref/index_modules.html
```
#use "topfind";;
#require "compiler-libs";;
#show Misc;;
```
Спасибо, но это только для топлевела. Что мне нужно линкануть? И где вообще почитать про это все?
g: ocaml opam
g: ocaml dune
Есть у кого OCaml from the Very Beginning?
Или где искать знает кто?
Или где искать знает кто?
libgen
Мое увожение
Какие киллер-фичи у ocaml по сравнению с rust?
> Сравниваю жопу с пальцем
Держи в курсе
На окамле можно писать ДСЛи.
Система модулей одна из лучших вообще.
> На окамле можно писать ДСЛи.
На расте, в целом, тоже, наверное. Деревья из сумтайпов, паттерн матчинг, что еще нужно?
> Система модулей одна из лучших вообще.
Вот это двачую. Модули функторы хороши
Треда по ФП нет, задам тута тоже
Ну в окамле много чего мутабельного есть. Да хоть тот-же Hashtbl:
type piece = King | Queen | Dvacher;;
type board = ((char * int), piece) Hashtbl.t;;
let b : board = Hashtbl.create 64;;
Hashtbl.add b ('e',2) Dvacher;;
Так как ты только вкатываешься -- пока так делай. Попривыкнешь, начинай в континуейшены, монады, в окамле Lwt, потихоньку
Я здесь мимо, но хочу задать вопрос любителям окамла. Чем эти ваши модули принципиально лучше объектов (на примере Scala)? Есть ли какие-то преимущества кроме несколько менее тупящего вывода типов (в скала всю малину Any портит). Можно ли делать вычисления на уровне типов с ними? (Как в скале с path-dependent types, которые дают функциональность очень похожую на type families в хацкеле)
Вот хорошее чтиво на тему:
http://www.stefanwehr.de/publications/Wehr_ML_modules_and_Haskell_type_classes.pdf
Какая библиотека для создания текстовых UI на OCaml сейчас считается наилучшей?
Рекомендую cmdliner
Текстовый UI, а не CLI, тупица. Notty же
Можно простой пример, как в монады оборачивать?
>Чем эти ваши модули принципиально лучше объектов (на примере Scala)?
https://discuss.ocaml.org/t/objects-use-cases-in-ocaml/2282/20
https://discuss.ocaml.org/t/what-is-the-right-way-to-add-constraints-on-a-type-to-handle-recursive-structures-with-variants-and-to-combine-fragments-of-types/2810/30
Бля, а где Haskell-тред?
Пару лет назад учил его, сейчас заинтересовался что там нового, узнал про Haskell 2020.
Чё там, надеюсь собираются дропать обратную совместимость в стандартной библиотеке и исправлять недочёты в иерархии классов?
Пару лет назад учил его, сейчас заинтересовался что там нового, узнал про Haskell 2020.
Чё там, надеюсь собираются дропать обратную совместимость в стандартной библиотеке и исправлять недочёты в иерархии классов?
Создай свой хаскель тред. Но зачем, прими OCaml как своего спасителя от лени.
>Чё там, надеюсь собираются дропать обратную совместимость в стандартной библиотеке и исправлять недочёты в иерархии классов?
А кастомную прелюдь запрещает юзать кто?
Блядь хороший язык, хотел вкатиться в хаскель но набрёл на fun-mooc, прохожу его сейчас, хорошо зделали. Бросил кложу из-за него вернусь.
Я сейчас поставил емакс и какие-то рекомендованые пакеты через opam install.
Какой у вас воркфлоу и какие инструменты? Я пока для хелловорлдов своих использую dune для сборки и запуска юнит-тестов (уёбки закрыли задачи на курсе, а пройти хочется), emacs для редактирования. Из емакса подбрасываю в utop если надо.
В принципе норм, но хотелось бы чтобы ворнинги/ошибки в файле на лету обновляло.
Дебаггер ещё не пробовал.
Я сейчас поставил емакс и какие-то рекомендованые пакеты через opam install.
Какой у вас воркфлоу и какие инструменты? Я пока для хелловорлдов своих использую dune для сборки и запуска юнит-тестов (уёбки закрыли задачи на курсе, а пройти хочется), emacs для редактирования. Из емакса подбрасываю в utop если надо.
В принципе норм, но хотелось бы чтобы ворнинги/ошибки в файле на лету обновляло.
Дебаггер ещё не пробовал.
dune двачую, а так использую VS Code вместо IDE.
F# не зависит от MS. Он давно уже опенсорс. Его пилит Fsharp Foundation.
У него довольно мощное русскоязычное сообщество в Телеграме, и вообще в СНГ.
Никто не хочет учиться играть на XYZ https://ailev.livejournal.com/1158826.html
Продолжение здесь https://ailev.livejournal.com/1385867.html
Утраиваю opam + dune + vscode + merlin
Это перевод или он так убого пишет?
Он отлично пишет. Это один из лучших русскоязычных преподавателей. Окамл как и Лисп для думающих, C++ и прочий мейнстрим для широких масс. Поэтому Окамл непопулярен, ты же об этом спросил, вот тебе ответ.
А дотнет уже опенсорс?
Я про манеру изложения говорил, неестественно как-то пишет.
Да. По крайней мере .NET Core точно. Ну и вся сопутствующая инфраструктура, компиляторы и библиотеки.
По мне наоборот, стиль повествовательный. Лучше многих статей на хабре. Где в основном Я, Я, Я... Да еще и подстраиваются под публику, чтобы минусов не получить. Жалкое зрелище. Анатолий Левенчук пишет как бы от третьего лица.
Толян, залогинься.
Он утверждает, что никто не хочет учиться, мол простых путей не бывает и сложные инструменты требуют длительного изучения. По его логике получается C++ > Ocaml, ибо кресты имеющие кучу нюансов нужно учить очень долго, достаточно даже сравнить синтаксис, человек с нулевыми знаниями программирования скорее предпочтет Ocaml нежели С++.
Ни разу. Мы видим как люди предпочитают что угодно, но только не Окамл, Хаскель, Лисп, и т.п. Эти языки заставляют думать, а этого делать никто не хочет. Проще пойти по накатанной, взять C++, установить IDE, создать переменную, написать цикл, создать класс. Это уже инструмент для широких масс. Все уже расписано, решено, нужно просто копировать, то есть НЕ ДУМАТЬ. В Лиспе, Хаскелле все по другому. Они не ограничивают. Поэтому приходится думать.
>Проще пойти по накатанной, взять C++, установить IDE, создать переменную, написать цикл, создать класс. Это уже инструмент для широких масс.
Это для человека знакомого с этими концепциями это знакомый путь, для человека знакомого только с ФП "накатанная" своя, но абсолютно такая же знакомая и привычная для него лично. Что отличает второго от первого, почему второй "думает", а первый ленится?
>человек с нулевыми знаниями программирования скорее предпочтет Ocaml нежели С++.
Он предпочтет то, что ему посоветует знакомый опытный програмист, или очередной топ-10 языков. А вероятность иметь знакомого плюсиста, выше, чем борщехлёба по очевидным причинам.
>для человека знакомого только с ФП
Таких почти нет. Подавляющее большинство программистов начинают с императивопетушни. И те, кто предпочитают ФП, уже имеют в своем арсенале "накатанное" ИП.
Интересно что Интеллектуальные Скрипачи про Rust думают.
С одной стороны много непривычных концептов которые нужно изучать и растотред заполнен хейтом от C++-инвалидов которым всё это НИНУЖНА.
С другой стороны заточенность под низкоуровневый пердолинг, под "архитектуру фон Неймана", а это сразу не стильно и не по-интеллектуальному.
>Чем эти ваши модули принципиально лучше объектов (на примере Scala)?
Надо подробно расписать? Кому-нибудь еще интересно?
Если сделаешь, то заранее спасибо тебе большое, анон. Читать пейперы достаточно трудновато все же
Не бывает людей знакомых только с ФП. Изучая программирование по любому столкнешься с мейнстримом вначале.
>С другой стороны заточенность под низкоуровневый пердолинг, под "архитектуру фон Неймана"
Как это понять? Rust поддерживает ФП.
Начинал со SICP и Scheme, сейчас Scala/Haskell. Ну и где твоя правда теперь?
(Хотя, ИХМО, Scala с Haskell и есть мейнстрим, но ты же так не считаешь)
Есть ли в окамле тайпклассы или наследование? Если нет, то какой вид полиморфизма там есть, чтобы писать generic функции?
Есть ли в окамле нормальный мультитрединг?
Есть ли нормальная экосистема с кучей либ и тулов? IDE завезли?
Есть ли в окамле нормальный мультитрединг?
Есть ли нормальная экосистема с кучей либ и тулов? IDE завезли?
>Есть ли в окамле тайпклассы или наследование?
Есть мощный механизм модулей. Есть наследование (и множественное) в системе объектов. Тайпклассов нет. Возможно через пару лет будут implicits, как в scala.
>Есть ли в окамле нормальный мультитрединг?
Сейчас есть с GIL. Многим достаточно. Скоро будет multicore.
>Есть ли нормальная экосистема с кучей либ и тулов?
define нормальная. Для кого-то текущая ситуация более чем нормальная. Если хочешь лепить вебапликухи, как привык в других языках, то будет мало.
>IDE завезли?
Есть merlin. Плагинов для редакторов хватает.
js_of_ocaml кто-то использует?
Я зашёл на первую ссылку - сайт ocsigen, там куча TODO, нерабочие ссылки и всё такое. Создаётся впечатление, что это какое-то сырое говно.
Я хотел бы просто готовый проект который всё это собирает и я бы мог понажимать в браузере, желательно без Reasonml парашного синтаксиса.
Я зашёл на первую ссылку - сайт ocsigen, там куча TODO, нерабочие ссылки и всё такое. Создаётся впечатление, что это какое-то сырое говно.
Я хотел бы просто готовый проект который всё это собирает и я бы мог понажимать в браузере, желательно без Reasonml парашного синтаксиса.
Респект за пик
Ну хуй знает, я вот научился писать на Х-е, теперь в других языках приходится подолгу думать, как бы изъебнуться, чтобы обойти ограниченную выразительность. И вообще, писать на языках без хорошей, строгой типизации - это большой труд и уныние. Но это мейнстрим, этому учат в школах и университетах, это спрашивают эйчары на собеседованиях, а людям не хочется идти к успеху окольными путями.
Сейчас популярны ReasonML который над BuckleScript который отпочковался от js_of_ocaml. А ocsigen подзаброшен да.
Подпекло немного с этих энтраев. Что плохого в том, чтобы делать что-то промежуточное, доступное для масс и позволяющее перейти на ступенку выше малой кровью? Неудевительно, что разработчики не хотят рисковать своим временем, изучая сложные вещи по советам незнакомых людей из интернетов. Это же деньги, вопрос выживания. Не надо делать проще ЛИБО сложнее, надо делать проще И сложнее, в разных вариациях, для разной аудитории.
Ты можешь жить в ограничениях, это твой выбор. Я выбираю свободу действий. Писать на том, что нравится. Что мощнее и удобнее.
Я тоже выбираю свободу и пишу на хаскелле, могу себе позволить. И всё-таки, что плохого в промежуточных вариантах?
>Есть ли в окамле тайпклассы или наследование? Если нет, то какой вид полиморфизма там есть, чтобы писать generic функции?
Там есть параметрический полиморфизм, модули и GADTs. Этого более чем достаточно для очень обобщенного полиморфизма.
По крайней мере, если ты просто пишешь бизнес-логику или свою имиджборду.
мимо scala/haskell-фаг
Проблема не в инструментах, а в том, как эти инструменты принято использовать. То же ООП можно готовить правильно: делать объекты с изысканным вкусом декомпозиции, полиморфизма и интерфейсов. А можно готовить так же, как и большинство - хуячить императивную лапшу, приправленную объектным соусом. Первое сложнее, поэтому мало кто так делает.
>пишу на хаскелле, могу себе позволить
классическая мамка с борщем, не так ли?
>То же ООП можно готовить правильно
А еще можно встретить розового единорога
>Это один из лучших русскоязычных преподавателей.
Который продает занятия по танцам за 30000 рублей?
Ага. И потом ты просто поймешь, что единственный способ правильно писать ООП - это начинать делать все иимутабельным. По-максимуму с использованием дженериков, где тебе уже придется явно словари прокидывать типо Equitable<T> или Ordering<T> (условно). С композицией вместо наследования. С эмуляцей (G)ADT и инкапсуляцей ручного паттерн матчинга в визиторах.
ТЕПЕРЬ ОСТАЛСЯ ОДИН ВОПРОС
Нахуя ты вообще брался за ООП если на этом этапе ты просто занимаешься работой комплиятора нормального функционального языка?
>А с чем связана низкая популярность OCaml?
Есть хаскель, который лучше во всем.
>Или макаки слишком тупы, чтобы его осилить?
Это никогда не бывает причиной.
> А с чем связана низкая популярность OCaml?
Есть языки которые в зависимости от целей ТУПО лучше. Хочешь просто функциональщины в вебе - Haskell. Хочешь нереального количества библиотек - Scala. Хочешь функционально и быстро? Rust
> Или макаки слишком тупы, чтобы его осилить?
C++ сложнее любого прувера, одна он популярен.
В твоем нормальном функциональном языке чтобы обыкновенный гетерогенный список сделать требуется куча бойлерплейта.
Паттерн матчинг так вообще не альтернатива визитору, это ебаный свитч.
> То же ООП можно готовить правильно
Как у Егорки Бугаенко?
> В твоем нормальном функциональном языке чтобы обыкновенный гетерогенный список сделать требуется куча бойлерплейта.
Если ты под гетерогенным списком подразумеваешь просто тупую хуйню как в типичной Java, то нихуя
{-#LANGUAGE GADTs#-}
data Shows where
ToShow :: Show a => a -> Shows
instance Show Shows where
show (ToShow a) = show a
shows = [ToShow 1, ToShow "hello"]
а еще в хацкеле есть Dynamic, но его я не пытался никогда использовать
Если ты говоришь про compile-time гетерогенный список, то да. Есть геморрой. Но это уже совсем другая конструкция относительно гетерогенного списка, как его понимают в диначески-типизированных языках.
> Паттерн матчинг так вообще не альтернатива визитору, это ебаный свитч
> Represent an operation to be performed on elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it operates.
(цитата из GoF)
Тебе не кажется, что ADT - по какой-то магической причине имеют ровно те же преимущества и недостатки, что и визитор. Подумай, может они реально являются представлением одного и того же?
>В твоем нормальном функциональном языке чтобы обыкновенный гетерогенный список сделать требуется куча бойлерплейта.
ЛПП.
[CODE]
{-# LANGUAGE
UnicodeSyntax
, DataKinds
, TypeOperators
, GADTs
#-}
module HList where
data HList xs where
HNil ∷ HList '[]
(:#) ∷ a → HList as → HList (a ': as)
infixr 6 :#
-- >>> :t 1 :# 'b' :# True :# HNil
-- 1 :# 'b' :# True :# HNil ∷ HList '[Int, Char, Bool]
[/CODE]
>Паттерн матчинг так вообще не альтернатива визитору, это ебаный свитч.
Про это вообще промолчу.
>делать все иимутабельным
>С композицией вместо наследования.
Это какие-то крайности. Иметь состояние тоже нужно и в объектах это хорошо реализуется. Наследование тоже годится, когда нужны дефолтные реализации конкретной функциональности.
>По-максимуму с использованием дженериков
Ну так это есть параметрический полиморфизм в статических ООП языках. Почти весь реюз кода на этом основандолжен быть.
>С эмуляцей (G)ADT
Объекты сами по себе можно рассматривать как декартово произведение. Тип-сумму не завезли, да, но обычно Object | null и перегрузки вполне хватает для практических задач.
>инкапсуляцей ручного паттерн матчинга в визиторах.
Чем перегрузка в той же Жабе хуже паттерн матчинга? Однохуйственно же. В динамикодристне, конечно же убого выглядит цепочка ифов.
Как вариант, да.
Да, и ещё тот факт, что я учу функциональщину со школы, а не посередь карьеры.
>Если ты под гетерогенным списком подразумеваешь просто тупую хуйню как в типичной Java, то нихуя
Ну да, GADT-синтаксис выглядит симпатичнее экзистенциальных типов, хотя все равно нужно смотреть, не обосрались ли где-то.
>Тебе не кажется, что ADT - по какой-то магической причине имеют ровно те же преимущества и недостатки, что и визитор. Подумай, может они реально являются представлением одного и того же?
Визитор позволяет добавлять новые сущности без перекомпиляции, а ADT, будучи свичом, нет.
>требуется куча бойлерплейта
Импортировать библиотеку с гетерогенными списками тебе куча бойлерплейта? Нихуя ты барин зажрался.
Я не буду с тобой спорить, ибо ты прав по каждому пункту. Но мне кажется что ты пропустил основной смысл моего поста. А заключался он в том, что хороший ООП-дизайн - это и есть свое переизобретение функциональщины in disguise
> Тип-сумму не завезли
Завезли. Только оно называется "наследование"
Нет. Это best practices из функциональщины с возможностью от них отступить, когда надо. Функциональщина же слишком категорична
Лучший подход в, прости господи, Rust. Жалко только в остальном он говно
Не понимаю, зачем ты мне отвечаешь. Я пишу про посты из жж. В постах из жж разговор про хорошие (функциональные) языки против плохих (прочих). С твоим тезисом я (почти) согласен, но как он связан с моим вопросом - не понимаю.
Взять наименьшего общего предка - это не сумма, если что.
> с возможностью от них отступить, когда надо
Вот именно из этого пункта и рождается хуевый ооп дизайн. И успешно процветает в любой большой системе, пока ее не перепишут
Хуевый функциональный дизайн рождается намного проще: его нет, потому что борщ закончился, а мама выпиздила на улицу.
Может я запутался, но я вижу это так:
Наследование + дженерики = открытые GADTs.
Тип-сумма является частным случаем второго, а следовательно и частым случаем первого
>Есть хаскель, который лучше во всем.
Очевидное неверное утверждение.
Чо ты в этом треде делаешь?
Можно уточнить: среди тех, кто в принципе решил взять ФП.
Он слишком компромиссный и не особо развивается энтузиастами из-за этого
> Он слишком компромиссный
Слабо понимаю о чем ты. Можно пример?
>среди тех, кто в принципе решил взять ФП.
Сначала ты говоришь про языки, а потом про людей, которые их используют. Надо разделять язык и пользователей.
>Он слишком компромиссный и не особо развивается энтузиастами из-за этого
Слишком компромиссный, это когда в нем вывод типом не ломают новой фичей, как это бывает в хаскеле? Перед тем, как что-то добавить в OCaml это сначала 10 раз обдумают и протестируют, чтобы нигде ничего не сломалось. За счет этого можно компилировать код, написанный 15 лет назад. С хаскелем это не работает.
>открытые GADTs
>Тип-сумма является частным случаем
Так нет же, сумма - "закрытый" тип.
Единственное чем отличаются закрытые типы отличаются открытых (являясь частым случаем), это тем, что для них типы можно автоматически выводить и pattern-match может включать exhaustiveness check.
Когда я увидел это:
> Тип-сумму не завезли
Я подумал про принципиальную выразимость.
Короче я имел ввиду, что сделать Either<A, B> в Java не предсталвляет никакой проблемы именно из-за наследования.
В добавку. Наследование как раз и можно рассматривать как тип-сумму с бесконечным числом конструкторов
Уловил, конечно жи. Это не переизобретение функциональщины. Грамотный подход к проектированию программы в любой парадигме сводится к одинаковым вещам, только называемых по-разному. В любом ЯП можно легко нахуевертить говна, потому что говно, как правило, не в инструментах, а в головах.
>но как он связан с моим вопросом - не понимаю.
Твой вопрос:
>Что плохого в том, чтобы делать что-то промежуточное, доступное для масс и позволяющее перейти на ступенку выше малой кровью?
Перевожу свой ответ: необходимости в чем-то промежуточном нет. В доступных массам инструментах есть всё необходимое. Массы могут изучать всё это в свободное от работы время, повышая свою квалификацию, но все равно этого не делают.
Да, Object + instance_of + cast такая себе тип-сумма.
> Да, Object + instance_of + cast такая себе тип-сумма.
В Scala оно так и реализовано, но никто же не будет утверждать, что это не функциональный язык
>Чем перегрузка в той же Жабе хуже паттерн матчинга? Однохуйственно же
Не понел, как можно в жабе сэмулировать паттерн матчинг перегрузкой?
Если мне приходит Option, к примеру, сделать два метода handle(Nothing x) и handle(Some x)?
Не понел, как можно в жабе сэмулировать паттерн матчинг перегрузкой?
Если мне приходит Option, к примеру, сделать два метода handle(Nothing x) и handle(Some x)?
>Я зашёл на первую ссылку - сайт ocsigen, там куча TODO, нерабочие ссылки и всё такое.
Все там рабочее. Некоторые примеры не открываются без прокси. Видимо роскомнадзор.
>Грамотный подход к проектированию программы в любой парадигме сводится к одинаковым вещам, только называемых по-разному.
Вот только в ФП это лучше реализовано и является твоими инструментами изначально, а не как в ООП где нужно городить паттерны, чтобы работало нормально. Тот анон пока прав, "хороший ООП-дизайн - это и есть свое переизобретение функциональщины", твой "аргумент" ничего не доказывает.
Я на жабе не программиовал и мне тоже интересно. Как, например, хранить список опций без некого интерфейса Option? Если все хранится в виде Option, то в какой-то момент все это дело надо кастовать обратно в Some, и None перед тем как вызывать handle (см. пост на который отвечаю), но тогда какой это паттерн матчинг, если это только проверка на exhaustiveness?
>как хранить список опций
пехаешь все в глобальный экзепляр соотв структуры и все
напридумывают всякой хуйни а потом ебуцца с этим
Там банально в ссылках (на гитхаб) закрывающиеся скобки есть и они не открываются кликом.
Если у них на сайте такой беспорядок, я лучше подумаю прежде чем инвестировать своё свободное время в их технологию.
Твое поведение - наглядная демонстрация того, что IT это ебаная мода.
В первую очередь надо идти и смотреть код, что там внутри и нет ли там говна, а не как у них сайт работает. А то привыкли, что у популярных фреймворков и библиотек отличный маркетинг с красивыми лендингами и похуй что там внутри, а потом все тормозит и разваливается.
Не понял, приведи пример.
Не передёргивай, дело не в красивых лендингах а банально в серьёзности подхода. Я, блять, когда своим факториалам ридми делаю такого не допускаю. Я могу в кложе написать что-то вроде `lein new figwheel hello-world` и у меня сразу поднимется проект который я могу потрогать.
Посмотри теперь https://ocsigen.org/js_of_ocaml/3.1.0/manual/overview.
Всё что мне предлагается это начать качать какие-то пакеты и что-то ими собирать, я даже не ебу какая должна быть структура проекта, как мне включить готовый js к проекту, вот это всё.
Issue ни гитхабе про ошибки на сайте у них с сентября 2018 висят.
>В первую очередь надо идти и смотреть код, что там внутри и нет ли там говна
Откуда мне знать, есть ли говно в коде если я на окамле только прошёл 3 недели онлайн-курса?
Пока джава сеньоры отдыхают, решил сам что-то написать:
https://pastebin.com/Myd3GZaq
Я ожидал, что у перегруженных функций будет late binding, т.е. я смогу вызывать getOrElse на тип Option, имея две реализации одну для Some, а другую для None, но нихуя.
Если я правильно всё понял, то в джаве придётся или эмулировать руками теги для нормальной читаемости и проверять их руками (собственно, оно сейчас в джаве так и есть: isPresent() в optional), или опускаться до instanceof. А без destructuring нужно будет ещё и руками выковырывать поля.
>в ООП где нужно городить паттерны, чтобы работало нормально.
Да не нужны никакие паттерны, это всё костыли для слабоумных. Объекты, наследование, интерфейсы, перегрузка, дженерики/темплейты - этого достаточно. И не надо ебаться с монадными трансформерами и лифтами, чтобы скомбинировать побочные эффекты.
Да с паттерн матчингом я погорячился. Всё-таки перегрузка это всего-лишь Ad-hoc полиморфизм.
Описанный случай, отлавливаемый на этапе компиляции, в жабе реализуется при помощи Object + Exception:
https://ideone.com/Bz5fHh
неа
достаточно структур, указателей на функции, void* и макросов
у тебя есть глобальная структура, поля в которой - параметры
и все
точка
нихуя
достаточно регистров общего назначения и стека
Нет, это даёт такую проверку только в случае Option<T>. А что, если у тебя с десяток подтипов (конструкторов типа-суммы)? Делать десяток разных checked exceptions?
А ваще checked exceptions считаются большим моветоном в современной Java, ибо использовать их в лямдах - это супер геморрой, и они не композируются каким-то тривиальным способом
Визитор как раз и даёт проверку заполнения на этапе компиляции, однако именно в случае Option разумнее использовать что-то простое типо getOrElse()
Экосистема OCaml одна из лучших. Скорее всего ты что то делаешь не так. Давай ссылки, посмотрим где что не работает.
В окамле мощная экосистема. Opam круче чем Lein. В нем намного больше возможностей. Лучше все автоматизировано. Возможно ты не умеешь им пользоваться.
>Всё что мне предлагается это начать качать какие-то пакеты и что-то ими собирать, я даже не ебу какая должна быть структура проекта, как мне включить готовый js к проекту, вот это всё.
Opam сам все компилит. Читай доку внимательней.
>Перефразировл уже написанное
Впрочем, что я ожидал от мелкобуквы.
Мне надо было сделать юнит-тесты для обычного окамла (потому что в вышенаписанном курсе закрыли проверку и я решил напилить свою).
Я потратил в сумме примерно день, копаясь в каких-то перстарелых и уже неактуальных страницах, чтобы выяснить что сейчас все пользуются dune, выяснить как там включать библиотеки (чтобы установить ounit нужно написать opam install ounit, чтобы воспользоваться им нужно написать Open OUnit. Чтобы включить его в dune проект нужно использовать oUnit). Всё это с непонятными ошибками компиляции итд (с хуя бы я что-то понимал 2 дня назад вкатившись в язык).
Если бы был просто пример настроенного проекта в котором всё это есть, никаких проблем бы вообще не было.
Сейчас ты мне предлагаешь потратить ещё время на то чтобы изучить весь тулинг вокруг js_of_ocaml и чтобы наконец мне удалось что-то запустить и попробовать. Нахуй оно мне? Я не хочу инвестировать время в изучение инфраструктуры языка, которым я ещё не знаю хочу я пользоваться или нет.
Чтобы быть юзер-френдли для вкатывающихся (если такая цель есть), нужно предоставить всё настроенное и отконфигурированное, едущее без всякой лишней хуйни. Кому понравится, потом будет постепенно разбираться.
Я лучше или reason накачу, или куда-то ещё вкачусь, а знания фич окамла останутся для общей эрудиции, пока он не повзрослеет.
>с хуя бы я что-то понимал 2 дня назад вкатившись в язык
Любую экосистему придется осваивать. В Окамле много всего автоматизировано. В других экосистемах будешь делать руками, и тратить больше времени на изучение и использование.
>Сейчас ты мне предлагаешь потратить ещё время на то чтобы изучить весь тулинг вокруг js_of_ocaml и чтобы наконец мне удалось что-то запустить и попробовать.
Ты что то путаешь. Я тебе вообще ничего не предлагаю. А вообще, без труда не выловишь и рыбку из пруда. Не получится изучить новый язык не потратив время.
>Я не хочу инвестировать время в изучение инфраструктуры языка, которым я ещё не знаю хочу я пользоваться или нет.
Не изучай. Что ты оправдываешься то.
>Чтобы быть юзер-френдли для вкатывающихся (если такая цель есть), нужно предоставить всё настроенное и отконфигурированное, едущее без всякой лишней хуйни.
В Окамле с этим все впорядке. Минимум ручного труда. Все делается через одну команду.
>Я лучше или reason накачу, или куда-то ещё вкачусь, а знания фич окамла останутся для общей эрудиции, пока он не повзрослеет.
Одолжение мне не делай. Мне вообще все равно чем ты будешь заниматься. Смешно то, что какой то новичек называет Окамл незрелым. Экосистема Окамла более продвинутая чем в больше языков. Просто ты неопытен, не понимаешь как что работает. Твои истерики из-за того что некоторые вещи устроены не так как ты себе представляешь, выглядят смешно. Я понимаю если бы ты имел опыт использования 10 разных языков, и сказал бы что в них сделано лучше. А так, твое мнение не объективно.
Илитариев полон тред. Так почему же не используют ocaml? Очевидно же, потому что все тупые и ленивые. Nuff said
Это не ты тот самый персонаж, что влетает в любой тред и начинает постить про мамкин борщ?
Нет, я залётный хаскеллист.
Так это же и есть тред для обсуждения haskell, чувствуй себя как дома
Ты про какой пост? И приведи пример постов персонажа.
Его не используют почти также, как и не используют хаскель.
Не согласен, но допустим. Что с того?
Непонятно в чем суть твоего сообщения. Замени ocaml на haskell и суть останется такая же. Не вижу смысла в пустом трепе, который замыливает интересные обсуждения.
Потому что это инструмент не для широких масс. Широкие массы выбирают ширпотреб, инструменты широкого потребления, - C/C++, Java, PHP, Python, etc. И гордятся тем, что их инструмент имеет широкое потребление. Это же глупость. Самые дорогие вещи, самые качественные - эксклюзивные, а не ширпотреб.
К примеру обувь ручной работы дороже, качественней, не используется широкими массами.
Согласен, что это смешно, но это моё впечатление, которое сложилось при чтении документации в первых ссылках из гугла.
Я не говорю, что язык плохой и экосистема незрелая, я говорю что это не подано в доступном виде для мимокрокодилов.
Если мнение мимокрокодилов мейнтейнеров языка и экосистемы не интересует (нет необходимости в популяризации), то претензий вообще никаких.
>Я тебе вообще ничего не предлагаю.
А потом
>А вообще, без труда не выловишь и рыбку из пруда.
лол.
Есть fundamental transferable knowledge. Будучи средней руки быдлокодером, изучая окамл как язык я узнаю про алгебраические типы данных, destructuring, вывод типов и прочее. Эти знания я могу взять с собой в другие языки, сэмулировать эти фичи если они мне нужны, лучше понимать весь объём доступных инструментов.
Есть знания экосистемы, тулинга и вот этого всего, которые мне за пределами окамла никак не пригодятся. Я хочу поиграться с окамлом и инвестировать максимум из своего времени в знания из №1 и минимум в №2.
Я вкатываюсь в надежде зайти на сайт, создать готовый проект в котором всё работает и сразу начать экспериментировать. Вместо этого я вижу кучу билд систем: jbuild, opam build, dune, между которыми я каким-то образом должен выбрать лучшую, сделать сам проект. Это всё идёт в категорию №2, и инвестировать сюда своё свободное время я не хочу.
Пустой трёп - это называть тупостью и ленью нежелание инвестировать в изучение чего-то непонятного и не имеющего очевидных профитов, в том и суть. Что можно сделать с окамлом или хаскелем, чтобы профиты стали очевидны и всё стало понятно - это интересное обсуждение.
Вот, кстати, хрестоматийный пример пустого трёпа.
>Будучи средней руки быдлокодером, изучая окамл как язык я узнаю про алгебраические типы данных, destructuring, вывод типов и прочее.
Тебе тогда не окамл нужен а скала/хаскелл например
Мимо
Не надо учить ocaml: единственное, чему он тебя научит - фрустрировать от этой твоей java/js/php или чем ты там деньги делаешь
Моё знакомство со scala описал прямо, теперь не могу смотреть на свой стек как на что-то полноценное.
Пользуйся ширпотребом. Никто же не против. Зачем ты вообще лезешь в экслюзив, если не готов принимать те жертвы, которые они требуют.
Почему нет?
Нет, спасибо, я буду пользоваться тем, что мне удобно.
Потому что больше документации и курсов, рассусоливающих знания именно первого рода.
Потому что тот же хаскелл - стандарт для всяких статей по ФП-фичам, по крайней мере в русскоязычном сегменте практически всё либо на нем либо на скале, да и в англоязычном полно.
Бамп топовому треду.
Помогите, ЧЯНТД? В out_channel все пишется, но при попытке считать из или закрыть in_channel, сразу выдает Unix.EBADF?
Не вникал, но ";" в networking.ml подозрительная.
Вник. Ты один и тот-же fd два раза закрываеш.
Посмотри как Lwt_io.with_connection делает.
https://github.com/ocsigen/lwt/blob/master/src/unix/lwt_io.ml#L1526
А лучше не изобретай велосипед а with_connection и используй
Спасибо за помощь. Я вообще думаю, что in_channel закрывать не нужно. Почему у меня не получилось считать я так и не понял, в переписанном варианте у меня все заработало.
Еще разобрался как работает Lwt_main.run, на пике у меня проеб при котором не будет нового accept'а пока не закончится сессия текущего клиента.
Написал что-то вроде:
let client = Lwt_main.run (sock >>= accept) in
Lwt.async (process client)
Вот я пиздоглазый, таки заметил, что ic тоже закрывают. Попробую сделать с with_connection.
нихуя
достаточно nand и чясики
нихуя
достаточно CMOS транзистора
нихуя
достаточно u,d кварков и электронов
заебал на дваче сидеть, физик йобаный
Анон, помогай. Читаю Ярона Мински и ко про вкат в окамл. В примерах кода юзается модули Core, Time. У меня такая шляпа выходит:
# open Time;;
Error: Unbound module Time
# open Core.Std;;
Error: Unbound module Core
Откуда эти модули брать? Они там советуют запускать utop в качестве калькулятора, я запускаю ocaml.
окамл ставил из арчлинуксового репозитория.
Вопрос снят, я слепошарый идиотчитайте внимательно введение.
Пожалуйста.
>Core
Меня одного воротит от этой хуиты? Бросил читать книгу из-за этого.
Я тут это... в хаскель ухожу, остановите меня пока не позно. Если жизнь в окамле без тайп-классов?
>Перед тем, как что-то добавить в OCaml это сначала 10 раз обдумают и протестируют, чтобы нигде ничего не сломалось. За счет этого можно компилировать код, написанный 15 лет назад
По ссылке из оп-поста https://realworldocaml.org:
>Version 1
>The original version of the book, as published in 2013. Note that many of the examples don't work with the latest versions of the libraries and tools involved.
>Если жизнь в окамле без тайп-классов?
Есть.
Православные модули вместо парашных тайп-классов - это же главное преимущество окемла, ты чего.
Каждый раз писать Hui.foo, Pizda.foo и для каждого типа делать модуль заебывает. pizda_foo, hui_foo ни чем не лучше.
>Каждый раз писать Hui.foo
open Module
let open Module in
Module.( ... )
Проблема остается когда нужно использовать оба foo в одном контексте.
Разве это проблема?
Если у тебя пересечение по названиям (что не так уж часто бывает), то лучше явно указывать откуда `foo`.
Пример с foo, пожалуй, слишком абстрактен. Возьмем print и его реализацию в окамле как print_тип. Ведь print это абстрактная функция, которая в идеале может принимать любой тип поддерживающий соответсвующий интерфейс. Зачем мне писать Pizda.print и Hui.print, когда можно написать print и дать возможность компилятору сделать свою работу?
Еще мне не нравится, что в окамле есть ad-hoc полиморфизм для оператора сравнения, но нет такого же для операций над числами. Так же минусом идет невозможность переопределить поведение оператора сравнения.
>Ведь print это абстрактная функция, которая в идеале может принимать любой тип поддерживающий соответсвующий интерфейс.
Здесь ты несешь знание о print откуда-то извне, из своего бэкграунда, потому что в окамле нет функции print. Есть print_string, print_int и другие примитивы. Нет здесь функции, которая поддерживает соответствующий интерфейс, потому что и интерфейса нет.
Ты путаешь, потому что в операторе сравнения
val (=) : 'a -> 'a -> bool
нет ad-hoc полиморфизма, это параметрический полиморфизм. Не определена функция `=` для каких-то конкретных типов `int` или `string`, она определена для всех типов.
Можно было бы с таким же успехом определить
val print : 'a -> unit
Вот только ты ничего не знаешь об `'a`, как его печатать?
Если сильно хочется, то можно воспользоваться ppx расширением: https://github.com/ocaml-ppx/ppx_deriving
И вот тогда компилятор (а точнее плагин) будет явно выполнять свою работу, позволяя превращать любой помеченный тип в строку.
Возникает вопрос: "а че, даже до ad-hoc полиморфизма тогда не додумались?" Додумались, но осознанно отказались, потому что это сильно осложняет язык. В хаскеле для этого пришлось потратить много времени на рисерч и построение системы тайп классов. Вместо этого создатели ocaml решили вложить усилия в другие направления (модули, объекты, gc, etc) и это логично, потому что зачем дублировать исследования, которые в то время проводились в хаскеле? Это же академические языки и никто тогда не думал, что через 20 лет на форумах их будут сравнивать и писать "фу, говно язык, даже feature_name нет". Такой вот дизайн чойс.
Есть движение в сторону добавления ad-hoc полиморфизма и для этого придумали modular implicits (https://arxiv.org/pdf/1512.01895.pdf), которые повторяют механизм имплиситов в Scala. Но это work in progress.
>зачем дублировать исследования, которые в то время проводились в хаскеле
Действительно. Могли бы присоединиться к исследованиям.
>через 20 лет на форумах их будут сравнивать и писать "фу, говно язык, даже feature_name нет"
В итоге окамл соснул у хаскеля.
Эх, вот и какой толк тут писать что-то полезное, если публика, уровня школьников, понять не может pros/cons разных решений и живет понятиями популярности, а то, что окамл по многим фронтам затыкает хаскель, видимо невдомек.
Годно расписал. За модули и двор стреляю в упор! Притом интересно, что сейчас именно тайпклассы (ну и прочие вариации на ту же тему, которые решают expression problem) стали дефолтной само-собой-разумеющейся фичей для всех языков. Интересно, произойдет ли в дальнейшем откат к чему-то более модульному, потому что все-таки неочевидные импорты в конечном итоге до добра не доводят.
>val (=) : 'a -> 'a -> bool
>параметрический полиморфизм
Извините, я не говорю на OCaml. А что будет, если туда стрелочный тип подставить? Функции тоже сравнит? Как это вообще для всех типов работает?
>Exception: Invalid_argument "compare: functional value".
А могли бы по указателям сравнивать, например. (мимо)
Функции -- это такие же значения, но ocaml основан на полиморфном лямбда исчислении, в котором для них не определена эквивалентность. Чтобы это работало и для функций, необходимы зависимые типы уровня HoTT (univalence axiom).
Во время компиляции это не отлавливается, потому что сложно: https://caml.inria.fr/mantis/view.php?id=4201 Поэтому ошибка в рантайме.
Есть сравнение по указателям через `==`. Просто `=` сравнивает структурно.
>Чтобы это работало и для функций, необходимы зависимые типы уровня HoTT (univalence axiom).
Не понял, а унивалентность тут чем поможет? Не будет же компилятор сам изоморфизмы выводить. Или будет?
Ну и, стало быть, не для всех типов определена эквивалентность. И не такой уж этот ваш полиморфизм параметрический.
Туда ли ты зашел, петушок?
Брысь.
>Ну и, стало быть, не для всех типов определена эквивалентность. И не такой уж этот ваш полиморфизм параметрический.
Нет, здесь все честно. В окамле импредикативный полиморфизм и `'a` означает `forall 'a` и поэтому код `id = id` и `id id id = id id id` компилируется (где `id = fun x -> x`), вплоть до рекурсивных типов. То есть `= : 'a -> 'a -> bool` определена для всех _типов_, но не на всех _значениях_.
Стоит добавить, что в core language окамла все типы имеют kind ``. Прямой поддержки higher kinded types в core language нет, только через модули.
>Не понял, а унивалентность тут чем поможет? Не будет же компилятор сам изоморфизмы выводить. Или будет?
Ошибка вылазит в рантайме, потому что структурно (intensionally) в общем случае мы не можем определить равны ли две произвольные функции.
Обычно для эквивалентности функций принимается определение, что для всех аргументов одинаковые значения (extensionally equal).
Пример: f x = 2 (x+5), g x = 2*x + 10.
Две функции extensionally equal, но не intensionally. Термы разные, а результаты возвращают одинаковые.
Extensional equality - это judgement. То есть это мета-правило над языком. Чтобы стало понятнее, стоит открыть спеку какой-нибудь теории типов и посмотреть на typing rules - они все judgements и они описывают язык (в нашем случае язык программирования).
Чтобы выразить утверждение об эквивалентности функций в самом языке необходима propositional equality. То есть нужен способ сказать на уровне типов, что две функции принимают одинаковое значение. Для этого вводится identity type (индуктивный зависимый тип), который по парадигме propositions as types выражает эту propositional equality. Таким образом мы встраиваем в язык extensional equality. Вот так она выражается внутри самого языка:
_ ≈ _ ∷ forall A B. (A -> B) -> (A -> B) -> (A -> Type)
f ≈ g ≡ forall x. Id(f x, g x)
Из того, что judgements удовлетворяют computational equality (это как раз про редукцию термов, то есть вычисляя 2+2 мы получаем 4), они и propositionally equal. Знание, что на мета-уровне 2+2 редуцируется до 4, дает возможность выразить внутри самого языка на уровне типов этот факт - `Id(2+2, 4)`. Тип Id(a, a) строится с помощью конструктора refl. Таким образом с помощью computational equality мы тип `Id(2+2, 4)` приводим к виду `Id(4, 4)`, который разумеется населен `refl`.
Обратное не работает в общем случае. Можно добавить judgement, что если `Id(a,a')` населен (существует терм этого типа), то `a = a'` на уровне judgement. Из этого следует, что:
f ≈ g -> f = g
То есть мы получаем functional extensionality внутри языка и вроде все становится клево. К сожалению, это превращает теорию типов в экстенсиональную и ломает тайпчекинг. Так работают пруверы семейства PRL: nuPRL, RedPRL, etc.
Что происходит в HoTT:
Привычные identity types заменяются на paths и вводится понятие эквивалентности `≃` - это функция A -> B с полезными о себе доказательствами. Тогда можно сформулировать утверждение, что если A = B (то есть Id(A, B), а именно существует path из A в B), то A эквивалентен B.
A = B -> (A ≃ B)
Сама аксиома унивалентности говорит, что:
A = B ≃ (A ≃ B)
То есть равенство эквивалентно эквивалентности. Из этого как следствие вытекает function extensionality, возможность говорить об эквивалентности функций внутри языка, сохраняя тайпчекинг.
Не знаю, меня всё равно коробит. Параметрический полиморфизм подразумевает, что функция с переменными для типов в сигнатуре будет работать для всех типов вне зависимости от этих типов. То есть, с функцией id понятно - ей всё равно, какой тип у аргумента, в её теле эта информация не используется. А сравнение на структурное равенство ну никак не может игнорировать тип, потому что для разных типов разное. А когда для разных типов разное определение, это ad hoc .
>Прямой поддержки higher kinded types в core language нет
Прекрасно, а это тут вообще каким боком?
>Две функции extensionally equal, но не intensionally
Протестую. При нормализации они обе дают один и тот же терм, стало быть, имеет место definitional equality.
>Чтобы стало понятнее
Спасибо, мне и так вроде понятно. Непонятно другое: как же именно, всё-таки унивалентность поможет компилятору сравнивать функции? Унивалентность позволяет свести вопрос о тождестве к вопросу об эквивалентности, значит, видимо, компилятор будет вынужден доказывать эквивалентность. Не то чтобы я был готов доказать, но интуиция подсказывает, что это невозможно.
А нет, не протестую, там помимо нормализации ещё коммутативность нужна.
И даже ассоциативность. Да, это я не подумал.
Наверное, ты дистрибутивность имел ввиду. Но мне с моей маленькой колокольни не понятно, что мешает добавить в язык возможность описания законов, а компилятор научить эти законы применять, чтобы сравнивать разные, но эквивалентные термы?
Скажем, полностью раскрыть скобки в выражении, отсортировать аргументы коммутативных операторов, вычислить константы, поприменять альфа-эквивалентность. В том же примере:
f y = 2(y+5) -> 2y + 2x5 -> 2y + 10 -> 2a + 10
g x = 2x + 10 -> 2a + 10
Да, ты прав. Именно `=` - ad-hoc. Подумал и понял, что сильно тупанул. Извиняюсь.
>Прекрасно, а это тут вообще каким боком?
Хотел какую-то мысль дальше написать, но забыл удалить.
>как же именно, всё-таки унивалентность поможет компилятору сравнивать функции
Она ему никак не поможет, она просто дает _возможность_ это выразить.
>компилятор будет вынужден доказывать эквивалентность
Доказывать - значит строить терм какого-то типа. С зависимыми типами вывод типов (и термов) не работает до конца. Так что да, в общем случае это невозможно. Надо делать самому руками.
Так оно и происходит в агде, где часто можно выводить термы для типов и для такой простой арифметики это сработает, но не в общем случае.
>для такой простой арифметики
Это же типичные алгебраические преобразования.
>но не в общем случае.
Кажется, что в большом количестве практических случаев это должно сработать. Программист сейчас вынужден в блокнотике доказывать корректность реализации, скажем функтора. Причем, это тупое сравнения структур термов после всех преобразований.
>Во время компиляции это не отлавливается, потому что сложно:
А с тайпклассами было бы просто.
>код `id = id` и `id id id = id id id` компилируется
>определена для всех _типов_, но не на всех _значениях_.
Не понимаю, какой толк от того, что он компилируется, если на всех значениях функциональных типов он гарантированно падает в рантайме.
У тебя блог есть? Запости свои посты в блог, чтобы гуглилось, анон.
>Именно `=` - ad-hoc. Подумал и понял,
А, ок, тогда disregard предыдущий пост, я suck cocks.
>я suck cocks
Только вышел из яой-треда, и тут опять.
>А с тайпклассами было бы просто.
Не все так просто. Почему-то люди на форумах думают, что раз в одном языке какая-то фича выстрелила, то ее легко притащить в другой и там все будет заебись, забывая, что консистентность системы типов может пойти по пизде. Если бы все было так просто, то так бы давно сделали.
Лол. Пока в Окамл-треде идет обсуждение господ, в хаскель-треде решают лабы.
Так держать, верблюды.
Так держать, верблюды.
В этих тредах сидят ровно одни и те же люди. И не "решают лабы", а один поехавший вторую неделю одну и ту же задачку мусолит.
Солверы-то есть, не проблема. Проблема в том, что нужен нормальный язык для доказательств, из которого можно нормально экстрактить рабочий код. Языки для доказательств нынче более-менее терпимые, а с экстракцией проблемы. Ну можно какой-нибудь Liquid Haskell взять, там поверх хаскеля навешиваются сигма-типы (или вроде того), решаются модел-чекером автоматически.
Уважаемые товарищи эмельщики. Когда же будут алгебраические эффекты?
Почему-то почти никто, хотя язык то норм. Вполне можно было бы гонять вместо монструозной скалы. Но есть замкнутый круг - не используют так как экосистема бедная, либ мало.. .а либ мало потому-что не используют.
Скала взлетела, потому что под JVM не было аналога C#. А под дот нет был, называется C#. Если бы C# оставался в версии 1.0 до 2014 года, но при этом был бы C#, то F# бы взлетел, естественно, за неимением альтернатив.
Я думал он из-за еботни с интеропом не взлетел
>алгебраические эффекты
Через год-два.
>Но есть замкнутый круг - не используют так как экосистема бедная, либ мало
Много либ, экосистема богатая.
Он живой вообще? На нём же почти нихера не пишут, вакансий ничтожно мало, известных проектов, активно развивающихся тоже мало... какие-то автоматизированный системы подпорки жабаскрипт костылей в духе Flow, bucklescript и ReasonML, и в общем-то всё.
let () = bump ()
чтобы постдокам во франции было о чем статьи писать
ну ты, бля, как маленький, глупые вопросы задаешь
Подкиньте идею мелкого десктопного аппа на камле так чтобы это не выглядело чисто выебоном по приколу на камле напесал))
Не тонем
Каталог индивидуалок для любителей продажной любви. Нужно хранить фотографии, телефоны и отзывы о шлюшках и вести историю для каждой инди.
1
А на OCaml потому что у каждой будет монада!
Возможно, вы имели в виду: манда
>ocaml
>монады
Хуле бы и нет то?
Lwt например - монада на самом деле нет, но всем похуй.
Я пишу за зарплату. Facebook пишет, janestreet, dassault, lexify, tezos foundation, citrix, дохуя кто.
А чо там у ситрикса на сабже?
Чтиво: https://realworldocaml.org, хотя многие пишут, что OCaml from the Very Beginning намного лучше.
Работа: например, контора под названием ahrefs вроде бы с украинскими корнями, офисы в Сан-Франциско и Сингапуре.