Принцип KISS применяется к дизайну языка программирования?

KISS («оставайся простым, глупым» или «делай это простым глупым», см., Например, здесь ) является важным принципом в разработке программного обеспечения, даже если он явно возник в инженерном деле. Ссылаясь на статью в Википедии:

Этот принцип лучше всего иллюстрируется историей о том, как Джонсон вручил команде инженеров-конструкторов несколько инструментов, при этом задача, которую создавал реактивный самолет, должен был быть отремонтирован средним механиком в поле в боевых условиях только с этими инструментами. Следовательно, «глупый» относится к связи между тем, как вещи ломаются, и изощренностью, доступной для их исправления.

Если бы я хотел применить это в области разработки программного обеспечения, я бы заменил «реактивный самолет» на «часть программного обеспечения», «средний механик» на «средний разработчик» и «в боевых условиях» на «при ожидаемой разработке / обслуживании программного обеспечения». условия »(сроки, временные ограничения, встречи / перерывы, доступные инструменты и т. д.).

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

Но может ли принцип KISS быть применен и к дизайну языка программирования? Знаете ли вы о каких-либо языках программирования, которые были разработаны специально с учетом этого принципа, то есть, чтобы «позволить среднестатистическому программисту при средних условиях работы писать и поддерживать как можно больше кода с наименьшими когнитивными усилиями»?

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

Когда я думаю о минимализме, я думаю о Lisp и 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 ++ печально известен тем, что его трудно понять)
• сосредоточиться на алгоритме, а не на синтаксисе

Я думаю, что Zen of 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, очень хорошо. (Кроме того, печать на стандартный вывод в Python - это замечательно, но это довольно ноль).

Наконец, методология «Батареи в комплекте», включающая обширную стандартную библиотеку с языком, замечательна. Вместо того, чтобы искать какой-то внешний репозиторий для пакетов, большая часть того, что мне нужно, уже включена в язык. Также хорошо иметь это внешнее репо, но не нужно копаться в нем, чтобы выполнить основную операцию, это действительно удобно.

Основным ключом к поддержанию «простоты» является признание того, когда сложность будет необходима, и наличие частей системы, которые могут наилучшим образом с ней справиться. Наличие единственного вида ссылки на объект, который не делает различий между неизменяемыми значениями, изменяемыми значениями и сущностями, делает Java «простой», не устраняет необходимость различать значения и сущности; это просто лишает программистов инструментов, помогающих им в этом.

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

Рассмотрим, например, путаницу правил, окружающих подписанные и неподписанные типы в C. Сложность этих правил проистекает из того факта, что некоторые коды используют целочисленные типы без знака для представления чисел, в то время как другой код использует их для представления членов оберточного алгебраического кольца. (в частности, набор целых конгруэнтных мод 2ⁿ). Правила преобразования типов ведут себя так, что иногда они подходят для одного использования, а иногда - для другого. Наличие отдельных типов переноса и неупаковывания удвоит число целочисленных типов, но может упростить связанные с ними правила:

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

• Операции, отличные от реляционных операторов, включающие целое без кольца и кольцо, будут неявно преобразовывать целое число в тип кольца.

• Кольца могут быть явно приведены к числам или к большим кольцам; значение беззнакового кольца - это наименьшее неотрицательное целое число, которое при добавлении к нулю кольца даст значение кольца. Значение кольца со знаком - это целое число наименьшей величины, которое при добавлении к нулю кольца даст значение кольца, причем отрицательное значение будет предпочтительным в случае связи.

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

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

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

Возможно, Tcl был разработан в этом направлении. Весь язык может быть описан только в 12 правилах на одной странице руководства . Это удивительно просто и последовательно.

Создатель Tcl утверждал следующие исходные цели:

• Язык должен быть расширяемым: для каждого приложения должно быть очень легко добавлять свои собственные функции к базовым функциям языка, а специфические для приложения функции должны казаться естественными, как если бы они были встроены в язык с самого начала.
• Язык должен быть очень простым и универсальным, чтобы он мог легко работать со многими различными приложениями и чтобы он не ограничивал возможности, которые могут предоставлять приложения.
• Поскольку большая часть интересной функциональности будет исходить из приложения, основная цель языка - интегрировать или «склеивать» расширения. Таким образом, язык должен иметь хорошие возможности для интеграции.

