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

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

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

  a := b + c;
        В выше приведённом примере сначала вычисляется правая часть выражения «b + c», а затем результат присваивается «a». Т.е. пределах этого выражения вычислительный процесс двигался справа налево! Из-за распространённости этой операции мы фактически перешли к арабскому и еврейскому порядку письменности «справа налево». Это стало настолько привычным, что об этом мало кто задумывается. Тем не менее, история языков программирования сохранила попытки вернуть вычисления в традиционное русло «слева направо». При разработке ALGOL 58 предлагалось записывать
  выражение => величина
        Но затем решили использовать
  выражение =: величина
        И по настоянию американских участников разработки пришли к
  величина := выражение
        В первоначальных версиях языка Рапира слева записывалось вычисляемое выражение, а справа — имя переменной:
  b + c -> a;
        Логично, не правда ли? На такой способ записи следовало бы обратить пристальное внимание. Чёткое и последовательное следование принципу «слева направо, сверху вниз» могло бы некоторых моментах сделать запись лаконичнее и логичнее. А языке Пифагор — демократия. Программист может записывать выражения как справа налево, так и слева направо:
результат >> return
return << результат
        В некоторых языках, стоящих в стороне от «мейнстрима», вычисления тоже идут «слева направо, сверху вниз». Вот пример на языке Forth:
  50 80 24 * +
     Пояснение для тех, кому Forth не знаком:
     положить в стек число 50,
     положить в стек число 80,
     положить в стек число 24,
     перемножить два числа на вершине стека,
     сложить два числа на вершине стека.
     Выражение равносильно 50 + 80 * 24
        Есть в языках программирования и такие операторы, которые нарушают порядок «сверху вниз». Вот типичный для C-подобный языков универсальный оператор цикла:
  for (i=0; i < N; i++)
   { /* тело цикла */ }
        Оператор «i++» является «выскочкой»: он записан впереди тела цикла, но выполняется как раз таки в конце. Наиболее естественным был бы такой способ записи цикла:
{<инициализирующие выражения> ( LOOP <условие>
   <тело цикла>
  <выражения приращения счётчика>
)}
        Пояснения: скобки «{» и «}» выделяют выражения цикла и «прячут» объявленные переменные внутри области видимости цикла. Собственно цикл начинается скобкой «(» и ключевым словом LOOP (возьмём его из языка Ада) и заканчивается закрывающей скобкой «)». К такой записи сохраняется порядок «сверху вниз». Минусом можно назвать то, что выражения приращения счётчика записаны после тела цикла. Желательно, чтобы заголовок цикла был описан в одном месте, а не разбросан по всему циклу. Подробнее циклы рассмотрим потом. Здесь же продолжим о ходе вычислений.

        Изменения естественного порядка вычислений, присущие выражениям цикла, запоминаются быстро и в дальнейшем вопросов не вызывают. Но есть ещё одна проблема, которая касается не собственно языка, а функций и процедур. В каком порядке должны располагаться аргументы функций и процедур? Где должен находиться «источник», а где «приёмник»? Языки не накладывают ограничений на аргументы функций. К чему это приводит? Возьмём функции из языка C:
  strcpy ( строка_куда, строка_откуда);         // <-- справа налево
  ltoa ( число_откуда, строка_куда);            // --> слева направо
  fputc( символ_откуда, файл_куда);             // --> слева направо
  fgets( строка_куда, сколько, файл_откуда);    // <-- справа налево
        Полная анархия! Всё смешалось в доме Облонских. Да если б только Облонских! Вот пример из Паскаля, который хвалят за «строгость» и «математичность». Вот так функция описывается:
function func(n: integer): integer;       <-- результат справа 
А вот так применяется:
        result := func(1);                <-- результат слева 
        Единый стиль, стандартизация были бы полезны. Предпочтительнее, если программист опирается на логику, а не надеется на память. Иначе многие вещи (например, порядок следования аргументов функции) приходится просто запоминать.

Опубликовано: 2012.09.25, последняя правка: 2022.04.30    13:35

ОценитеОценки посетителей
   ████████████████████████████ 6 (66.6%)
   ██████████ 2 (22.2%)
   █████ 1 (11.1%)
   ▌ 0

Отзывы

     2013/11/16 12:55, Noname          # 

Варианты присвоения и извлечения глобальной переменной в Форт
\ после слеш комментарий 
variable abc  \ переменная abc адрес ячейки памяти
123 abc !     \ запишем в ячейку abc значение 123
abc @ .       \  извлечём значение из ячейки и отобразим
0 value zxc  \ определим переменную zxc с помощью слова value и значением 0 
123 to zxc    \ присвоим zxc значение 123
zxc .         \ отобразим значение переменной zxc

     2016/04/17 12:58, rst256          # 

a := b + c;
А как же тип? Тип результата желательно сразу узнать. Да и вся математика пользуется такой записью.

А последнее именно потому, что я читаю слева направо, оно должно записываться справа налево. Программисту гораздо чаще нужно лазить по коду и не вычислять его, поэтому мне в данном случае плевать на такие тонкости. Человек читает в обратную сторону, он получатель, так сказать, в данном случае. Простой пример
"....
....
....
Заголовок: Некая статья"
Меня вы понимаете? А вы меня понимаете?

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

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

Авторизация

Регистрация

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

Карта сайта


Содержание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

●  Циклы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Компилятор

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

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

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

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




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

2024/06/21 00:20 ••• Gudleifr
О превращении кибернетики в шаманство

2024/06/19 00:16 ••• Gudleifr
Программирование исчезнет. Будет дрессировка нейронных сетей

2024/06/12 11:27 ••• Автор сайта
Все языки эквивалентны. Но некоторые из них эквивалентнее других

2024/05/31 12:31 ••• Прохожий
Идеальный транслятор

2024/05/28 15:16 ••• Прохожий
Русской операционной системой должна стать ReactOS

2024/05/25 17:18 ••• Прохожий
Избранные компьютерные анекдоты

2024/05/11 16:33 ••• Автор сайта
Энтузиасты-разработчики компиляторов и их проекты

2024/04/28 15:58 ••• Автор сайта
Обработка ошибок

2024/04/23 00:00 ••• alextretyak
Признаки устаревшего языка

2024/04/21 00:00 ••• alextretyak
Постфиксные инкремент и декремент

2024/04/20 21:28 ••• Бурановский дедушка
Русский язык и программирование

2024/04/01 23:39 ••• Бурановский дедушка
Новости и прочее

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