Непонимание...

Подытожу факты:

1. http://www.forth.com/resources/evolution/evolve_0.html:
В конце 50-х Мур работает программистом в обсерватории. И пишет программу для управления телескопом. ДЛЯ СОКРАЩЕНИЯ РАБОТЫ ПО ЕЕ ПЕРЕКОМПИЛЯЦИИ пишет простой интерпретатор, воспринимающий команды и числа, разделенные пробелами. Т.е. даже первая Forth-образная программа не была предназначена для "управления", но для чтения входного потока управляющей программы.

2. Е.W.Dijkstra. An attempt to unify the constituent concepts of serial program execution. 1962. В этой статье Дейкстра описывает некую модель простой и однозначно действующей машины, очень похожей на будущий Forth. Разумеется, там нет никаких намеков на "управляющий язык".

3. CHARLES H.MOORE. PROGRAMMING A PROBLEM-ORIENTED-LANGUAGE, июнь 1970. (Примерно в одно время с первой документацией на Forth). Мур пишет, что написал статью СРАЗУ после написания первых версий Forth как ОБОСНОВАНИЕ СОЗДАНИЯ ЯЗЫКА ЗАДНИМ ЧИСЛОМ. В статье, как следует из названия, Forth рассматривается как метаязык. Интересно, что Мур "забывает" объяснить, как он "придумал" те вещи, которые ранее описал Дейкстра.

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

AXT>> где тут Форт вообще?
Balancer> JVM — стековая машина.

Ммм... тут очень тонкая разница, но ИМХО она таки есть. Java может быть реализована и на регистровой машине (Dalvik, как пример), а с Фортом дело обстоит не так — язык заточен строго под стековую машину.

AXT> язык заточен строго под стековую машину.
Только он - не язык.
Сам F пользуется стеком двояко a) потому что так проще (он обычно поддерживается A), б) потому, что исходная модель Дейкстры базировалась на стеках. Трудно представить себе расширяемый язык, не имеющий возможности расширения своих структур, а простейшая из расширяемых структур - стек. Поэтому, начав с чтения потенциально бесконечного ввода символов в стек, и очевидно признав, что без стека возвратов рекурсия все-таки невозможна, Forth начал плодить, в дополнение к ним, "свои" стеки - словаря, контекстов и т.д.
Это я к чему? К тому, что собственно "стековые вычисления" - всякие DUP и SWAP - чистая условность, а не особенность Forth. Гораздо важнее "другие" стеки. А "вычислительная" часть может работать и без них. В языке P стеков вообще может не быть.

AXT> Ммм... тут очень тонкая разница, но ИМХО она таки есть. Java может быть

Между Java и JVM — отнюдь не тонкая разница

Gudleifr> Это я к чему? К тому, что собственно "стековые вычисления" - всякие DUP и SWAP - чистая условность, а не особенность Forth. Гораздо важнее "другие" стеки. А "вычислительная" часть может работать и без них. В языке P стеков вообще может не быть.

Forth это то ради чего его используют. Может, кто-то его использует ради DUP и SWAP .
Я бы хотел его видеть в качестве операционной системы для поддержки языков типа P.
Но кто эти языки будет создавать? А если создать. кто будет использовать?
При том, что фортеров мало и у каждого свои тараканы в голове.
Экономическая проблема Форта давно переросла в историческую.

mak44> Но кто эти языки будет создавать?
Создание P (и, как частный случай - путем написания F) может быть невыгодно:
1. Когда "пользовательский язык" трудно формализуем. Как свести к языку оконно-визуальный беспредел?
2. Когда P - "типовой". Берем типовое решение, добавляем типовой интерфейс - и готово? Какой-такой язык?
3. Когда P легко создать другими методами. Например, не вижу ниши для Forth под Linux. В среде, где автоматизировано даже написание компиляторов и без него тесно.

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

mak44>> Но кто эти языки будет создавать?
Gudleifr> Создание P (и, как частный случай - путем написания F) может быть невыгодно:
Gudleifr> 1. Когда "пользовательский язык" трудно формализуем. Как свести к языку оконно-визуальный беспредел?
Нельзя производить навигацию текста F без ограничений на использование спец меток
выделенных для навигации. Т.к. F не язык (не имеет определенного синтаксиса).
P может иметь жесткий синтаксис удобный для визуального средства.
Генерировать с помощью визуального средства можно хоть F хоть P хоть шитый код.

Gudleifr> 2. Когда P - "типовой". Берем типовое решение, добавляем типовой интерфейс - и готово? Какой-такой язык?
Gudleifr> 3. Когда P легко создать другими методами.
Это исторические причины т.е. вторичные.

