KPG
> На поддержку и косяки купленного iForth один из разработчиков (с его слов) для
> своего проекта ругался
У iForth достаточно хорошая поддержка. Обычно письма Марцелу достаточно, чтобы получить внятное решение. Но он странный сам по себе, потому-что позиционируется как Matlab в RPN. Ещё раздражает, что он ожидает расположения исходных текстов в строго определённом месте...
> Он и 8th покупал
Охренеть. За 3 штуки баксов?
> gForth так особо и не получилось собрать до завершения всего процесса для Linux32
У меня собирается из master. Правда для ARM 32.
> не удалось стартовать штатную библиотеку графического интерфейса Minos
Minos сопровождается в объёме нужном Пейсану. Т.е. считайте её мёртвой.
> А, не разрушит ли такое развитие базисную идею Форт языка?
А так он просто сдохнет.
nbkolchin
> Охренеть. За 3 штуки баксов?
X.З
nbkolchin
> Minos сопровождается в объёме нужном Пейсану. Т.е. считайте её мёртвой.
Вероятно, т.к. сборка из последних исходников BigForth так и не появилась в дистрибутивах Linux
(вероятно, что его запустить можно только в Linux32, хотя мне удалось его собирать для запуска под Win10 с функционалом и Minos библиотеки, сейчас что то сломалось для повторения такого результата)
P.S. gForth вроде тоже не особо быстрая система среди других возможных для использования систем
да и gForth тоже в сборках Линух наблюдается в версии 0.7.3.
nbkolchin
> А так он просто сдохнет.
Да, что то не особо виден такой исход.
KPG
> gForth вроде тоже не особо быстрая система среди других возможных для
> использования систем.
Текущая версия из master по производительности сравнима с VFX и LXF, которые вообще компиляторы. 0.7.3 — восемь лет. Это у gforth такой исторически долгий разрыв между релизами...
KPG
> Да, что то не особо виден такой исход.
Вполне видно. Каких-то серьёзных проектов на форте не существует. Последний "прорывной" компилятор — LXF, вышел в 2005-м году. И с тех пор оно медленно катится в забвение.
nbkolchin
> Вполне видно. Каких-то серьёзных проектов на форте не существует. Последний
> "прорывной" компилятор — LXF, вышел в 2005-м году. И с тех пор оно медленно
> катится в забвение.
Компилятор сам по себе не может продвинуть Форт для использования среди пользователей
ориентированных на использование Питон (Бейсик) и.т.д.
Здесь нужeн какой то особенный подход.
И, раньше не было какого то значимого разработаного ПО на Форт для масс рынка.
А, вот, в рамках использования для всяких контрoллеров он вполне себе живчик.
если даже на Rust его делают. :)
P.S.тот же nncron не стал каким то значимым продуктом для использования в сравнении с пользовательской базой AutoIT.
Парадокс количества разработанных Форт систем и часто не на уровне студенческих поделок и при этом без приложения какого то проекта реализованного на них должен как то объясняться. :)
nbkolchin
> 0.7.3 — восемь лет.
а 0.7.9 когда тогда? :)
KPG
> А, вот, в рамках использования для всяких контрoллеров он вполне себе живчик.
Может лет 20 это и было актуальной информацией, а сейчас когда можно купить на сдачу пучок тех же CH582M. У них на борту 512кб флеша, 32кб оперативки и 80МГц ядро... можно не заморачиваясь писать на С++ (а если заморочиться то даже Java можно внутрь запихать).
0iStalker
> можно не заморачиваясь писать на С++
А, можно не заморачиваться и писать на Forth.
что и для них (RISC-V) уже сделано. :)
KPG
> А, можно не заморачиваться и писать на Forth.
Нельзя. Для сишечки есть отладчик, а с Фортом ты будешь играть в угадайку.
0iStalker
> Нельзя. Для сишечки есть отладчик, а с Фортом ты будешь играть в угадайку.
В какую ещё угадайку?
В Форт вполне отработаны инструменты и по отлавливанию возникающих эксепшинов.
Отладчики тоже использовать можно.
и при использовании Форт для них возможность интегрироваться с Си всегда имеется возможность.
KPG
> В какую ещё угадайку?
В обычную угадайку, без возможности пошаговой отладки и просмотра содержимого памяти и переменных
0iStalker
> В обычную угадайку, без возможности пошаговой отладки и просмотра содержимого
> памяти и переменных
Откуда такая информация?
Вот к примеру и статья Создаем ELF-файл с отладочной информацией (DWARF) вручную (для микроконтроллеров ARM) (oco 29 октября 2013)
Или даже так (2018)
KPG
> Вот к примеру и статья Создаем ELF-файл с отладочной информацией (DWARF)
> вручную (для микроконтроллеров ARM) (oco 29 октября 2013)
Примерно 99.(9)% разработчиков этой херью заниматься не будут (да даже сам автор признался, что только 30% спецификации осилил) изучать форматы отладочных файлов и далее по списку. Потому что усилия не стоят результата.
0iStalker
Путь Форта не для слабых духом разработчиков. :)
Cи в роли промежуточного языка
KPG
> Компилятор сам по себе не может продвинуть Форт для использования среди
> пользователей ориентированных на использование Питон (Бейсик) и.т.д.
Я имел ввиду, что после LXF вообще ничего не происходило.
> Здесь нужeн какой то особенный подход.
Да не надо никакого особенного подхода. Раньше (в 80-е) применение Forth было оправдано. Ничего более удобного для разработки под 8-битные процы не существовало. Компьютеры росли, компиляторы развивались и внезапно на Си стало писать удобнее. А фортовики вместо того, чтобы пытаться как-то изменится вместе с окружающим миром — закрыли глаза и делают вид, что ничего не изменилось.
А по факту, всё стало значительно хуже. Поставка F-PC/TCOM — была самодостаточной. Вместе с фортом, поставлялись библиотеки для создания и интерфейсов, и резидентных программ. А сейчас, тот же VFX имеет значительно более бедный набор "из коробки".
Народ пишет на не менее экзотических языках типа Idris и Elm. Дайте людям хоть какую-нибудь причину для разработки на Форте, кроме пафосного надувания щёк и народ потянется. Нужная вменяемая среда разработки (хоть отладчик сделайте, да?). Нужен нормальный lint, чтобы не искать два часа где у тебя стек съехал. Нужна хорошая стандартная библиотека, на уровне zig/factor/etc, потому-что не все готовы писать хеш-таблицы с нуля. Нужно стандартизованное решение по раздельной компиляции/модулям. Переделайте control-flow, потому-что сейчас достаточно памяти для хранения таблицы переходов, и не надо делать вид, что у вас по прежнему 4 килобайта на всё.
А вместо всего этого мы имеем враньё Пелка про миллион строк в секунду...
> И, раньше не было какого то значимого разработаного ПО на Форт для масс рынка.
Его было очень много в 80-е. Открываем список авторов ANS и видим всех значимых игроков — от IBM и Sun, до Boeing и DoD. Это всё реальные пользователи Forth в то время.
> А, вот, в рамках использования для всяких контрoллеров он вполне себе живчик.
Неа. Во-первых у нас рабочих фортов для встройки можно посчитать по пальцам одной руки: zeptoforth, vfx (который безобразный код генерирует для arm), flashforth и всё. Mecrisp — под GPL, коммерцию на нём нельзя. amforth — умер разработчик, умерла и система. Ещё есть stm8ef, но я его руками не трогал.
Во-вторых, перенос программы на Си для STM32F4 под Keil, на GD32 под gcc — занимает два часа. Сколько понадобится времени для такого переноса у программы на Forth? Всего-то 100 тысяч строк на асме переписать (для zeptoforth).
Ну и появление таких систем как Arduino, MicroPython, etc — значительно упростило разработку под мелкашку.
Сейчас Форт — удел фриков, потому-что разумно обосновать его использование в проекте — невозможно. Только аргументами нравится/хочется...
> если даже на Rust его делают
Так Rust язык общего назначения, у которого в отличии от плюсов нет завязок на стандартную библиотеку на уровне самого языка. А ещё он сейчас на хайпе, поэтому его во все дыры и пихают.
> а 0.7.9 когда тогда?
Это к Пейсану/Эртлу. Для Андроид уже 0.7.9 в store. И пауза между 0.6 и 0.7 была вроде ещё дольше.
nbkolchin
> А по факту, всё стало значительно хуже. Поставка F-PC/TCOM — была
> самодостаточной
Использовал AstroForth, а TCOM пробовал доделать до ANSI и для программирования PDP-11,
но, в этот момент, встретил проект FF303 и его уже использовал для PDP-11 "контроллера"