Собственно, вот это интервью:
https://ia800107.us.archive.org/25/item ... yazyku.pdfНекоторые вопросы в нем ожидают обсуждения.
Цитата:
«Чак: Нет, главное то, что язык обеспечивает высшую степень структурирования. Программа на Форте состоит из множества коротких слов, тогда как программа на Си состоит из меньшего числа длинных слов. Под коротким словом я понимаю его определение размером примерно в одну строку. Язык строится путём определения новых слов через уже существующие, и эта иерархия развивается, пока не наберётся, скажем, тысяча слов.»
Вообще-то говорить о программе на Си, которая «состоит из меньшего числа длинных слов» не вполне корректно. А если и программу на Си писать в виде большого количества функций длиной в одну строку? Точно так же можно и определять новые функции через существующие, развивая иерархию – и в Си даже есть функция main(), до которой нужно все развить. В этой связи говорить о «высшей степени структурирования» (что это такое, кстати?) несколько странно. Во-первых, в других языках можно действовать так же, во-вторых, заявленное отличие в обеспечении структурирования не подкреплено примерами того, что можно сделать в Форте отличного от других.
Цитата:
«У вас отсутствуют накладные расходы вызовов Си.
Чак: Верно. Это очень расширяет возможности программиста.»
Накладные расходы Си в виде управления стековым кадром вполне компенсируются теми же операциями со стеком, «размазанными» по всему коду Форта. К тому же компиляторы Си могут управлять распределением регистров, и к собственно языку это имеет не слишком-то прямое отношение. С отдельным стеком данных проще компилировать код, это действительно так. Но при чем здесь расширение возможностей программиста? Скорее это их сужение до вполне определенной модели, которая при своих недостатках проста для понимания и воспроизводима.
Цитата:
«Вы сказали, что многие программы на Форте, которые вы видели, напоминают Си программы. Как правильно писать программы на Форте?
Чак: Снизу вверх. Начать, видимо, придётся с каких-то сигналов ввода/вывода, которые нужно генерировать, - вот и займитесь ими. Затем напишите код, который управляет генерацией этих сигналов. Потом вы поднимаетесь выше, пока наконец не дойдёте до слова самого верхнего уровня. Вы даёте ему имя go, вводите с клавиатуры go - и понеслось. Я не очень доверяю системным аналитикам, действующим в нисходящем направлении. Они определяют, в чём заключается задача, а потом разбивают её на части так, что реализация бывает очень затруднена.»
Это он про плохих системных аналитиков. Направления «снизу вверх» и «сверху вниз» взаимодополняющие, и однозначно утверждать, что для какого-то языка только один подход правильный, означает смешивать совершенно разные аспекты программирования. Можно легко дополнить обозначенную «страшилку».
Плохой системный аналитик – дает спецификацию, которую трудно выполнить.
Хороший системный аналитик – дает спецификацию, которую просто выполнить.
При этом:
Хороший программист – начинает снизу и легко доходит до верхнего уровня.
Плохой программист – начинает снизу и с трудом доходит до верхнего уровня.
Противопоставление хорошего программиста и плохого аналитика заведомо субъективно. А ну как получится наоборот?
Цитата:
«Чак: Надо надеяться, что программист ознакомится с предметной областью, прежде чем начнёт писать код.»
Не просто надеяться, а прямо на это рассчитывать.
Цитата:
«Вы говорите <2.03 percent>,»
И такое число… не соответствует текущим требованиям ANS на наличие символа E в записи числа с плавающей точкой!
Цитата:
«Программист может определять слова, которые кратко отражают характеристики задачи в точном иерархическом виде.»
Ну да, и при этом следует надеяться, что программист эту иерархию построит самостоятельно. Для больших программ недостаточно просто начать писать код, надеясь, что дальше оно все само получится.
Цитата:
«Что даёт Форт? Будучи простым языком, он довольствуется простым компьютером. 256 слов оперативной памяти, 2 стека, 32 команды, асинхронная работа, простая связь с соседями. Небольшой, с малым энергопотреблением.»
При этом Мур попадает в большую ловушку – требования Форта он распространяет на требования задачи…
Цитата:
«И требуется при этом какой-нибудь 1% объёма кода, который был бы написан в других случаях. Слыша, как кто-то похваляется миллионами строк кода, я уверен, что этот человек вопиющим образом не разобрался в своей задаче. Нет в наше время задач, которые требовали бы миллионов строк кода.»
«Только ситхи все возводят в абсолют».
Мда. «Слыша, как кто-то похваляется рецептом борща, я уверен, что этот человек вопиющим образом не разобрался в кулинарии». «Слыша, как кто-то похваляется построенным небоскребом, я уверен, что этот человек вопиющим образом не разобрался в постройке шалашей». Ну и так далее.
Если у Мура «нет задач, которые требовали бы миллионов строк кода», он просто живет в другом времени. Может быть, отстал. Может быть, ему лень осваивать современные технологии, и он пытается делать хорошую мину при плохой игре. Но простите, откуда вот эта безапелляционность насчет строк кода? Требования к алгоритмам могут быть переведены банально в математическую плоскость. Есть, например, меры сложности, которые дают число ребер и узлов графа задачи… и если это число объективно велико, то они потребуют как минимум не меньшего количества операторов.
Нет, конечно, можно все упростить сверх всяких разумных пределов. Но тогда это выглядит как рекомендация «если боитесь потолстеть, выпейте перед едой 50 граммов коньяка – он притупляет чувство страха». Надо сказать, что и OKAD Мура является примером неописуемо наивного подхода, когда «да я же на Форте напишу» каким-то волшебным образом перекрыло объективные требования анализа физических процессов на кристалле, чтобы оно вообще заработало.
Цитата:
«Но для параллельной обработки почти всегда чем больше компьютеров, тем лучше.»
При этом попытка связать большое количество компьютеров уже сейчас выявляет эффект, когда падает не просто удельная, а и абсолютная производительность. Накладные расходы на обмен данными съедают весь эффект от дополнительных вычислительных узлов. Вот если бы связи были только локальными… и достаточность таких связей имела строгое математическое доказательство. Но нет же такого доказательства в общем случае.
Цитата:
«Операционная система абсолютно не нужна вам. Если у вас есть подпрограмма, называемая драйвером дисков, и другая программа, обеспечивающая поддержку какого-то типа связи, то вам ничего больше не нужно от операционной системы.»
Аргументы, которые бьют совершенно мимо. Наличие драйвера дисков и сетевой библиотеки не является обязательным признаком операционной системы. Операционная система имеет другой ключевой признак – она выполняет диспетчеризацию ресурсов. Что будет, когда диск начнут дергать в разные стороны две программы сразу? Понятие ОС не эквивалентно понятию «набор драйверов», поэтому и утверждение, что раз есть драйверы, то ОС уже не нужна, далеко от реальности.
Цитата:
«Windows тратит массу времени, работая с оверлеями, дисками и т.п., что никому не нужно. Сейчас есть гигабайтные диски и мегабайтная оперативная память.»
Запись одного байта средствами BIOS: 512 байт требуют 512 переписываний сектора. Та же запись при наличии ОС кэшируется и работа с диском становится на порядок быстрее (в данном конкретном случае). Мур не разобрался и сделал хорошую мину при плохой игре.
Цитата:
«В чём главная проблема параллелизма?
Чак: Главная проблема параллельной обработки в скорости. Компьютер должен решать в приложении множество задач. Это можно осуществить на одном процессоре с помощью многозадачности. А можно одновременно выполнять задачи на нескольких процессорах. Последнее осуществляется гораздо быстрее, и современное программное обеспечение нуждается в такой скорости.»
Интересно, Мур вообще слышал про закон Амдала?
Цитата:
«Чак: Соединить несколько процессоров нетрудно. Таким образом, аппаратное обеспечение есть.»
Ну это пока процессоров действительно «несколько». А когда их станут тысячи, соединяться они должны теми же банально-наивными способами – «каждый с каждым» либо «один с соседями»?
Цитата:
«Чак: Вы совершенно правы. По большей части компьютеры заняты перемещением данных, а не расчётами. Не просто перемещением, но сжатием и шифрованием.»
Именно так. Про сжатие и шифрование уже можно опустить, но при попытке соединить множество компьютеров неминуемо наступит момент, когда «третий в пятом ряду» затребует данные, которые хранятся на «восьмом в десятом ряду». И эта проблема просто есть, не сводясь к решению «да это просто надо на Форт перейти».
Цитата:
«Чак: В моём компьютере это учтено, и умножение выполняется просто и медленно. Оно используется нечасто.»
Ну…. у него нечасто. В ЦОС – часто.
Цитата:
«Вы сказали, что Форт реально поддерживает асинхронную работу. В каком смысле вы говорили об асинхронной работе?
Чак: В нескольких сразу. В Форте всегда была возможность мультипрограммности и многопоточности - средство под названием Cooperative.»
Дальше идет форменный ужас. Времен, наверное, Windows 3.11, когда неаккуратно написанная программа могла обрушить всю систему. Опять же, это не вопрос языка, это вопрос организации совместной работы. Нет никакого смысла в отдельном слове pause, если программисту заранее говорят, что он должен организовать взаимодействие программ и потоков буквально вручную, если это все выдается за «реальную поддержку асинхронной работы».
Цитата:
«Спрашивается, если взять такую задачу, как, скажем, стек TCP/IP, то как разбросать её по множеству таких компьютеров, чтобы выполнялась нужная функция и при этом на каждом из компьютеров было не более 512 команд? Очень красивая проблема, за которую я как раз взялся.»
Ой, я уже хочу на это посмотреть. Именно на TCP. Даже не на скорость работы, а просто на полноту функционального описания обработки пакетов.
Цитата:
«Похоже, вы совершенно уверены в том, что в ближайшие 10-20 лет мы всё чаще будем встречаться с тем, что программы образуются в результате свободного соединения множества мелких частей.
Чак: О да. Я уверен, что так и будет.»
Подозреваю, что системным анализом Мур не интересовался. Вообще говоря, утверждение, что сумма компонентов образует или же не образует новое качество, само по себе является предметом исследования. Наивная вера, что достаточно написать мелкие программы, а дальше они как-нибудь сами, гораздо опаснее, чем мифическая угроза от старого ПО с миллионами строк кода.
Цитата:
«Основные ошибки в Форте совершаются при работе со стеком. Можно случайно что-нибудь оставить в стеке и потом поскользнуться на этом.»
Счастлив (в своем невежестве) человек, у которого основные ошибки – из-за стека…
Цитата:
«Моя философия, которую я стараюсь систематически распространять, состоит в том, что количество условных операторов в программе должно быть минимально. Вместо одного слова, которое проверяет некое условие, а потом выполняет либо одно, либо другое, лучше иметь два слова: одно выполняет это, другое - то, а вы решаете, которое из них применить.»
Ну, философия – это сильно. А утверждение без уточнений – еще сильнее. То есть, например, можно иметь два слова – одно делит, а другое нет, вместо проверки условия «а не делим ли мы на ноль». И правда, пусть пользователь каждый раз задумывается и прокручивает в голове, что именно ему набрать в консоли. Перемещение данных в памяти (назад/вперед при перекрытии адресов) – тоже вручную! Особенно если параметры вида addr1 addr2, и с ходу непонятно, начинать с младших адресов или со старших. Собственно, примеров можно приводить десятки очевидных и сотни менее очевидных, но от этого не менее важных.
Цитата:
«В Си так не получится, потому что вызов обходится дорого, и стараются ввести такие параметры, чтобы одна и та же подпрограмма выполняла разные действия в зависимости от того, как её вызвали. Отсюда все ошибки и осложнения в старых программах.»
Опять это утверждение про «дорогой вызов» в Си. Вообще-то проверка параметров на входе является приемом повышения надежности больших проектов. Да, я хочу открывать файлы, не думая о том, вызвать мне драйвер HDD, SSD, флеш-накопителя, сетевую библиотеку или это вообще UART.
Цитата:
«Глупо писать электронное письмо с помощью Word: 99% его возможностей окажутся невостребованными. Для электронной почты нужен свой редактор. Когда-то такой был, но мода идёт в другом направлении. Непонятно почему.»
Да потому что при написании письма человек занят написанием письма. А не вспоминанием того, какие минимальные возможности ему дали в этом редакторе. Да, я хочу редактировать любые тексты с примерно одинаковым набором возможностей – шрифты, таблицы, картинки, проверка орфографии и прочее.
Цитата:
«Мне нравится определение - не знаю, есть ли другие, - что из двух концепций проще та, у которой короче описание.»
Например, уравнение Шредингера короче, чем таблица умножения…
Цитата:
«Чак: Групповую работу слишком превозносят. Первая задача группы - разбить задачу на относительно независимые части. Назначьте исполнителя для каждой части. Руководитель команды отвечает за стыковку отдельных частей между собой.»
То есть у Мура пробел не только в системном анализе, но и в организации групповой работы?...
Цитата:
«Чак: Хороший программист быстро пишет хороший код - корректный, компактный и читаемый. значит несколько часов или дней. Плохому программисту нужно обсудить задачу, и он будет тратить время на планирование, вместо того чтобы писать код, и сделает своей профессией написание и отладку кода.»
Вот и наглядное подтверждение. Чего там планировать, просто пишем код. Снизу вверх. Работы хватит – низкоуровневых слов полно, можно описать вывод данных в каждый порт. Архитектура, взаимодействие модулей, проверка данных? Нет, ну зачем же. Отсюда и непонимание смысла групповой работы. Ну какая тут групповая работа у нескольких «мастеров Форта», которые тянут каждый в свою сторону, не проверяют данные на входе, произвольно выбирают слова и в конечном итоге вываливают в проект массу мелких слов «в одну строчку», из которых проект не складывается.
Цитата:
«Чак: Я меньше придаю значения комментариям, чем это обычно принято.
…
Самое главное, комментарии часто оказываются неточными. Код может измениться, а в комментариях это не отражается.»
Ну да, если писать «по велению сердца» и на адреналине, да еще никак не продумывая проект, то код будет регулярно уходить в стороны.