Слова исполняются "неправильно", а в Стандарте написано "зависит от реализации"

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

Там же, ранее:
> Где-то прочитал, что Fig-Forth - это воплощение самого духа Форта. А все остальное уже не тру. Решил потратить время и приобщиться.
> По ходу пьесы во всех реализациях Фиг-Форта для IBM-PC обнаружил одну и ту-же хрень...

Если глянуть стандарт (ANSI-94), то там, действительно, видим изначально заложенную несовместимость, которую предлагается компенсировать документированием и установкой специальных переменных окружения.

Так стоит ли, в принципе, рассчитывать на то, что на FORTH можно что-то написать раз и навсегда, без правки по месту при последующих переносах? Можно ли выделить "стандартное ядро", "классику", которые железобетонно работают всегда одинаково?

Практика FORTH это отвергает.
Во-первых, итерационный способ построения программы подразумевает подстройку системы под программиста. В идеале - полную, включая операционную систему и конкретные средства редактирования/запуска/отладки. Так что, ничего "железобетонного" там быть не должно...
Как же тогда править программу по месту? Тут работают два важных FORTH-принципа программирования: в программе не должно быть ничего, кроме того, что нужно. Никакой обязательной (структурной, объектно-ориентированной, безопасной, управляемой, абстрактной...) обфускации. Любое слово в программе лежит на пути логического построения нужного результата и является логически законченным. Поэтому оно завсегда понятно что делает и может быть легко проверено на правильность.
Второй принцип - опять же, итерактивность построения программы. В отличие от C, где для проверки отдельных функций приходится добавлять в программу заглушки и эмуляторы, FORTH-программисту средства устроить программе (и/или любой ее части) "закат солнца вручную" даны изначально.

ОЧЕНЬ ВРЕДНЫЙ ДОКУМЕНТ

Первая причина очевидна: вместо того, чтобы попытаться формализовать идеи, лежащие в основе Forth, авторы ANSI-94 попытались формализовать некое обобщенное состояние "вычислительной среды" в которой Forth должен существовать. Но, ведь, Forth славен своей способностью существовать в любой среде...
Так что, большинство терминологических и основополагающих измышлений авторов - просто колебания воздуха, закономерно не интересующие никого из фортеров.
Редкие термины, имеющие постоянное употребление в Forth, гораздо проще вводяться путем определения использующих их слов (в смысле - словарных статей).
Ведь, почти все (кроме микро-фортеров) соглашаются с тем, что сильная сторона Forth - в открытом описании всех подробностей его реализации (на нем же). Чтобы можно было его "саморазвивать".
Поэтому фортеры чаще всего воспринимают Стандарт, как набор обязательных слов. Ибо в процессе их реализации Forth рождается "сам собой".
***

Слова, которые описаны в Стандарте, разбиты на категории:

- CORE - по сути - весь Forth (остальное - по желанию). Ведь, авторы [не]понимают Forth как "многоуровневую среду, содержащую элементы машинного языка, а также операционную систему и машинный монитор". И все "оно" - в этой категории. Навалом.
- CORE EXT - то, что по разным причинам не влезло в CORE. "У нас возник спор, стоит ли пускать крысу в дело. Гаррис сказал, почему бы и нет, если смешать ее со всем остальным, каждая мелочь может пригодиться. Но Джордж сослался на прецедент: он никогда не слышал, чтобы в ирландское рагу клали водяных крыс, и предпочитает воздержаться от опытов".
- Остальные категории: BLOCK, DOUBLE, EXCEPTION, FACILITY, FILE, FLOATING, LOCALS, MEMORY, TOOLS, SEARCH, STRING. По большей части, это вещи, которые оказались нужными/полезными/возможными в каких-то конкретных реализациях.
- Причем, каждая из этих категорий имеет свое недосогласованное EXT. Очень много взаимоисключающих концепций.
***