Gudleifr> Поэтому мне более перспективным (в пропагандистских целях) кажется внедрение Forth-методов в "обычные" языки.
Под Forth-методами, я понимаю предоставление пользователю вмешиваться в процесс работы
интерпретатора (компилятора) . Для этого он должен иметь простое устройство.
Производителю инструментальных средств не выгодно предоставлять возможности,
шире изложенных в спецификации. Ему выгодно держать пользователей в зависимости.

mak44> Нельзя производить навигацию текста F без ограничений на использование спец меток
mak44> выделенных для навигации. Т.к. F не язык (не имеет определенного синтаксиса).
А при чем здесь загадочная "навигация текста"?
mak44> P может иметь жесткий синтаксис удобный для визуального средства.
Трудности представляет обратный процесс.
mak44> Генерировать с помощью визуального средства можно хоть F хоть P хоть шитый код.
Если одинаково легко генерировать F и P, то F не нужен.
mak44> Это исторические причины т.е. вторичные.
Что значит "вторичная причина"?
mak44> Под Forth-методами, я понимаю предоставление пользователю вмешиваться в процесс работы
mak44> интерпретатора (компилятора) .
Это, как раз, вторично. Важно: зачем это делается?
mak44> Производителю инструментальных средств не выгодно предоставлять возможности,
mak44> шире изложенных в спецификации.
Причина описана еще Муром: переложить ответственность за порядок действий и обработку ошибок на пользователя. Все визуальные интерфейсы этим, в общем-то, и занимаются...

Gudleifr> А при чем здесь загадочная "навигация текста"?
Например, обработка некого события это фрагмент текста в программе. Его надо найти.
Для этого в программе должны быть ориентиры.

Gudleifr> Если одинаково легко генерировать F и P, то F не нужен.
Не важно, какого рода текст генерируется. Проблема в том, чтобы он попал в нужное место.

mak44>> Это исторические причины т.е. вторичные.
Gudleifr> Что значит "вторичная причина"?
Вторичные по времени т.е. следствие. Выражается в том. что под Форт мало чего можно
найти включая : средства разработки, наработки, литературу.

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

визуальные интерфейсы это только форма общения. Занимаются тем-же что и любые другие
виды интерфейсов.

Gmak44> Например, обработка некого события это фрагмент текста в программе. Его надо найти.
mak44> Для этого в программе должны быть ориентиры.
Понял. В последнее время пришел к идее "вторичной Forth-машины" - наличия в Forth-системе не одного ядра "интерпретации", а нескольких. И поток внешних событий - "нормальный поток" для интерпретации, только вместо слов, разделенных пробелами - например, четверки msg-wnd-wpar-lpar (Windows).

С остальным примерно согласен. Но Forth на то и Forth, что позволяет некоторые вещи сделать проще. Т.е. сэкономить время разработчика.

Gudleifr> поток внешних событий - "нормальный поток" для интерпретации, только вместо слов, разделенных пробелами - например, четверки msg-wnd-wpar-lpar (Windows).

Что-то вроде nncron ?
GUI для SPF http://spf.cvs.sf.net/viewvc/spf/lib/win/spfgui/spfgui.f

Gudleifr> Но Forth на то и Forth, что позволяет некоторые вещи сделать проще. Т.е. сэкономить время разработчика.
Нынче, с временем разработчика не особо считаются. Основное время уходит на
разного рода согласования и оформление документации.

mak44> Что-то вроде ?
Нет.
1. Никакой многозадачности для этого не нужно. То, что для одной машины интерпретатор, для другой - просто слово.
2. И никаких убогих CASE. Честный набор EXCEPT', WORD', FIND', NUMBER'... в добавление к обычным EXCEPT, WORD, FIND, NUMBER...

Народ не просто не понимает "зачем нужен Forth", но и не знает его изначальных идей.
На "единственном российском Forth-ресурсе", например, новостью стали старые "заметки на полях" Мура: colorforth.com/binding.html. Если бы не на английском, наверное стали бы обсуждать.

mak44> Forth это то ради чего его используют. Может, кто-то его использует ради DUP и SWAP .
mak44> Я бы хотел его видеть в качестве операционной системы для поддержки языков типа P.
mak44> Но кто эти языки будет создавать? А если создать. кто будет использовать?
Разработка любой операционной системы начинается с ответа на вопрос "Зачем?" Если, конечно, это не попытка самоутверждения. Нельзя забывать и о том, что сама по себе операционная система никому не нужна. Итак?
Полный контроль над A средствами F стал возможен сравнительно недавно - когда пали границы сегментов и появился 64-битный Long Mode x86-64, а также UEFI, предельно упрощающий загрузку.
Интерпретация намного эффективнее разграничивает доступ, чем прямое управление памятью. Идея операционной системы с двойной интерпретацией (F и P) мне нравится. Хотелось бы услышать предложения относительно P.

