Принцип KISS застосовується для розробки мови програмування?

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

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

Якби я хотів застосувати це до галузі розробки програмного забезпечення, я б замінив "реактивний літак" на "частину програмного забезпечення", "середній механік" на "середній розробник" і "в бойових умовах" на "під очікувану розробку / обслуговування програмного забезпечення" умови "(терміни, часові обмеження, зустрічі / перерви, доступні інструменти тощо).

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

Але чи можна застосувати принцип KISS також у дизайні мови програмування? Чи знаєте ви про будь-які мови програмування, розроблені спеціально з цим принципом, тобто "дозволити середньому програмісту в середніх умовах праці писати та підтримувати якомога більше коду з найменшими пізнавальними зусиллями"?

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

Коли я думаю про мініміалізм, я думаю про Lisp and Go . З Lisp все, що ви маєте, - це функції та списки, що приблизно так само просто, як і ви можете (ну, ще трохи, але що б там не було). Однак я вважаю, що справа Go є цікавішою.

Go був розроблений так, щоб він був простим (це гідне читання). Термін, який вони використовують, - "ортогональність функції", що означає, що будь-яку функцію слід додавати лише у тому випадку, якщо вона забезпечує щось справді унікальне. Це, мабуть, пов'язане з участю авторів ( приходять на думку Рус Кокс та Роб Пайк ) з Plan9 , який був переосмисленням UNIX з простотою на увазі. (Якщо вас цікавить мінімальний дизайн, папір Роб Піка на простій віконній системі - це добре читати.)

Ось кілька простих прикладів синтаксису:

Лише одна петлева конструкція

Цикл може мати такий вигляд:

Нескінченна петля

for {
}

Поки петля

for <conditional> {
}

Традиційні для петлі

for i := 0; i < 10; i++ {
}

Цикл форекс

// works for maps or arrays
for k, v := range arr {
}

Багатоцільовий вимикач

switch {
    // cases must be evaluate to a boolean
}

switch <value> {
}

switch t := <value>; t {
    // can use t inside
}

Багаторазова віддача

return val1, val2, ...

• Вилучає потребу в киданні (передайте помилку як останнє значення повернення)
• Усуває необхідність у виведенні параметрів
• Знімає потребу в кортежах

Інтерфейси

type X interface {
    DoSomething()
    String() string
}

• Вирішує подібні проблеми, як і дженерики
• Дозволяє абстрагувати

Вбудовування

type A struct {
    Thing string
}

type B struct {
    A // embeds A in B, so B.Thing refers to A.Thing
}

• Вирішує ту ж проблему, що і спадкування
• Уникає потреби в заняттях

Канали

Може використовуватися для реалізації семафорів

var c = make(chan bool, 1)
c<-true // semaphore lock
<-c // semaphore free

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

func produce(c chan<- bool) {
    for {
        c <- true
    }
}
func consume(c <-chan bool) {
    for {
        <-c
    }
}

var c = make(chan bool)
go produce(c)
go consume(c)

Може використовуватися для обробки асинхронних подій

func async() chan bool {
    var c = make(chan bool)
    go doSomethingAsync(c)
    return c
}

// wait for long async process to finish
c := async()
select {
    case _ = <-c:
}

Висновок

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

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

Перевага мов KISS полягає в тому, що можна писати ідіоматичний код, оскільки стиль коду обмежений мовою. Наприклад, у програмі Go ви не можете написати щось подібне:

if <condition>
    statement;

Ви повинні використовувати фігурні брекети:

if <condition> {
    statement;
}

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

Переваги мови KISS перед функціональними мовами:

• простіше зрозуміти код інших
• простіше рихлити цілою мовою (C ++ відомий тим, що важко зрозуміти)
• фокус на алгоритмі, а не на синтаксисі

Я думаю, що дзен Python заявить , чому Python - це проста мова набагато краще, ніж я можу:

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

Редагувати у відповідь на @Giorgio

Як зазначено у вашому запитанні,

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

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

Python також не змушує вас дотримуватися певної методики при написанні програм. Я можу вибрати дотримуватися строгого об'єктно-орієнтованого стилю програмування, або можу написати простий сценарій для виконання послідовно. Не потрібно ініціалізувати клас, тоді main()дуже добре називати метод, як ви змушені робити в Java. (Крім того, друк до stdout у Python є чудовим, але це досить нульовий момент).

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

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

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