Из " Истории Tcl " - http://www.tcl.tk/about/history.html

Если язык зафиксирован в его дизайне из-за KISS, он не может расти. Язык, который не может расти, умрет.

В следующем видео Гай Стил умело объясняет, что язык программирования должен развиваться и почему. Если вы применяете KISS, то как может расти язык, потому что после выпуска его набор инструментов исправлен и никогда не может изменяться.

Основной доклад Гая Стила на конференции ACM OOPSLA 1998 года «Выращивание языка» обсуждает важность и проблемы, связанные с разработкой языка программирования, который может быть выращен его пользователями.

Это часовое видео, но стоит посмотреть. Если вы не знаете, кто такой Гай Стил, вы действительно должны говорить о языковом дизайне.

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

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

РЕДАКТИРОВАТЬ

Когда я писал приведенный выше ответ, он основывался на рассуждениях: если движок можно поддерживать только с помощью фиксированного набора инструментов, то моя переформулировка этого значения в отношении языкового дизайна заключается в том, что язык не может измениться после освобождения. Комментарии указывают, что это не то, что имелось в виду. Итак, позвольте мне предложить этот измененный ответ, который будет более соответствовать пересмотренному пониманию.

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

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

У каждого компьютерного языка есть свое чувство, своя атмосфера, свой дух. Вы не можете действительно определить этот дух, но вы знаете, что это такое, когда видите его. Я думаю о Basic как о противоположности утверждению Альберта Эйнштейна:

Сделайте вещи максимально простыми, но не проще.

Если бы эта цитата была написана оригинальными дизайнерами Basic, Джоном Кемени и Томасом Курцем, она была бы еще более упрощена:

Сделать вещи проще, чем возможно.

В этом и заключается противоречие хардкорных программистов Visual Basic. Мы хотим, чтобы все было просто, элегантно и интуитивно понятно, но это не так. Мы хотим, чтобы наши программы моделировали реальность, но они этого не делают. Мы хотим, чтобы наш язык работал так, как мы думаем, а не так, как компьютеры или операционные системы хотят, чтобы мы думали, - но мы не готовы платить цену .

Но может ли принцип KISS быть применен и к дизайну языка программирования? Знаете ли вы о каких-либо языках программирования, которые были разработаны специально с учетом этого принципа, то есть, чтобы «позволить среднестатистическому программисту при средних условиях работы писать и поддерживать как можно больше кода с наименьшими когнитивными усилиями»?

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

Я удивлен, что никто еще не упомянул C, хотя он ставит простоту на первое место по нескольким важным причинам, часто настолько радикально, что программисты не могут оценить простоту:

• Там нет скрытой магии. Если вы пишете a + bна C, у вас есть гарантия, что он будет скомпилирован не более чем с одной инструкцией ассемблера.

  Даже в относительно простых языках, таких как Java, простое утверждение типа a + bможет занять несколько микросекунд (если переменные являются строками). Другие языки добавляют много, намного больше к этому с крайним примером C ++, где a + bмогут быть перегружены, чтобы появились розовые слоны. В C это не так: если это не вызов функции, это займет не более нескольких наносекунд. Эта предсказуемость производительности является одной из ключевых особенностей C, и, безусловно, является формой простоты.

• Типы данных настолько просты, насколько это возможно, и в то же время описывают все интересные структуры данных, которые вы, возможно, захотите встроить в память: есть только основные типы, которые ЦПУ может обрабатывать + агрегация ( struct) + повторение (массивы) + ссылки (указатели) ).

  Это правда, что различные языки на основе lisp намного проще, чем 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 Википедия - хотя это явно не указано в Википедии, упрощение упоминалось несколько раз и было первоначальной целью разработки, поскольку единственным серьезным языком, способным к ОО (термин использовался слабо) в те дни, был C ++, который, как мы все знаем, является мощным но есть несколько ловушек для неосторожных.

JVM была задумана как способ упростить кроссплатформенную разработку, и «Писать один раз в любом месте» стала мантрой Java на несколько лет - опять же, цель заключалась в простоте развертывания инфраструктуры.

Я считаю, что C # попадает в эту категорию упрощения языка.

Хм ... на самом деле это сложный вопрос, на который нужно ответить "положительно", потому что, когда я думаю о простоте проектирования языка программирования (и о том, с чем "легче" работать), я сразу думаю о:

