Forth и другие саморасширяющиеся системы программирования Locations of visitors to this page
Текущее время: Пт июн 22, 2018 05:38

...
Google Search
Forth-FAQ Spy Grafic

Часовой пояс: UTC + 3 часа [ Летнее время ]




Начать новую тему Ответить на тему  [ Сообщений: 255 ]  На страницу 1, 2, 3, 4, 5 ... 17  След.
Автор Сообщение
 Заголовок сообщения: Как можно эффективно использовать Форт
СообщениеДобавлено: Вс дек 09, 2007 02:39 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 6330
Благодарил (а): 14 раз.
Поблагодарили: 99 раз.
Сразу хочу отметить, что в названии темы не вопрос, а информация :) То есть я не планирую обсуждать "да или нет", а только "что именно получалось". Тема выделена в ответ на аргументы 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] Добавлять будем? :))


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Вс дек 09, 2007 04:56 
Не в сети
Moderator
Moderator
Аватара пользователя

Зарегистрирован: Чт май 04, 2006 00:53
Сообщения: 4920
Откуда: был Крым, теперь Новосибирск
Благодарил (а): 18 раз.
Поблагодарили: 56 раз.
я бы добавил этот текст в пакет СПФа в доку.
(вполне серьезно говорю)


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Вс дек 09, 2007 11:57 
Не в сети

Зарегистрирован: Вт май 09, 2006 12:31
Сообщения: 3438
Благодарил (а): 5 раз.
Поблагодарили: 16 раз.
Да, хороший текст, и системный так подход заметен :writer;
соталось сделать выводы, как оживить форт сейчас, чтобы ответить на параллельную тему. :D
Интересно, что при обсуждении (пока) не состоявшейся форт-оси многое говорилось похожее начёт интерактивности :idea:

_________________
понимаю некоторую бестолковость некоторых вопросов


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Вс дек 09, 2007 12:41 
Не в сети
Аватара пользователя

Зарегистрирован: Вт мар 20, 2007 23:39
Сообщения: 1254
Благодарил (а): 3 раз.
Поблагодарили: 16 раз.
mOleg писал(а):
я бы добавил этот текст в пакет СПФа в доку.
(вполне серьезно говорю)

Думаю это лучше сделать в конце обсуждения, т.к. вероятно еще кто-нибудь от себя добавит что-то. Потом подведем итоги, систематизируем и посмотрим что из этого всего получится, а также куда это девать.

_________________
Cтоимость сопровождения программного обеспечения пропорциональна квадрату творческих способностей программиста.
Роберт Д. Блисc


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Вс дек 09, 2007 20:02 
Не в сети

Зарегистрирован: Вс дек 02, 2007 17:31
Сообщения: 442
Благодарил (а): 0 раз.
Поблагодарили: 0 раз.
Хищник писал(а):
2ForthWare: обсуждать будем?
Обязательно! :D Очень вам благодарен за такое изложение, уверен оно будет многим на пользу! :D

Сразу скажу про название ветки, раз уж меня вспомнили в роли зачинщика. ;) Я там ставил вопрос типа: "как сделать форт привлекательным для людей которые стыкаются с ним впервые", а не о том "как его можно эффективно использовать". :shuffle; Хотя, сама статья (такое вот сообщение на статью вполне тянет ;) ) сама по себе в какой то мере может добавить этой самой привлекательности для людей которые ее прочтут. Честно, не хуже Броди! :D

Поскольку материал получился обьемным и информативным, прокомментирую чуток позже....

_________________
Am I evil? I'm man - yes I am! © James Hatefield


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Вс дек 09, 2007 21:00 
Не в сети

Зарегистрирован: Вт май 09, 2006 12:31
Сообщения: 3438
Благодарил (а): 5 раз.
Поблагодарили: 16 раз.
позволю себе пошутить:
на форуме обнаружился г-ав-тор
только выглядит он как мяв-тор :)) (смотрим хищническую аватарку)
Это очень хороший подход, основательнй, но на вопросы ответов на все концептуальные пока нет

третий плюс называется гибкость, но почему это используется для нового железа только?