Розглянемо, наприклад, безлад правил, що стосуються підписаних та непідписаних типів у C. Складність цих правил випливає з того, що деякий код використовує непідписані цілі типи для представлення чисел, а інший код використовує їх для представлення членів обгорткового алгебраїчного кільця (конкретно, набір цілих чисел, що збігаються mod 2ⁿ). Правила перетворення типів поводяться способами, які іноді підходять одному використанню, а іноді способами, відповідними іншому. Наявність окремих типів загортання та неповернення може подвоїти кількість цілих типів, але може спростити правила, пов’язані з ними:

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

• Операції, відмінні від реляційних операторів, що включають ціле число без кільця і ​​кільце, неявно перетворять ціле число в тип кільця.

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

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

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

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

Можливо, Tcl був розроблений за цими напрямками. Всю мову можна описати лише в 12 правилах на одній чоловічій сторінці . Це надзвичайно просто і послідовно.

Творець Tcl стверджував, що в якості початкових цілей:

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

З " Історії Tcl " - http://www.tcl.tk/about/history.html

Якщо мова зафіксована в її дизайні через KISS, вона не може рости. Мова, яка не може вирости, помре.

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

Основний коментар Гая Стіла на конференції ACM OOPSLA 1998 року на тему "Вирощування мови" обговорює важливість та проблеми, пов'язані з розробкою мови програмування, яку можуть вирощувати її користувачі.

Це відео довгою години, але його варто переглянути. Якщо ви не знаєте, хто такий Гай Стіл, ви насправді повинні говорити про мовний дизайн.

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

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

EDIT

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

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

Ось велика цитата з Hardcore Visual Basic Брюса Маккінні , яка, в свою чергу, вкладає слова в рот дизайнерів BASIC, Kemeny та Kurtz . Підкреслює мою.

Кожна комп'ютерна мова має своє відчуття, власну атмосферу, власний дух. Ви справді не можете визначити цей дух, але ви знаєте, що це таке, коли його бачите. Я вважаю, що Базик є антитезою твердження, приписуваного Альберту Ейнштейну:

Зробіть речі максимально простими, але не простішими.

Якби цю цитату написали оригінальні дизайнери Basic, Джон Кемені та Томас Курц, вона була б спрощена далі:

Зробіть речі простішими, ніж можливо.

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

Але чи можна застосувати принцип KISS також у дизайні мови програмування? Чи знаєте ви про будь-які мови програмування, розроблені спеціально з цим принципом, тобто "дозволити середньому програмісту в середніх умовах праці писати та підтримувати якомога більше коду з найменшими пізнавальними зусиллями"?

Добре, що ви пояснили, що ви маєте на увазі під «простим», адже на мою думку, проста мова програмування - це така, яка має мінімальний синтаксис і мало функцій (Scheme, Forth, ML), що не перекладається безпосередньо на ваше визначення. Я думаю, ви дійсно шукаєте дизайн мов, маючи на увазі RAD (швидкий розвиток додатків), і їх досить багато. Перегляньте цей потік StackOverflow, наприклад: /programming/66227/what-is-the-best-multi-platform-rad-language

Я здивований, що ще ніхто не згадував C, хоча він ставить простоту спочатку кількома важливими способами, часто так радикально, що програмісти не оцінюють простоту:

• Прихованої магії немає. Якщо ви пишете a + bна C, ви маєте гарантію, що вона складе максимум до однієї інструкції асемблера.

  Навіть у відносно простих мовах, таких як Java, простий оператор, як-от Java, a + bможе зайняти кілька мікросекунд (якщо змінні - це рядки). Інші мови додають до цього багато, набагато більше, завдяки надзвичайному прикладу C ++, де a + bможе бути перевантажено, щоб з’явитися рожеві слони. Не так у C: Якщо це не виклик функції, це займе не більше декількох наносекунд. Ця передбачуваність продуктивності є однією з ключових особливостей C, і це, безумовно, форма простоти.

• Типи даних настільки ж прості, наскільки вони можуть бути, але все ще описують всі цікаві структури даних, які ви можете створити в пам'яті: Є лише основні типи, з якими CPU може обробляти + агрегацію ( struct) + повторення (масиви) + посилання (покажчики) ).

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

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

  Візьмемо для прикладу масиви змінної довжини в C і C ++: C дозволяє тривалість виконання всюди, тоді як найліберальніші запити на розширення стандарту C ++ дозволяють їм лише у певних контекстах, таких як автоматичні масиви, і навіть там, лише в першому вимірі. Це дозволяє C обробляти справжні багатовимірні масиви з розмірами, відомими лише під час виконання, тоді як програмісти C ++ зводяться до запису data[k + (j + i*lineLength)*lineCount]знову і знову.

  Іншим прикладом цього є покажчик: Вказівник даних на C це насправді не більше, ніж просто змінна, що містить адресу пам'яті якоїсь іншої змінної. Оскільки вказівник сам по собі є змінною, то подвійний покажчик - це чітко визначена річ. Тобто з огляду на те, що intі що int*є, зрозуміло, що int**має бути. Порівняйте це з посиланнями на C ++, де у вас немає абсолютно ніякого поняття, чому int&&надається значення intта int&!)

