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

mak44> Наверно, вы имели ввиду чужого. Неготовое нельзя использовать по определению.
mak44> Тем, кто делает все сам и по своему, конференция ненужна.
Нужна и обратная связь по обсуждению и доводке
+ все программные разработки которые хотелось бы сделать сложно довести до приемлемого уровня использования в ограниченное время.

P.S. mak44 твои разработки интересны и наполнены некоторой новизной идей, но им не хватает уровня доведения до хорошего юзабельного варианта. С "полуфабрикатами" не все Фортеры готовы работать дальше, а "партизанские" настроения "процветают" в текущий момент и как это изменить непонятно. Без востребованности Форт программистов на рынке труда или поддержки (при понимании получаемых выгод) данного направления в рамках структур "предприятий" вряд ли что изменится.

Kopa> Но собрать этот вариант на последней версии SPF 4.20 уже сложно
Для сборки img.asm в KolSPForth12 под UBUNTU тоже пришлось кое-что поправить
http://fpauk.narod.ru/KolSPForthL12.tar.bz2

Gudleifr> Имелись в ввиду фрагменты, которые программисту самому интересно писать.
Своего рода прототипы.

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

mak44>> Как правило, словарные статьи, определённые пользователем, имеют точно такое же представление в Форт-системе, как и все словарные статьи,
Gudleifr> Это один из тормозов развития FORTH.
Представать процедуру в виде словарной статьи это, всего лишь, занести ее адрес
в словарь предав мнемоническое имя. Нечему мешать это не может.

mak44>> Проблемно-ориентированный язык следует развивать параллельно программе в которой он применяется. Иначе, будет не соответствие.
Gudleifr> Тавтология. В такой трактовке развитие языка и программы - суть одно и тоже.
Я не точно выразился. Проблемно-ориентированный язык и программа для компиляции
которой он создается.

mak44>> В большинстве случаев, новый язык в рамках Форта для собственных нужд самостоятельно создавать не целесообразно.
Gudleifr> Тогда и FORTH не нужен. Его прелесть именно в создании языков.
Он создавался для управления телескопом. Его прелесть в том, что может
использоваться шире замыслов автора за счет полного доступа ко всем его компонентам.
Но больше операционная система, чем язык программирования.

Gudleifr> * присутствует заголовок с описанием внешних форматов и точек входа
Gudleifr> * далее - список импортируемых модулей
Gudleifr> * далеее - описание основных внутренних форматов и размещение глобальных массивов.
Gudleifr> Т.е. прочтя начало программы, уже знаешь, с чем имеешь дело.

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

mak44> Своего рода прототипы.
Нет, просто интересные куски кода. Думаю, термин "прототипы" надо либо определить, либо выкинуть.

mak44> Как я понял вы рассматриваете Форт, прежде всего, как метаязык.
Формально - нет. Метаязык должен обладать некоторыми свойствами, которых у FORTH нет. FORTH, скорее, заготовка языка. "Прототип"?

mak44> Представать процедуру в виде словарной статьи это, всего лишь, занести ее адрес в словарь предав мнемоническое имя. Нечему мешать это не может.
Может. Например, в win-программах именем слова служит не строка, а четверка win-msg-wpar-lpar.

mak44> Я не точно выразился. Проблемно-ориентированный язык и программа для компиляции которой он создается.
Проблемно-ориентированный язык, большей частью, не компилируется, а интерпретируется. Изначальный смысл FORTH - не создать исполняемый файл, а исполнить команду пользователя.

mak44> Он создавался для управления телескопом.
Никоим образом.
Просто Мура задолбало перекомпилировать программу при изменении параметров.
Поэтому он начал думать о разбиении программы на атомарные куски, из которых "умный пользователь" сможет собрать нужную ему программу.

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

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

Gudleifr> FORTH, скорее, заготовка языка. "Прототип"?
По моему да. Или полуфабрикат - почти тоже самое.

mak44>> Представать процедуру в виде словарной статьи это, всего лишь, занести ее адрес в словарь предав мнемоническое имя. Нечему мешать это не может.
Gudleifr> Может. Например, в win-программах именем слова служит не строка, а четверка win-msg-wpar-lpar.
Неможет http://spf.cvs.sf.net/viewvc/spf/lib/win/spfgui/spfgui.f?annotate=1#l128


Gudleifr> он начал думать о разбиении программы на атомарные куски, из которых "умный пользователь" сможет собрать нужную ему программу.
Думаю Мур создавал Форт для собственных нужд.

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

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

mak44> Неможет...
А у меня может!

mak44> Думаю Мур создавал Форт для собственных нужд.
И так как сразу заявил о его приспособлении под создание проблемно-ориентированных языков, то необходимость создания такого языка для самого себя доказана!

Кстати, обмен подобными языками смотрится гораздо логичнее, чем обмен "прототипами".

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