_________________
понимаю некоторую бестолковость некоторых вопросов


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Вс дек 09, 2007 21:29 
Гм... я вот, не в обиду будет сказано, конструктива не увидел... Разве что использовать первый пост в рекламных целях. :) Ибо при всей своей увлекательности, ответа на вопрос "как это сделать" он не даёт. :(

Да, Форт привлекает своей возможностью применить мозги. В некоторых случаях это может дать преимущество перед другими языками. Но вот положа руку на сердце - в настоящее время время осталось РОВНО ОДНО МЕСТО, где это возможно - встраиваемые системы.

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

Тормознотусть же скриптов... Это как история про "радиус кривизны рук админа". :) Расскажу и свою байку из недавнего прошлого. Прошлым летом делали одну систему... В общем - автоматизация кислородно-компрессорной станции советского производства.

Особенности были у этого проекта... своеобразные. Во-первых, мы были субподрядчиком, во-вторых - генеральный подрядчик откровенно делал деньги и результат его не шибко интересовал.

Результат - работа без ТЗ (тут надо сказать большое "спасибо" уже нашему начальству) и чётких требований "на чём это будет крутиться". Удалось добиться, чтобы это был не один контроллер, а четыре, а вот по верхнему уровню - которым занимался лично я - такой определённости не было. В частности - допустимая лицензия на InTouch.

В общем, про что я рассказываю - мы стали пихать дискретику (сигнализацию, в основном), в 32-битные теги. А сигнализацию эту надо обрабатывать... (изначально, кстати, такое не планировалось - иначе я бы всех просто послал, но тут мне уже отступать было некуда). В общем - этим занимались автоматически сгенерированные скрипты где-то под 500..800 килобайт размером. :)

Надо признать - InTouch показал себя молодцом - никаких лагов обнаружить не удалось.

Теперь про сравнение скриптов. Сейчас мы делаем систему на WinCC. Там есть встроенные C-скрипты. Т.к. они достаточно хорошо защищают память и т.п. (ну заценили, да - прямая работа с указателями в строках и контроль обращений к памяти :) ) - известны они, в первую очередь, своей тормознутостью.

В InTouch скрипты - это изначально, видимо, "на коленке" сделанный бейсик.

Вот и скажите - чего лучше - барсик или "крутой C". Имхо - лучше прямые руки. :)

Ладно, что-то я увлёкся...

Проблемы с популярностью Форта лежат никак не в области производительности сгенерированного кода. И не в сложности освоения - он гораздо проще тех же плюсов, да и чистого "C", вообще-то.

Проблемы, на мой взгляд - в области производительности программиста. Нынешний Форт совершенно не приспособлен для построения сложных систем. Его всё равно прийдётся изменить, если вы хотите, чтобы у этого языка было будущее - вот и вся правда.


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Вс дек 09, 2007 21:29 
Не в сети

Зарегистрирован: Чт окт 25, 2007 08:01
Сообщения: 154
Благодарил (а): 0 раз.
Поблагодарили: 0 раз.
сорри - долго писал - предыдущий пост - мой


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Пн дек 10, 2007 01:54 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 6330
Благодарил (а): 14 раз.
Поблагодарили: 99 раз.
вопрос писал(а):
Это очень хороший подход, основательнй, но на вопросы ответов на все концептуальные пока нет

Ответы? На все концептуальные вопросы? Я? За вечер? :aaa;
вопрос писал(а):
третий плюс называется гибкость, но почему это используется для нового железа только?

Гибкость, да. Но за этим словом каждый видит что-то свое, и прежде чем обобщать свойство одним термином, надо говорить, говорить, говорить... пояснять, пояснять, пояснять... приводить примеры...


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Пн дек 10, 2007 02:14 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 6330
Благодарил (а): 14 раз.
Поблагодарили: 99 раз.
Гость писал(а):
Ибо при всей своей увлекательности, ответа на вопрос "как это сделать" он не даёт.

"Как это сделать" - это процесс, а не состояние :) Ну на то мы здесь и собрались. Перед оформлением мыслей всегда есть этап размышлений, проб, постепенной систематизации материала... а как иначе? Появляются интуитивные ощущения, что вот эта задача - для Форта, а вот тут модуль написали - так он какой-то не-фортовский. "Как это сделать", я примерно представляю, правда, в круге своих задач. Выдать в тексте, чтобы все сразу согласились - а так вообще бывает? Да и сложная это работа - писать систематизирующие обзоры.
Гость писал(а):
Да, Форт привлекает своей возможностью применить мозги. В некоторых случаях это может дать преимущество перед другими языками. Но вот положа руку на сердце - в настоящее время время осталось РОВНО ОДНО МЕСТО, где это возможно - встраиваемые системы.

