Comments 18
Исправьте название поста «пРограммируем»… В глаза бросается.
Блин, сам хотел перевести эту статью пару месяцев назад, но думал что никому не будет интересно :)
Я подумал, что после этой статьи — habrahabr.ru/post/189712/, ещё одна статья про линзы не помешает
Как такое…
units.traversed.(around target 1.0).health -= 3
… может не заинтересовать?
***даже без упоминания, что это — чистый, в смысле изменения состояния, код.
units.traversed.(around target 1.0).health -= 3
… может не заинтересовать?
***даже без упоминания, что это — чистый, в смысле изменения состояния, код.
просто бросают изучать функциональные языки намного раньше, чем смогут обнаружить подобные удобные вещи. Имхо
А зачем изучать декларированный язык, что бы писать на нём императивный код?
Вообще задачи разные бывают. И необходимы разные подходы к разным задачам.
Во-первых, не декларированный, а декларативный. Во-вторых, Haskell — не декларативный, а функциональный язык.
В чисто функциональном языке для обычной разработки особого смысла нет, поэтому в Haskell есть средства работы с состояниями. Какой смысл изучать? Хотя бы для того, чтобы писать в несколько раз меньше кода.
В чисто функциональном языке для обычной разработки особого смысла нет, поэтому в Haskell есть средства работы с состояниями. Какой смысл изучать? Хотя бы для того, чтобы писать в несколько раз меньше кода.
Стоит ли идти к функциональному языку, а потом придумывать/искать костыли решения, чтоб писать на нем в императивном стиле?
Стоит
Некоторые вещи удобно выразить с помощью одного способа, а некоторые — с помощью другого. Самый банальный пример: рекурсивные алгоритмы можно выразить без рекурсии (иногда просто через циклы, иногда надо писать свой стек), но при этом можно потерять красивость и понятность кода. Решение любых динамических задач можно выразить через ручной императивный алгоритм, через рекурсию с кешем или через определение переходов между состояниями (не видел такого. но как идея интересна; редактирование: хотя, возможно стоит глянуть на пролог). Точно так же с функциональщиной и императивщиной. Смешивая парадигмы мы можем получить оптимальный код с точки зрения удобности, понятности и скорости.
Линзы — это не костыли, а другой подход. Более удобный и выразительный.
Думаю, что несмотря на название «программируем императивно», линзы ближе к «программируем объектно-ориентированно».
Но, линзы — это всё же не объекты, поэтому говорить о костылях в данном случае неуместно.
В основном человек принимает новое только через что-то знакомое. Поэтому дана попытка показать совершенно новый инструментарий (ранее неизвестный) при помощи аналогий.
Но, линзы — это всё же не объекты, поэтому говорить о костылях в данном случае неуместно.
В основном человек принимает новое только через что-то знакомое. Поэтому дана попытка показать совершенно новый инструментарий (ранее неизвестный) при помощи аналогий.
Sign up to leave a comment.
Программируем императивно в Хаскеле, используя линзы