Во все времена фортеры надеялись на то, что где-то существует "стандарт", реализовав который, можно разом решить все Forth-проблемы. От совместимости/переносимости, до компактности/быстродействия и избежания лишних стековых операций... Нет такого "стандарта" не будет и, уж всяко, ANSI-94 ничем подобным и близко не является.

ЛЕГЕНДА О СОВМЕСТИМОСТИ

Авторы стандарта не только, как указано выше, выдвинули какие-то требования к "вычислительной среде", но и ограничились в своей стандартизации только определенным уровнем слов - примерно уровня BASIC тех времен, отметив: "Все, что ниже и выше - зависит от реализации".
***

Затем они смело заявили: "А все, что зависит от реализации, должно быть документировано". Этих "должно быть документировано" я насчитал в Стандарте около сотни (т.е. их перечисление в тексте весит примерно, как сам Forth).
Искать в тексте чужой программы "одну из сотни возможных нестыковочек" или "сначала сверить документацию по сотне пунктов и затем искать в программе только пяток критических нестыковочек"?
Или все-таки, как обычно, запустить, и посмотреть "что не работает"?
Согласитесь, последняя альтернатива для системы, которая мы знаем как устроена и поддерживает итерактивную разработку и любую отладку, как-то предпочтительнее.
***

С другой стороны, невзирая на отсутствие "супер мета-языка описания основ Forth" большинство программистов (за исключением, разве что, мета-фортеров) как-то вполне друг другу способны объяснить, как "оно работает".
А большинство системотехников (за исключением структурных фортеров) способны на пальцах объяснить (и понять), как работает программа в целом...
Так много ли проку от "стандартизации посредине", тем более, что переписать Forth полностью - не проблема?

ДЛЯ АТОСА ЭТО СЛИШКОМ МНОГО, А ДЛЯ ГРАФА ДЕ ЛА ФЕР - СЛИШКОМ МАЛО

Если не заметить в самом конце списка расширений слова CODE, то Стандарт навевает мысль исключительно о создании Forth-системы на языке высокого уровня (и в могучей ОС). Чисто для любителей обратной польской записи, нестандартных имен и посрамления ООП применением CREATE ... DOES> ...

1. Один стек, одно адресное пространство, одна арифметика, один набор операторов управления, один интерпретатор... Конечно, никто не запрещает дополнять систему своими средствами, но если размер расширения значительно превысит размер Стандарта, то какой прок в стандарте? Слово "плюс" обозначает сложение двух верхних элементов стека? А кто-то думал не так?
2. Конечно, у Мура не было текстового редактора и был телетайп-консоль... Но оптимизировать под это систему в 94-м году как-то странно. Например, под Windows я должен написать достаточно серьезную программу для создания нормальной оконной консоли, но т.к. Forth "не знает", что это такое, писать придется "не на нем", а как Мур - вслепую.
3. Как я уже писал выше, BASIC-возможности взаимодействия с ОС легко организуются средствами любой ОС. Но, вот, достучаться к "остальным возможностям" ОС BASIC-машина практически не способна. Поэтому Forth, описанный в Стандарте - просто игрушка.
***

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

ОТКУДА ЖЕ БЕРУТСЯ СОПЛИ О СТАНДАРТАХ,..

Очевидно, что, глядя на систему программирования, которую можно изготовить в домашних условиях, можно
1. искать общих принципов, поняв которые можно создать свою систему;
2. стараться понять, что сделает свою систему не хуже других;
3. оценивать возможность применения созданной системы для своей пользы (программирования).

Посмотрев, на развитие FORTH-систем можно обнаружить жуткий перекос в сторону п.2. Все разговоры за "общие принципы" и "границы применимости", например, на "кошачьем форуме" непременно скатываются в обсуждение стандартов и обязательных танцев с бубнов. (Как сделать свой FORTH?- Сначала напиши слова DUP и SWAP...) (Как запрограммировать сложную программу?- Реализуй на FORTH ООП, добавь библиотек...)