Ну почему бы и не так? Место-то огромное, есть где развернуться :pilot2; Впрочем, для дальнейшего размышления могу подкинуть идею с моделированием сложных систем на PC - там встречается достаточно активная динамика в процессе выбора и описания моделей, часто требуется контроль произвольной глубины - от задания серии вычислительных экспериментов до введения уточнений в модели нижнего уровня.
Гость писал(а):
"Прямые" скрипты - это замечательно, но, как показывает практика, сейчас их пишут все кому не лень. Даже те, кто никогда не слышал про теорию компиляторов, да и вообще ни про что не слышал, окромя Delphi.

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

Совершенно согласен. Только программисту не надо наперебой предлагать коробки с дополнительными расширениями, все равно под все области применения их не напастись. Лучше дать "удочку" - методики расширения языка и примеры, а дальше грамотный специалист и сам разберется, что ему добавить в язык, чтобы все получалось. Обмен информацией по таким системам будет способствовать кумулятивному накоплению навыков, примеров и методик. Наблюдаю на группе из 4 активно пишущих фортеров - удачные решения мгновенно выделяются и начинают кочевать из проекта в проект. Причем часто обсуждается именно идея, а набивку кода каждый делает сам (в своем стиле, своим синтаксисом, да еще включая сразу и зрительную, и моторную память, так что никакого унылого штудирования "док к либам" потом не бывает - каждый и так в целом помнит, где что лежит и как править). А что же будет при наличии "группы групп"? Собственно, чего мяться около проблемы "можно или низзя писать", аки корнет около вдовы? :)) Надо действовать в стиле Ржевского, а познакомиться можно и наутро :)) Сделан проект - пишем о нем в success stories! Кстати, вот и раздел форума - по одному проекту на тему, где автор будет описывать, как ему Форт помог решить задачу.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Пн дек 10, 2007 02:55 
Не в сети

