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

Информация к размышлению.
Повторю рисунок:

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

Gudleifr> Стек накапливает "символы"...
Да, тут есть о чём подумать.

Gudleifr> Как бы, обычно все приложения с исходниками так и выкладываются.
То есть, речь идёт об исходниках на ассемблере?

Gudleifr> "организовать раздачу работающих программных иллюстраций к моей страничке в условиях ограничений хостинга"
Интересно. Как это должно выглядеть?
Gudleifr> "организовать удобный программистский интерфейс к Win-API".
Зачем здесь WinAPI? Чем плохо реализовать на скриптовом языке вроде JavaScript виртуальный процессор, подходящий для демонстрации?
Gudleifr> А когда "удобного интерфейса" сразу не получилось,...
Проблемой был дизайн или техническая сторона дела?

Veden12> То есть, речь идёт об исходниках на ассемблере?
Ядра - да. Остальное - уже на FORTH.

Veden12> Интересно. Как это должно выглядеть?
Примерно так же, как и примеры на CGI, только без перегрузки трафика и с чуть большей интерактивностью. Нет, конечно, ДОЛЖНЫ они выглядеть гораздо красивее, но будут ли?

Veden12> Зачем здесь WinAPI?
Он есть у всех. Я не хочу заморачиваться изучением вещей, усложняющих жизнь.
К тому же, как я и писал, "Win-API" очень быстро превратился в самоцель.

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

Veden12>> Интересно. Как это должно выглядеть?
Gudleifr> Примерно так же, как и примеры на CGI, только без перегрузки трафика и с чуть большей интерактивностью. Нет, конечно, ДОЛЖНЫ они выглядеть гораздо красивее, но будут ли?
Подозреваю, что визуальные компоненты WinAPI сегодня едва ли будут привлекательны для посетителя. А вот средствами DHTML вполне можно вылепить концептуальный дизайн, придав смысловую нагрузку каждому цвету, форме. Конечно, трафик будет больше, но сомневаюсь, что это всё ещё настолько значимо.

Veden12>> Зачем здесь WinAPI?
Gudleifr> Он есть у всех. Я не хочу заморачиваться изучением вещей, усложняющих жизнь.
Сегодня люди всё чаще ходят в интернет с планшетов. А там, как правило, Андроид. И среди этих людей куда больше желающих необычного, чем среди пользователей MS Windows (признаться, не знаю ни одного пользователя Windows8).

Gudleifr> Основной проблемой, видимо, является отделение смысловой составляющей интерфейса от украшательной и ритуальной.
Мне кажется, эти две стороны интерфейса должны дополнять и усиливать друг друга.

Veden12> А вот средствами DHTML вполне можно вылепить концептуальный дизайн, придав смысловую нагрузку каждому цвету, форме.
Veden12> Сегодня люди всё чаще ходят в интернет с планшетов.
Veden12> Мне кажется, эти две стороны интерфейса должны дополнять и усиливать друг друга.
Сверхзадача: отделить генотип (смысл) интерфейса от фенотипа (визуального представления). Т.е. программист пишет ОТВЕТИТЬ, а уже интерфейс с конкретным API (настроенный главредом) создает окно и Controls (Win) или выбирает нужное выравнивание (Tcl/Tk), или обвешивает тегами (HTML)...

Gudleifr> Сверхзадача: отделить генотип (смысл) интерфейса от фенотипа (визуального представления). Т.е. программист пишет ОТВЕТИТЬ, а уже интерфейс с конкретным API (настроенный главредом) создает окно и Controls (Win) или выбирает нужное выравнивание (Tcl/Tk), или обвешивает тегами (HTML)...
Подозреваю, что большинство программистов шокирует мысль, что слово ОТВЕТИТЬ можно набрать на клавиатуре, а не нажать мышкой или ткнуть пальцем в означенную надпись. Но главное, есть уже привычный инструментарий для выполнения подобных действий. Кто по доброй воле откажется от привычных Visual Studio, Word/Excel?
А вот программы, способные поддерживать диалог, имитируя человека (psysop), будут интересны и сегодня. Наследие LISP'а малоизвестно. На Си/Java реализовать такое затруднительно. Если продемонстрировать способность Форта к обучению, то эта его сторона вполне может оказаться привлекательной.