Причем, можно видеть, что на уровне п.2. фортеры никогда не договорятся. У каждого - своя домашняя заготовка стандарта. Каждый считает, что его реализация (или хорошо изученная чужая) лучше всех, и все дальнейшее FORTH-развитие - лишь ее совершенствование.

Получается парадокс. Пп.1 и 3 обсуждать отказываемся, а по п.2. договориться не можем. И так - уже полвека.

А можно ли, вообще, обсуждать "края" без "середины"? Ведь, как описывать общие идеи FORTH, не касаясь слов, которые эти идеи реализуют? Как писать сложные программы, иначе чем строя конгломераты (лексиконы) из простых слов?.. Дык, ни то, ни другое не верно!

Во-первых, FORTH-образующие слова - ОК, СИМВОЛ, ВЫПОЛНИТЬ, КОМПИЛИРОВАТЬ, СЛЕДУЮЩИЙ - совсем не являются "правильными" FORTH-словами. Большинство из них либо пишутся в кодах, либо состоят из немногочисленных кодовых слов. Повторное использование кода/слов - минимально. Обмениваются друг с другом они, тоже, по большей части, совсем не через СТЕК...

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

В-третьих, обе эти крайности - простейшая реализация и сложные проекты - достигаются применением одного и тем же механизма! Суперсложная FORTH-программа будет обозримой и управляемой только, если будет состоять из тех же частей - ОК, СИМВОЛ, ВЫПОЛНИТЬ, КОМПИЛИРОВАТЬ, СЛЕДУЮЩИЙ (разумеется, реализованных на ином уровне, чем исходные). Нет никаких сложных "философий" и "инноваций", позволяющих успешное FORTH-писание - есть лишь понимание одного несчастного принципа - построения системы, как набора интерпретаторов, реализованных простейшим способом на чем придется.

> 4. ...
Не совсем...
> 5. ...
Примеры,
> 7. ...
Чем?
> 14. ...
Согласен
> 16. ...
Действительно, просто расширили какой-нибудь "дибилизм" 79-STANDARD или FORTH-83.
> 17. ...
Я вообще уже не признаю букву "M" (MIXED)!
> 18. ...
Чем предлагается заменить?
> 21. ...
Да я сам...(не особо люблю числа с запятой). Какие есть другие предложения?
> 22. ...
Стандарт вообще не понял

> 1. Один стек, одно адресное пространство, одна арифметика, один набор операторов управления, один интерпретатор...
Конечно, никто не запрещает дополнять систему своими средствами, но если размер расширения значительно превысит размер Стандарта,
то какой прок в стандарте? Слово "плюс" обозначает сложение двух верхних элементов стека? А кто-то думал не так?
Вообще, я всегда хотел реализовать систему чисто по стандарту: моё слово -- слово в стандарте, и не более. Итог ясен
Стандарт Форта действительно миф. Лучше новый документ назвать ...(описал чуть ниже)
Вообще, в последнее время благодаря некоторым мыслям mOlegа я начал лучше понимать Форт, а из-за совета посмотреть
на SmallTalk (я даже чуть-чуть переборщил с просмотром :]) я начал просматривать Wiki и потихоньку начал понимать
мир открытого программирования (к открытым нам языкам) и ваши мысли.
Теперь я кажется точно понял, что вы хотели сказать под словом "метод".
Форт - язык, с помощу концепций которого можно описать что угодно.
Вообще, Форт, на мой взгляд, очень походит на язык построения этого материального мира, но это не точно...

Откуда вообще взялись языки программирования? Нетрудно догадаться, что всё в этом мире повторяется (фракталы...).
Я тут зачем-то составил такую диаграмму ("Иерархия архитектур ЭВМ"?):
0. Логика и алгоритмы окружаещего мира (...)
1. Аппаратных архитектуры ЭВМ
2. Архитектуры языков программирования и вспомогательных программ управления
(BIOSы и др.)
3. Архитектуры операционных систем
4. Архитектуры прикладных программ и (как частное) виртуальных машин
Правила тут получаются довольно просты. Чем выше уровень, тем больше вероятности того,
что этот метод был реализован в предыдущей(их) иеерархии(ях).

