А теперь устраивает? Раз "использую..."?


т.е. это провокационные замечания?

Так что с ним не так? Что именно не получилось хорошо сделать?

негуманно это - такие опыты на фортерах. Их и так мало осталось.. а вы... эх..


1. Можно подробнее про связь C# и Smalltalk? Для меня это какой-то оксюморон...
2. Видел и тот и тот. Как это связано с Фортом и его декларируемой "гнусностью"? Smalltalk красивый язык - но другой.
3. Интересно - эти языки альтернатива Форту для встраиваемых систем?

Можно подробнее? Какие test-suites, на что, на Форт вообще или на какую-то конкретную систему или на прогу?

В FAQ !!!

я экспериментировал с интерпретируемой реализацией -- выполнение всех команд логгил в текстовый файл: адрес, команда, указатели регистров, входные/выходные данные на стеке для каждой команды

потом полученный лог сравнивал с этим как его, не оригинальным, а ... эталоным, целиком или кусками используя regexpы скриптамина Python

на роль test-suite не подходит ?

м-да, решили задать вопрос "а что ты сделал для хип-хопа?"

in4

после обработки напильником и переписывания под целевое приложение - устраивает
но при этом часто приходится менять и внутренний интерпретатор, думать над форматом заголовка слов (особенно если у нас ПЗУ и ОЗУ)
по факту, у нас в руках вместо конкретного программного пакета есть лишь идеология "ноу-хау", не в смысле изобретения, а в смысле инженерного метода

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


я имею право высказать своё мнение, даже если его считают провокационным

yGREK

как фортер фортеру скажу - нам нужна встряска

forth@km.ru

была бы отличная примочка, скажем, к Win32Forth.

Да-да, нужна!
"Только повалуфта вубы не фыбифайте!" (c)..

Честно говоря, из сказанного ничего не понял. Чего надо обрабатывать напильником?
что переписывать? когда и зачем?
Для конкретного разговора нужно изложить вашу методику.
Лучше, конечно предоставить исходники.
Неоспоримым аргументом в пользу Форта является его расширяемость до
любого другого языка программирования. Но это его потенциальное
преимущество. LCC для Форта я сделал но получаемый код мягко говоря не оптимизирован.
Единственный недостаток Форта это неразвитость в следствии экономической проблемы.
Проблема заключается в том, что производители не заинтересованы
чтобы их пользователи могли сами о себе позоботится.

Решение проблемы:

http://action.nclug.ru/plugins/content/ ... ?content.5

По указанной ссылке решение проблемы не находится.

Mihail

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


Странная трактовка "экономической проблемы". Может быть, дело обстоит в том, что Форт как продукт из-за неразвитости в базовом варианте не выдерживает конкуренции?

Так в чем причина этой неразвитости?

У Форта есть ряд фундаментальных недостатков, которые не позволили ему завоевать место под солнцем. А я, блин, помню ещё обзоры (конец 1980-х), по которым Форт занимал 4-е место по популярности! (а сейчас у него на том же SF 30-е место по числу проектов!).

Главный фундаментальный недостаток - это его гибкость. Он не может не позволить программисту писать плохо. А подавляющее большинство программистов именно так и пишут, увы.

Чем дальше, тем больший вес набирают семантически жёсткие языки.

Неудивительно, что на рынке никому не нужен продукт, на котором средний программист будет писать плохо читаемый, низконадёжный и медленный код.

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

А это не будет похоже на "Сам себе ГИБДД-шник"?
Т.е. самоограничением, которое просто будет лениво соблюдать?

Но это будет уже _не Форт_. К тому же - _можно_. А не _уже есть_. Где стандарт на это решение?

Увы, нет, и слава Богу, не будет.

Поэтому и Форту не бывать в мэйнстриме.

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

Да вот вам PostScript. Стековая машина. Манипуляция стеком. Форт ли это? Если да - радуйтесь, вот вам готовый мэйнстрим. Что, не слышно радости? И понятно. Ибо это - _не Форт_

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


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