Pull to refresh
Конференция разработчиков на Ruby и RoR

Разговор со спикерами FPConf (часть 2)

Reading time2 min

Конференция FPConf уже завтра, сегодня последний шанс купить билет и присоединиться! Регистрация — тут.

Накануне мы решили задать нашим спикерам один довольно неоднозначный вопрос. Большая часть ответов была опубликована вчера — тут

А сегодня мы получили ответ от нашего гостя Эдварда Кметта. Пока публикуем без перевода, обновим пост после конференции.


Вопрос был такой:

В объектно-ориентированных языках есть широко известный список паттернов проектирования (design patterns) от «Банды четырех» (Gang of Four). В функциональных языках такого известного списка не существует. С вашей точки зрения, почему так?
Подобные паттерны не нужны при программировании на функциональных языках или просто их канонический список еще не сложился?

Эдвард Кметт, Глава Haskell core libraries committee, Haskell программист, математик.

Design patterns give you a vocabulary for how to talk about things that your language isn't able to let you craft into a library. We use the term «design pattern» to talk about iterators, visitors, singletons, command patterns, etc. Each of which conveys the «general idea» of what is going on but doesn't actually give you the details of how to use the particular instantiation. You still have to care a great deal about the instances of the abstraction, and can do nothing based on symbol pushing with laws alone. Functional programmers are much much happier with symbol pushing than imperative programmers. That is a lot easier in a functional setting, where you don't have to go off and reason with Hoare logic or separation logic to figure out the state of the universe after each instruction like you do in an imperative setting.

We do have «design patterns» after a fashion in the functional programming world. The notion of monad «transformers», of effect systems, of encoding things in a 'finally tagless' manner, or initial encodings of syntax trees, of using 'data types a la carte', building interpreters for embedded DSLs, or «classy lenses» all have that same sort of design pattern feel to them. Data.Vector replicates the same list-like API a half dozen times. These all rise at least to the level functional programming idioms. The major difference in culture I think is that for the most part we like even these patterns or abstractions to carry with them some laws, while design patterns merely carry cultural guidelines.

In practice I personally like to pursue constructions that are somehow universal or free or something that is initial or terminal in a category theoretic sense. Why? Because if I can produce such a solution any other solution in the space should factor through mine.

But I think ultimately a design pattern in most settings is an attempt to go a bit beyond the notion of the idioms of a language, but not quite into the realm of laws, and that middle ground isn't something we tend to like too much as functional programmers. After all, an abstraction you can't reason about isn't an abstraction at all.

А что вы думаете по этому поводу?
Обсудим на FPConf.ru. Присоединяйтесь!
Total votes 6: ↑5 and ↓1+4