Veden12> А вот программы, способные поддерживать диалог, имитируя человека (psysop), будут интересны и сегодня. Наследие LISP'а малоизвестно. На Си/Java реализовать такое затруднительно. Если продемонстрировать способность Форта к обучению, то эта его сторона вполне может оказаться привлекательной.
AI Mind in Forth Что то подобное? Или как задачу "создание" эвристического переводчика на основе базиса сравнения, анализа и выстраивания эвристик трансляции например на анализе двуязычных вариантах текстов (одного содержания) Реально или нет без углубленного изучения лингвистики сделать такое - непонятно.

Veden12> Подозреваю, что большинство программистов...
Kopa> Что то подобное?..
Преимущество FORTH (как и любого другого) не может состоять в том, чтобы сделать то, что другие не могут. За исключением подробностей реализации, они все в общем смысле эквивалентны.
Вопрос только в том, чтобы сделать "проще" и/или "красивее".
Если я спрашиваю как доходчивее и единообразнее что-то изобразить на экране для пользователя (а меня этот вопрос волнует), то к FORTH это отношения не имеет (да и к программированию вообще). А вот вопрос, как заставить FORTH-систему подобный способ общения с пользователем сделать естественным с точки зрения лексики языка и удобства программиста - уже проблема FORTH-программиста.
Тоже и "искусственным разумом"... FORTH не обладает никакой особой "самообучаемостью" (как и LISP или PROLOG)... Просто, некоторые штуки на этих языках выглядит естественнее...

Kopa> Что то подобное?
Разумнее заставить жестянку делать то, чего мы делать НЕ можем. Иначе, если бы искусственный интеллект разработал бы для нас свой тест Тьюринга, мы бы точно его провалили
Думаю, имеет смысл реализовать диалог с зеркалом. Потом можно попробовать аккуратно оценить отражение множества его аспектов на человеке.
Kopa> Реально или нет без углубленного изучения лингвистики сделать такое - непонятно.
Перевод всегда завязан на контексте – непрерывно изменяющемся, многофакторном. Кроме того, как быть с текстом, если предполагается последовательное извлечение информации в несколько проходов, с учётом ассоциативности мышления? Я думаю, для того чтобы автомат сумел это сделать, он должен научиться имитировать деятельность всех отделов мозга. Вы считаете это возможно?

Gudleifr> Если я спрашиваю как доходчивее и единообразнее что-то изобразить на экране для пользователя...
Мне кажется, что доходчивость и единообразие – это две противоположности, из которых я бы пожертвовал второй. Если же нужно сохранить обе, тогда материал приходится разбивать на две части: концептуальную (цели) и справочник (средства). Первая часть доходчивая, вторая – единообразная.
Gudleifr> FORTH не обладает никакой особой "самообучаемостью" (как и LISP или PROLOG)...
Это правда. Но можно ли утверждать это, сравнивая с Си, Java?

Veden12> Я думаю, для того чтобы автомат сумел это сделать, он должен научиться имитировать деятельность всех отделов мозга.
Рассуждения имели бы смысл, если бы задача перевода вообще имела бы решение. Ведь это просто пересказ своими словами услышанного. Игра в "плохой телефон".

Veden12> Мне кажется, что доходчивость и единообразие – это две противоположности, из которых я бы пожертвовал второй...
Дело вкуса. Единого универсального решения нет.

Veden12> Это правда. Но можно ли утверждать это, сравнивая с Си, Java?
Не вижу никакой разницы. Все могут то же, что и Машина Тьюринга.

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