Gudleifr> Создание P (и, как частный случай - путем написания F) может быть невыгодно:
Gudleifr> 1. Когда "пользовательский язык" трудно формализуем. Как свести к языку оконно-визуальный беспредел?
Если функции P основаны на абстрактном оконном интерфейсе, то есть на самом P, беспредел неизбежен.
Если же функции P основаны на A, то это не проблема - OpenGL, возвращающую трёхмерные координаты щелчка мыши по объекту, никто не отменял.

Veden12> Если функции P основаны на ... на самом P...
Veden12> Если же функции P основаны на A...
Совершенно не понял.

AXT>>> где тут Форт вообще?
Balancer>> JVM — стековая машина.
AXT> Ммм... та с Фортом дело обстоит не так — язык заточен строго под стековую машину.

Программка на Форте, которая делает Форт регистровым и заодно избавляет от польской записи занимает примерно 20 строк...+еще 10 строк и ты получаешь еще и встроенный ассемблер

P.S. В процессоре пикоДжава это реализовали еще и аппаратно При помощи "зацепления команд" - верхние 64 слов стека еще и регистры с произвольным доступом.

Veden12>> Если функции P основаны на ... на самом P...
Veden12>> Если же функции P основаны на A...
Gudleifr> Совершенно не понял.
Утилизируя Win32 и GTK, действительно сложно получить адекватный строгий оконный API. Сегодня вместо абстрактных оконных систем всё чаще используют оригинальные интерфейсы на OpenGL. Саму OpenGL уже можно интегрировать с языком прикладного уровня, написанном на Форте. Впрочем, можно пойти дальше. В последних разработках я использую CEGUI, что даёт под OpenGL (и не только) в высшей степени гибкие виджеты. Если не зацикливаться на ООП, логика этой библиотеки хорошо ложится на идеологию Форта. Вот это уже вполне реализуемо. И при этом нет места "оконно-визуальному беспределу".

Мне интересно Ваше представление о пользовательском языке. Каким он должен быть? Если не подстраивать его под существующую операционную систему, а наоборот, учить Форт-систему (она же ОС) лексикону этого языка.

Veden12> Утилизируя Win32 и GTK, действительно сложно получить адекватный строгий оконный API.
Что значит "строгий"? Строго соответствующий изначальному стандарту CUA? Его удачным ОО-реализациям? Модели Раскина? ... Чему-то вроде моей комнатной модели?
Veden12> И при этом нет места "оконно-визуальному беспределу".
"Беспредел" я понимаю следующим образом. Вместо выбора некоего "языка общения" пользователя и программы, программист честно пытается предвосхитить все возможные телодвижения пользователя при виде диалогового окна более-менее стандартного вида. Т.к. окна действительно стандартные, то практически все возможные реакции пользователя уже предусмотрены "визуальными обезьянниками". Так что, задача вполне разрешима (хотя от результата очень часто тошнит, о чем Раскин очень хорошо написал).
Veden12> Мне интересно Ваше представление о пользовательском языке.
Пользовательский язык (по Муру) - это отказ программиста от упомянутого предвосхищения в пользу требования от пользователя самому решать, что и как он хочет посчитать.
Как программист, чаще сталкиваюсь с другой стороной P. Задача бывает столь сложна, что ее сам-то понимаешь только тогда, когда придумаешь язык, на котором ее можно описать.

Veden12>> Утилизируя Win32 и GTK, действительно сложно получить адекватный строгий оконный API.
Gudleifr> Что значит "строгий"? Строго соответствующий изначальному стандарту CUA? Его удачным ОО-реализациям? Модели Раскина? ... Чему-то вроде моей комнатной модели?
На практике склоняюсь к последним двум. Но в принципе это откосится ко всему перечисленному. Я к тому, что реализация, к сожалению, не всегда даёт ожидаемое поведение. Бывает, и заплаток недостаточно.
Veden12>> Мне интересно Ваше представление о пользовательском языке.
Gudleifr> Пользовательский язык (по Муру) - это отказ программиста от упомянутого предвосхищения в пользу требования от пользователя самому решать, что и как он хочет посчитать.
Gudleifr> Как программист, чаще сталкиваюсь с другой стороной P. Задача бывает столь сложна, что ее сам-то понимаешь только тогда, когда придумаешь язык, на котором ее можно описать.
Компьютер используется как средство общения и моделирования. "Пользователь не должен знать, что у него есть операционная система" (тот же Раскин). Пользовательский язык определяет удобство и гибкость решения этих задач. Полный 100% отказ от предвосхищения оставляет человека перед голым железом. Столь же полное предвосхищение исключает участие человека в процессе (вспомним Лема). Где золотая середина? Достижима ли она скриптовым языком или иным способом?

