"Легко міркувати про" - що це означає? [зачинено]

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

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

Питання: Чи можете ви навести кілька прикладів "Нелегко міркувати про", тому це можна порівняти із прикладами "Легко міркувати"

На мій погляд, фраза "легко міркувати про", відноситься до коду, який легко "виконати в голові".

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

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

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

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

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

Ще гіршими є глобальні змінні: щоб розмірковувати про код, який читає глобальну змінну, вам потрібно зрозуміти, де у вашому коді ця змінна може бути встановлена ​​і чому - і навіть не може бути легко знайти всі ці місця.

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

Що стосується функціонального програмування, значення «Легко міркувати про» полягає в тому, що воно детерміновано. Під цим я мав на увазі, що даний вхід завжди призведе до одного і того ж результату. Ви можете робити все, що завгодно з програмою, доки ви не торкнетеся цього фрагмента коду, він не порушиться.

З іншого боку, OO, як правило, важче міркувати, тому що "отриманий вихід" залежить від внутрішнього стану кожного об'єкта, що займається. Типовим способом його прояву є несподівані побічні ефекти : при зміні однієї частини коду ламається незрозуміла частина.

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

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

Уникаючи більш широкого обговорення та вирішення конкретного питання:

Чи можете ви навести кілька прикладів "Нелегко міркувати про", тому це можна порівняти із прикладами "Легко міркувати про"?

Я посилаю вас на "Історію Мела, справжнього програміста" , твір програмувального фольклору, який датується 1983 роком і тому вважається "легендою" для нашої професії.

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

явна нескінченна петля насправді була закодована таким чином, щоб скористатися помилкою перенесення при перенесенні. Додавання 1 до інструкції, яка розшифровується як "Завантажити з адреси x", зазвичай отримує "Завантажити з адреси x + 1". Але коли x вже була найвищою можливою адресою, не тільки адреса завершилась до нуля, але 1 перенесла в біти, з яких буде читатися опкод, змінивши опкод з "завантаження з" на "перейти на" так що повна інструкція змінилася з "завантаження з останньої адреси" на "перейти до нульової адреси".

Це приклад коду, який "важко міркувати".

Звичайно, Мел не погодився б ...

Я можу навести приклад і дуже поширений.

Розглянемо наступний код C #.

// items is List<Item>
var names = new List<string>();
for (var i = 0; i < items.Count; i++)
{
    var item = items[i];
    var mangled = MyMangleFunction(item.Name);
    if (mangled.StartsWith("foo"))
    {
        names.Add(mangled);
    }
}

Тепер розглянемо цю альтернативу.

// items is List<Item>
var names = items
    .Select(item => MyMangleFunction(item.Name))
    .Where(s => s.StartsWith("foo"))
    .ToList();

У другому прикладі я точно знаю, що цей код робить з першого погляду. Коли я бачу Select, я знаю, що перелік елементів перетворюється на список чогось іншого. Коли я бачу Where, я знаю, що певні елементи фільтруються. З namesпершого погляду я можу зрозуміти, що таке, і ефективно використовувати це.

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

Зрештою, простота міркування тут також залежить від розуміння методів LINQ Selectта Where. Якщо ви їх не знаєте, то спочатку другий код важче міркувати. Але ви сплачуєте витрати лише, щоб зрозуміти їх один раз. Ви платите витрати, щоб зрозуміти forцикл кожного разу, коли ви використовуєте його, і знову кожного разу, коли він змінюється. Іноді вартість варто заплатити, але зазвичай набагато важливіше "легше міркувати".

Пов’язана фраза (я перефразую),

Для коду недостатньо " жодних очевидних помилок ": натомість він повинен мати " очевидно, що немає помилок ".

Прикладом порівняно "легко міркувати про" може бути RAII .

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

Суть програмування - аналіз випадку. Алан Перліс на це зауважив у Епіграмі № 32: Програмісти повинні вимірюватися не своєю винахідливістю та логікою, а повнотою їх аналізу.

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

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

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

Властивість систем, що спрощує міркування, є ортогональністю : це властивість того, що випадки, що регулюють підсистеми, залишаються незалежними, коли ці підсистеми поєднуються. Жодна комбінація не породжує "особливих випадків". Якщо чотири випадки щось поєднуються з трьома випадками щось ортогонально, є дванадцять випадків, але в ідеалікожен випадок - це сукупність двох випадків, які залишаються незалежними. У певному сенсі насправді не існує дванадцяти справ; комбінації - це лише "виникаючі випадкові явища", про які ми не повинні турбуватися. Це означає, що у нас ще є чотири випадки, про які можна думати, не враховуючи інших трьох в іншій підсистемі, і навпаки. Якщо деякі комбінації мають бути спеціально визначені та наділені додатковою логікою, то міркування складніше. У гіршому випадку у кожної комбінації є якесь особливе поводження, і тоді справді з’являються дванадцять нових справ, які є на додаток до оригінальних чотирьох і трьох.

Звичайно. Візьміть одночасність:

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

Альтернативні моделі, наприклад, програмування без замків або актори: потенційно набагато елегантніші та потужніші, але пекло важко зрозуміти, тому що ви більше не можете покладатися на (здавалося б) фундаментальні поняття, такі як "тепер запишіть це значення в це місце".

Легко міркувати - це один із аспектів методу. Але вибір способу використання вимагає врахування всіх аспектів у поєднанні.

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

