Каким должен быть язык программирования? Анализ и критика Описание языка Компилятор
Отечественные разработки Cтатьи на компьютерные темы Компьютерный юмор Новости и прочее

Должна ли программа быть удобочитаемой?

Должна ли программа быть удобочитаемой?
Нужно ли её разбивать на строки? Давайте посмотрим программу, написанную на языке J, который автор называет «помехами в телеграфной линии».

s =: ({. , }. /: 12"_ o. }. - {.) @ /:~
l =: 11"_ o. [: (* +)/ }. - {.
rr =: (1"_ , (0"_ > 3: l\ ]) , 1"_) # ]
hull =: [: rr^:_ s


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

              Роберт У. Себеста, «Основные концепции языков программирования», страница 46:

Даниель Мак-Кракен (Daniel McCracken) однажды отметил, что чтение и анализ программы из четырёх строк, написанных на языке APL, заняли у него четыре часа.

            Хорошо читаемая программа должна иметь, как минимум, хороший синтаксис. Далее мы как раз этим и займёмся.

Что ещё почитать на эту тему

Опубликовано: 2012.09.25, последняя правка: 2015.01.23    03:04

ОценитеОценки посетителей
   ███████████████████████████████████ 5 (83.3%)
   ▌ 0
   ███████ 1 (16.6%)
   ▌ 0

Отзывы

     2017/09/19 15:16, rsashka          # 

Компактная и понятная программы, это не одно и тоже.

     2021/08/26 10:44, Gudleifr          # 

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

Алгоритм Грэхема (приведенный выше код) по Википедии выглядит так:
1) Пусть p0 — точка из множества Q с минимальной координатой y или самая левая из таких точек при наличии совпадений.
2) Пусть <p1,p2,... ,pm> — остальные точки множества Q, отсортированные в порядке возрастания полярного угла, измеряемого против часовой стрелки относительно точки p0 (если полярные углы нескольких точек совпадают, то по расстоянию до точки p0).
3) Push(p0,S). (где S — стек).
4) Push(p1,S).
5) for i = 2 to m do пп.6-8.
6) while угол, образованный точками NextToTop(S), Top(S) и pi, образуют не левый поворот (при движении по ломаной, образованной этими точками, мы движемся прямо или вправо. Условие левого поворота считается из векторных произведений)...
7) do Pop(S).
8) Push(pi,S).
9) return S.

Можно этакую программу сделать понятной в принципе?
1) Можно откомментировать. Мы видим, что даже запись алгоритма на человеческом языке требует комментариев. Но это, минимум, двойная работа.
2) Можно изобрести универсальный язык, вводящий математические (в данном случае) операции через универсальные конструкции? Чтобы по виду формулы всем было видно, что это "левый поворот"?
3) Можно просто взять специальный математический язык. Вы знаете язык, совмещающий обозначения геометрии и множеств?
4) Можно создать нужный язык "на лету". В случаях неповоротливых ЯВУ — просто придумав подходящие имена для переменных и функций. Для более совершенных — близкий к человеческому.

4-й способ настолько прост, что пп.2 и 3 дольше осмысливать, чем им воспользоваться. Причем он работает на всех языках.

     2021/08/29 23:57, Автор сайта          # 

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

Человеческий язык описания тоже не всегда вносит ясность волшебным образом. Если Григорий Перельман опишет своё доказательство теоремы Пуанкаре, то поймут его единицы из миллиардов.

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

     2021/08/30 00:49, Gudleifr          # 

Внесение в язык новых слов не является созданием нового языка «на лету», это лишь расширение старого.

С точки зрения филологии — да. С точки зрения программирования очень часто этого бывает достаточно. Просто Вы, пардон, распространяете "программировании путем масштабирования" на все программирование.

     2021/08/31 21:59, Автор сайта          # 

Теория формальных языков не видит разницы между языками естественными (которые рассматривает филология) и искусственными (в том числе языками программирования). Есть методика измерения «расстояния» между языками. Между русским и польским, к примеру. Она работает и для языков программирования.

Добавить свой отзыв

Написать автору можно на электронную почту
mail(аt)compiler.su

Авторизация

Регистрация

Выслать пароль

Карта сайта


Содержание

Каким должен быть язык программирования?

Анализ и критика