Veden12> Мне кажется, что обучение для процедурных языков и ООП ещё менее естественно, чем для Форта.
А что Вы называете обучением?

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

1. : CRTC@ 3D4 2PORT@ ;
2. : CRTC! 3D4 2PORT! ;
3. : CRTC DUP >R CRTC@ AND OR R> CRTC! ;

Потом пишем
08 F7 1A CRTC
А это уже не похоже на Форт. И вообще ни на один язык. И нет ничего лишнего.

Veden12> С одной стороны, это означает, что программа на основе полученных данных программа пишет саму себя, постоянно совершенствуя этот процесс.
Ну, как бы FORTH сам себя не пишет. Его пишет программист. Если мы хотим, чтобы машина M на основе анализа среды S написала машину N для взаимодействия с этой средой, то на всех существующих языках сложность M должна быть больше N, а N - больше S.

Veden12> С другой стороны, это выглядит так, что она действительно способна научиться чему-то принципиально новому...
Так важно иметь возможность писать в свободном формате? Пишете "лексиконы" N0,N1,..Nn на честном C, а на уровне Nn+1 добавляете простенький интерпретатор. Результат идентичен.

Veden12> И нет ничего лишнего.
Лишнего очень много. Во-первых, так ли критично на данном уровне наличие в системе интерпретатора? Во-вторых, внутри у этой штуки - пара абсолютно чуждых для FORTH-системы "выходов наружу" (где совершенно не очевидно, что этими портами не играет кто-то еще). И, кстати, очень вероятно, что эта штука работает только благодаря тормознутости FORTH - на C пришлось бы для гарантии того, что запись успела пройти, либо тайм-аут, либо проверку втюхать.
Кстати, Броуди еще бы возмутился вводу явно избыточных слов, упрятывающих адрес порта. Да и одновременное использование AND и OR - вещь достаточно избыточная.

Gudleifr> Ну, как бы FORTH сам себя не пишет. Его пишет программист.
Растут словари, растут способности к восприятию новых слов. Выходит, что программист пишет программу после того как запустил её на выполнение.
Gudleifr> Пишете "лексиконы" N0,N1,..Nn на честном C, а на уровне Nn+1 добавляете простенький интерпретатор. Результат идентичен.
Не совсем. Для Форта не нужно добавлять интерпретатор, он уже есть и готов к работе. Но гораздо важнее, что на честном Си вызов каждой функции – времяубийство, ни в какое сравнение не идущее с парой тактов на NEXT.
Gudleifr> Лишнего очень много. Во-первых, так ли критично на данном уровне наличие в системе интерпретатора?
На данном уровне подобных строчек – десятки (с вариациями). Для Форт надо несколько новых слов, таких вот простеньких. На Си – интерпретатор данных с множеством "else if". Сначала я думал что интерпретатор проявит себя лишь с ростом сложности программы. Сейчас я в этом уже не так уверен.
Gudleifr> Во-вторых, внутри у этой штуки - пара абсолютно чуждых для FORTH-системы "выходов наружу"
Почему чуждых? Разве Форт не используют в контроллерах?
Gudleifr> (где совершенно не очевидно, что этими портами не играет кто-то еще).
Этим "кто-то" могу быть лишь я сам. Но программирование контроллера VGA – разовая операция.
Gudleifr> И, кстати, очень вероятно, что эта штука работает только благодаря тормознутости FORTH ...
По-сути, это чтение-обработка-запись порта. Работает даже с портами, отображёнными на память. Более того, если бы в следующий раз железо вместо чтения вернуло бы мне этот порт из кэша, я бы только спасибо сказал. Но нет, оно этого не сделает. Никогда.
Gudleifr> Кстати, Броуди еще бы возмутился вводу явно избыточных слов, упрятывающих адрес порта.
Да. Виноват. Я не упомянул о том, что все три слова используются и сами по себе. Это меняет дело?
Gudleifr> Да и одновременное использование AND и OR - вещь достаточно избыточная.
Почему? Мне же нужно маску наложить перед установкой битов в порту.

