Что не хватает Форту?

mak44> В качестве JVM может выступать форт-машина (тем самым мы избавились от лишней сущности). Своего рода JIT - компиляция.
Это единственный способ получить нечто, не уступающее обычной JVM. Но почему Вы при этом утверждаете, что "писать ничего не придётся"? По-моему, ещё как придётся.
mak44> Например, словарь форта или шитый код можно использовать в качестве прикладной базы данных.
Почему бы и нет? Если как следует оптимизировать по времени, добавляя где нужно CODE, этому ничто не мешает.
Veden12>> Признаться, меня коробят CATCH-THROW
mak44> Это перехват исключительных ситуаций.
Понимаю, но не могу избавится от мысли, что есть более элегантное решение. Это строго субъективно, конечно же.

Veden12> 1. ... Для других (как для меня) Форт - язык вне уровней...
Кроме этого вечного самооправдания, есть и объективные особенности. К тому же, FORTH - не язык.

Veden12> Думаю, тут комментарии излишни.
Наоборот. Если Вы сформулируете это "различие" явно, будет полезно.

Veden12> Кто прав?
Прав Дейкстра.

Veden12> читать будет некому...
Найдутся...

Gudleifr> Кроме этого вечного самооправдания, есть и объективные особенности. К тому же, FORTH - не язык.
То, что ключевой является Форт-концепция, я понимаю. Но почему "не язык"?

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

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

Gudleifr> Прав Дейкстра.
Да, безусловно.

Veden12>> читать будет некому...
Gudleifr> Найдутся...
Столкнувшись с ассемблерными кодами Z80 многие придут в уныние. Вы не согласны с этим?

Veden12> То, что ключевой является Форт-концепция, я понимаю.
Не только. Еще пара-другая концепций втихаря работают, но сформулировать их достаточно сложно. Например, общая концепция интерпретации. Единство символа и кода...

Veden12> Но почему "не язык"?
Ну, как бы, как язык он не работает по двум причинам: не имеет грамматики и не существует в окончательной форме.

Veden12> Я про тех, для кого "оптимизация кода" - не пустой звук.
Ну, не знаю, C, пожалуй, с этих позиций повыгоднее смотрится. Впрочем, я уже писал, что с другими видами оптимизации, кроме ликвидации узких мест, не сталкивался. Наверное, после определения Хоаром "бутылочного горлышка", тут особо ловить нечего.

Veden12> Столкнувшись с ассемблерными кодами Z80 многие придут в уныние.
Коды, они и в Африке - коды... Z80 не хуже и не лучше прочих. Сам Кнут примеры в кодах приводил...

Gudleifr>> Найдутся...
Veden12> Столкнувшись с ассемблерными кодами Z80 многие придут в уныние. Вы не согласны с этим?
Некоторые Статьи Родригеса с кодами Z80 "Как создать ассемблер.." уже имеют перевод и размещены в разделе статей Статьи Форт тематики

Gudleifr> Еще пара-другая концепций втихаря работают, но сформулировать их достаточно сложно. Например, общая концепция интерпретации. Единство символа и кода...
Это интересно. Обычно видно лишь то, что на поверхности, интегральный результат.
Veden12>> Но почему "не язык"?
Gudleifr> Ну, как бы, как язык он не работает по двум причинам: не имеет грамматики и не существует в окончательной форме.
Есть и другие расширяемые языки: Tcl, Lua и т.д.
Здесь исходник - единая строка с разделителями-пробелами. Или это как раз не регламентировано?

Veden12>> Я про тех, для кого "оптимизация кода" - не пустой звук.
Gudleifr> Ну, не знаю, C, пожалуй, с этих позиций повыгоднее смотрится.
Спорный момент, к тому же зависящий от решаемой задачи. Компилирующие в код языки хороши на вычислительных задачах (под них и создавались), а вот логика принятия решения - совсем другое дело, локальная оптимизация там бессмысленна.
Gudleifr> Впрочем, я уже писал, что с другими видами оптимизации, кроме ликвидации узких мест, не сталкивался. Наверное, после определения Хоаром "бутылочного горлышка", тут особо ловить нечего.
Обязательно почитаю про это. Обычно я рассматриваю три направления оптимизации: классические "время-объём" и сколько времени нужно на переработку при изменении начальных условий.

Gudleifr> Коды, они и в Африке - коды... Z80 не хуже и не лучше прочих. Сам Кнут примеры в кодах приводил...
Спасибо за поддержку. Закончу вторую главу (всего их восемь) - выложу на страничку.

Veden12>> Столкнувшись с ассемблерными кодами Z80 многие придут в уныние. Вы не согласны с этим?
Kopa> Некоторые Статьи Родригеса с кодами Z80 "Как создать ассемблер.." уже имеют перевод и размещены в разделе статей
Да, действительно. Самое главное - есть перевод его "Moving Forth". И очень качественный. Попробую на досуге перевести Лёлигера. Книга - не статья. На это нужно время...