Gudleifr> на уровне алгоритмов (которые каждый может реализовать в меру своего знания Forth).
Любая программа и есть алгоритм. Обычно под алгоритмом понимают такую программу,
для которой не существует интерпретатора (компилятора), за счет чего, можно
повысить наглядность. Т.е. подлежит переработки т.е. прототип. Думаю,
большую ценность будут представлять отлаженные программы.
Вообще, так рассуждают большие начальники, которым самим ничего реализовывать
не нужно. Сейчас уже такие программы, для которых жизни не хватит просто набрать
исходный текст. На данный момент, изобретать особо, ничего не нужно.
Нужно открытые исходники нужных фортерам программ привести к форт-виду.
(перевести на язык воспринимаемый форт-системой)

Gudleifr> Но никоим образом не на Forth-уровне. А копирование кусков плохого кода - практика порочная.
Плохой - понятие относительное.(дело вкуса) Найдутся те кому проще исправить,
чем делать заново. Тем кому проще делать заново, здесь вообще не причем.
Пусть варятся в собственном саку. Только и разговоров, что не надо делать
фортерам. Чего не хватает форту, так это рабочих рук.

mak44> Подлежащая переработки не обязательно недоделанная. Поставленную задачу она может выполнять идеально.
mak44> Найдутся те кому проще исправить, чем делать заново.
Наше отношение к чему-то очень хорошо сделанному, но нам не подходящему, и к просто плохо сделанному не может принципиально отличаться - все равно надо выкидывать и начинать заново.
Доделывать и исправлять - практика порочная, хотя и имеет в место в языках высокого уровня, обладающих большой избыточностью. В Forth такое просто не нужно. Гораздо лучше начать заново.

mak44> Если у каждого будет свой вариант форт-системы, фортеры нечем друг другу не помогут.
На уровне выше (алгоритмов) и ниже (Forth-парадигм) - помогут. Тем более, что не только "у каждого программиста - свой Forth", но и "для каждой новой задачи - свой Forth", и даже (и чаще) "Forth-парадигы без Forth".

mak44> Любая программа и есть алгоритм.
Реализация алгоритма. А "прототип" как Вы его определили в прошлом посте - "что-то, что нужно доделать", к понятию алгоритма отношения иметь не может. Алгоритм - идеален.

mak44> Сейчас уже такие программы, для которых жизни не хватит просто набрать исходный текст.
Проблема поставлена Дейкстрой в 70-е годы. Тогда же и показан путь решения. Велосипеды изобретать не нужно.

mak44> Тем кому проще делать заново, здесь вообще не причем.
Чарльз Мур: "СДЕЛАЙТЕ ЭТО САМИ!"

P.S.
mak44> Чего не хватает форту, так это рабочих рук.
Это, как раз, не проблема. Нет людей, заинтересованных в решении проблемы - нет и проблемы.
Нет, не хватает всегда одного - мозгов. Все остальное: время, деньги, люди...- вторично.

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

Gudleifr> Доделывать и исправлять - практика порочная
Так чего плохого?
Gudleifr> В Forth такое просто не нужно. Гораздо лучше начать заново.
Почему именно В Forth?

Gudleifr> На уровне выше (алгоритмов) и ниже (Forth-парадигм) - помогут
Если (алгоритмы) и (Forth-парадигмы) будут реально востребованы, то
в условиях микроплатежей тоже будут товаром.

Gudleifr> "для каждой новой задачи - свой Forth"
Вот свой Forth точно не нужен. Любой Forth можно насытить чем угодно.
Все форт-системы друг друга выражают. Несовместимость форт-системами
обусловлена только тем, что о совместимости мало заботятся.
В условиях микроплатежей сформируется служба приведения к стандартам.

Gudleifr> Нет, не хватает всегда одного - мозгов. Все остальное: время, деньги, люди...- вторично.
Первична эволюция. Мозги создала она.

mak44> И при этом, работающие программы могут служить источником отлаженного материала для построения новой программы.
mak44> Так чего плохого?
Два нюанса: отлаженная программа перестает быть таковой при встраивании куда-то; и отлаженность программы не свидетельствует о ее правильности.

mak44> Почему именно В Forth [проще начать заново]?
Forth-метод сводится к созданию языка решения задачи.
Т.о. кроме самого решения задачи в Forth-программе практически не содержится.
Так зачем копировать сюда же решения прошлых задач?

mak44> Вот свой Forth точно не нужен.
Из соседнего топика:
"... имеем A (язык машины), пишем на коленке за неделю F (Forth), затем на нем - P (проблемно-ориентированный язык), отдаем юзеру и тот решает на P свои задачи.
Очевидно: F должен быть максимально прост (если он сравним по сложности с P, то проще сразу P реализовать) и настолько универсален, что его можно создать для любого A. Что и имеем".
Т.е. потратить неделю на написание своего F (под конкретные A и P) проще, чем искать ошибки в чужом.

