Мало ли поводов прибавлять к числу 2...

Численные выражения в тексте вообще признак плохого стиля. Если вот так вот взять и поменять в программе 100 на 1000, потому что захотелось увеличить размер массива, то под раздачу попадет и температура кипения воды. Не говоря уже о том, что заменить значение константы в заголовке программы существенно проще, чем гоняться за ней по всему тексту (а потом еще раз гоняться, чтобы вернуть обратно).


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


А это факт. И с машинами, и с компьютерами. От него никуда не деться. Замечу, что фактом тут является не оценка полезности или прогрессивности, а просто количество машин/лошадей и компьютеров. Я не призываю любить какое-то определенное направление, например, процесс разработки онлайн-RPG или интернет-магазинов. Просто эти вещи имеют место в современной IT-индустрии, и кто-то этим всем занимается. Соответственно, формирует требования к инструментам разработки, дает работу дизайнерам и художникам, и т.д. Если принципиально идти поперек течения, никому от этого лучше не станет. А информационный повод от декларирования 16 бит, блоков текста, доступа только к 3,5-дюймовым дискетам и CGA-монитору отдает скорее скандалом, чем благородным налетом понимания основ.


До ~1000 строк можно и не особенно задумываться о структуре программы. Разве что для пользы дела и выработки стиля. А вот дальше уже просто необходимо. И чем меньше будет подводных камней, тем лучше. Помнить в этой ситуации про 2+ - это примерно как гордиться хождением зимой без шапки ("а Васька из соседнего подъезда так не может!").

Угу, "ЧИСЛО-ПОРОСЯТ ПОРОСЕНКА", "ЧИСЛО-ВОЛКОВ ВОЛК И ЧИСЛО-КОЗЛЯТ КОЗЛЯТ"... См. Броуди.
Т.к. речь идет о пределах того, что мы можем запрограммировать, то приходится.
1000 строк кода, это по современным нормам ок.30 оставшихся после отладки ошибок. Так что тоже приходится. Если, с точки зрения писания 1000 строк - это фигня, то с точки зрения работы программы или чтения программы другим - это, практически, детективный роман.

И речь, повторю, не в том, чтобы горевать или радоваться 64-разрядным "солитерам" и "лайнсам", а в том. чтобы не считать "слова, инкапсулирующие размер ячейки" чем-то важным для стандартизации.

Эммм... Так вот же он и есть. Несколько мегабайт кода. Один мегабайт - это 1024 килобайта, а один килобайт - это 1024 байта. Или символа. 30 станиц - это примерно 50 килобайт. 1Мб > 50кб. Что не так то?

Нет, 3 ПОРОСЕНКА 1 ВОЛК 7 КОЗЛЯТ. В данном случае речь идет о введении в программу констант, которые определяются один раз и будут использоваться на всем протяжении. ЧИСЛО-ПОРОСЯТ - лишняя сущность, поскольку используется один раз, для определения дублирующей по смыслу константы. Однако:

ЧИСЛО-ПОРОСЯТ ЧИСЛО-КОЗЛЯТ + CONSTANT ЧИСЛО-ЖЕРТВ-ВОЛКА

Впоследствии сюда можно добавить учет Красной Шапочки. А если

11 CONSTANT ЧИСЛО-ЖЕРТВ-ВОЛКА , то еще поди догадайся, что это сумма поросят, козлят и Красной Шапочки. Хотя вроде сказки все читали, после объяснения очевидно. Правда, потом можно забыть, почему 11, и это была Красная Шапочка, или еще и ее бабушка. И вот такого по проекту будет навалом.



Сами по себе слова - вряд ли. Важен подход, заключающийся в том, что Форт должен иметь механизмы контроля и тестирования возможностей, а не замыкаться в том, что "всем очевидно". Ну очевидно же, что 3.1415 - слово двойной длины? Речь же идет о марте 1415 года, разве не понятно? В стандарте ведь именно так трактуется запись с точкой. С очевидными последствиями со стороны тех, кто может написать свою реализацию. Поэтому стандартизация начинается с выработки основных целевых положений и понимания того, зачем именно он нужен, кого и с какой целью собирается объединять, и какие для них будут соотношения выгод и компромиссов. Пока что ANS работает по принципу "создадим уродца, чтобы отличия от общепринятых подходов бросались в глаза, спровоцируем таким образом программистов на критику, чтобы выглядеть жертвами и объяснять таким образом отсутствие практического выхода". Еще можно стараться внедрить в практику как можно больше подходов, плохо сочетаемых с другими инструментами программирования, формируя группку программистов с гипертрофированными навыками, и привязывая их к вожаку. А потом воспитанный ANS "форт-Гуинплен", умеющий писать только на 16-битных числах с фиксированной точкой, уже просто никуда не денется.