Veden12> Есть и другие расширяемые языки: Tcl, Lua и т.д.
Veden12> Здесь исходник - единая строка с разделителями-пробелами. Или это как раз не регламентировано?
Да все языки расширяемые...
Здесь минимум два нюанса:
1. Большинство языков, становясь полезными, приобретают грамматику. Программист использует обороты (например, TO value) и предложения (например, IF ... THEN). Но FORTH на это наплевать. Он ни об оборотах, ни о предложениях ничего не знает.
2. Т.к. описывать сам язык в случае FORTH бессмысленно, то описывается сам механизм реализации этого языка. И, опять, будет ли программист использовать этот механизм для реализации чистого FORTH или для чего-нибудь другого, FORTH-у плевать.

Veden12> Спорный момент, к тому же зависящий от решаемой задачи. Компилирующие в код языки хороши на вычислительных задачах (под них и создавались), а вот логика принятия решения - совсем другое дело, локальная оптимизация там бессмысленна.
Если решения принимает машина, то пространство решений - тоже множество, и оптимизировать работу с ним надо на общих основаниях. Если же речь идет о принятии решения оператором, то все зависит от языка управления (а на чем этот язык реализовывать - дело десятое).
(Я однажды видел большой проект, написанный на Питоне именно из этих соображений - интерактивности и гибкости. Но все свелось к куче фантиков, завернутых в другие фантики).

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

Gudleifr> Берешь диск с (ОС-зависимым) инсталлятором и ставишь, ни разу не задав себе вопрос, на каком языке написана ОС... Не Java-ОС, и не BASIC-ОС, и не FORTH-ОС, а просто ОС, на которую (в силу наличия у нее свойств ОС) можно хоть Питон, хоть Эрланг ставить...
Из-за неуклюжести данной организации разработок ПО, концепция черного ящика не доведена
до логического завершения. Программист Питона ничего не должен знать о существовании ОС.
Все что нужно, ему может быть предоставлено в виде процедур Питона.
Форт нужен тому, кот хочет выйти за рамки конкретного языка.

mak44>> Например, словарь форта или шитый код можно использовать в качестве прикладной базы данных.
Gudleifr> С тем же успехом можно использовать и наскальные рисунки.

: TYPEMYSELF CREATE LAST @ , DOES> @ ID. ;

: TRANSLATE:
TYPEMYSELF LAST @ NAME>C @ >BODY
TYPEMYSELF LAST @ NAME>C @ >BODY
OVER @ OVER @ SWAP
ROT ! SWAP !
;
\ англо-русский словарь
TRANSLATE: ПРИВЕТ HELLO
TRANSLATE: ЛЮБОВЬ LOVE

Частное мнение с частного сайта Почему обречён язык Форт
Одна из мыслей - почти нет видимого значимого софта сделанного на Форт для создания чего в итоге и предназначены языки программирования кто бы что об этом ни говорил.

mak44> Можно всю Java с JVM представить в ассемблерном виде и скормить Форту.
mak44> Про бинарники я ничего не говорил.
???

mak44> его следует расположить в области форта
Если у нас FORTH-ОС, то очевидно "область FORTH" - весь компьютер (вся сеть).

mak44> Программист Питона ничего не должен знать о существовании ОС.
Программист Питона, к сожалению, ничего не знает даже об устройстве Питона (проверял!).
Но если Вы оперируете термином Язык-ОС, то очевидно, что ОС описывается средствами языка. Например, в старых микро-ЭВМ, ориентированных на BASIC (до IBM AT включительно), BASIC имел возможность доступа практически ко всем нужным пользователю средствам ОС, имел возможность встраивания фрагментов кода, были документированы входные точки BASIC-процедур и порты, управляющие железом.

mak44> Форт нужен тому, кот хочет выйти за рамки конкретного языка.
???
Как бы любая ОС позволяет грузить компиляторы/интерпретаторы любых языков.

mak44> : TYPEMYSELF CREATE LAST @ , DOES> @ ID. ;
Это и есть, практически, наскальная живопись. Фокус, показывающий возможности компилирующих слов, но никак не применимый практически. Как только Вы начнете создавать нормальную БД, проблемы выбора подходящего языка отойдут на второй план.

Gudleifr> Т.к. описывать сам язык в случае FORTH бессмысленно, то описывается сам механизм реализации этого языка.
Да, концепция Форта вовсе не определяет язык как таковой. Но разве стандарты Форта - заявленные или порождаемые де-факто любой реализованной Форт-системой - не описывают язык (каждый свой, правда)? Мне кажется, под Фортом чаще понимают эту группу языков, чем метод.
В отличие от формальных стандартов, реализации, как правило, позволяют использовать IF вместо WHILE и наоборот, но EXIT внутри цикла DO скорее всего будет фатальным.
Gudleifr> Если решения принимает машина, то пространство решений - тоже множество, и оптимизировать работу с ним надо на общих основаниях.
Я про автоматы. После формального доказательства отсутствия замкнутых путей принятия решения остаётся широкое поле для оптимизации.

