Чи зрозумілі невеликі обсяги функціонального програмування людям, які не є ПП? [зачинено]

Випадок : я працюю в компанії, пишу заявку в Python, яка обробляє безліч даних у масивах. Я є єдиним розробником цієї програми на даний момент, але вона, ймовірно, буде використана / модифікована / розширена в майбутньому (1-3 роки) деяким іншим програмістом, на даний момент невідомим мені. Я, мабуть, не буду там безпосередньо, щоб допомогти, але, можливо, надам деяку підтримку електронною поштою, якщо у мене буде час на це.

Отже, як розробник, який вивчив функціональне програмування (Haskell), я схильний вирішувати, наприклад, фільтрацію так:

filtered = filter(lambda item: included(item.time, dur), measures)

Решта коду - OO, це просто деякі невеликі випадки, коли я хочу його вирішити так, бо, на мою думку, це набагато простіше і красивіше.

Питання : Чи добре сьогодні писати такий код?

• Як розробник, який не написав / не вивчив FP, реагує на такий код?
• Чи читається?
• Модифікується?

• Чи слід писати документацію, як пояснити дитині, що робить рядок?

   # Filter out the items from measures for which included(item.time, dur) != True

Я попросив свого начальника, і він просто каже: "FP - це чорна магія, але якщо вона працює і є найбільш ефективним рішенням, тоді це нормально використовувати".

Яка ваша думка з цього приводу? Як програміст, який не є FP, як ви реагуєте на код? Чи є код "googable", щоб ви могли зрозуміти, що він робить? Я хотів би отримати відгук про це.

Чи читається?

Для мене: Так, але я зрозумів, що спільнота Python часто, здається, вважає розуміння списку більш чистим рішенням, ніж використання map()/ filter().

Насправді GvR навіть розглядав можливість взагалі відмовитися від цих функцій.

Врахуйте це:

filtered = [item for item in measures if included(item.time, dur)]

Крім того, це має перевагу в тому, що розуміння списку завжди повертає список. map()а filter()з іншого боку поверне ітератор у Python 3.

Примітка. Якщо ви хочете мати ітератор замість нього, це так само просто, як замінити []на ():

filtered = (item for item in measures if included(item.time, dur))

Якщо чесно, я не бачу причин для використання map()або filter()в Python.

Чи можна змінити?

Так, звичайно, є одне, що полегшує це: зробити це функцією, а не лямбда.

def is_included(item):
    return included(item.time, dur)
filtered = filter(is_included, measures)
filtered = [item for item in measures if is_included(item)]

Якщо ваш стан стане складнішим, це значно зменшить масштаб, а також дозволяє повторно використовувати чек. (Зверніть увагу, що ви можете створювати функції всередині інших функцій, це може тримати її ближче до місця, де вона використовується.)

Як розробник, який не написав / не вивчив FP, реагує на такий код?

Він шукає документацію на Python і знає, як вона працює через п'ять хвилин. Інакше він не повинен програмувати в Python.

map()і filter()є надзвичайно просто. Це не так, як ти просиш їх зрозуміти монадів. Тому я не думаю, що потрібно писати такі коментарі. Використовуйте хороші назви змінних та функцій, тоді код майже не пояснює себе. Ви не можете передбачити, які мовні особливості розробник не знає. Наступний розробник може не знати, що таке словник.

Те, що ми не розуміємо, зазвичай для нас не читається. Таким чином, ви можете стверджувати, що це не менш читабельно, ніж розуміння списку, якщо ви ніколи не бачили жодного з них раніше. Але, як Джошуа зазначив у своєму коментарі, я теж вважаю, що важливо відповідати тому, що використовують інші розробники - принаймні, якщо альтернатива не дає суттєвої переваги.

Оскільки спільнота розробників відновлює інтерес до функціонального програмування, незвично бачити деякі функціональні програми на мовах, спочатку повністю орієнтованих на об'єкти. Хороший приклад - C #, де анонімні типи та лямбда-вирази дозволяють бути набагато коротшими та виразнішими за допомогою функціонального програмування.

Як сказано, функціональне програмування дивно для початківців. Наприклад, коли під час навчального курсу я пояснював початківцям, як вони можуть покращити свій код за допомогою функціонального програмування на C #, деякі з них не переконалися, а деякі сказали, що оригінальний код для них легше зрозуміти. Приклад, який я надавав їм, був такий:

Код перед рефакторингом:

var categorizedProducts = new Dictionary<string, List<Product>>();

// Get only enabled products, filtering the disabled ones, and group them by categories.
foreach (var product in this.Data.Products)
{
    if (product.IsEnabled)
    {
        if (!categorizedProducts.ContainsKey(product.Category))
        {
            // The category is missing. Create one.
            categorizedProducts.Add(product.Category, new List<Product>());
        }

        categorizedProducts[product.Category].Add(product);
    }
}

// Walk through the categories.
foreach (var productsInCategory in categorizedProducts)
{
    var minimumPrice = double.MaxValue;
    var maximumPrice = double.MinValue;

    // Walk through the products in a category to search for the maximum and minimum prices.
    foreach (var product in productsInCategory.Value)
    {
        if (product.Price < minimumPrice)
        {
            minimumPrice = product.Price;
        }

        if (product.Price > maximumPrice)
        {
            maximumPrice = product.Price;
        }
    }

    yield return new PricesPerCategory(category: productsInCategory.Key, minimum: minimumPrice, maximum: maximumPrice);
}

Той самий код після рефакторингу за допомогою FP:

