Pull to refresh
4
0

Haskell разработчик

Send message

Ну так хаскель 90-го года и хаскель совеременный — это очень разные языки.

школьная реализация динамики вручную

Ну во первых, любая динамика может быть встроена в статику. Во вторых линзы это общий фреймворк для работы с любого вида данными. Тут же только аксессоры и общее представление XML документа.


без каких-либо проверок

Как это без проверок? Там в сигнатурах вполне ясно записано, каким образом аксессор работает и что гарантирует: Lens, Traversal, Prism.


и оптимизаций

При этом оно всё ещё намного оптимальнее, чем в любом монотипизированном языке.


Поставленную задачу (найти по селектору) не решает

По какому селектору вы с этим инструментарием что-то не сможете найти, не поделитесь?


даже комментарии ни та ни другая блин не обрабатывают.

В XML обрабатывает, а в валидном JSON комментариев быть не может.

К счастью у меня под рукой как раз оказалось Generic решение такой задачи для JSON'а: https://gist.github.com/Nexmean/2a85607888c6af2bfa0ec9116847ba71


Примерно аналогичным образом это можно сделать для XML.

Так ведь задача состоит именно в том, чтобы этого не делать.

Необходимая валидация просто делается заранее и всё:


let accessor = el "bar" . el "baz" . text
in if not $ null $ xml ^.. accessor
  then xml & set accessor "1"
  else error "invalid xml"
xml & set (el "bar" . el "baz" . text) "1"

В рантайме ничего не падает. Фактически в таком случае ничего не происходит.

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

Легче лёгкого:



При чём я уверен, что с линзами в хаскеле это будет сделать намного проще, чем в питоне без них.

А вот rank-2 уже нельзя. В том же хаскеле очень трудно найти библиотеку, которая могла бы без них обойтись. Ту же Cont монаду без этого никак не построить.

Может стоит тогда быть хотя-бы оптимальным с опциональной ленью, а не как идрис?

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

В лени нет никакой магии, её поведение вполне себе детерменировано и предсказуемо, так что и надеяться на ум компилятора не обязательно.

В общем-то это не задача для решения через комбинаторы, но вот:


isEqual left right =
  length left == length right
  && (all id $ zipWith (==) left right)

для списков это решение эвалюирует весь список, чтобы посчитать длины.


Простой рекурсией это решается лучше:


isEqual (x:xs) (y:ys) = x == y && isEqual xs ys
isEqual []     []     = True
isEqual _      _      = False

Ну и вариант для вектора, который полностью эквивалентен императивной лапше с циклами и ранним выходом.


isEqual a b = V.length a == V.length b
  && all id
  $  zipWith (==) (V.toList a) (V.toList b)
logAndRet1 :: HasLogger m => m Int
logAndRet1 = do
  logInfo "just info"
  pure 1

HasLogger m здесь обозначает, что у нас монада m наделена возможностью логгирования, при этом интерпретатор логгирования определён где-то выше по колл стэку.

Забавно. Приверженцы ИП так любят говорить любителям ФП "счастливой отладки", но как-то так получилось, что за 8 месяцев работы со скалой и хаскелем мне ни разу не пришлось запускать отладчик.

Сторонники ФП по необразованности, к сожалению, часто ставят себя выше остальных, и всё лишь потому, что они обнаруживают в ФП лишь некоторые возможности, которые давно есть в других языках.

Чушь полная. Большинство фич в мейнстримовые языки приходят из ФП. Начиная от генериков, которые хрен знает когда появились в жаве, заканчивая ADT, которые кое-как добираются до мейнстрима, встречают дикий восторг императивных программистов, хотя в ФЯ они появились ещё в 80-е.


А как ещё назвать людей с самомнением, да к тому же не желающих изучать альтернативы?

Люди в ФП приходят обычно не в начале карьеры, а уже после изучения альтернатив.


Ну и до кучи — возможность изменять внешнее состояние полезна. И если язык позволяет эту возможность использовать — это хороший язык. А если программист при использовании этой возможности не умеет избегать ошибок — это плохой программист. Сторонники ФП нашли выход из такой ситуации — запретили менять внешнее состояние.

Чушь, никто ничего не запрещал. А вообще человеку свойственно допускать ошибки и не надо ляля по поводу того, что это все баги и уязвимости в IT порождены плохими программистами. Человек может устать, может заболеть, может просто ошибиться по невнимательности.


А указывать лишь на один класс ошибок (из миллионов) и при этом гордо задирать нос, мол вот мой любимый подход (ФП) какой прекрасный, это признак очень ограниченного интеллекта.

ФП хорошо не тем, что решает какой-то класс ошибок, а даёт разумные ограничения, которые позволяют проводить local reasoning и тратить меньше времени на понимание кода. Но людям, которые на это всё дело смотрят сугубо со стороны, конечно же такого не понять. В итоге как-то так получается, что все, кто умеет в ФП — сторонники ФП, все кто не умеет — его противники, а людей которые умеют в ФП и при этом ему оппонируют, почему-то дефицит. Это при том, что большинство сторонников ФП, если надо, могут и на C что-то низкоуровневое и на джаве какую-нибудь опердень написать (но скорее всего не станут).

Information

Rating
Does not participate
Location
Владивосток, Приморский край, Россия
Date of birth
Registered
Activity