...Когда мы пытаемся его стандартизировать или подогнать под определённые цели, то мы ограничваем эталон.
Когда мы ограничиваем эталон, то ограничиваем и сферу, в которой может использоваться Форт.

Поэтому я и предлагаю создать документ, который точно определяет принципы Форта и методы создания
Форт-среды (более расширенное понятие Форт-системы) для различных проблем.
Под проблемами я понимаю:
a) Парадигмы программирования и их сочетания
б) Архитектурно-аппаратные зависимости
в) Архитектурно-программные зависимости

Как реализовать этот универсальный Форт-документ я не знаю, но... прошу оценить мои мысли!

Так как мысли изменяются, буду делать копии...
[конец 2]
...Когда мы пытаемся его стандартизировать или подогнать под определённые цели, то мы ограничваем эталон.
Когда мы ограничиваем эталон, то ограничиваем и сферу, в которой может использоваться Форт.

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

Под проблемами я понимаю:
a) Парадигмы программирования и их сочетания
б) Архитектурно-аппаратные зависимости
в) Архитектурно-программные зависимости
г) Начальная задача

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

Как реализовать этот универсальный Форт-документ я не знаю, но... прошу оценить мои мысли!

А вообще я запутался Зачем промежуточное решение на Форте, когда может быть готовое на нормальном языке?.. Короче, по поводу бессмысленности Форт-Философии я согласен. (как с вами, так и с mOLEG (из переписки)

что же касается философии, то тут вообще мрак как накручено.
Для меня суть философии - делать все как можно проще.

)
P.p.s. Интересно, почему вы разошлись с ним во мнениях?

...кое-что из последнего - мой бред.
Невозможно усидеть на многих стульях так просто. Я просто вспомнил о ваших подходах в реализации программ на си с форт-методами и слова KPG(?) о встраимости Форта в другие программы. Бам! (в голове) Исключение.
Выводы: Нельзя встраивать форт напрямую в дургие программы, т.к. это его ограничивает (зачастую сильно). Исключение - построение программы за счёт идей Форта.
Самой главными идеями форта является оптимальность, компатность и точность конечной программы (или объекта, на соответствующем уровне).

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

Заранее прошу прощения. Вы вывалили такую кучу замечаний, что я заведомо упущу главное...

Почему я считаю мусором "Совместимую работу с памятью"? Потому, что я считаю мусором любую заботу о совместимости. Если наш язык допускает адресную арифметику, то, как ни крути, при переносе программы под другой размер ячейки придется переписывать все. Я тут неделю назад пытался читать байтовый массив из файлов средствами JavaScript. Не тут-то было, байты сразу сворачиваются в UTF-8. Пришлось пользоваться специальным объектом DataView, но он есть только в последних версиях... И это общая болезнь - чем переносимее система, тем более она несовместима сама с собой.

Примеры вынужденности переноса арифметики? Начнете писать - заметите. Универсальные вычисления вещь достаточно редкая. Обычно вычисления кучкуются в сложные куски, которые приходится еще и оптимизировать. И работать машинными командами с регистрами гораздо удобнее, чем жонглировать стеками. Например, в DOS-FOBOS мне не только пришлось запихивать обсчет графики в коды, но делать ее честно 32-битной.

Чем неудобны операции с флагами? Двойным ветвлением - при установке и при проверке флагов. Чем заменять? Работой с флагами как с целыми и адресной арифметикой.

Чем заменить "Структурную обработку исключений"? Ничем. Она либо не нужна (управление нужно отделять от вычислений), либо вредна (маскирует ошибки).

Там еще есть какой-то вопрос, но я не понял, к чему он относится.

