Сразу хочу отметить, что в названии темы не вопрос, а информация
То есть я не планирую обсуждать "да или нет", а только "что именно получалось". Тема выделена в ответ на аргументы ForthWare, который в кои-то веки существования форума поставил вопрос (запрос) об эффективном практическом использовании Форта ребром.
Сначала лирическое отступление в виде хищнических мемуаров. Когда-то я писал на Турбо-паскале под ДОС кучку программ управления оборудованием. Управление не просто так, а со снятием характеристик, статистикой, матобработкой, сохранением-загрузкой - вобщем, PC, а не контроллер, и не коммерческий проект, а НИР. Иными словами, требовать ТЗ не с кого, пишется для себя же. Windows тогда был только 3.1, то есть в виде интересной графической оболочки, но никак не мейнстрима. Понятное дело, что проектировать оконный интерфейс на Turbo Vision в такой ситуации себе дороже - требования постоянно меняются, новые шаги становятся понятными только после запуска предыдущих. В итоге набралось полтора десятка программ, программок и программешек на паскале, каждая из которых делала какую-то мелкую задачу. Дилемма была та еще - либо смотреть на черный экран со спорадически возникающими результатами вывода отдельных процедур, либо проектировать мертворожденные интерфейсы, по которым надо будет в процессе работы добираться до нужного пункта (а в процесс отладки включать еще и проверки, подключены ли интерфейсные компоненты к соответствующим процедурам на паскале, правильно ли и из тех ли диалоговых окон передаются параметры, и туда ли выводятся результаты). А вот удачно купленный диск со сборником компиляторов, где была коллекция фортов, кардинально изменил ситуацию. Форт я знал с момента выхода книги Баранова, которую в период изучения программирования аккуратно законспектировал (наряду с изученными тогда бейсиком, паскалем, си и ассемблером 580ВМ80), чуть позже видел его на Спектруме. Так что версия для PC была как раз в тему, и убеждать себя совершенно не пришлось. В конечном итоге ВЕСЬ набор паскалевских поделий заменился на два (!) экрана текста на Форте. Дальше на протяжении долгого времени свою великую роль играла командная строка. Работа по сути сводилась к опробованию разного порядка вывода в порты, ввода из портов в массивы, сохранения на диск и т.п. - сами операции не такие уж и сложные, а вот увязка их в паскале, да с кучей вариантов требовала уже интерфейса. В Форте же - ничего не требовала, все набиралось по мере необходимости. Тот Форт (spf 2.02) был развит до состояния "плавающая точка, EMS, XMS, VGA-графика, функциональные клавиши и мышка", что дало возможность писать приложения, на 100% удовлетворяющие по функциональности "внутренних" слов, и в общих чертах - по интерфейсу. Вывод из этого этапа был сделан следующий.
В компилирующих языках интерфейс в основной массе решает проблемы, которые сами же языки и ставят. Интерактивное управление программой в большинстве случаев позволяет обойтись более простым интерфейсом, поскольку из командной строки можно задать все те параметры, для которых в ином случае пришлось бы заводить массу полей редактирования, кнопок и чекбоксов, а также развитую систему перехода между этими элементами, их группировки и поддержки. Еще одним замеченным неудобством диалоговых окон является необходимость
ввода туда значений вместо загрузки их snapshot-а из какого-либо временного файла. Я уже не говорю о ситуации, когда надо пустить процесс, регулируемый вот этим диалоговым окном, 10 раз, и чтобы вот это поле менялось от 25 с шагом 3. Это, как ни крути, влезание в программу и усложнение интерфейса. А потом мне этот циклический запуск не понадобится, и пойдет откат назад.
Разумеется, это справедливо для определенного класса проектов. Да, это нельзя назвать мейнстримом - часто программисту желательно, чтобы интерфейс был если не определен в ТЗ, то хотя бы четко описан. Тогда можно выбрать дизайн, положить компоненты на форму и аккуратно реализовать обработчики. Однако кто-то ведь эти ТЗ придумывает
И с определенной точки зрения, необходимость при существенной корректировке ТЗ начинать работу с интерфейсом сначала есть недостаток. Программисту это не так уж важно - он вообще-то честно отработал предыдущее задание, и его совесть абсолютно чиста. А вот автора ТЗ этот момент несколько гложет, потому что он задействовал исполнителя, выделил деньги, а результат не тот, и исполнитель в этом не виноват.
Итак,
первый плюс Форта - интерактивность программы и возможность интерпретируемого управления. Сюда же включаем возможность управления путем запуска мелких скриптов, которыми разработчик дополняет программу при появлении у пользователя новых пожеланий (вместо того, чтобы влезать в проект, править там порядок вызова слов и заново все перекомпилировать). Еще раз отмечу - в Дельфи для этого нужно вводить возможность проигрывания макросов - вошли в диалоговое окно, заполнили поля вот этими значениями, выбрали пункт меню, и чтобы все эти действия потом были по одной кнопке. В Форте подобная кнопка будет грузить файл и интерпретировать его. Примерно 5 лет назад мы так сдали хороший проект на Форте, когда заказчик, апеллируя к немаленькой сумме договора, постоянно подбрасывал изменения и дополнения, а мы, пожимая плечами, дописывали мелкие скриптики
Канва-то была, интерфейс и математика на месте, а вот что, куда и откуда, и что потом делать с результатами - эти мысли у заказчика и появляться-то стали только после взгляда на первые релизы.
Казалось бы, тут подойдет любой интерпретируемый язык. А вот и нет, Форт к тому же еще и выполняет скомпилированный код, так что его производительность не сильно ниже, чем у Си. Так что он попадает где-то в верхнюю часть огромной таблицы производительности, поскольку какой-нибудь tcl будет уже настолько медленным, что при работе оно станет заметно, что неминуемо приведет к претензиям и предложениям писать на более производительном языке. Разницу же между Фортом и другими языками "верхнего эшелона" обычно можно обнаружить разве что с секундомером, тем более что тут еще и от выбранных алгоритмов многое зависит. Вобщем,
не тормозит Форт настолько сильно, чтобы приходилось принимать серьезные меры на всех этапах разработки.
Далее (опять же чисто исторически-мемуарно), стали появляться МК-проекты. Само направление МК - тот еще зоопарк, приходится учитывать и производительность, и набортную периферию, и цену, и средства разработки, и наличие программатора, и вид корпуса, и сроки доставки (а также наличие на складах и саму возможность покупки). Тем более когда проекты идут с высокой долей наукоемких технологий, так что продается не навык МК-разработчика, а математика, способы и алгоритмы измерений... и вообще цена контроллера и всей электроники от силы 5-10% от цены изделия. Спрашивается, почему в такой ситуации, когда сроки и цены не поджимают, а поджимает как раз необходимость иметь свободно мыслящую голову и возможность приходящие мысли свободно класть в электронику, надо пользоваться тем, что "все берут"? Да, "все берут" Си для соответствующего чипа, с удовольствием настраивают периферию по готовым шаблонам, вбивают некоторое количество математики и облегченно выпускают изделие. Мне же надо разработать эту самую математику, причем она в десятки раз больше по объему и трудоемкости, чем настройка периферии, и потом на протяжении основного времени работы писать в неудобном для меня стиле. Альтернативный вариант есть, это целое направление. Называется domain-specific languages (DSL). То есть если я буду писать 10 ГРАДУСОВ ВЛЕВО 5 СЕК ЖДАТь СТАРТ, то мало того, что это мне удобно, так я еще могу показать этот текст специалисту в предметной области, который с трудом понимает Си, но прекрасно представляет, на сколько градусов надо повернуть и сколько секунд ждать. Вот это мы с ним и обсудим, а не "программа честно-честно работает правильно, вах, мамой клянус!". Как ни крути, это один из камней преткновения - предметник утверждает, что не работает из-за программиста, программист божится, что ошибка в постановки задачи, а он все сделал, как сказали. В данном случае Форт дает готовые интерпретатор и компилятор, плюс фортер обычно представляет, как с помощью CREATE DOES> создавать новые конструкции (и вообще понимает, как создавать новые конструкции управления).
Таким образом,
второй плюс Форта - высокая степень готовности к созданию проблемно-ориентированных расширений языка.
Сюда можно включать и
разработку кросс-ассемблеров (прецедент: есть чип, софт к нему платный, оплачивать и ждать минимум неделю - за это время был быстренько сделан ассемблер, на нем написано 90% функциональности проекта, так что необходимость в другом компиляторе попросту отпала). Можно и кросс-Форт, но не всегда нужен Форт именно в целевой машине. Часто достаточно просто иметь возможность транслировать ассемблер, получать образ памяти и конвертировать его в формат, пригодный для программирования. Ассемблер, опять же, не обязательно должен быть в точности по документации. Загрузить регистры, посчитать, вывести данные в порт - для этого не надо штудировать документацию и гонять тесты, убеждаясь в 100%-й совместимости с чем-либо.
Еще один, весьма важный,
третий плюс - возможность интегрирования новых технологий в реализацию Форт-транслятора. Навскидку, опять же по своему опыту
Для ДОС:
EMS, XMS, прямой вывод в видеопамять (вот по последнему - что там паскаль с графикой делал? драйвер? прямой вывод через руками написанную библиотеку - а в этом случае чем он лучше Форта?)
Для DPMI:
прямой вывод в видеопамять
Только через Linear Frame Buffer - т.е. через перевод видеокарты в режим отображения видеопамяти на линейное адресное пространство. Это опять же скорость вывода графики близкая к теоретическому пределу. Какие вообще средства разработки давали такую возможность "из коробки"? С учетом, что под DPMI32 по-хорошему работал только Watcom C...
Для Windows (уже про quark)
да-да... прямой вывод в видеопамять
Через OpenGL. Вот то самое скрывание от программиста обработки сообщений и простое рисование на экране.
реализация на ассемблере свертки через SSE. Я не знаю, насколько это значимо выглядит, скажу только, что "тяжелые" расчеты с плавающей точкой ускоряются опять-таки почти до теоретического предела. SSE работает с четырьмя парами чисел в формате short float. Спектральный и вейвлет-анализ, цифровая фильтрация, тюнинг фильтров и анализирующих функций. Все в 4 раза быстрее, чем без SSE. Умеет ли делать так используемый "здесь и сейчас" компилятор, и сможет ли он преобразовать набранный текст в SSE (а там надо массивы правильно подготовить и еще выровнять по параграфу) - отдельный вопрос. Может быть, оно после некоторых шаманских плясок как-то и подключается к Дельфи... если опять на ассемблере, то чем оно лучше Форта?
Я не говорю о сетевых и интернет-технологиях, которые в ассортименте сделаны в SPF. Я даже не говорю о возможности написать на любом другом языке все, что он существенно облегчает "из коробки", оформить это в виде dll, а потом в свое удовольствие менять параметры вызова из Форта. Тогда не придется при каждом чихе запускать навороченную IDE, пересобирать там весь проект, а потом для проверки добираться до нужного пункта через дебри меню и настроек. Корректировки, существенно меняющие порядок работы проекта, выполняются в этом случае над небольшими файлами, в простом редакторе, никакой компиляции тут не требуется, поскольку она Just-In-Time. Не запускать IDE мало - правку становится возможным делать на машине без "тяжелой" среды разработки, с одним блокнотом.
2ForthWare: обсуждать будем?
2 [All \ ForthWare] Добавлять будем?