mak44> Несовместимость форт-системами обусловлена только тем, что...
Универсальный F для всех возможных A и P создать, очевидно, невозможно.

Kopa> честно сказать мне непонятно о чём идёт разговор в последних постах данного топика

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

mak44> Gudleifr отвел для применения Форта очень узкую нишу.
Вот с этого места, пожалуйста, поподробнее.

mak44> Я рассматриваю Фотр, прежде всего, как операционную систему.
Вспомним BASIC под DOS. По сути, удобная операционная система для прикладных задач, практически без ограничений для алгоритмов и интерфейсов. Однако, если тот же BASIC построить на Форте, можно ли задействованную реализацию Форта со всем его проблемно-ориентированным словарным запасом называть операционной системой?

Veden12> Вспомним BASIC под DOS. По сути, удобная операционная система для прикладных задач, практически без ограничений для алгоритмов и интерфейсов.
BASIC тут - правильное слово. Очень многое в FORTH изначально сделано "по BASIC-овски". Т.е. легко реализуется в любой ОС (и даже без них). Но, вот, свойствами ОС, к сожалению, ни тот, ни другой не обладают. Не умеют управлять ресурсами.
К тому же в словосочетании "BASIC под DOS" нормальная операционная система упоминается - DOS.

Veden12> Однако, если тот же BASIC построить на Форте, можно ли задействованную реализацию Форта со всем его проблемно-ориентированным словарным запасом называть операционной системой?
В качестве операционной системы может быть использован любой интерпретатор.
Может быть JavaOS, PitonOS, LispOS и т.д.
BASIC в рамках ForthOS ничем не должен мешать. Не запускаешь, можешь считать, что его нет.
Языки в рамках форта могут наследовать его свойства.

mak44> В качестве операционной системы может быть использован любой интерпретатор.
???
Кто-нибудь пытался использовать в качестве ОС awk?

Gudleifr> Но, вот, свойствами ОС, к сожалению, ни тот, ни другой не обладают. Не умеют управлять ресурсами.
А если и драйверы на том же Форте? Сначала сетевой, потом, допустим, понадобилась 105-кнопочная мышь (а события от мыши и клавиатуры в DOS оторваны друг от друга), нестандартное видео, дисковые массивы собственной структуры (под параллельную обработку), SD-кэш...
Можно ли в таком случае утверждать, что Форт обладает свойствами ОС, или по-прежнему нет? Может ли инструмент (Форт) стать изделием (ОС)?
Мне кажется, что изделием всегда будет то, с чем работает пользователь - оболочка, BASIC. И Форт никак при этом не проявится, как не видно железа.

Veden12> А если и драйверы на том же Форте?
...
Veden12> Можно ли в таком случае утверждать, что Форт обладает свойствами ОС, или по-прежнему нет? Может ли инструмент (Форт) стать изделием (ОС)?
1. Nix'ы написаны, в основном, на C. Но C операционной системой не называют.
2. Драйвера на FORTH написать можно, но их очень трудно сделать органичной частью FORTH-системы. Даже те попытки обобщить FORTH-методы, которые предпринимаю я, никто не принимает.

Gudleifr> 1. Nix'ы написаны, в основном, на C. Но C операционной системой не называют.
Си не обладает функциональной полнотой для этого, требуя ассемблерные расширения, идущие вразрез с основными парадигмами языка. Форт же легко ассимилирует любые расширения, принимая их как собственные примитивы.
Gudleifr> 2. Драйвера на FORTH написать можно, но их очень трудно сделать органичной частью FORTH-системы.
Если конечный продукт не содержит средств разработки (Форт - инструмент) и исключает аппаратные прерывания (а с ними и критические секции), то что мешает драйверу быть органичной частью Форт-системы?

Veden12> Си не обладает функциональной полнотой для этого, требуя ассемблерные расширения, идущие вразрез с основными парадигмами языка.
Вообще-то, перевод языка в ассемблер является основной парадигмой C.
Можно запустить компилятор с опцией -s и править получившийся ассемблерный текст в свое удовольствие.
А затем скормить компилятору для "докомпиляции".

Veden12> Форт же легко ассимилирует любые расширения, принимая их как собственные примитивы.
А какая разница: включать asm-вставки в C или FORTH? И там, и там они снаружи неотличимы от обычных "примитивов".

Veden12> Если конечный продукт не содержит средств разработки (Форт - инструмент) и исключает аппаратные прерывания (а с ними и критические секции), то что мешает драйверу быть органичной частью Форт-системы?
Слишком много неувязок для одного предложения:
1. "Если конечный продукт не содержит средств разработки... то что мешает... быть органичной частью Форт-системы?" — Так, все-таки, есть FORTH-система или нет?
2. "исключает аппаратные прерывания (а с ними и критические секции)" — одно с другим в общем случае не связано.
3. "исключает аппаратные прерывания... и критические секции..." — а почему ОС должна их исключать? Чем Вы хотите их заменить?

