gudleifr писал(а):
Нас должно волновать не улучшение кода, а улучшение языка, т.к. обычно задача перестает быть управляемой программистом задолго до того, как начнет вызывать проблемы у процессора.
Это как раз об улучшении языка! Использование флагов процессора, а не значения на стеке; разделение словаря и кода => имя слова представляет адрес, множественные точки входа в слово; оптимизация хвостовой рекурсии - это изменение языка!
А про управляемость - это уже к среде разработки. Есть мысли и о нескольких вариантах такой среды, даже на Форт-принципах. Поддержка среды может существенно увеличить производительность и избавить от некоторых типов ошибок. А еще бы локальное тестирование слов с автоматической генерацией тестов...
gudleifr писал(а):
набор общих решений и соглашений, облегчающих заимствование уже написанного кем-то кода...
К сожалению, часто это затруднительно. Разные стили трудновато красиво совместить в одной программе. Проще переработать. Например, если в одном из вариантов условия проверяют значение на стеке, а в другом - флаг процессора и при этом код с соответствующими оптимизациями(и трюками) для каждого стиля - к какому приводить? Уже столкнулся. Пока выбрал переработать в один стиль. Заимствовать получилось только идеи. Трюки не все получается перетаскивать.
Но, по идее, если работать на более высоком уровне, можно и совмещать. Но удобным будет, если объемлющая система будет иметь описание(метаописание) всех включаемых стилей и возможности взаимно конвертировать код и подстраиваться под нужный стиль(а это уже элементы ИИ
). Локальная связность(стиль отдельных частей программы) сохранится. Кстати, тут придется использовать различные интерпретаторы.
И, кстати, соглашения еще нужно соблюдать!
А тут авторы Форт-программ даже рекомендациям Броуди не следуют. Не осилили? Привыкли по-старинке? Забыли?
Делать систему посложнее - с анализом кода и подсказками и постоянным обучением? Вообще-то уже пора! А в современном мире - единственная мера.
И нужно постараться выбрать интуитивно-понятные решения. Тогда просто узнав о них - им будут следовать. Думаю это и будет "общими решениями и соглашениями". Причем опираться хорошо бы на несколько стандартов. Мне, например, плоский интерфейс в варианте Микрософта кажется шагом назад по сравнению с объемными кнопками. Как догадаться, что сбоку еще что-то выезжает?! Подсказки должны быть хорошо видны! Не стОит заставлять пользователя решать ребус! Да и чуть раньше - чтоб узнать, на какие кнопки можно нажимать, стало нужным таскать над ними мышку! Или меню из двух пунктов, в котором не видно, какой выбран? Ой, это уже про юзабилити - но тоже важный момент. И такие моменты лучше рассматривать в комплексе. Тогда результат может взлететь.
gudleifr писал(а):
Вы упомянули "флаги, как в ColorForth". Я с его исходниками не знаком.
Вот тут,
тут и
тут что-то есть.Если интересно, могу еще код показать, но не все рабочее и документация не обработана...
Есть разобранный исходник компилятора colorForth Мура, но напрямую он мне не подходит - слишком подход радикальный. Я приблизил к традиционному, но в системе он пока не работает.
И одна из моих любимых статей Мура -
1%.