Удобная для пользователя и разработчика платформа

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

Очистка разделов GNU/Linux

Написал пару простых скриптов для автоматизации очистки разделов дистрибутивов GNU/Linux, преимущественно, основанных на Debian — . Это поверхностное удаление кэша установочных пакетов и давно не обновляемых каталогов с кэшем приложений, используя по возможности безопасное удаление через корзину.

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

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

Умение сочинять и исполнять музыку — это совершенно разные навыки?

Когда это так, то и результат соответствующий.

Пустили EXIT в Oberon

Многие из немногих, программирующих на диалектах языка Oberon, полагают, что циклы FOR, WHILE и REPEAT не содержат иного способа досрочно прервать их выполнение кроме как через выход из процедуры с помощью неструктурного RETURN, и только специальный цикл LOOP по EXIT позволяет неструктурно покинуть его, не покидая саму процедуру.

Как же легко людей обмануть. В Oberon, Oberon-2, Component Pascal, Active Oberon всегда можно было написать, например, так:

FOR i := 0 TO LEN(a) - 1 DO
  IF a[i] = b THEN
    EXIT
  END
END;

Про шлифовку винтиков

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

ChatGPT4 про переносимость машинных языков

ЕИ: Машинные языки являются переносимыми точно так же, как и высокоуровневые языки. Верно?

ИИ: Нет, это неверно. Машинные языки не являются переносимыми так же, как высокоуровневые языки. Давайте рассмотрим различия:

1. Специфичность для архитектуры: Машинный язык тесно связан с конкретной аппаратной архитектурой. Это означает, что машинный код, написанный для одного типа процессора (например, x86), не будет работать на другом (например, ARM), так как у них различные наборы инструкций и способы обработки данных.
2. Уровень абстракции: Высокоуровневые языки, такие как Java, Python, или Go, предоставляют большую степень абстракции от аппаратного обеспечения. Код на этих языках может выполняться на разных платформах без изменений, поскольку он транслируется или интерпретируется средой выполнения, специфичной для каждой системы.

Мысли о программировании

Короткие разрозненные утверждения

В программировании всё не совсем то, чем кажется. Фильмы, подобные «Матрице» и «Началу» — это, во многом, художественное оформление того, что в нём происходит — сны внутри снов внутри ещё одних снов. Мы придумали метафоры и слишком серьёзно поверили в них. Часто видим непроходимость препятствий там, где её нет, и не видим возможностей, когда они есть, но «так не принято».

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

Взаимная блокировка в однопоточном языке

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

Меджусловјанскы Оберон

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

Развитие и сложность

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

Неправильные «правильные» ответы. Обратная сторона парадокса лжеца

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

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

Алгоритм преобразования числа в троичную симметричную форму

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

Бумажные книги по программированию компьютеров уже не нужны

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

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

ChatGPT4 про ДРАКОН

Для оценки разницы задал ChatGPT4 те же самые вопросы про ДРАКОН, что были заданы ChatGPT3.5 за исключением корректировки под иные ответы.

Знаешь язык блок-схем ДРАКОН?

ChatGPT4 про Оберон

Для оценки разницы задал ChatGPT4 те же самые вопросы про Oberon, что были заданы ChatGPT3.5 за исключением корректировки под иные ответы. Эта версия активно обращалась к поиску в интернете в местах, где предыдущая версия говорила о незнании или выдавала ложные ответы. Значит, система достаточно хорошо знает, в каких вопросах она слаба, но видимо настроена на то, чтобы чаще отвечать хоть что-то наудачу, а не более скучное "не знаю". Ответы, в целом, лучше, но логику система по-прежнему не тянет.

Автоматический контроль над ошибками в коде не увеличивает надёжность

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

Дополнительные символы в украинской раскладке

Как известно, типичная русская раскладка по дополнительным символам выглядит обеднённо в сравнении с английской. Не хватает @ # ^ & { } [ ] < > ʼ ~ |, что составляет проблему при наборе некоторых текстов, например в программировании. Украинская раскладка, на первый взгляд, кажется такой же скромной - в ней есть ', но недостаёт \ / на основном блоке. Но это только на первый взгляд.

Типы интерфейсов в разработке

С точки зрения проектирования интерфейсы можно разделить на:

1. Изолирующий. Скрывает конструктивные особенности кода, но ссылается на конкретное внешне проявлямое поведение. Все утверждения (предикаты), которые к нему можно предъявить, должны оставаться неизменными вне зависимости от изменений внутреннего устройства. Когда это не так, говорят, что «абстракции протекают».
2. Обобщающий. Представляет стабильную составляющую, как одну из граней кода, благодаря которой к нему можно обращаться единообразно, но не гарантирует полного совпадения поведения для разных кодов. Наоборот, позволяет передавать новые свойства коду, который его использует. Только часть утверждений относительно такого интерфейса остаётся неизменными, и они составляют его область применимости.

ChatGPT3.5 про ДРАКОН

Знаешь язык блок-схем ДРАКОН?

Да, я знаком с языком блок-схем ДРАКОН. Это графический язык программирования, который был разработан в России в конце 1980-х годов для проектирования программного обеспечения. Язык блок-схем ДРАКОН имеет простой и понятный набор символов, которые могут использоваться для создания диаграмм, описывающих логику работы программы. Этот язык удобен для разработки алгоритмов, так как он позволяет наглядно представить последовательность действий, которые должны быть выполнены программой.

ChatGPT3.5 про Oberon

В этом чате было задано несколько вопросов и дано несколько ответов на темы, связанные с языком программирования Oberon. Были заданы вопросы про различия между Oberon и Java, наличие сборщика мусора в Oberon, компиляторы Oberon, форки Ofront и другие технические вопросы. Также были даны примеры кода на Oberon и произошла дискуссия на тему правильности вычислений в некоторых примерах кода. Был задан вопрос о возможности замены массива BOOLEAN на массив SET в одном из примеров кода на Oberon.

Синтаксическая раскраска естественного языка.

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

Перевод текстовой формы числа в машинную

Математическое определения значения числа, записанного в позиционной системе счисления:

$$ Ч = \sum_{р=0}^{к} Ц_р·О^{р} $$