Программируем императивно в Хаскеле, используя линзы

[ghaiklor]

Исправьте название поста «пРограммируем»… В глаза бросается.

[ghaiklor]

Ну и чего минусуем?

[steck]

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

[maksbotan]

Блин, сам хотел перевести эту статью пару месяцев назад, но думал что никому не будет интересно :)

[Vitter]

Я подумал, что после этой статьи — habrahabr.ru/post/189712/, ещё одна статья про линзы не помешает

[dima_mendeleev]

Как такое…

units.traversed.(around target 1.0).health -= 3

… может не заинтересовать?
***даже без упоминания, что это — чистый, в смысле изменения состояния, код.

[Vitter]

просто бросают изучать функциональные языки намного раньше, чем смогут обнаружить подобные удобные вещи. Имхо

[fshp]

А зачем изучать декларированный язык, что бы писать на нём императивный код?

[Vitter]

Вообще задачи разные бывают. И необходимы разные подходы к разным задачам.

[burjui]

Во-первых, не декларированный, а декларативный. Во-вторых, Haskell — не декларативный, а функциональный язык.

В чисто функциональном языке для обычной разработки особого смысла нет, поэтому в Haskell есть средства работы с состояниями. Какой смысл изучать? Хотя бы для того, чтобы писать в несколько раз меньше кода.

[fshp]

За поправку спасибо, но функциональный язык это частный случай декларативного.

[VladVR]

Стоит ли идти к функциональному языку, а потом придумывать/искать костыли решения, чтоб писать на нем в императивном стиле?

[GrigoryPerepechko]

Стоит

[nsinreal]

Некоторые вещи удобно выразить с помощью одного способа, а некоторые — с помощью другого. Самый банальный пример: рекурсивные алгоритмы можно выразить без рекурсии (иногда просто через циклы, иногда надо писать свой стек), но при этом можно потерять красивость и понятность кода. Решение любых динамических задач можно выразить через ручной императивный алгоритм, через рекурсию с кешем или через определение переходов между состояниями (не видел такого. но как идея интересна; редактирование: хотя, возможно стоит глянуть на пролог). Точно так же с функциональщиной и императивщиной. Смешивая парадигмы мы можем получить оптимальный код с точки зрения удобности, понятности и скорости.

[sophist]

Думаю, люди, которые высказываются подобно тредстартеру, имеют в виду не мультипарадигменность, а именно костыли (попытки писать в парадигме, явно языком не поддерживающейся). Другое дело, что линзы в Haskell, как они здесь описаны, совсем на костыли не похожи.

[nsinreal]

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

[int_index]

Линзы — это не костыли, а другой подход. Более удобный и выразительный.

[Vitter]

Думаю, что несмотря на название «программируем императивно», линзы ближе к «программируем объектно-ориентированно».
Но, линзы — это всё же не объекты, поэтому говорить о костылях в данном случае неуместно.
В основном человек принимает новое только через что-то знакомое. Поэтому дана попытка показать совершенно новый инструментарий (ранее неизвестный) при помощи аналогий.