Veden12> Растут словари, растут способности к восприятию новых слов. Выходит, что программист пишет программу после того как запустил её на выполнение.
Даже на C программист запускает программу задолго до выполнения. Погоняет - допишет, еще погоняет - еще допишет...
Veden12> Для Форта не нужно добавлять интерпретатор, он уже есть и готов к работе.
А в культуре C есть компилятор компиляторов, гораздо более мощный...
Veden12> Но гораздо важнее, что на честном Си вызов каждый функции – времяубийство, ни в какое сравнение не идущее с парой тактов на NEXT.
Зато С не считает операцию сложения отдельной подпрограммой. И не занимается перетасовками стека...
Veden12> На данном уровне подобных строчек – десятки (с вариациями).
Это плохо. Ибо сказано: "Не предполагайте!"
Veden12> На Си – интерпретатор данных с множеством "else if".
На плохом C.
Veden12> Почему чуждых? Разве Форт не используют в контроллерах?
Используют. В отсутствие нормальных языков.
Veden12> Но программирование контроллера VGA – разовая операция...
И кто-то заявил: "ничего лишнего"? Три слова ради желания "красиво" написать разовую операцию? Более того, все Ваши условия: нет влияния на многозадачность, время отклика порта заведомо мало... никак не отражены в тексте "программы". Разве хороший язык не постарался бы акцентировать внимание программиста эти тонкие места? (Ср. ОККАМ).

Gudleifr> Даже на C программист запускает программу задолго до выполнения. Погоняет - допишет, еще погоняет - еще допишет...
Это да. Любой программист знает, что когда количество обогащённого кода достигает критической массы, цепной реакции ждать не приходится.
Gudleifr> А в культуре C есть компилятор компиляторов, гораздо более мощный...
На Си есть много чего. Но написать на нём интерпретатор, сравнимый с Фортом, не получится. Хотя бы потому, что Си заточен под компиляцию. Си – не плохой язык. Он неизбежный.
Gudleifr> Зато С не считает операцию сложения отдельной подпрограммой. И не занимается перетасовками стека...
Ничто не может отвлечь Си от куда более увлекательного дела – перетасовывания регистров процессора.
Veden12>> На данном уровне подобных строчек – десятки (с вариациями).
Gudleifr> Это плохо. Ибо сказано: "Не предполагайте!"
Там нет места предположеиям. Ничего лишнего. Все объявленные слова используются. Избыточен лишь набор документированных базовых слов (машинные коды), но в какой части – неясно. Функциональная полнота греет.
Gudleifr> Три слова ради желания "красиво" написать разовую операцию?
Используются все три. И не раз. И не два. Разовый лишь вызов всей немаленькой процедуры. А если "красиво" значит "понятно" и позволяет избежать тяжёлых ошибок, способных угробить железо, то оно того, думаю, стоит.
Gudleifr> Более того, все Ваши условия: нет влияния на многозадачность, время отклика порта заведомо мало... никак не отражены в тексте "программы".
То, что при установки битов в порту время отклика порта роли не играет – неотъемлемое свойство железа. Что же до многозадачности, то мысль распараллелить процедуру установки видеорежима мне в голову не приходила. Учитывая, что при этом программируется матричный процессор, звучит достаточно безумно для того, чтобы попробывать. Я, наверное, сделаю это. Когда у меня появится новая карточка этой на смену
Gudleifr> Разве хороший язык не постарался бы акцентировать внимание программиста эти тонкие места? (Ср. ОККАМ).
Возможно, в мире матричных процессоров ОККАМ заставит нас забыть Си.

Veden12> На Си есть много чего. Но написать на нём интерпретатор, сравнимый с Фортом, не получится.
Подавляющее число фортеров пишут сейчас свой FORTH на С. Я уже не говорю о тех, кто на C написал не только awk, но и Perl с Python...