> Как реализовать этот универсальный Форт-документ я не знаю, но... прошу оценить мои мысли!
Вы все пытаетесь найти какие-то решения на уровне абстракций и агрегаций... Все проще. Есть машинный код процессоров, который состоит из что-то делающих команд. Никаких слов, которые что-то "описывают" там нет. Программисты же изобретают языки высокого уровня, описывающих общие случаи/парадигмы применения этих команд - "работа с переменными", "передача параметров", "виртуальные методы"... И изобретать эти абстракции можно двумя способами: с точки зрения построения законченных моделей универсальной модели вычислений, или по мере практической надобности. И FORTH - это второй путь. Поэтому стандартизировать в нем "решения проблем" бессмысленно. Скорее следует стандартизировать орг.меры.

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

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

> Самой главными идеями форта является оптимальность, компатность и точность конечной программы
Это неправда.
В FORTH:
... оптимизируется процесс писания программы, но не ее работа
... компактна программа, но не ее код
... программа точно соответствует задумке программиста, но это не гарантирует точного решения задачи

(что это я про quote забыл?)

Я тут неделю назад пытался читать байтовый массив из файлов средствами JavaScript. Не тут-то было, байты сразу сворачиваются в UTF-8. Пришлось пользоваться специальным объектом DataView, но он есть только в последних версиях... И это общая болезнь - чем переносимее система, тем более она несовместима сама с собой.

Но это совсем не походит на аппаратную совместимость, а больше на совместимость с прошлыми версиями. А разве хотя-бы CELL в Форте не нужна? Но я вас понял) Про арифметику вы имеете ввиду тоже самое: алгоритмы лучше реализовывать на ассемблере целевой архитектуры. (поэтому видимо вы крайне плохо относитесь к стековым манипулчторам)

Чем заменить "Структурную обработку исключений"? Ничем. Она либо не нужна (управление нужно отделять от вычислений), либо вредна (маскирует ошибки)

Возможно, но на мой взгляд она плоха тогда, когда встраивается в главный цикл системы (как у ETHEREAL).

Там еще есть какой-то вопрос, но я не понял, к чему он относится

Какой?

Чем неудобны операции с флагами? Двойным ветвлением - при установке и при проверке флагов. Чем заменять? Работай с флагами как с целыми и адресной арифметикой.

Что-то я вас не понял.

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

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

_KROL пишет:Но это совсем не походит на аппаратную совместимость, а больше на совместимость с прошлыми версиями.

Здесь именно "аппаратная". В JavaScript так увлеклись "стандартными символами", что до байтов стало не достучаться.

_KROL пишет:А разве хотя-бы CELL в Форте не нужна?

Нет, не нужна. Т.к. при определении структур данных и писании в кодах, все равно, приходится все время помнить, что она равна 4 байта. А в тот момент, когда фортер говорит: "Наконец-то, теперь я могу забыть про реальный размер ячейки",- FORTH просто перестает быть нужным. Получается неувязочка: фортеры похваляются тем, что могут залезть в самые кишки системы, но сами от себя прячут реальные параметры.

_KROL пишет:поэтому видимо вы крайне плохо относитесь к стековым манипулчторам

Не по этому. Просто я не вижу им никакого полезного применения. Легко написать "DUP OVER SWAP DROP DROP"? Но я стараюсь либо минимизировать перестановки, либо разбиваю их на осмысленные куски.

_KROL пишет:Какой?

19?

_KROL пишет:Что-то я вас не понял.

Про двойное ветвление? Или про адресную арифметику?

_KROL пишет:Как может быть код оптимизирован, но не компактен, и наооборот?

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

Gudleifr пишет:А в тот момент, когда фортер говорит: "Наконец-то, теперь я могу забыть про реальный размер ячейки",- FORTH просто перестает быть нужным. Получается неувязочка: фортеры похваляются тем, что могут залезть в самые кишки системы, но сами от себя прячут реальные параметры.

Понятно, кроссплатформенность программе нужна не всегда, поэтому CELLы можно опстить.

