Вече на п-п-р

Типа рецензии с элементами ТЗ на переделку.

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

Мне тоже приходилось писать программы, не имея компьютера. Допустим, мы напишем программу более качественно. Но написание программы - это не единственное действие с программой. Обычно в наше время приходится иметь дело с чужой программой. При этом, если чужая программа работает нормально, то иметь с ней дело вряд ли придётся. Обычно приходится выяснять, почему чужая программа не работает. И вот как раз тут отладчик полезен.

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

Есть действия, когда мышь нужна, но это лишь некоторые действия. Например, удобно ли мышью набирать текст? Никак нет. У микрософта до недавного времени почти всё можно было сделать с клавиатуры и это для меня было важно. В т.ч. и манипуляции с видимыми элементами тоже, как правило, удобнее делать с клавиатуры. Значимость мыши преувеличена. Особенно пагубно это отразилось на ББЦБ. Насчёт проекта Оберон - посмотрим. Скорее всего, тоже требуется переработка UI. Я - сторонник vi-образия и, пока не забыл - команды vi должны кодироваться не одной буквой, а двумя. Например, не i, а ii. Тогда, если мы по ошибке печатаем текст в режиме команд, мы более-менее защищены от катастроф. Или же любые команды с необратимыми побочными эффектами должны быть с клавишами-модификаторами.

система Оберон в основном предполагает наличие трех кнопок.

В мобильных интерфейсах только две команды: нажатие и долгое нажатие. Т.е. одна или две кнопки. Три кнопки можно считать устаревшими.

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

Это, по сути, то же, что def-symbol-readmacro. Но не всем процедурам нужна такая же гибкость. А платить за неё приходится всегда. Цена высока: нет способа вызвать эту процедуру с параметрами из другой процедуры, и проверить их статически. Т.е. фактически в этом проекте создать команду с параметрами - то изрядный напряг:

- создать версию с параметрами для вызова из других процедур
- создать версию без параметров
- для версии без параметров написать парсер
- парсер должен из версии без параметров прочитать параметры и вызвать версию с параметрами

Сравнив это с тем же bash-ем или тиклем, где есть стандартный парсер параметров, получаем ад.
Лучшее решение - это, конечно же, лисп с Def-symbol-readmacro. Когда надо - он гибкий, как оберон. В остальных случаях - простой, как простая процедура в обероне (ну, конечно, не считая параметров-ключей и прочих роскошных штучек).

Хотя, если у нас культ простоты, то не нужны def-symbol-readmacro. Нужны только обычные функции и стандартный способ ввода параметров.

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

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

Команды. В Юниксе команды - это встроенные команды bash и файлы, которые ищутся по путям. В Обероне команды - это процедуры и живут они в пространстве имён модулей. Хорошо это или плохо? Вообще, я здесь за Оберон-вей, который совпадает с лисп-вей в общих чертах. Не считая того, что в Обероне автозагрузка модулей. Единственное, если у наc культ простоты, то нужно проследить, чтобы не появился второй вид команд, живущий уже в файловой системе. А также не хватает man, apropos и параметров. Здесь лисп-вей опять же стал лучше.

Пока процессор не занят выполнением команды, он непрерывно циклически опрашивает источники событий.

Не очень здорово. Не хватает какого-то epoll/WaitForMultipleObjects. Надеюсь, внутри оно есть.

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

Не совсем правда, но подход мне нравится.

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

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

Пролистал всю книжку до конца и в конце Вирт наконец-то дошёл до лиспа. Посмеялся.

бум-да-тссс.jpg