Forth http://fforum.winglion.ru/ |
|
Как можно эффективно использовать Форт http://fforum.winglion.ru/viewtopic.php?f=4&t=1065 |
Страница 1 из 17 |
Автор: | Hishnik [ Вс дек 09, 2007 02:39 ] |
Заголовок сообщения: | Как можно эффективно использовать Форт |
Сразу хочу отметить, что в названии темы не вопрос, а информация То есть я не планирую обсуждать "да или нет", а только "что именно получалось". Тема выделена в ответ на аргументы 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] Добавлять будем? |
Автор: | mOleg [ Вс дек 09, 2007 04:56 ] |
Заголовок сообщения: | |
я бы добавил этот текст в пакет СПФа в доку. (вполне серьезно говорю) |
Автор: | вопрос [ Вс дек 09, 2007 11:57 ] |
Заголовок сообщения: | |
Да, хороший текст, и системный так подход заметен соталось сделать выводы, как оживить форт сейчас, чтобы ответить на параллельную тему. Интересно, что при обсуждении (пока) не состоявшейся форт-оси многое говорилось похожее начёт интерактивности |
Автор: | VoidVolker [ Вс дек 09, 2007 12:41 ] |
Заголовок сообщения: | |
mOleg писал(а): я бы добавил этот текст в пакет СПФа в доку.
(вполне серьезно говорю) Думаю это лучше сделать в конце обсуждения, т.к. вероятно еще кто-нибудь от себя добавит что-то. Потом подведем итоги, систематизируем и посмотрим что из этого всего получится, а также куда это девать. |
Автор: | Forthware [ Вс дек 09, 2007 20:02 ] |
Заголовок сообщения: | |
Хищник писал(а): 2ForthWare: обсуждать будем? Обязательно! Очень вам благодарен за такое изложение, уверен оно будет многим на пользу!
Сразу скажу про название ветки, раз уж меня вспомнили в роли зачинщика. Я там ставил вопрос типа: "как сделать форт привлекательным для людей которые стыкаются с ним впервые", а не о том "как его можно эффективно использовать". Хотя, сама статья (такое вот сообщение на статью вполне тянет ) сама по себе в какой то мере может добавить этой самой привлекательности для людей которые ее прочтут. Честно, не хуже Броди! Поскольку материал получился обьемным и информативным, прокомментирую чуток позже.... |
Автор: | вопрос [ Вс дек 09, 2007 21:00 ] |
Заголовок сообщения: | |
позволю себе пошутить: на форуме обнаружился г-ав-тор только выглядит он как мяв-тор :)) (смотрим хищническую аватарку) Это очень хороший подход, основательнй, но на вопросы ответов на все концептуальные пока нет третий плюс называется гибкость, но почему это используется для нового железа только? |
Автор: | Гость [ Вс дек 09, 2007 21:29 ] |
Заголовок сообщения: | |
Гм... я вот, не в обиду будет сказано, конструктива не увидел... Разве что использовать первый пост в рекламных целях. Ибо при всей своей увлекательности, ответа на вопрос "как это сделать" он не даёт. Да, Форт привлекает своей возможностью применить мозги. В некоторых случаях это может дать преимущество перед другими языками. Но вот положа руку на сердце - в настоящее время время осталось РОВНО ОДНО МЕСТО, где это возможно - встраиваемые системы. "Прямые" скрипты - это замечательно, но, как показывает практика, сейчас их пишут все кому не лень. Даже те, кто никогда не слышал про теорию компиляторов, да и вообще ни про что не слышал, окромя Delphi. Тормознотусть же скриптов... Это как история про "радиус кривизны рук админа". Расскажу и свою байку из недавнего прошлого. Прошлым летом делали одну систему... В общем - автоматизация кислородно-компрессорной станции советского производства. Особенности были у этого проекта... своеобразные. Во-первых, мы были субподрядчиком, во-вторых - генеральный подрядчик откровенно делал деньги и результат его не шибко интересовал. Результат - работа без ТЗ (тут надо сказать большое "спасибо" уже нашему начальству) и чётких требований "на чём это будет крутиться". Удалось добиться, чтобы это был не один контроллер, а четыре, а вот по верхнему уровню - которым занимался лично я - такой определённости не было. В частности - допустимая лицензия на InTouch. В общем, про что я рассказываю - мы стали пихать дискретику (сигнализацию, в основном), в 32-битные теги. А сигнализацию эту надо обрабатывать... (изначально, кстати, такое не планировалось - иначе я бы всех просто послал, но тут мне уже отступать было некуда). В общем - этим занимались автоматически сгенерированные скрипты где-то под 500..800 килобайт размером. Надо признать - InTouch показал себя молодцом - никаких лагов обнаружить не удалось. Теперь про сравнение скриптов. Сейчас мы делаем систему на WinCC. Там есть встроенные C-скрипты. Т.к. они достаточно хорошо защищают память и т.п. (ну заценили, да - прямая работа с указателями в строках и контроль обращений к памяти ) - известны они, в первую очередь, своей тормознутостью. В InTouch скрипты - это изначально, видимо, "на коленке" сделанный бейсик. Вот и скажите - чего лучше - барсик или "крутой C". Имхо - лучше прямые руки. Ладно, что-то я увлёкся... Проблемы с популярностью Форта лежат никак не в области производительности сгенерированного кода. И не в сложности освоения - он гораздо проще тех же плюсов, да и чистого "C", вообще-то. Проблемы, на мой взгляд - в области производительности программиста. Нынешний Форт совершенно не приспособлен для построения сложных систем. Его всё равно прийдётся изменить, если вы хотите, чтобы у этого языка было будущее - вот и вся правда. |
Автор: | K`[f [ Вс дек 09, 2007 21:29 ] |
Заголовок сообщения: | |
сорри - долго писал - предыдущий пост - мой |
Автор: | Hishnik [ Пн дек 10, 2007 01:54 ] |
Заголовок сообщения: | |
вопрос писал(а): Это очень хороший подход, основательнй, но на вопросы ответов на все концептуальные пока нет Ответы? На все концептуальные вопросы? Я? За вечер? вопрос писал(а): третий плюс называется гибкость, но почему это используется для нового железа только?
Гибкость, да. Но за этим словом каждый видит что-то свое, и прежде чем обобщать свойство одним термином, надо говорить, говорить, говорить... пояснять, пояснять, пояснять... приводить примеры... |
Автор: | Hishnik [ Пн дек 10, 2007 02:14 ] |
Заголовок сообщения: | |
Гость писал(а): Ибо при всей своей увлекательности, ответа на вопрос "как это сделать" он не даёт. "Как это сделать" - это процесс, а не состояние Ну на то мы здесь и собрались. Перед оформлением мыслей всегда есть этап размышлений, проб, постепенной систематизации материала... а как иначе? Появляются интуитивные ощущения, что вот эта задача - для Форта, а вот тут модуль написали - так он какой-то не-фортовский. "Как это сделать", я примерно представляю, правда, в круге своих задач. Выдать в тексте, чтобы все сразу согласились - а так вообще бывает? Да и сложная это работа - писать систематизирующие обзоры. Гость писал(а): Да, Форт привлекает своей возможностью применить мозги. В некоторых случаях это может дать преимущество перед другими языками. Но вот положа руку на сердце - в настоящее время время осталось РОВНО ОДНО МЕСТО, где это возможно - встраиваемые системы. Ну почему бы и не так? Место-то огромное, есть где развернуться Впрочем, для дальнейшего размышления могу подкинуть идею с моделированием сложных систем на PC - там встречается достаточно активная динамика в процессе выбора и описания моделей, часто требуется контроль произвольной глубины - от задания серии вычислительных экспериментов до введения уточнений в модели нижнего уровня. Гость писал(а): "Прямые" скрипты - это замечательно, но, как показывает практика, сейчас их пишут все кому не лень. Даже те, кто никогда не слышал про теорию компиляторов, да и вообще ни про что не слышал, окромя Delphi. То есть в итоге работают над разновидностями таких систем, ярким представителем которых является Форт? Так это прекрасно, значит, фортеры как раз в центре событий и обладают нужными навыками в полной мере. Однако имеют то преимущество, что не пытаются сделать все с нуля, получая в итоге скриптовый язык, скособоченный в сторону наиболее удачных соображений автора. В Форте все же разные моменты представлены достаточно ровно, и даже если не быть крутым гуру во всем, можно сделать какой-то кусок системы "как у всех". А вот у наколенного скриптового языка в этом месте возможен существенный провал. Гость писал(а): Проблемы, на мой взгляд - в области производительности программиста. Нынешний Форт совершенно не приспособлен для построения сложных систем. Его всё равно прийдётся изменить, если вы хотите, чтобы у этого языка было будущее - вот и вся правда.
Совершенно согласен. Только программисту не надо наперебой предлагать коробки с дополнительными расширениями, все равно под все области применения их не напастись. Лучше дать "удочку" - методики расширения языка и примеры, а дальше грамотный специалист и сам разберется, что ему добавить в язык, чтобы все получалось. Обмен информацией по таким системам будет способствовать кумулятивному накоплению навыков, примеров и методик. Наблюдаю на группе из 4 активно пишущих фортеров - удачные решения мгновенно выделяются и начинают кочевать из проекта в проект. Причем часто обсуждается именно идея, а набивку кода каждый делает сам (в своем стиле, своим синтаксисом, да еще включая сразу и зрительную, и моторную память, так что никакого унылого штудирования "док к либам" потом не бывает - каждый и так в целом помнит, где что лежит и как править). А что же будет при наличии "группы групп"? Собственно, чего мяться около проблемы "можно или низзя писать", аки корнет около вдовы? Надо действовать в стиле Ржевского, а познакомиться можно и наутро Сделан проект - пишем о нем в success stories! Кстати, вот и раздел форума - по одному проекту на тему, где автор будет описывать, как ему Форт помог решить задачу. |
Автор: | Ilya [ Пн дек 10, 2007 02:55 ] |
Заголовок сообщения: | |
K`[f писал(а): сорри - долго писал - предыдущий пост - мой
Офф-топик! Привет "коллега"! На предыдущей работе весьма "активно" использовали InTouch 7.11 и даже застал 8-ку. Кста, даже написал "отладчик" (win-GUI) для оного на SPF4 (правда по протоколу DDE). To: Хищник По поводу GUI и интерактивности. Требовалось срочно (дело было в командировке на объекте) выявить ошибку в протоколе обмена (RS-485), проблема была решена макс. за 1/2 часа написанием на SPF-е "шпиёна", который подслушивал (и писал в лог) обмен по магистрали! И ессно безо всякого GUI. |
Автор: | K`[f [ Пн дек 10, 2007 09:51 ] |
Заголовок сообщения: | |
Хищник писал(а): Ну почему бы и не так? Место-то огромное, есть где развернуться pilot2 Тут одна беда - далеко не все этим занимаются (я бы вот хотел, но ныне работаю в совершенно иной области ), а те кто занимаются либо уже используют Форт, либо (и часто так и есть) худо-бедно осваивают ассемблер и на том успокаиваются. Популярности Форту это точно не прибавит. Хищник писал(а): Однако имеют то преимущество, что не пытаются сделать все с нуля, получая в итоге скриптовый язык, скособоченный в сторону наиболее удачных соображений автора. Если у автора с головой всё в порядке, то получается решение не хуже, чем на Форте, к тому же не требующее танцев с бубном "как его прикрутить". Это в частных случаях. Если же нужно общее решение, то обычно используют lua или ещё что-нибудь такое. Хищник писал(а): Лучше дать "удочку" - методики расширения языка и примеры, а дальше грамотный специалист и сам разберется, что ему добавить в язык, чтобы все получалос У Форта и сейчас нет никаких проблем с расширяемостью. Однако популярности это ему не добавило. Я считаю, что Форт следует изменить, ориентируясь, в том числе, на современно состояние компьютерного железа. Сейчас ситуация такая, что прога для микроконтроллера, скорее всего, будет без проблем писаться на боле-менее стандартном Форте. А вот более сложная система на том же "писюке" - нет. Если ситуацию оставить в текущем положении, то ещё лет через десять Форт будет восприниматься, наверное, почти исключительно как язык для микроконтроллеров. Как мне кажется, в нынешнем Форте мало средств абстракции данных. Сравните - если в Форте на вход слова приходит непонятно что, то мы, в общем случае, не можем даже предположить, откуда оно пришло и что означает. Нужно возвращаться назад по ходу движения программы и т.п. Кажется, небольшая проблема - все не раз так делали и достаточно успешно - но вспомните - так ли просто всегда определить, что данные на стеке - мусор, не относящийся к делу? Теперь сравните эту ситуацию с обычным "C" - строго заданный набор переменных. И если в них что-то лежит, значит - компилятор по какой-то причине вычислил эти значения. Если там мусор - значит, по каким-то соображениям мы применяли "хак" системы (типа сложной адресной арифметики) и копать в первую очередь надо именно туда. Последняя ситуация в Форте является штатной. Я неоднократно уже на этом форуме предлагал попробовать ввести несколько стеков - в первую очередь, чтобы они ВСЕГДА были под контролем программиста - стек чисел с плавающей точкой, стек адресов, стек структур управления - и они должны быть ИМЕНННО раздельными. Важно - попробовать это решение в деле, я не призываю все всё бросить и заниматься этой идеей. Без опробации не стоит и рассматривать её серъёзно. Но даже такое развитие не решит полностью проблемы уровня абстракции - нужно думать над чем-то ещё... Кто-то ведь предлагал решение с разделением слов немедленного исполнения? А это ещё один из источников путаницы... Ilya писал(а): Кста, даже написал "отладчик" (win-GUI) для оного на SPF4 (правда по протоколу DDE).
Я написал за пару месяцев хорошую обёртку к DDE на плюсах - интересная была задача. Воистину - если что-то делается через задницу, то это, скорее всего, оборачивание обёрток мелкософта. Судя по всему, основной недостаток DDE с их точки зрения - слишком он уж простой. |
Автор: | вопрос [ Пн дек 10, 2007 10:27 ] |
Заголовок сообщения: | |
Цитата: Кажется, небольшая проблема - все не раз так делали и достаточно успешно - но вспомните - так ли просто всегда определить, что данные на стеке - мусор, не относящийся к делу? Теперь сравните эту ситуацию с обычным "C" - строго заданный набор переменных.
Я уе предлагал, ничего не меняя в работе Форта изменить запись - просто поименовать переменные на стеке и вызывать слово как функцию в С++ function(first_value, second_value, ...). Разницы для Форта - никакой - переменные И ТАК уже лежат как-раз на стеке , разница только для программиста, что-то это не понравилось |
Автор: | Kopa [ Пн дек 10, 2007 10:47 ] |
Заголовок сообщения: | |
вопрос писал(а): Цитата: Кажется, небольшая проблема - все не раз так делали и достаточно успешно - но вспомните - так ли просто всегда определить, что данные на стеке - мусор, не относящийся к делу? Теперь сравните эту ситуацию с обычным "C" - строго заданный набор переменных. Я уе предлагал, ничего не меняя в работе Форта изменить запись - просто поименовать переменные на стеке и вызывать слово как функцию в С++ function(first_value, second_value, ...). Разницы для Форта - никакой - переменные И ТАК уже лежат как-раз на стеке , разница только для программиста, что-то это не понравилось Прежде всего теряем гибкость при последующих возможных изменениях текущего кода из-за фиксации синтаксиса:) |
Автор: | Pretorian [ Пн дек 10, 2007 11:34 ] |
Заголовок сообщения: | |
Не навижу когда откомпилированный код выглядит как черный ящик. Вот из-за этого мне нравится асм и forth, люблю что бы было все под контролем. А что там "насрут" другие языки при компиляции, меня раздражает разбирать. Для меня главное что было просто и понятно, а не просто и ХЗ как. |
Страница 1 из 17 | Часовой пояс: UTC + 3 часа [ Летнее время ] |
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/ |