Впрочем, я, кажется, понял. Вы действительно рветесь FORTH с чем-то сравнивать. Хотите доказать, что он быстрее, компактнее, безошибочнее... чего-то. Это все фигня.

Многие вещи, например, просто сравнивать не стоит. Например, быстродействие. На чем бы Вы не писали, если Вы пишете правильно, критическими по скорости будут десяток операторов, которые все просто переписывают на ассемблере. Хоть на FORTH, хоть на C, BASIC или FoxBase+...

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

Однако, за такую свободу надо платить.
1. FORTH нужно каждый раз писать заново. Иначе он будет так же давить парадигмами, как и другие языки.
2. Т.к. большинство простых задач уже решены (т.е. проблемно-ориентированный язык для них всем известен и давно реализован), то применение здесь FORTH избыточно. Только проблемы с совместимостью получить.
3. FORTH не масштабируем. Если например, два краеугольных камня C - процедуры и переменные - легко упаковываются в более крупные опять же процедуры и переменные, то FORTH так умеет делать только со СЛОВАРЕМ. Остальные части FORTH-интерпретатора (см. вышеприведенный рисунок) расти не умеют и поневоле должны заранее соответствовать создаваемому проблемно-ориентированному языку. А вопрос взаимодействия нескольких FORTH-систем разного уровня совершенно не проработан.
4. FORTH завсегда создает иллюзию решаемости задачи: мол, начнем с малого, затем объединим, затем как-то будем управлять... Хотя, как сказано в предыдущем абзаце решать-то обычно, все равно, надо сверху вниз...
...

Самое главное, FORTH (как и любой язык программирования) должен соответствовать вашей скорости писания программы - не тормозить и не опережать ваши размышления...

Gudleifr> Вы действительно рветесь FORTH с чем-то сравнивать.
Ещё проще. Есть два языка программирования, организацию которых, логику я понимаю, но вот просчитать ситуацию, развитие проекта, проблемы на несколько шагов вперёд никак не выходит. Один из них – Форт, другой – Лисп. Знания, опыт бесполезны. Легко узнать то, чего не знаешь. Но как быть если не знаешь чего не знаешь? В этой ситуации обычно помогает сравнительный анализ. Находим общий знаменатель... Гм. Скорость? Прожорливость? Ниша? Лексикон? Даже метод каждый понимает по-своему. Ну ладно, дифференцирование не помогает, интегрируем: быть может, имеющиеся реализации друг друга дополняют и лишь объединив их можно понять что происходит? Опять нет?
Gudleifr> Хотите доказать...
Предпочитаю сомнения

Gudleifr> FORTH просто позволяет Вам писать, как нравится.
Это точно.
Gudleifr> Я бы например просто зафигачил в начало программ что-то навроде таблицы, содержащей в одинаковом виде списки поднятия всего железа
Я бы тоже... Это был отладочный, моделирующий код. Для таблиц слишком рано.

Gudleifr> 3. FORTH не масштабируем. Если например, два краеугольных камня C - процедуры и переменные - легко упаковываются в более крупные опять же процедуры и переменные, то FORTH так умеет делать только со СЛОВАРЕМ.
Словарь – это не весь Форт?
Gudleifr> Остальные части FORTH-интерпретатора (см. вышеприведенный рисунок) расти не умеют и поневоле должны заранее соответствовать создаваемому проблемно-ориентированному языку.
Я так и не понял, почему интерпретатором целевого языка обязательно должен быть Форт-интерпретатор, используемый для компиляции.
Gudleifr> А вопрос взаимодействия нескольких FORTH-систем разного уровня совершенно не проработан.
Очень интересный вопрос.
Gudleifr> 4. FORTH завсегда создает иллюзию решаемости задачи: мол, начнем с малого, затем объединим, затем как-то будем управлять...
Взглянуть бы на упавшую падающую башню... Отрицательный результат... Наверное, многое бы прояснилось.

