vak | Скала: функционально или процедурно

Удачный язык Scala: хочешь пиши в функциональном стиле, а хочешь - в традиционном процедурном, на выбор. Сравним два стиля на примере упомянутой задачки Two-Sum.

Функциональный стиль, так называемый "однострочник":

def twoSum(nums: Array[Int], target: Int): Array[Int] = {
    nums.zipWithIndex.combinations(2).find(_.map(_(0)).sum == target).get.map(_(1))
}

Процедурный стиль:

def twoSum(nums: Array[Int], target: Int): Array[Int] = {
    for (j <- nums.indices) {
        for (i <- 0 until j) {
            if (nums(i) + nums(j) == target) {
                return Array(i, j)
            }
        }
    }
    throw Exception("no solution")
}

Какое из этих двух решений легче понять и доработать при необходимости?

Мне по жизни доводилось решать задачки в функциональном стиле. Делали мы однажды девайс для передачи данных, и надо было научить его тестировать линию связи. Для этого на девайсе нажимается кнопочка, и такой же девайс на удалённом конце линии включает "шлейф" - принятые от нас данные заворачивает обратно к нам. Нужен простой способ послать команду удалённому девайсу, не вмешиваясь в основной поток данных. Имелся медленный однобитовый канал out-of-band. Решение было послать по этому последовательному каналу псевдослучайный поток, сформированный сдвиговым регистром с обратной связью (LSFR).

Математически LSFR выглядит как двоичный полином, к примеру x¹⁶+x¹⁴+x¹³+x¹¹+1. Чтобы выбрать подходящий к ситуации полином, я быстренько сбацал код на Scheme, и через час решение было найдено.

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

Перефразируя Форреста Гампа, это всё, что я могу сказать о моём отношении к функциональному программированию. 😀

Flat | Top-Level Comments Only

From:

euthanasepam

Процедурное человеку наглядней и понятней, поскольку мы рассуждаем и вообще мыслим процедурно, и мир вокруг нас в некотором смысле процедурен и для нашего восприятия последователен (с точки зрения линейности и направленности времени, каким его мы себе обычно представляем). У математиков своя реальность, где, помолясь, иногда можно (и даже нужно) сократить записи, упаковав цепь рассуждений в одну работающую формулу. Простому же человеку готовая формула может и не подсказывать о скрывающихся за нею рассуждениях и операциях, может и вовсе ничего не подсказывать, выглядя как китайская грамота. Если исходить из того, что предназначение программного текста — чтение его прежде всего человеком, то предпочтительней понятность и наглядность.

vanja_y

и мир вокруг нас в некотором смысле процедурен и для нашего восприятия последователен

Зависит от тренировки. Если много лет писать однопоточный код, то восприятие будет поледовательным. Если разрабатывать схемы на каком-нибудь VERILOG, то будет вполне себе паралельным.

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