1. «Читаемость» кода - насколько хорошо язык инкапсулирует объекты, методы и т. Д.
2. Согласованность языковых API и интерфейсов.

Есть ряд языков, которые хорошо справляются с этой задачей, но мне в голову приходит язык, который плохо работает как «язык программирования»: PHP.

[Отказ от ответственности - я написал PHP, и PHP все еще мой «переход на язык» для простых веб-проектов. Это критика любви ...]

Во-первых, PHP хорошо работает в среде, в которой он обычно работает - веб-серверах. Это легко установить, легко поддерживать и т. Д.

Где я борюсь с PHP: когда вы хотите сделать что-то «необычное» - то, что вы обычно не делаете на регулярной основе (в случае, если я думаю, что это потребляет веб-сервис SOAP - не то, что я с PHP), вы столкнулись с двумя вариантами:

1) Различные расширения с открытым исходным кодом для PHP. Объектная модель PHP достаточно свободна, когда дизайн интерфейса также не очень согласован от библиотеки к библиотеке, от разработчика к разработчику. Когда вы сталкиваетесь с набором кода, в котором кто-то использовал библиотеку, о которой вы никогда не слышали, вы тратите много времени на выяснение «какого черта это происходит», потому что язык позволяет свободно создавать API / библиотеки.

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

На мой взгляд, простота - это последовательность.

Теперь подход KISS к языкам программирования - забавное понятие, по крайней мере, если вы рассматриваете языки программирования как уровень абстракции для набора команд ЦП и т. Д. Если вы не определяете «KISS» более близко. Я просто говорю здесь, что повозка - это ПОЦЕЛУЙ, примененный к автомобилю в его полном объеме.

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

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

• Одним из них является машина Тьюринга, которая определяет машину и простую учебную модель, способную вычислить все, что может сделать компьютер.
• Другой - лямбда-исчисление Черча и др. и др. что эквивалентно по силе

Интересная вещь: хотя машина Тьюринга довольно проста в своей компоновке, она не является системой, с которой легко обращаться, и я не думаю, что она подходит под «умный KISS». Но лямбда-исчисление больше связано с известными нам языками программирования - и с новаторскими функциями Лиспа и Схемы лямбда-исчисления оно вошло во многие языки.

Lisp и Scheme ДЕЙСТВИТЕЛЬНО просты, по крайней мере, с точки зрения синтаксиса. Синтаксис - основная проблема языков программирования (возможно, поэтому они постоянно обновляются). В случае C ++ для человеческого мозга почти невозможно предсказать, как некоторые строки исходного текста интерпретируются компилятором.)

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

(command param1 param2 ...)

Это может быть вызов метода, такой как

(max 1 2 3 4)

а также ветвь if, цикл и т. д.

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

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

Форма

(command param1 param2 ...)

также можно интерпретировать как список

(item1 item2 item3)

И это основа простоты и красоты Lisps. Поскольку вложенные списки (как в ifпримере оператора) составляют деревья, и их легко понять как машине, так и человеку перед машиной.

Еще одна особенность Lisps - макросы. Я не буду вдаваться в подробности, но поскольку синтаксических различий между обычными вызовами функций и синтаксисом нет («Синтаксис» (яйцо для циклов, объявление переменной и т. Д., Все, что анализатор должен обрабатывать в других случаях). языки программирования) вы можете создать свой собственный синтаксис. Макросы по сути являются манипуляциями с деревом, которое составляет вашу программу.

Я думаю, что Лисп имеет поцелуй в программировании. То, что вы можете манипулировать синтаксисом с помощью макросов, привело к тому, что Lisp развивался довольно динамично. Нужна новая языковая функция, например - скажем, ориентация объекта - просто напишите систему ООП с макросами!

В то время как C был расширен круговым движением в 2 раза с функциями ООП (C ++, Obj. C), Lisp был расширен несколько раз, в конце концов, был победитель.

Это еще одна причуда о Лиспе, он развивается (см. Clojure и Clojurescript для интересной новой мутации lisp).

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

Для начала, я твердо убежден, что при изучении новых, а порой и сложных тем, совершенно вредно перегружать студентов легкомысленными синтаксическими правилами. Следовательно, Enfield разработан с минимальными синтаксическими правилами и тем, что является более минимальным, чем синтаксис, похожий на Лисп.