Если Вы Изобретете Язык Программирования Xxi Века

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

Вводить текст с клавиатуры больше не составляет труда.

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

Вещи как (($:@(<#[), (=#[), $:@(> #[)) ({~ ?@#)) ^: (1<#) - очень короткий и емкий формат записи (это, кстати, настоящий кусок кода в настоящий язык ), но это никак не улучшает читабельность.

И, что еще более важно, его трудно найти в Google или в stackoverflow. То же самое можно сказать о загадочных именах функций, соглашениях о кодах возврата и атрибутах с неясным значением.

В прошлом они хорошо служили, экономя много места на перфокартах, но сегодня им пора уйти на покой.

Что-то вроде

FILE * test_file = fopen("/tmp/test.txt", "w+");

должен быть преобразован в

create file /tmp/test.txt for input and output as test_file

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

Подсветка синтаксиса вполне способна полностью заменить синтаксические обозначения.

Некоторые вещи доступны в 21 веке в изобилии: например, скорость синтаксического анализа, память компьютера, онлайн-поиск.

Остальные ресурсы по-прежнему в цене: время разработки, память программиста, усилия, затрачиваемые на изучение особенностей языка.

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

Например, вот так:

> 10.8 / 100 0.10800000000000001

Этот результат не уникален для JavaScript. И это вовсе не парадокс, а пример абсолютно правильного следования уважаемому стандарту IEEE 754. Подобная реализация чисел с плавающей запятой встречается практически во всех архитектурах.

И это не так уж и плохо, учитывая, что мы пытаемся втиснуть бесконечное количество действительных чисел в 32, 64 или 256 бит. То, что математики считают невозможным, инженеры реализуют, отказываясь от здравого смысла ради практической реализации.

Числа с плавающей запятой IEEE вообще не являются числами.

Математика требует ассоциативности от операции их сложения.

Типы float и double не всегда сохраняют это свойство.

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

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

Не только числа с плавающей запятой имеют подобные особенности.

Встроенные целые числа реализованы не лучше.

Знаете ли вы, что произойдет, если вы попытаетесь сложить два таких 16-битных числа?

0xFFFF + 0x0001

Точного ответа никто не даст. Я инстинктивно подскажу, что переполнение выдаст 0x0000. Однако такой результат не зафиксирован ни в одном мировом стандарте.

При обработке этой операции все руководствуются подходом C и семейством процессоров x86. Альтернативы могут привести к 0xFFFF, вызову прерывания или сохранению какого-либо специального бита переполнения в специальном месте.

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

Если странности с плавающей запятой хотя бы зафиксированы стандартом, то последний поднятый вопрос в принципе непредсказуем.

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

Что-то вроде этого:

1.000 / 3.000 = 0.333 0001 + 9999 = overflowed 9999 0.001 / 2 = underflowed 0

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

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

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

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

Насколько я могу судить, типичный программист XXI века нечасто решает дифференциальные уравнения.

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

Racket, Rebol и Forth — лишь несколько примеров.

Мне они все нравятся, играть с ними одно удовольствие.

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

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

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

И вот здесь начинаются проблемы.

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

Для посторонних идея овладения языком — это инвестиция, которая вряд ли окупится.

Но изучение чего-то стандартизированного — это инвестиция на всю жизнь.

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

Люди спорят об эстетике, идеологии, архитектуре и других неважных вещах.

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

Ребята из Лиспа прошли через это в 80-х.

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

Так родился Common Lisp. И оно оказалось огромным.

INCITS 226-1994 имеет объем 1153 страницы.

Этот рекорд 17 лет спустя был побит только C++ с ISO/IEC 14882:2011 (1338 страниц).

C++ приходится нести с собой огромный багаж наследия, хотя он не всегда был таким большим.

Common Lisp был создан практически с нуля.

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

Это не обязательно.

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

Конечно, сохранить баланс между размером и применимостью непросто.

Опыт C++ на практике показал, насколько это сложно.

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

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

Как здорово, что такой язык уже существует! Как вы думаете, о чем мы говорим? Да, это КОБОЛ.

Это один из первых языков высокого уровня, сегодня практически забытый.

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

И я сделал это, чтобы показать одну вещь.

Код не написан с учетом особенностей языка.

Ты делаешь это.

Наивно думать, что за качество кода отвечает язык, и что добавление некоторых наворотов (или их удаление) может автоматически все улучшить.

Программистам когда-то не нравились Fortran и COBOL, поэтому они изобрели C++ и Java, но через 20–30 лет оказались в ситуации, когда они тоже всем перестали нравиться.

По моим ощущениям, корень проблемы лежит где-то в области социологии и психологии, а не программирования.

Неужели мы так сильно не любим языки? И довольны ли мы средой, в которой работаем? Windows уязвима, Visual Studio работает слишком медленно, из Vim невозможно выйти.

На самом деле именно эти вещи вызывают недовольство, а не сам творческий процесс.

Но всегда нужно найти виноватого.

Как инженеры-программисты, которые частично несут ответственность за то, насколько дрянным может быть программное обеспечение, мы не будем винить себя, не так ли? Поэтому ищем недостатки в инструментах.

Давайте изобретать новые COBOLы, пока однажды солнце не засияет ярче, птицы не запоют громче, а Windows не начнет загружаться за 2 секунды.

Но, скорее всего, этот день никогда не наступит. Поэтому, если бы я хотел изобрести язык программирования XXI века, я бы вместо этого попытался найти новый подход к ответственности.

Или новый способ лучше освоить существующие инструменты.

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

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