Gudleifr пишет:Легко написать "DUP OVER SWAP DROP DROP"? Но я стараюсь либо минимизировать перестановки, либо разбиваю их на осмысленные куски.

Я тоже так делаю. Но TUCK иногда нужен.

Gudleifr пишет:19?

Исправился, там 21.

Gudleifr пишет:Про двойное ветвление? Или про адресную арифметику?

Про всё) Да и вопроса я вроде не задавал, но понять интересно.

Gudleifr пишет:FORTH оптимизирует писание програмы, но не написанный код. FORTH-программа быстро пишется и коротка на бумаге, но медленно работает и занимает много места в памяти.

Хм, а я как-то забываю, что (в настоящем Форте) код относится ко всей системе.

У меня как-то вообще была мысль о полном разделении ФВМ и системы для кроссплатформенности. Сейчас я вижу немного схожее у SmallTalk (только там ООП).

_KROL пишет:Понятно, кроссплатформенность программе нужна не всегда

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

_KROL пишет:Исправился, там 21.

Дык, к этому вполне относится то, что я писал про арифметику. Например, в программе "Лунолет" ТЕМА #43, АБЗАЦ #431, можно видеть, что вся вещественная арифметика собирается в "кубики": "расчет ускорения", "подсчет расстояния" и т.п.

_KROL пишет:Да и вопроса я вроде не задавал, но понять интересно.

_KROL пишет:> 7. ...
Чем?

Двойное ветвление - это очевидно. В "X Y < IF ..." мы дважды проверим условие (и соответственно выполним условный переход) - в < и в IF. Как это заменить адресной арифметикой? См., например, у Броуди - во 2-й главе TF ("ОПРЕДЕЛЕНИЕ ПРАВИЛ").

_KROL пишет:У меня как-то вообще была мысль о полном разделении ФВМ и системы для кроссплатформенности.

Как только возникает идея что-то разделить, выкидывайте одно из них и пишите второе. Впрочем, ФВМ - это такая же ерунда, как и кроссплатформенность.

Спасибо! Ладно, завтра разберусь. Спокойной ночи!
P.s. Если вам эти вопросы мешают, то можете вынести в отдельную.
P.p.s.

Изначально Мур предложил организовывать блоковую память, как расширение словаря. Если лексему не удавалось распознать, ни как имя словарной статьи, ни как литерал, оно считалось именем числовой константы, определенной в дисковой памяти. Его следовало искать в в индексных таблицах диска. Результат успешного поиска давал число: маленькое или большое.
...
В ориентированных на процессы Операционных Системах файлы, это не "просто место на диске". Там файлы - каналы связи между процессами.

А может так и сделать? Тогда блочный диск (или файл) получается как pagefile, да и использовать его можно как канал между процессами.

_KROL пишет:Если вам эти вопросы мешают, то можете вынести в отдельную.

Нет, они пока в тему.

_KROL пишет:А может так и сделать? Тогда блочный диск (или файл) получается как pagefile, да и использовать его можно как канал между процессами.

Пляшите от задачи.

_KROL пишет:Парадигмы программирования и их сочетания

Забудем на минуту о FORTH, вернемся к проблемам быдлокодеров. Допустим (я, действительно на днях участвовал в подобном обсуждении), нам в программе нужен двусвязный список. Быдлокодер тут как тут и быстренько копипастит библиотечку строк на сто. Теперь мы можем писать в программе что-то вроде

list.push_back(foo); (1)

вместо выученного еще по первому тому "Искусства программирования" Кнута

P<=AVAIL, LLINK(P)<-X, RLINK(P)<-RLINK(X), LLINK(RLINK(X))<-P, RLINK(X)<-P. (2).

И, разумеется, быдлокодеры докажут любому, что запись (2) устарела, не читается, не переносима...

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