Veden12> Я к тому, что реализация, к сожалению, не всегда даёт ожидаемое поведение.
Мы говорим о программах вообще или об интерфейсах человек-машина?
В последнем случае мне кажется правильным писать программу как можно "отдельнее" от интерфейса.
Самопроцитируюсь:
"Программа - организм. Смысловая часть - генотип. Принятые в твоей конторе оформительские соглашения - ограничения фенотипа. Зародыш развивается, заполняя своей биомассой структуру оконных форм (может - консоль, может - MDI). Гены лишь определяют ветвление в судьбоносные для зародыша моменты. Фенотип может быть представлен таблицей всех параметров всех окон, может списком отклонений стиля каждого окна от стандартного, может описанием совсем уж аппаратно-независимого дисплея.
Главное - минимум универсальности и максимум удобства".
Veden12> Где золотая середина?
Мур категоричен: основной принцип - простота. (Правда, назвать его сегодняшние эксперименты с цветом и Forth-процессорами "упрощающими жизнь" язык не поворачивается).

Gudleifr> Главное - минимум универсальности и максимум удобства".
Всё верно. Для решения поставленной задачи удобство должно быть на первом месте, универсальность - зло. Ещё большее зло - поставленные сроки. Люди всё больше понимают программирование как сборку из готовых компонентов.

Но как быть с мета-программой? То есть, с программированием метасистемы? Допустимо ли изменение её поведения средствами самой метасистемы (какими?) или это исключительно функции образующих её детерминированных систем?

Veden12>> Где золотая середина?
Gudleifr> Мур категоричен: основной принцип - простота.
Мур прав. Но он говорит только о целевом программировании. Метапрограммирование не так однозначно.
Gudleifr> (Правда, назвать его сегодняшние эксперименты с цветом и Forth-процессорами "упрощающими жизнь" язык не поворачивается).
Ну почему же? GA144 способен облегчить жизнь всем, кроме программиста. У нас нет приемлемых математических моделей для эффективного программирования матричных сложноподчинённых процессоров, не говоря уже о сложноподчинённых матрицах, набранных из таких процессоров. Или это только мне так кажется?

Veden12> Но как быть с мета-программой? То есть, с программированием метасистемы? Допустимо ли изменение её поведения средствами самой метасистемы (какими?) или это исключительно функции образующих её детерминированных систем?
Veden12> Метапрограммирование не так однозначно.
Опять ничего не понимаю. Что такое "метасистема": сложная система, система создания систем, заготовка системы?

Veden12>> Но как быть с мета-программой? То есть, с программированием метасистемы? Допустимо ли изменение её поведения средствами самой метасистемы (какими?) или это исключительно функции образующих её детерминированных систем?
Veden12>> Метапрограммирование не так однозначно.
Gudleifr> Опять ничего не понимаю. Что такое "метасистема": сложная система, система создания систем, заготовка системы?
Система, состоящая из управляющей подсистемы и управляемых ею многих однородных подсистем - метасистема по отношению к управляемым подсистемам (по Турчину). В данном контексте роль подсистем выполняют программы, решающие отдельные задачи. Ни Раскин, ни Мур не рассматривают управление в рамках метасистемы (не обязательно операционной системы, управляющей подсистемой может быть и скрипт пользователя, мета-программа). Никак не взаимодействующие в смысле визуализации и обмена данными программы могут быть написаны целиком на Форте. Но для управляемого взаимодействия удобен соответствующий язык более высокого уровня.

Veden12> по Турчину
Почитать, что ли?
Veden12> управление в рамках метасистемы (не обязательно операционной системы, управляющей подсистемой может быть и скрипт пользователя, мета-программа).
Ну, во-первых, об управлении тут речь не идет. (Первый признак управления - сложность управлятора, большая сложности управляемого). Операционные системы лишь снабжают программы ресурсами, а скрипты - лишь передают управление (удачный термин) то одной, то другой.
Во-вторых, если наш "управлятор" все-таки желает взаимодействовать с подлыми программами, то чем последние отличаются от пользователя? И Forth-решение - язык интерфейса - тут работало еще когда и Forth не было - тот же язык системных вызовов. Forth - это, если угодно, попытка поставить пользователя в один ряд с программами и устройствами.
Допустим, наша DOS-программа активно использует вызов системы - INT 21h. Имея дело с большими объемами файловых операций, программист группирует DOS-вызовы в нужные ему подпрограммы: обновить содержимое файла, загрузить файл конфигурации и т.п... Forth тоже дает пользователю лишь набор примитивных операций и предлагает самому сгруппировать их в что-то полезное.