Veden12> Словарь – это не весь Форт?
А для кого я рисовал?
Veden12> Я так и не понял, почему интерпретатором целевого языка обязательно должен быть Форт-интерпретатор, используемый для компиляции.
Потому что "Очень интересный вопрос" не проработан.
"Другой интерпретатор" вполне возможен, но в его написании FORTH так же беспомощен, как другие языки.
Вспомните, как Вы пытались голову вывернуть, чтобы понять, как SPF сам себя за волосы вытаскивает...

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

Veden12> Какие материалы, книги Вы считаете наиболее полезными в понимании интерпретации?
А что тут понимать-то? Сказано, ведь: "самый простой интерпретатор из возможных"...
Конечно, упомянутые в соседней ветке статьи Дейкстры и Мура прочитать полезно.
И, возможно, поиграть в Tcl/Tk и Perl - чтобы оценить насколько плохой выбор языка может усложнить задачу...

Veden12> Эволюция...

Неожиданно..

1. Предпосылка 8086tiny Простейший эмулятор компьютера на Х86 (8086) процессоре.
2. Детали о линейке Win3.х на Wikipedia Win3.0 последняя "ОС" работает только в реальном режиме
3. Проект Calmira расширенной оболочки для Win 3.х системы.

... и даже "старый" софт (или старое железо) на что то может сгодиться. (или нет, а только для настольгии?)

P.S. А запуск этого "хлама", сделанный, например в рамках KolibriOS или другой ОС на современном железе может послужить разным целям
с Win3.1 на Win95 с лёгкостью "перешёл" только из-за того как выглядел дизайн интерфейса Win95.
но от Far-а до сих пор не отказался.

Veden12 мне нравится Ваш подход к "проблеме" осмысления "сущного"

Галерея скриншотов пользователей Calmira

Veden12> Какие материалы, книги Вы считаете наиболее полезными в понимании интерпретации?
В качестве упражнения по "Общей Теории Всего": Оллонгрен А. - Определение языков программирования интерпретирующими автоматами. Есть в Книги серии "Математическое обеспечение ЭВМ".

P.S. К упоминанию Кернигана и Ричи в Вашем списке литературы обязательно надо добавить Кернигана и Пайка: "UNIX" и "Практика программирования". В первой из них, кстати, хорошо расписан C-подход к интерпретаторам...

Kopa> P.S. А запуск этого "хлама", сделанный, например в рамках KolibriOS или другой ОС на современном железе может послужить разным целям
Kopa> с Win3.1 на Win95 с лёгкостью "перешёл" только из-за того как выглядел дизайн интерфейса Win95.
Мне кажется, сегодня человеко-машинный интерфейс должен обладать двумя свойствами:
1. Способствовать автоматизации деятельности человека, а не отдельных действий.
2. Учитывать, что добрая половина интерфейса не на экране, а в голове у человека ("...сколько пищи для маленьких наших мозгов").

Взгляните, пожалуйста, на рисунок слева. Что Вы узнали, поняли, почувствовали?... А теперь – на рисунок справа. В общем-то, такой же зелёный квадрат. Какие чувства вложили в свои квадраты создатели Windows8? Взаимно

Kopa> но от Far-а до сих пор не отказался.
Я тоже.

Gudleifr> В качестве упражнения по "Общей Теории Всего": Оллонгрен А. - Определение языков программирования интерпретирующими автоматами.
Спасибо. Скачал. Почитаю. Выглядит довольно фундаментально. Видимо, то что надо.
Gudleifr> P.S. К упоминанию Кернигана и Ричи в Вашем списке литературы обязательно надо добавить Кернигана и Пайка: "UNIX" и "Практика программирования".
Доберусь и до них Пока ничего основательнее Баха про UNIX не встречал. Там всё очень концептуально.