Зарегистрирован: Чт ноя 23, 2006 00:44
Сообщения: 311
Откуда: СПб
Благодарил (а): 7 раз.
Поблагодарили: 4 раз.
K`[f писал(а):
сорри - долго писал - предыдущий пост - мой

Офф-топик!
Привет "коллега"! :) На предыдущей работе весьма "активно" использовали InTouch 7.11 и даже застал 8-ку. Кста, даже написал "отладчик" (win-GUI) для оного на SPF4 (правда по протоколу DDE).

To: Хищник
По поводу GUI и интерактивности.
Требовалось срочно (дело было в командировке на объекте) выявить ошибку в протоколе обмена (RS-485), проблема была решена макс. за 1/2 часа написанием на SPF-е "шпиёна", который подслушивал (и писал в лог) обмен по магистрали!
И ессно безо всякого GUI.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Пн дек 10, 2007 09:51 
Не в сети

Зарегистрирован: Чт окт 25, 2007 08:01
Сообщения: 154
Благодарил (а): 0 раз.
Поблагодарили: 0 раз.
Хищник писал(а):
Ну почему бы и не так? Место-то огромное, есть где развернуться pilot2


Тут одна беда - далеко не все этим занимаются (я бы вот хотел, но ныне работаю в совершенно иной области :( ), а те кто занимаются либо уже используют Форт, либо (и часто так и есть) худо-бедно осваивают ассемблер и на том успокаиваются. Популярности Форту это точно не прибавит.

Хищник писал(а):
Однако имеют то преимущество, что не пытаются сделать все с нуля, получая в итоге скриптовый язык, скособоченный в сторону наиболее удачных соображений автора.


Если у автора с головой всё в порядке, то получается решение не хуже, чем на Форте, к тому же не требующее танцев с бубном "как его прикрутить". Это в частных случаях. Если же нужно общее решение, то обычно используют lua или ещё что-нибудь такое.

Хищник писал(а):
Лучше дать "удочку" - методики расширения языка и примеры, а дальше грамотный специалист и сам разберется, что ему добавить в язык, чтобы все получалос


У Форта и сейчас нет никаких проблем с расширяемостью. Однако популярности это ему не добавило. :(

Я считаю, что Форт следует изменить, ориентируясь, в том числе, на современно состояние компьютерного железа. Сейчас ситуация такая, что прога для микроконтроллера, скорее всего, будет без проблем писаться на боле-менее стандартном Форте. А вот более сложная система на том же "писюке" - нет. Если ситуацию оставить в текущем положении, то ещё лет через десять Форт будет восприниматься, наверное, почти исключительно как язык для микроконтроллеров.

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

Я неоднократно уже на этом форуме предлагал попробовать ввести несколько стеков - в первую очередь, чтобы они ВСЕГДА были под контролем программиста - стек чисел с плавающей точкой, стек адресов, стек структур управления - и они должны быть ИМЕНННО раздельными. Важно - попробовать это решение в деле, я не призываю все всё бросить и заниматься этой идеей. Без опробации не стоит и рассматривать её серъёзно.

Но даже такое развитие не решит полностью проблемы уровня абстракции - нужно думать над чем-то ещё... Кто-то ведь предлагал решение с разделением слов немедленного исполнения? А это ещё один из источников путаницы...

Ilya писал(а):
Кста, даже написал "отладчик" (win-GUI) для оного на SPF4 (правда по протоколу DDE).


Я написал за пару месяцев хорошую обёртку к DDE на плюсах - интересная была задача. :) Воистину - если что-то делается через задницу, то это, скорее всего, оборачивание обёрток мелкософта. :)

Судя по всему, основной недостаток DDE с их точки зрения - слишком он уж простой. :)


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Пн дек 10, 2007 10:27 
Не в сети

Зарегистрирован: Вт май 09, 2006 12:31
Сообщения: 3438
Благодарил (а): 5 раз.
Поблагодарили: 16 раз.
Цитата:
Кажется, небольшая проблема - все не раз так делали и достаточно успешно - но вспомните - так ли просто всегда определить, что данные на стеке - мусор, не относящийся к делу? Теперь сравните эту ситуацию с обычным "C" - строго заданный набор переменных.

Я уе предлагал, ничего не меняя в работе Форта изменить запись - просто поименовать переменные на стеке и вызывать слово как функцию в С++ function(first_value, second_value, ...). Разницы для Форта - никакой - переменные И ТАК уже лежат как-раз на стеке , разница только для программиста, что-то это не понравилось :o

_________________
понимаю некоторую бестолковость некоторых вопросов


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Пн дек 10, 2007 10:47 
Не в сети
Moderator
Moderator

Зарегистрирован: Ср май 10, 2006 15:37
Сообщения: 1132
Откуда: Chelyabinsk ( Ural)
Благодарил (а): 0 раз.
Поблагодарили: 9 раз.
вопрос писал(а):
Цитата:
Кажется, небольшая проблема - все не раз так делали и достаточно успешно - но вспомните - так ли просто всегда определить, что данные на стеке - мусор, не относящийся к делу? Теперь сравните эту ситуацию с обычным "C" - строго заданный набор переменных.

Я уе предлагал, ничего не меняя в работе Форта изменить запись - просто поименовать переменные на стеке и вызывать слово как функцию в С++ function(first_value, second_value, ...). Разницы для Форта - никакой - переменные И ТАК уже лежат как-раз на стеке , разница только для программиста, что-то это не понравилось :o


Прежде всего теряем гибкость при последующих возможных изменениях
текущего кода из-за фиксации синтаксиса:)


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Пн дек 10, 2007 11:34 
Не в сети

Зарегистрирован: Ср сен 13, 2006 10:06
Сообщения: 636
Откуда: Омск
Благодарил (а): 0 раз.
Поблагодарили: 3 раз.
Не навижу когда откомпилированный код выглядит как черный ящик. Вот из-за этого мне нравится асм и forth, люблю что бы было все под контролем. А что там "насрут" другие языки при компиляции, меня раздражает разбирать. Для меня главное что было просто и понятно, а не просто и ХЗ как.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 255 ]  На страницу 1, 2, 3, 4, 5 ... 17  След.

Часовой пояс: UTC + 3 часа [ Летнее время ]


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 3


Вы не можете начинать темы
Вы можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
phpBB сборка от FladeX // Русская поддержка phpBB