Почему многословие вредно для языка программирования? [закрыто]

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

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

Итак, каковы возможные недостатки подробного языка программирования?

Цель - быстрое понимание

«Подробный» означает «использует слишком много слов». Вопрос в том, что такое «слишком много».

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

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

Если язык многословен, больше вашего кода - это шум. Сравните Java "Hello World" :

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 для объема кода, который вы могли прочитать / page. Но теперь речь идет скорее о вашем собственном внутреннем кеше - если у оператора есть один оператор, мой стареющий мозг легче разобрать, чем оператор с 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, поэтому необходимо соблюдать баланс.

Я думаю, вам нужно перевернуть вопрос с ног на голову и спросить: почему некоторые люди думают, что краткий код это хорошо?

Мой ответ: две основные причины:

Причины, почему Terse может быть лучше

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

Причины, почему Terse может быть хуже

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

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

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

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

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

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

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

Так что я бы порекомендовал?

Используйте оба стиля, но обратите особое внимание на то, почему вы используете каждый стиль.

Например, все, что может взаимодействовать с внешним миром, должно быть интенсивно многословным на некотором уровне, даже если только в форме встроенных комментариев, смешанных с кодом, и также должно включать автоматические проверки на правильность использования. Загадочные и особенно не полностью определенные нотации не имеют никакого отношения к таким интерфейсам, поскольку в какой-то момент они почти гарантированно не будут поняты. Потери 1999 на Марс климат попутного из - за отказ признать , были ли выражены модули интерфейса программного обеспечения в фунтах или ньютонах являются особенно острым примером опасности полагаться слишком случайно на сырье чисел в программных или аппаратных интерфейсах.

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

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

Многие люди намекают на то, что, я думаю, должно быть сформулировано явно.

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

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

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

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

Вместо того чтобы перейти к технической книге, я вернусь к элементам стиля * Strunk and White. Основная концепция - «Будь точным» и «Не говори больше, чем нужно». Все остальное - комментарии.

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

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

В конце концов, все, что «отличается», заставит людей завывать. Я знаком с синтаксисом стиля C и, следовательно, хорошо с другими языками, которые имеют похожий синтаксис (C ++, Java, C #). Поэтому я склоняюсь в пользу этого конкретного стиля.

Языки, как правило, находят баланс между достаточно описательным, а не многословным.

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

Кобол - пример слишком многословного.

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

Я обнаружил, что это правда между мной и коллегой. Она пишет код с большим количеством комментариев, объясняющих, что такое строки кода, и большим количеством пробелов. Если я читаю его, то обнаруживаю, что из-за этого могу разместить только несколько строк кода на одном экране. Это делает понимание каждой отдельной строки намного проще, но уловить всю функцию становится намного сложнее.

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

Эйнштейн понял все правильно: «Делай вещи как можно проще, но не проще».

Это относится и к коду. Если вы можете упростить код, удалив повторяющиеся и ненужные подробные элементы, это хорошо.

Кроме того, некоторые исследования показывают, что производительность программиста, измеренная в строках кода, является более или менее постоянной величиной. Так же и количество ошибок в 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 и так далее.

Я думаю, что ясный и интуитивно понятный синтаксис очень важен. Он также должен быть достаточно многословным, чтобы облегчить чтение. Слишком короткие утверждения, содержащие слишком много логики, часто могут привести к большему количеству времени для расшифровки, чем их чуть более длинные аналоги. С другой стороны, бесполезный раздутый код, заполненный шаблонными строками для выполнения чего-то совершенно простого, - тоже неприятность.

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

Многословие это плохо, потому что:

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

Определенный уровень многословия важен для ясности, однако ...

минимальный уровень многословия хорош, потому что:

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

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

Или указатель C / C ++ и ссылочные операторы, &а не ключевое слово *BASIC byref. В C / C ++ я могу иметь переменную X и передать указатель на эту переменную, но я должен помнить, какой именно указатель, а какой «использовать указатель в качестве переменной, на которую он указывает»; в основном, я просто передаю ссылку с ключевым словом byref в вызове функции, что более понятно, но менее гибко:

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

В этом коде содержимое x изменяется из-за флага byref. Некоторые ароматы позволяют byref по вызову, другие в определении, некоторые в любом.

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

С этим тесно связана проблема ясности - краткий код часто неясен, а чрезмерно подробный код (как в AppleScript) может быть в равной степени неясным. Знакомство с данным языком повышает ясность краткого кода в этом языке - начинающий, сталкивающийся с кодом C ++, вероятно, сможет анализировать только формулы, и даже большая часть функционального кода BASIC или Python слишком лаконична для понимания, но appleScript может ломать голову, как правило, не прибегая к языковым словарям. Наименее ясно, с чем я столкнулся без преднамеренного запутывания - это Информ 7 ...

В старину

Еще одно важное соображение в прошлом, но уже не столь важное для хобби-программиста, - это пространство для работы и хранения. (Это по-прежнему жизненно важно для высокого класса.) Учитывая, что многие языки были интерпретированы, особенно BASIC, и многие другие были скомпилированы во время выполнения, пространство кода было важно, особенно когда диски содержали только 128 КБ, а отдельные перфокарты - только 80 В.

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

Компиляция и компоновка нескольких объектных файлов также использовалась, чтобы обойти ограничения пространства. Секция кода Pascal размером 100 КБ может составлять только 5 КБ; связывая несколько скомпилированных файлов, можно было создавать массивные приложения, не имея доступа к дискам большого формата (помня, что 10 МБ было удивительно большим, и покупать новый автомобиль дороже).

Более краткие языки, тем не менее, получали больше кода в заданную часть диска и оперативной памяти и, таким образом, компилировали более крупные блоки за раз. Помните: «миникомпьютеры» начала 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 ++ должен принять решение (при определенных обстоятельствах) во время выполнения о том, какие части кода выполнять.

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