Незважаючи на це, вираз тьмяно визначений і не може бути встановлений суворо. Але це не означає, що він повинен залишатися таким тьмяним для нас. Уявімо собі, що структура проходить певний тест і отримує оцінки для різних точок. Хороші оцінки для КОЖНОГО пункту означають, що структура зручна в будь-якому аспекті і, таким чином, "Легко міркувати".

Структура "Легко міркувати про" повинна отримувати хороші оцінки для наступного:

• Внутрішні терміни мають розумні, легко розрізнені та визначені назви. Якщо елементи мають певну ієрархію, різниця між іменами батьків та дочірок повинна відрізнятися від різниці між іменами братів та сестер.
• Кількість типів конструктивних елементів невелика
• Використовувані типи конструкційних елементів - це легкі речі, до яких ми звикли.
• Навряд чи зрозумілі елементи (рекурсії, мета кроки, 4+ розмірна геометрія ...) ізольовані - не поєднуються безпосередньо між собою. (наприклад, якщо ви спробуєте продумати якесь правило рекурсії, що змінюється для 1,2,3,4..n..вимірних кубів, це буде дуже складно. Але якщо ви перекладете кожне з цих правил у якусь формулу залежно від n, ви будете мати окремо формулу для кожного n-куба і окремо правило рекурсії для такої формули. І про те, що дві структури окремо можна легко подумати)
• Типи структурних елементів очевидно різні (наприклад, не використовуються змішані масиви, починаючи з 0 і з 1)

Чи є тест суб'єктивним? Так, природно. Але і сам вираз є суб'єктивним. Те, що легко для однієї людини, нелегке для іншої. Отже, тести повинні бути різними для різних областей.

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

На прикладі системи міркувань, у пі-числення кожне місце, що змінюється, пам'яттю в імперативній мові, повинно бути представлене як окремий паралельний процес, тоді як послідовність функціональних операцій - це єдиний процес. Сорок років з теореми про LFC, ми працюємо з ГБ оперативної пам’яті, тому, що сотні процесів є меншою проблемою - я використав pi-обчислення для видалення потенційних тупиків із декількох сотень рядків С ++, незважаючи на те, що представники мають сотні обробляє, що раніше вичерпав простір стану приблизно в 3 Гб і вилікує переривчасту помилку. Це було б неможливо в 70-х роках або вимагав суперкомп'ютер на початку 1990-х, тоді як державний простір функціональної мовної програми подібного розміру був досить малим, щоб тоді міркувати.

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

Легко міркувати - це культурологічний термін, саме тому так важко придумати конкретні приклади. Це термін, прикріплений до людей, які повинні робити міркування.

"Легко міркувати про" - насправді дуже самоописова фраза. Якщо хтось дивиться на код і хоче пояснити, що він робить, це легко =)

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

Найгірший випадок для "простого розуму" - це коли єдиний спосіб зрозуміти те, що робить код, - це проходити по черзі через код, як машина Тьюрінга для всіх входів. У цьому випадку єдиний спосіб що- небудь міркувати про код - перетворити себе на комп’ютер і виконати його в голові. Ці найгірші приклади легко помітити в ослаблених конкурсах програмування, таких як три рядки PERL, які розшифровують RSA:

#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)

Що стосується простого міркування, знову ж таки, термін є висококультурним. Ви повинні врахувати:

• Якими навичками володіє ресаунер? Скільки досвіду?
• Які запитання можуть мати у кодового питання про код?
• наскільки певним повинен бути ренаунер?

Кожен із них по-різному впливає на "легко міркувати". Візьмемо для прикладу навички ренаунера. Коли я почав працювати в своїй компанії, мені рекомендували розробити свої сценарії в MATLAB, тому що це "легко міркувати". Чому? Ну, всі в компанії знали MATLAB. Якби я вибрав іншу мову, мені було б важче когось зрозуміти. Не забувайте, що читабельність MATLAB загрожує деяким завданням, просто тому, що вона не була призначена для них. Пізніше, по мірі просування моєї кар'єри, Python ставав все більш популярним. Раптом код MATLAB став "важко міркувати", і Python став мовою переваги для написання коду, на яку було легко міркувати.

Також розглянемо, які ідоми може мати читач. Якщо ви можете розраховувати на те, щоб ваш читач розпізнав FFT у певному синтаксисі, код "легше міркувати про", якщо дотримуватися цього синтаксису. Це дозволяє їм дивитись на текстовий файл як на полотно, на яке ви намалювали FFT, а не вникати в солодкі зернисті деталі. Якщо ви використовуєте C ++, дізнайтеся, наскільки читачам комфортно користуватися stdбібліотекою. Наскільки їм подобається функціональне програмування? Деякі ідіоми, що виходять із бібліотек контейнерів, дуже залежать від того, який ідентичний стиль ви віддаєте перевагу.

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

Наскільки читач певний, насправді цікавий. У багатьох випадках туманних міркувань насправді достатньо, щоб виріб вийшов із дверей. В інших випадках, таких як програмне забезпечення для польотів FAA, читачеві захочеться мати розсудження із залізами. Я зіткнувся з випадком, коли я сперечався за використання RAII для певного завдання, тому що "Ви можете просто встановити його і забути про нього ... це зробить правильно". Мені сказали, що я помилявся з цього приводу. Ті, хто збирався міркувати над цим кодом, не були тими людьми, які "просто хочуть забути про деталі". Для них RAII більше нагадував висячу чаду, змушуючи їх думати про все, що може статися, коли ви вийдете із сфери застосування.