Це правда, що саме ця простота заробила С стільки ненависті: простота мови дозволяє програмістам більше свободи, ніж користі для них, що призводить до безлічі проблем із невизначеною поведінкою та неправильним керуванням покажчиками. Особливо простота ортогональності, яка дозволяє програмісту визначити змінну як int (*array[m])(struct foo* (*arg)[n])таку, яка має тенденцію створювати читачі головні болі, оскільки справді складні речі можуть бути виражені в дуже стислій формі шляхом ліберального поєднання декількох простих функцій . Це тип простоти, при якому C перевершує, і які надають йому репутацію важкої мови.

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

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

Спільний JVM був розроблений як спосіб спростити розробку крос-платформ, і "Пишіть один раз запустити куди завгодно" стала мантрою Java на кілька років - знову ж таки, наміри були простою для розгортання рамкою.

Я вважаю, що C # потрапляє до тієї категорії спрощення мови.

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

1. "Читабельність" коду - наскільки добре мова інкапсулює об'єкти, методи тощо.
2. Узгодженість мовних API та інтерфейсів.

Існує кілька мов, які роблять ці справи добре - але те, що спливає мені в голову, це мова, яка не робить все добре "як мова програмування": PHP.

[Відмова від відповідальності - Я написав, що PHP і PHP все ще є моїм "переходом до мови" для простих веб-проектів. Це критика любові ...]

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

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

1) Різні розширення з відкритим кодом на PHP. Об'єктна модель PHP досить вільна, де дизайн інтерфейсу також не дуже відповідає бібліотеці в бібліотеці, розробнику та розробнику. Якщо ви зіткнулися з набором коду, де хтось використовував бібліотеку, про яку ви ніколи не чули, ви витрачаєте багато часу, щоб зрозуміти, "що це за чорт", тому що мова дозволяє вільно створювати API / бібліотеку.

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

На мою думку, простота - це послідовність.

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

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

Для програмування існують 2 досить відомих абстрактних моделі:

• Один - це машина для твердіння, яка визначає машину і просту навчальну модель, яка здатна обчислити все, що може зробити комп'ютер.
• Інший - це Lambda-Calculus від Church et. ін. що еквівалентно за потужністю

Забавна річ: Хоча машина turing за своєю компонуванням досить проста, це не проста система управління, і я не думаю, що вона є кваліфікованою для "розумного KISS". Але Lambda Calculus має більше спільного з мовами програмування, які ми знаємо, - і з піонерськими особливостями Lisp і Scheme в основі обчислення лямбда вона пробилася на безліч мов.

Lisp і схема дійсно прості, принаймні синтаксичні. Синтаксис є основною проблемою з мовами програмування (тому, ймовірно, вони постійно переосмислюються). У випадку з C ++ людський мозок майже не піддається прогнозуванню, як інтерпретується компілятор деякі вихідні лінії.)

Липси взагалі зменшують синтаксичну складність, вводячи одну загальну форму для команд:

(command param1 param2 ...)

Це може бути виклик методу, наприклад

(max 1 2 3 4)

а також гілка if, петля тощо.

(if (< 1 2) 
    (write 4)
    (write 5))

(весь код тут псевдо-Lisp / Dialect агностик)

Форма

(command param1 param2 ...)

можна також інтерпретувати як список

(item1 item2 item3)

І це основа для простоти і краси Ліпса. Оскільки вкладені списки (як у ifприкладі заяви) складають дерева, і їх можна легко зрозуміти як машиною, так і людиною перед машиною.

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

Я думаю, що Лісп має KISS для програмування. Те, що ви можете маніпулювати синтаксисом за допомогою макросів, призвело до явища, що Лісп розвивався досить динамічно. Потрібна нова функція мови на зразок - скажімо, орієнтація на об'єкт - просто напишіть систему OOP з макросами!

У той час як C було розширено в 2 рази з функціями OOP (C ++, Obj. C) Lisp було збільшено кілька разів, врешті-решт, був переможець.

Це ще одна химерність щодо Ліспа, вона розвивається (див. Clojure та Clojurescript для нових цікавих мутацій lisp).

Завдяки своїм властивостям KISS деякі з них віддають перевагу як викладання мов. Як Фогус окреслює його план навчальної мови ( http://blog.fogus.me/2013/01/21/enfield-a-programming-language-designed-for-pedagogy/ )

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