Давайте рассмотрим регулятор Уатта... А почему не адронный коллайдер? Он, ведь больше...
Ваш текст нам не подходит по очень простой причине - его анализ займет очень много времени. И, думаю, даст заведомо неудобный для Вас результат (навскидку два-три процесса гораздо легче 64K). Не потому, что я хочу Вас обидеть, а потому, что "так всегда бывает". Так что вместо "большого муравейника" прошу показать мне "одного большого муравья".
Это Вы Броуди расскажите. По своему опыту могу только сказать, что использование констант порождает большее число ошибок, чем "просто числа". Например, даже в такой простой программе, как упомянутые выше "танчики", есть ошибочная константа.
Вы опять путаете "понимать, что такое размерность" с "считать все сущее 16-разрядным". Наверное, умышленно?

Так он вроде на пенсии, чего ему рассказывать? К тому же кроме Броуди есть, например, Макконнелл, активно критикующий "магические числа".


Можно подумать, "понимание размерности" - какое-то сакральное знание Получается, 2+ надо писать в программе, чтобы никто не заподозрил программиста в неспособности по прошествии некоторого времени сопоставить разрядность процессора с размером ячейки для одного числа?

Имя им - Легион.
Ну, как бы, люди ходят в туалет не для того, чтобы никто их не заподозрил в неумении спускать воду. Просто 2+ ставить естественнее (ведь, 2 байта-то). Если нет отдельных операций сложения для яблок, коров и драконов, то зачем отдельное сложение для адресов?

Избегайте «магических чисел» Магические числа — это
обычные числа, такие как 100 или 47524, которые появляются в программе без объяснений. Если вы программируете на языке, поддерживающем именованные константы, используйте их вместо магических чисел. Если вы не можете
применить именованные константы, применяйте глобальные переменные, когда это возможно.
Исключение магических чисел дает три преимущества.
- Изменения можно сделать более надежно. Если вы используете именованные константы, нет нужды искать каждое из чисел 100, и вы не измените по ошибке те из этих чисел, что ссылаются на что-либо иное.
- Изменения сделать проще. Когда максимальное число элементов меняется со100 на 200, используя магические числа, вы должны найти каждое число 100 и изменить его на 200. Если вы используете 100+1 или 100%1, вы также должны найти и изменить все числа 101 и 99 на 201 и 199 соответственно. При использовании именованных констант вы просто меняете определение константы со 100 на 200 в одном месте.
- Ваша программа лучше читается. Конечно, в выражении:
for i = 0 to 99 do ...
можно предположить, что 99 определяет максимальное число элементов. А вот
выражение:
for i = 0 to MAX_ENTRIES-1 do ...
не оставляет на этот счет сомнений. Даже если вы уверены, что это число никогда не изменится, применяя именованные константы, вы получите более читабельную программу.
Применяйте жестко заданные нули и единицы по необходимости Значения 0 и 1 используются для инкремента, декремента, а также в начале цикловпри нумерации первого элемента массива. 0 в конструкции:
for i = 0 to CONSTANT do ...
вполне приемлем, так же как 1 в выражении:
total = total + 1
Вот хорошее правило: используйте в программе как константы только 0 и 1, а любые
другие числа определите как литералы с понятными именами.



Ну приехали! Прирост драконов зависит от того, построено ли соответствующее здание, а также от наличия Цитадели и Замка, также могут быть захвачены внешние строения и поставлен Грааль Поэтому имеет смысл написать ДРАКОНЫ+ и уже внутрь спрятать логику расчета конкретного прироста.

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


Для Win32FORTH у меня получилось:

И кого здесь спасет CELL+ ?

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


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

Это объяснимо, вера во что-то простое гораздо привлекательнее понимания чего-то сложного.
Ну, во-первых, FORTH - не язык. А, во-вторых, если сделать его независимым от собственного устройства, проще перейти на любой из общепринятых компилирующих языков. Это как независимость lex от регулярных выражений или yacc от грамматики.

Ну так вот же он - ннкрон, например. Или браузер. Или вообще любая программа.

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

Конечно, не язык!
"Средь богов он - Великий Брахма,
Среди птиц он могучий Гаруда,
Средь наставников - мудрый Дрона
Среди дваждырожденных - Арджуна..."

(Услышанное во сне после чтения Махабхараты и книги "Язык Форт и его реализации")

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

Хорошо, рассматриваем программу, состоящую из 100500 команд "OR EAX, EAX". Видим, что ее можно заменить менее, чем 64K-блоком. Ч.Т.Д.
Сейчас, скорее, наоборот. Но, речь не о том, заводить или не заводить константы, а в том, чтобы понимать, зачем они нужны. Обратите, например, внимание на константу DOES-PFA на экр. 24 приведенного выше листинга.
Заголовок Форума читали? Кончайте троллинг...

Это сейчас-то наоборот? Сейчас годятся любые методы повышения продуктивности программиста и сохранения его контроля над процессом разработки. Способности к концентрации конечны, и засорять память элементарными деталями в угоду некоему "пониманию базовых вещей" попросту вредно. Покажите мне сначала человека, активно пишущего на Форте, который не понимает, сколько надо прибавить к адресу для перехода к следующей ячейке. Годами будем мусолить идею "понимания размера"? А работать уже когда?


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


Нет, я его писал