А что можно сказать в защиту (2)?
а) (1) короче? Но, это только в общем случае. Здесь начинает работать "синдром чайника". Например, мне надо не добавить элемент в список, а слить вместе два списка. Усложнять код программы или расширять возможности библиотеки? Не забываем, у (2) уже есть фора в сотню строк, т.к. библиотека ей вообще не нужна. "Современные программисты" живут в страшном мире, где нельзя просто написать то, что нужно, но надо комбинировать из того, что есть, поэтому даже то, что (1) короче (2) приводит к раздуванию размеров кода;

б) (1) легче запомнить? Но какой ценой? Ведь, из записи (1) вообще не понятно, с чем я имею дело. Заметив знакомые имена в (2), я сразу вижу: "двусвязный список". И, уж извините, наверное программист должен уметь оперировать с указателями на данные так же легко, как он умеет писать арифметические выражения;

в) (1) выглядит единообразно? А это надо? Если нам тут нужен двусвязный список, имеет ли смысл оставлять "дыру" для возможной его замены любым другим деком? И, в конце концов, операция "добавить в конец" не имеет никакого отношения к двусвязным циклам. Она им просто не нужна.

Конечно, если (2) повторяется сотню раз внутри моей программы, я вынесу ее в отдельную подпрограммы/макрос/слово, но зачем мне для этого целая, созданная по всем правилам структурного и объектно ориентированного программирования, библиотека?
Например, единственное, что у меня постоянно повторяется "про списки" (при писании на C) умещается в три строки макросов:

/* Список типа X обязан иметь указатель X *next и деструктор del##X() */
#define LIST(X) p##X next;
#define FREE(X) free##X(p) p##X p; { if (p) { free##X(p->next); del##X(p); free(p); } }
/* Двусвязный список типа X обязан иметь указатели X *next, *pred и деструктор del##X() */
#define BLIST(X) p##X next, pred;

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

Является ли эта игра в структуризацию просто "детской болезнью" или она чревата "осложнениями"?
Я наблюдал за развитием нескольких около-игровых форумов.
Сначала все рвутся быстро написать игру.
Потом начинаются рассуждения, что перед написанием игры надо бы создать свой "движок" т.к. все существующие на данный момент жутко неудобны. Все бросают писание игр и идут писать "движки".
Следом выясняется, что все существующие языки программирования так же убоги и недостаточны... Значит, надо написать новый язык... И все строем идут создавать свои языки...

"Мир тянулся с севера на юг, от Перевала вниз, через земли все меньшей вероятности, в край абсурда. На крайнем юге Мир переходил в пустыню, населенную призраками и миражами. За пустыней не было ничего. Даже нереальный Мир там истончался и переставал существовать" /С.Логинов, Страж Перевала/.

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

Gudleifr пишет:

KROL пишет:Парадигмы программирования и их сочетания

..

Во-первых, я тогда думал не об том, что вы сейчас пишите, а об более-менее универсальной среде, сочитающей парадигмы. Правда, когда увидел smalltalk у меня отпали 2 желания: сделать форт единственным и неповторимым языком, и сделать самому ОС. IMHO я увидел в smalltalk лучшую GUI, которая почти такая же свободная, как форт, хотя форт один из лучших императивных языков (по своему).
Во-вторых, знаете, какой способ написания программ в последнее время я использовал в Turbo Pascal? Безмодульный. Просто подключаешь исходник директивой, редактируешь если надо (те же процедуры работы со списками) и более оптимизированным машинный код получается. Да, пишется зачастую всё заново (как на форте), но зато нету такой громадины из связей как модуль crt.
И да, это порой более удобно, чем держать abc.c и abc.h ... Ах вот почему мне C-- понравился)

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

Да, даже Торвальдс писал (судя по записям кошачего форума), что "в форте можно всё, и вы напишите всё", но это не повод решать так все задачи! Форк тут можно привести как пример хорошей, пусть и не "стандартной", системы...

_KROL пишет:Во-первых, я тогда думал ... об более-менее универсальной среде, сочитающей парадигмы...

Через это прошли все программисты. Лекарство одно - что-то написать.