return this.Data.Products
    .Where(product => product.IsEnabled)
    .GroupBy(product => product.Category)
    .Select(productsInCategory => new PricesPerCategory(
              category: productsInCategory.Key, 
              minimum:  productsInCategory.Value.Min(product => product.Price), 
              maximum:  productsInCategory.Value.Max(product => product.Price))
    );

Це змушує мене думати, що:

• Ви не повинні турбуватися, якщо знаєте, що наступний розробник, який підтримуватиме Ваш код, матиме достатній загальний досвід та деякі знання функціонального програмування, але:

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

Я програміст, який не є FP, і нещодавно мені довелося змінити код свого колеги в JavaScript. Був Http-запит із зворотним дзвоном, який дуже нагадував додану вами заяву. Треба сказати, що мені знадобилося певний час (як півгодини), щоб все це зрозуміти (код загалом був не дуже великий).

Не було жодних коментарів, і я думаю, в цьому не було потреби. Я навіть не просив колегу допомогти мені зрозуміти його код.

Враховуючи те, що я працюю близько 1,5 років, я думаю, що більшість програмістів зможуть зрозуміти та змінити такий код, оскільки я це зробив.

Крім того, як сказав Йоахім Зауер у своєму коментарі, часто є фрагменти ПП на багатьох мовах, як, наприклад, C # (indexOf, наприклад). Тож багато програмістів, що не належать до ПП, займаються цим досить часто, і фрагмент коду, який ви включили, не є чимось жахливим або незрозумілим.

Я б точно сказав, що так!

Існує багато аспектів функціонального програмування, а використання функцій вищого порядку, як у вашому прикладі, є лише одним із них.

Наприклад, я вважаю написання чистих функцій надзвичайно важливим для будь-якого програмного забезпечення, написаного будь-якою мовою (де під "чистим" я маю на увазі відсутність побічних ефектів), оскільки:

• їх простіше провести одиничну перевірку
• вони набагато більше композиційні, ніж побічні функції
• їх простіше налагодити

Я також часто уникаю мутуючих значень та змінних - інша концепція, запозичена у FP.

Обидві ці методи чудово працюють у Python та інших мовах, які зазвичай не класифікуються як функціональні. Їх часто навіть підтримує сама мова (тобто finalзмінні на Java). Таким чином, майбутні програмісти з технічного обслуговування не зіткнуться з глибоким бар'єром для розуміння коду.

У нас була така сама дискусія про компанію, в якій я працював минулого року.

Дискусія стосувалася "магічного коду", і чи варто його заохочувати чи ні. Подивившись на це трохи більше, здавалося, що люди мали дуже різні погляди на те, що насправді є "магічним кодом". Ті, хто підняв дискусію, здавалося, в основному означають, що вирази (в PHP), які використовували функціональний стиль, були "магічним кодом", тоді як розробники, які походять з інших мов, які використовували більше FP-стилю в своєму коді, здається, вважають, що магічний код швидше коли ви робили динамічне включення файлів через імена файлів тощо.

Ми ніколи не прийшли до цього хорошого висновку, більше того, що люди в основному думають, що код, який виглядає незнайомим, є "магічним" або важко читати. Тож чи гарна ідея уникати коду, який здається незнайомим іншим користувачам? Я думаю, що це залежить від того, де він використовується. Я б утримався від використання виразів у стилі fp (динамічне включення файлів тощо) в основному методі (або важливих центральних частинах додатків), де дані повинні бути тунельними чітким та легким для читання, інтуїтивним способом. З іншого боку, я не думаю, що варто побоюватися натиснути на конверт, інші розробники, ймовірно, швидко вивчать FP, якщо вони зіткнуться з кодом FP ​​і, можливо, матимуть хороший власний ресурс для консультацій з питань.

TL; DR: уникайте центральної частини додатків високого рівня (які потрібно прочитати для огляду функціональності програми). В іншому випадку використовуйте його.

Нещодавно спільнота C ++ отримала і лямбда, і я вважаю, що вони мають приблизно те саме питання. Однак відповідь може бути не однаковою. Еквівалент C ++ був би:

std::copy_if(measures.begin(), measures.end(), inserter(filter),
  [dur](Item i) { return included(i, dur) } );

Зараз std::copyне ново, і _ifваріанти теж не нові, але лямбда є. І все-таки це визначено досить чітко в контексті: durзахоплюється і, отже, є постійним, Item iзмінюється в циклі, і одне returnтвердження виконує всю роботу.

Це виглядає прийнятним для багатьох розробників C ++. Я не брав на себе вибірки думок щодо лямбда вищого порядку, і я би очікував набагато менше прийняття.

Надішліть фрагмент коду співрозмовнику, який не так добре володіє пітоном, і запитайте його, чи може він витратити 5 хвилин на перевірку коду, щоб дізнатися, чи він це розуміє.

Якщо так, ви, мабуть, добре їхати. Якщо ні, то слід поглянути на те, щоб зробити це зрозумілішим.

Чи міг ваш колега бути спритним і не зрозуміти чогось, що має бути очевидним? Так, але ви завжди повинні програмувати відповідно до KISS.

Можливо, ваш код є більш ефективним / гарним виглядом / елегантним, ніж більш прямий ідіотівський підхід? Тоді вам потрібно запитати себе: чи потрібно це робити? Знову ж таки, якщо відповідь - ні, тоді не робіть цього!

Якщо після всього цього ви все-таки вважаєте, що вам потрібно, і хочете зробити це FP способом, то всіма силами зробіть це. Довіряйте своїм інстинктам, вони краще підходять для ваших потреб, ніж більшість людей на будь-якому форумі :)