Veden12> что мешает драйверу быть органичной частью Форт-системы?
То, что в FORT-концепция рассматривает подобную фигню, как нечто, относящееся к языкам А и P, но не к языку F. (См. например, Броуди). FORTH не умеет включать общение с ненужным ему железом в свой Цикл Управления, рассматривая ее (как и C) как вызовы каких-то нужных пользователю функций. С другой стороны, FORTH требует написания драйверов нужного ему железа (консоли, памяти) в кодах "идущих вразрез с основными парадигмами языка".

Veden12> А если и драйверы на том же Форте? Сначала сетевой, потом, допустим, понадобилась 105-кнопочная мышь (а события от мыши и клавиатуры в DOS оторваны друг от друга), нестандартное видео, дисковые массивы собственной структуры (под параллельную обработку), SD-кэш...
Veden12> Можно ли в таком случае утверждать, что Форт обладает свойствами ОС, или по-прежнему нет?
Доступ к устройствам которыми пользуются несколько процессов нужно оформить как
разделяемый ресурс. Все это решаемо. Однако, целесообразнее Форт встраивать в уже
отлаженные ОС, тем самым они становится ФортОС. Форт в ядре ОС это привилегированный форт.
Форт-системы в защищенном режиме могут разделять с привилегированным общую библиотеку
подпрограмм.

Veden12> Мне кажется, что изделием всегда будет то, с чем работает пользователь - оболочка, BASIC. И Форт никак при этом не проявится, как не видно железа.
Для использования средств Форта в BASIC-е, достаточно в BASIC добавить
возможность вызова функций Форта.

mak44> Однако, целесообразнее Форт встраивать в уже отлаженные ОС, тем самым они становится ФортОС.
Встройте! Например, изготовьте ФортWindows. Хотя бы, наметьте пути "встраивания"...

mak44> Для использования средств Форта в BASIC-е, достаточно в BASIC добавить возможность вызова функций Форта.
А для превращения ВАЗа в престижный автомобиль надо сзади на веревочку привязать Кадиллак.

Gudleifr> Вообще-то, перевод языка в ассемблер является основной парадигмой C.
Это верно для всех языков программирования, кроме, конечно, самого ассемблера. Изюминкой Си является принцип локализации алгоритмов и данных, препятствующий произвольному переключению контекстов. Диспетчер задач (переключение по прерыванию) на Си? Это вообще возможно?
Gudleifr> А какая разница: включать asm-вставки в C или FORTH? И там, и там они снаружи неотличимы от обычных "примитивов".
Можно не скармливать ассемблерные инструкции интерпретатору Форта, а сразу же реализовать как базовые слова языка.
Gudleifr> Так, все-таки, есть FORTH-система или нет?
Форт-система (реализация Форта, включащая все необходимые словари, но вовсе необязательно интерпретатор) безусловно есть - у каждого своя, своя под задачу, но есть. А операционная система Форт - полагаю, нет.
Gudleifr> 3. "исключает аппаратные прерывания... и критические секции..." — а почему ОС должна их исключать? Чем Вы хотите их заменить?
Кооперативной многозадачностью, получением данных по опросу. Учитывая, что современные CPU содержат "графическое" ядро на сотню "шейдерных процессоров", долго ли ещё просуществует концепция прерываний?
Gudleifr> С другой стороны, FORTH требует написания драйверов нужного ему железа (консоли, памяти) в кодах "идущих вразрез с основными парадигмами языка".
После введения в базовый словарь пары ключевых слов PORT@ и PORT! обнаружилось, что писать драйверы на Форте легко и приятно. Или здесь есть незамеченные мною с ходу подводные камни?

Gudleifr> Разработки "снизу вверх". Ведь, задача не всегда логично решается снизу вверх, иногда хочется и сверху вниз.

Зачастую `снизу-вверх` является единственной возможностью реализации ПО для клиента.

Veden12> Или здесь есть незамеченные мною с ходу подводные камни?
Подводный камень здесь только один. И на C, и на FORTH, и на языке ассемблера... все это пишется одинаково. И не надо отказывать себе в прерываниях и/или критических секциях.
Но во всех упомянутых языках все это выглядит "внешними библиотеками", никак не связанными с "глубинной сущностью" языка.
Исключения - [Visual]BASIC (ценой упрощения пользовательской модели ОС), OKKAM (с его завязкой на многопроцессорность), CUA/GUI (с заложенной внутрь объектной ориентированностью), nix'-shell (с файлами-каналами)...