Чому багатослівність погана для мови програмування? [зачинено]

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

Єдиний недолік, про який я можу подумати - це те, що це змушує вас набирати більше, але я маю на увазі, що більшість людей використовують IDE, які роблять всю роботу за вас.

Отже, які можливі недоліки в мові багатослівного програмування?

Мета - швидке розуміння

"Багатослівний" означає "використовує занадто багато слів". Питання в тому, що таке "занадто багато".

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

Сигнал проти шуму

Якщо мова є багатослівною, більше вашого коду - це шум. Порівняйте Java "Hello Hello" :

class HelloWorldApp {
    public static void main(String[] args) {
        System.out.println("Hello World!");
    }
}

... з Рубі:

print "Hello World!"

Шум витрачає психічну енергію.

Cryptic vs Clear

З іншого боку, надмірна терміновість у мові також коштує розумової енергії. Порівняйте ці два приклади із Common Lisp :

(car '(1 2 3))   # 3 characters whose meaning must be memorized
# vs
(first '(1 2 3)) # 5 characters whose meaning is obvious

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

x++ а не set(x,Integeradd(get(x),1))

пс. Це не лише питання читання коду. У дні 40x25 екрани тоді мови типу APL або Perl були корисними для Cobol або Fortran за кількість коду, який ви могли прочитати / на сторінку. Але тепер мова йде більше про ваш власний внутрішній кеш - якщо у виписці є один оператор, моєму старечому мозку легше розібратися, ніж один із 3 символами та 4 викликами функцій.

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

Деякі мови мають такий багатослівний синтаксис, що розуміння значення коду займає більше часу (я думаю про VB.NET проти C #):

If something Then
End If

if(something)
{}

Це дійсно зводиться до того, що кодер знайомий і комфортний.

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

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

Подивіться на весь шум ключових слів у цьому тривіальному прикладі:

tell application "Finder"
    if folder "Applications" of startup disk exists then
        return count files in folder "Applications" of startup disk
    else
        return 0
    end if
end tell

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

Я думаю, що вам потрібно повернути питання на голову і запитати: Чому деякі люди вважають, що короткий код хороший?

Моя відповідь буде, що є дві основні причини:

Причини, чому терс може бути кращим

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

Причини, чому терс може бути гіршим

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

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

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

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

Другий і більш стислий стиль - математичне орієнтоване (математичне) програмування. Цей стиль міркування також покладається на мову, оскільки, наприклад, змінні аналогічні іменникам, а оператори - дієсловам. Однак математичне міркування використовує дивовижну і дуже паралельну здатність нашого мозку робити складні просторові перетворення на об'єктах, що знаходяться в нашій лінії зору. Представляючи іменники та дієслова як компактні, відмінні символи, які можна впорядкувати в добре структуровані уявні об'єкти - рівняння - ми можемо використовувати наші високопаралельні візуальні можливості для виконання обертань, замін, рухів, інверсій та інших перетворень на цих уявних об’єкти. Результат - величезне збільшення кількості випадків, з якими ми можемо розробитись одразу, оскільки кожен символ може представляти цілі класи об'єктів, що мають тісний зв’язок.

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

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

То що б я рекомендував?

Використовуйте обидва стилі, але уважно приділіть, чому ви використовуєте кожен стиль.

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

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

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

Ряд людей натякнув на щось, що, на мою думку, повинно бути чітко сказано.

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

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

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

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

Замість того, щоб перейти до технічної книги, я повернувся до елементів стилю * Струнк і Білий. В основі лежить концепція "Будьте точні" та "Не кажіть більше, ніж потрібно". Все інше - коментар.

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

• Я цитую оригінальну версію, оскільки вона є найбільш стислою. :-)

Зрештою, все, що є "іншим", викличе людей. Мені подобається синтаксис стилю C, а отже, добре з іншими мовами, які мають спільний синтаксис (C ++, Java, C #). Тому я схильний надавати перевагу саме цьому стилю.

Мови, як правило, знаходять баланс між достатньо описовим, а не багатослівним.

Perl - приклад, коли можна написати дуже стислий код. Для непосвячених код, написаний ніндзя Perl, не є малим.

COBOL - приклад занадто багатослівного.

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

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

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

Ейнштейн правильно зрозумів: "Зробіть речі максимально простими, але не простішими".

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

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

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

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

Справжня майстерність полягає в тому, щоб робити складні речі простим способом, а не робити складні речі складними способами.

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

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

Оскільки більше коду означає більше часу розробки та більше помилок.

Якщо ви пишете 100 рядків кодів, а не 300 рядків кодів. Це означає, що вам потрібно майже 1/3 необхідних для вас розробки та 1/3 потенційних помилок, які ви можете зустріти.

У більшості випадків вам потрібно збалансувати ефективність та стислість, оскільки писати менше кодів означає, що машині потрібно робити більше справ, і це знизить ефективність.

Зазвичай люди віддають перевагу читаним / багатослівним мовам над криптованими / стислими. Однак я вважаю, що більшість людей засвоюють «багатослів’я» з «захаращенням», що не одне і те ж.

Наприклад: while(<>){print if($.==2 || $& && !$x++); $.=0 if (/^--+$/)}

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

З іншого боку, багатослівність - це http://en.wikipedia.org/wiki/Literate_programming , яку я вважаю досить цікавою концепцією.

Ще один аспект - «небажана багатослівність», яку також називають «захаращенням». Речі, які потрібно додати з технічних причин, відсутність синтаксичного цукру, роздуті API та інше.

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

Багатослівність - це тенденція до використання великої кількості тексту, а Terseness - використання дуже мало тексту ...

Багатослівність погана, оскільки:

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

Певний рівень багатослівності є важливим для ясності, однак ...

мінімальний рівень Verbosity хороший тим, що:

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

Деякі чудові приклади занадто скупих команд для багатьох людей включають старі BASIC резервних кошти val(x$), str$(x)і chr$(x)... повертають число з його строкового подання, повертають рядок для номера, і повертають один символ , що має значення ASCII х у вигляді рядка.

Або вказівник C / C ++ і посиланнями операторів &та ключовим словом *BASIC byref. У C / C ++ я можу мати змінну X і передати вказівник на цю змінну, але я повинен пам’ятати, який є вказівник, а який - «вказівник використання як змінна, на яку він вказує»; в основному я просто передаю посилання на ключове слово byref у виклику функції, який є більш зрозумілим, але менш гнучким:

def fn Foo(x byref as float) foo= (x += x+1)
...
Foo(x)

У цьому коді вміст x змінюється через прапор byref. Деякі аромати дозволяють бутиреф по дзвінку, інші - за визначенням, інші - будь-яким.

Багатослівність важлива для випадкових програмістів, щоб мати можливість легше використовувати символіку; BASIC або python є більш читабельними для людини та більш дослідними, ніж C / C ++, і тому набагато корисніші для випадкових програмістів; лаконічність C / C ++ значно покращує досвідченіших програмістів, яким потрібно побачити більше коду та складнішого коду за один екран, але вони повинні були вивчити різні умовні символьні структури. У кінці кінця APL, який майже повністю не читається для людини.

Тісно пов'язана проблема - чіткість - короткий код часто нечіткий, і надмірно багатослівний код (як в AppleScript) може бути однаково незрозумілим. Ознайомлення з даною мовою збільшує чіткість короткого коду всередині цієї мови - неодноразовий початківець, що стикається з кодом C ++, швидше за все, зможе розібратися лише у формулах, і навіть багато функціональних BASIC або Python-коду занадто просто для розуміння, але applescript може загалом, не зважаючи на мовні словники. Найменш зрозуміле, з чим я стикався без навмисного затуманення, - це Inform 7 ...

За старих часів

Ще одне важливе враження в минулому, але те, що вже не є настільки важливим для кодера хобі, - це робота та простір для зберігання. (Це все ще важливо в кінцевому підсумку.) Маючи на увазі, що багато мов інтерпретувались, особливо BASIC-ароматизатори, і багато інших були складені під час виконання, кодове місце було важливим, особливо, коли диски вміщували лише 128KiB, а окремі пункти-картки лише 80B.

Існувало кілька рішень - токенізація була надзвичайно поширеною в BASIC; окремі ключові слова мови були зменшені до 1 або 2 байтового слова або у верхньому 128, або в просторі контрольних символів. Токенізація також призводить до компіляції байтових кодів (як у Inform та Z-Machine).

Для подолання обмежень на простір також використовувались компіляція декількох об'єктних файлів та посилання. Розділ коду Паскаль кодом 100 Кб може скласти лише 5 КБ; пов'язуючи декілька складених файлів, можна було створити масивні програми, не маючи доступу до накопичувачів великого формату (пам’ятаючи, що 10MiB було приголомшливо великим, і купити новий автомобіль дорого).

Однак більш лаконічні мови отримали більше коду в заданий фрагмент як диска, так і оперативної пам’яті, і, таким чином, компілювали більші шматки за раз. Маючи на увазі: «міні-комп’ютери» початку 1970-х могли мати лише 64 Кбіт оперативної пам’яті (Honeywell 800 мав базову установку з 4 банків по 2048 слів по 8В у кожному). APL та подібні символічні мови наближаються до 1B за інструкцію плюс його операнди, порівняно зі значно більшими 3B-10B за інструкцію плюс операндами. (Це було кошмаром набирати на перфокарти, тим більше, що символи, по суті, були шрифтом на кулі типу, і багато картонних ударів не мали символів на клавішах ...)

Також майте на увазі, що картки не вдалося стерти ... і на програмах було введено багато програм. Хоча це не окремо дорого, тим більше стиснутий код може на картці, тим менше вам потрібно, і чим більші програми можуть бути, тим менш дорогими. Це є причиною того, що BASIC має поєднання декількох інструкцій на рядок у більшості смаків - це було введено для економії на перфокартах. (Або так говорить мій текст програмування Vax Basic.) Поки я не запрограмований для зчитування карт, я зробив штампування картки для Honeywell 800 у форматі FORTRAN, BASIC, APL та ще декількох інших символічних мовах.

Як і у багатьох випадках, відповідь залежить від конкретного визначення поняття "багатослів'я". Якщо визначення таке, що багатослів'я передбачає надмірність, то я б стверджував, що це завжди погано. Зауважте, що при такому визначенні часто цитовану програму Java hello world не можна кваліфікувати як "багатослівну", оскільки в ній немає нічого зайвого.

Програмісти, як правило, люблять мови з виразною силою, оскільки це дозволяє їм кодувати прості речі, які часто доводиться робити часто, невеликими фрагментами коду. Багатослівні мови, як правило, означають, що багато, багато рядків коду потрібно використовувати, щоб робити те саме і знову і знову. Однак, ви можете платити щось виразними мовами, оскільки вони можуть бути не настільки швидкими для виконання, як простіші мови високого рівня. Якщо я можу навести приклад в контрасті між C і C ++. C ++ надає більш виразної сили письменникам коду - вони можуть інкапсулювати уявлення про реальні об'єкти світу на заняттях. Програмісти на C можуть досягти одних і тих же речей, але вони мають виразну силу побудови класу, щоб допомогти їм - тому часто їм доводиться писати довший, складніший (для розуміння) код. Але цей код цілком може працювати швидше (хоча це сильно залежить від якості компілятора тощо), оскільки він не використовує "запізніле прив'язування" C ++ (тобто рефакторинг часу виконання) для виконання коду. C тільки виконує скомпільований і пов'язаний код, C ++ повинен прийняти рішення (за певних обставин) під час виконання про те, які фрагменти коду виконувати.

Я вважаю, що є відповідь на запитання, коріння якого є більш фундаментальним і теоретичним питанням, ніж читальність, і ця відповідь пов'язана з алгоритмічною теорією інформації, заснованою Грегорі Чайтіном: http://en.wikipedia.org/wiki/Algorithmic_information_theory . В кількох словах, "інформаційний вміст рядка еквівалентний довжині найкоротшого можливого автономного подання цього рядка", Це означає, що найкоротша програма (а саме з точки зору її лексикографічної довжини) тісно вирішує задану проблему відповідає внутрішній складності проблеми, для якої вона дає рішення, і, таким чином, вона більше залежить від природи проблеми і менше від представлення проблеми.