Kopa> Частное мнение с частного сайта "Почему обречён язык Форт"
Похоже, целью статьи является не оценка языка Форт, а продвижение языка Фактор.
То, что автор не упомянул про GA144 c ColorForth, мне не кажется случайностью.
Что до проблем Форта, то я вижу всего три: нет документации для программирования железа, практика выдачи исходников Linux за свои и повальное обучение объектно-ориентированному подходу.

Veden12> Но разве стандарты Форта - заявленные или порождаемые де-факто любой реализованной Форт-системой - не описывают язык (каждый свой, правда)?
В том-то и дело: "стандарт" и "каждый свой" - это две большие разницы. Имеет смысл стандартизировать либо выше (алгоритмы, проекты), либо ниже (уровни разработки/целевой компиляции, основные структуры/процедуры).
(Я даже картинку нарисовал - основные части FORTH-подобных интерпретаторов:


Veden12> В отличие от формальных стандартов, реализации, как правило, позволяют использовать IF вместо WHILE и наоборот, но EXIT внутри цикла DO скорее всего будет фатальным.
Если бы подобные "лингвистические" рассуждения имели смысл, FORTH был бы языком. А так - в ANSI-94 увидели что EXIT в DO не работает и зафигачили UNLOOP... А кто-то любит THEN; и IF*... А FORTH - плевать, хоть уизобретайтесь...

Veden12> Я про автоматы.
А в чем там проблема? Выбрать нужный автомат, оптимизировать переключатель состояний (работу с магазином)...

Kopa> Частное мнение с частного сайта
См. топикстартер темы "Непонимание".

Kopa> почти нет видимого значимого софта сделанного на Форт
А для других языков есть? Кто-нибудь знает много программ, написанных на C?
(Нет, их, конечно, миллионы, но помним-то мы обычно только одну-две любимых).
Обычный ответ на вопрос: "На чем это написано?" - "Ну мы взяли за основу, добавили и переделали... Получился новый язык, на котором..."
С другой строны, для простых программ, мы чаще говорим не "на языке", а "в среде": Delphi, Visual...

Kopa>> Частное мнение с частного сайта
Gudleifr> См. топикстартер темы "Непонимание".
Я не дискутирую с Вами т.к. непонимаю цель Ваших высказываний и суждений в данном топике

P.S. Форт такой какой он есть и принимать и понимать его парадигмы может каждый его пользователь в силу своих способностей.

Gudleifr> В том-то и дело: "стандарт" и "каждый свой" - это две большие разницы. Имеет смысл стандартизировать либо выше (алгоритмы, проекты), либо ниже (уровни разработки/целевой компиляции, основные структуры/процедуры).
Тогда, видимо, языками следует считать FORTH-83, FORTH-94,..
Если я напишу несколько строк на FORTH-83, уверен, Вы поймёте меня без объяснений.

Veden12>> Я про автоматы.
Gudleifr> А в чем там проблема? Выбрать нужный автомат, оптимизировать переключатель состояний (работу с магазином)...
Оптимизация велась сразу на нескольких уровнях абстракции. Но сейчас есть радикальное решение - более мощный процессор. Впрочем, к Форту это уже не имеет отношения.

Есть ещё один вопрос. Вы как-то писали, что Форту не нужен CASE. Почему?

Veden12> Если я напишу несколько строк на FORTH-83, уверен, Вы поймёте меня без объяснений.
Понять-то, Вас поймут... Но число матюгов, сложенных на любой FORTH-стандарт (не мной), огромно.
Важнее другое - "в чистом" стандарте никто не пишет. Попробуйте найти в прямом шитом коде замену идентификации типа слова по его CALL-адресу, применяемой в косвенном шитом коде. А теперь - найти и переделать в чужой программе места, где этот механизм применяется. А теперь - найти в программе другие непереносимые трюки...

Veden12> Есть ещё один вопрос. Вы как-то писали, что Форту не нужен CASE. Почему?
1. Нормальным размером определения в FORTH исторически считается одна-две строчки. CASE просто не помещается.
2. Со времен Windows-программирования на Си осталось чувство радости: оконная функция для CASE на все виды сообщений, занимающая несколько страниц, вдруг съежилась до коротенькой таблички указателей и маленьких обособленных смысловых фрагментиков. Уже потом прочел у Броуди: старайся вычислить; не получилось - построй таблицу; только, если не вышло ни так, ни так, вставляй IF-ы. Придумать невычислимый и не табулируемый CASE очень трудно.
3. FORTH уже имеет готовую CASE-структуру почти на все случаи: словарь.
4. CASE обычно приводит к очень нелюбимой мной конструкции - множеству почти одинаковых строк. Жутко смотрится и служит источником множества ошибок.

Gudleifr> Если у нас FORTH-ОС, то очевидно "область FORTH" - весь компьютер (вся сеть).
Если Форт в ядре ОС от весь компьютер. Для непривилегированных пользователей
предоставляется виртуальная машина с логическим адресным пространством.
Форт-системы во всех виртуальных машинах могут разделять одну библиотеку подпрограмм.
Это несколько экономит память. А главное, облегчает изучение системы.

Gudleifr> Как бы любая ОС позволяет грузить компиляторы/интерпретаторы любых языков.
Вопрос в интерфейсе меду этими интерпретаторами. В технологии Форта - взаимодействие
осуществляется через единое адресное пространство. Система должна быть многоуровневая.
Интерпретатор типа Питон - самый высокий уровень. В основном, программист
пользуется высоким уровнем. В исключительных случаях, спускается на нижний уровень.
Уровень Форта - самый нижний уровень.

mak44> ...
Я понимаю, что этакая вавилонская башня позволит делать бабло из воздуха (на проблеме совместимости, например), но может ли она что-то дать в плане возможностей программирования?

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

Gudleifr> А теперь - найти в программе другие непереносимые трюки...
По-правде, я знаю лишь один язык, где их нет - это Ада.
Я верно Вас понял, что Форт сложно считать языком потому что все реализации имеют слишком серьёзные отличия друг от друга? Значительно большие, чем в любых языках?

Gudleifr> если не вышло ни так, ни так, вставляй IF-ы.
CASE в Форте всего лишь прячет их THEN...THEN
Gudleifr> Жутко смотрится и служит источником множества ошибок.
Компилятор Си всегда сам строит таблицу адресов. На Форте это должен делать программист. Вы правы, велика вероятность такого же бездумного использования CASE, как на Си.

mak44> Если Форт в ядре ОС от весь компьютер.
Форт в качестве ОС - интересная задача. К сожалению, чётко формализовать такую постоянно развиваемую по всем направлениям систему вряд ли получится. Как без этого создать грамотные, хорошо продуманные API и интерфейсы пользователя (удобные для человека, по Раскину)?

Veden12> Я верно Вас понял, что Форт сложно считать языком потому что все реализации имеют слишком серьёзные отличия друг от друга? Значительно большие, чем в любых языках?
Я бы сказал по-другому. FORTH позволяет вносить серьезные различия в свои реализации. Это его полезное свойство, которого нет в других языках.

Допустим, мы описываем решение задачи в виде алгоритма на ALGOL-60 (раньше так и делали). Понятно, что любая неточность в соблюдении стандарта вызвала бы непонимание и могла бы привести к двусмысленностям и ошибкам.
А теперь, мы будем объяснять то же человеческим языком. Всех тонкостей передать не удастся даже при использовании немецкого языка. Зато, основную идею, весьма возможно, удастся описать буквально в двух словах. Образно и доходчиво.
(В книге Ахо, Хопкрофта и Ульмана можно посмотреть на правильное дозирование алгоритмического и английского языков. Или - у Кнута в его Литературном Программировании).
Так вот, FORTH позволяет обойтись без этого. Он позволяет комбинировать человеческие и машинные описания в пределах своего языка. Причем, то, что не относится к решению данной задачи, можно просто не реализовать.

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

7 bricks: LBDBR LBRR DBRR LBRD RDL LBDR RBDL

У какого фортера возникнет проблема в создании слов L R U D B и простенького интерпретатора строк из них? Зачем мне навязывать свое решение, которое, может быть, легко ложится на мою реализациию, но тяжело на вашу?

Конечно, хочется взять чужую прогу и без проблем засунуть в свой компьютер. Но если прога не может быть больше 100 строк, то, может быть, набить ее самому? Более того, это позволит обмениваться прогами просто в журнальных статьях. А сложные программы? Во-первых, дружественная ОС может намного их укоротить (Ведь, в том же Windows большая часть программного кода носит чисто ритуальный характер. Вместо "выйди по Esc" мы пишем "обрабатывая сообщения, в случае, если это сообщение о нажатии на клавишу с кодом Esc, освободи следующие ресурсы... и пошли следующие сообщения..."). А, во-вторых, регулярный обмен FORTH-идеями должен привести к накоплению своих реализаций полезных общих решений, на которые вполне можно ссылаться в дальнейшем.

На рускоязычном Форт форуме проводится опрос возрастной категории участников форума

Вопрос темы: Что не хватает Форту?
Ответ:
Kopa> проводится опрос возрастной категории участников форума
Браво!