●  Устарел ли текст как форма представления программы

●  Русский язык и программирование

●  Многоязыковое программирование

Синтаксис языков программирования

Синтаксический сахар

●  Некоторые «вкусности» Алгол-68

●  «Двухмерный» синтаксис Python

●  Почему языки с синтаксисом Си популярнее языков с синтаксисом Паскаля?

●  Должна ли программа быть удобочитаемой?

●  Стиль языка программирования

●  Тексто-графическое представление программы

●●  Разделители

●●  Строки программы

●●  Слева направо или справа налево?

●  Комментарии

●●  Длинные комментарии

●●  Короткие комментарии

●●  Комментарии автоматической генерации документации

●●  Нерабочий код

●●  Помеченные комментарии

●  Нужны ли беззнаковые целые?

●  Шестнадцатиричные и двоичные константы

●  Условные операторы

●  Переключатель

●  Циклы

●●  Продолжение цикла и выход из него

●  Некошерный «goto»

●  Изменение приоритетов операций

●  Операции присвоения и проверки на равенство. Возможно ли одинаковое обозначение?

●  Так ли нужны операции «&&», «||» и «^^»?

●  Постфиксные инкремент и декремент

●  Почему в PHP для конкатенации строк используется «.»?

●  Указатели и ссылки в C++

●●  О неправомерном доступе к памяти через указатели

●  Обработка ошибок

●  Функциональное программирование

●●  Нечистые действия в чистых функциях

●●  О чистоте и нечистоте функций и языков

●●  Макросы — это чистые функции, исполняемые во время компиляции

●●  Хаскелл, детище британских учёных

●●  Измеряем замедление при вызове функций высших порядков

●●  C vs Haskell: сравнение скорости на простом примере

●●  Уникальность имён функций: за и против

●●  Каррирование: для чего и как

●●  О тестах, доказывающих отсутствие ошибок

●  Надёжные программы из ненадёжных компонентов

●●  О многократном резервировании функций

●  Использование памяти

●  Почему динамическое распределение памяти — это плохо

●  Как обеспечить возврат функциями объектов переменной длины?

●●  Типы переменного размера (dynamically sized types, DST) в языке Rust

●●  Массивы переменной длины в C/C++

●●  Размещение объектов в стеке, традиционный подход

●●  Размещение объектов переменной длины с использованием множества стеков

●●  Размещение объектов переменной длины с использованием двух стеков

●●  Реализация двухстековой модели размещения данных

●●  Двухстековая модель: тесты на скорость

●●  Изменение длины объекта в стеке во время исполнения

●●  Размещение объектов переменной длины с использованием одного стека

●  Можно ли забыть о «куче», если объекты переменной длины хранить в стеке

●  Безопасность и размещение объектов переменной длины в стеке

●  Массивы, структуры, типы, классы переменной длины

●  О хранении данных в стеке, вместо заключения

●  Реализация параметрического полиморфизма

Описание языка

Компилятор

Отечественные разработки

Cтатьи на компьютерные темы

Компьютерный юмор

Новости и прочее




Последние отзывы

2024/03/28 21:36 ••• Ivan
Энтузиасты-разработчики компиляторов и их проекты

2024/03/27 19:12 ••• MihalNik
Постфиксные инкремент и декремент

2024/03/22 20:41 ••• void
Раскрутка компилятора

2024/03/20 19:54 ••• kt
О многократном резервировании функций

2024/03/20 13:13 ••• Неслучайный читатель
Надёжные программы из ненадёжных компонентов

2024/03/10 18:33 ••• Бурановский дедушка
Русской операционной системой должна стать ReactOS

2024/03/07 14:16 ••• Неслучайный читатель
«Двухмерный» синтаксис Python

2024/03/03 16:49 ••• Автор сайта
О неправомерном доступе к памяти через указатели

2024/02/28 18:59 ••• Вежливый Лис
Про лебедей, раков и щук

2024/02/24 18:10 ••• Бурановский дедушка
ЕС ЭВМ — это измена, трусость и обман?

2024/02/22 15:57 ••• Автор сайта
Русский язык и программирование

2024/02/19 17:58 ••• Сорок Сороков
О русском языке в программировании

2024/02/16 16:33 ••• Клихальт
Избранные компьютерные анекдоты