Предлагаю в рамках "мозгового штурма" рассмотреть основные тенденции развития транслятора Форта на примере кварка.

Основные возможности и желательности,? Тенденции - чаще из области анализа истории.

Именно тенденции. Потому что "желательности", как правило, бессистемны и не обязательно реальны на данном этапе. Поэтому сначала надо, как у кэрроловской Алисы, понять, где мы, чтобы разобраться, куда надо идти, чтобы попасть, куда нужно. Вот эта мысленно нарисованная стрелочка и будет "тенденцией" (кстати, надо еще понять, куда она будет вести). При всем при том "основные возможности" выступают как use cases, то есть некие в общих чертах формулируемые сценарии взаимодействия с будущим продуктом.

Склонен ли Хищник видеть в развитиии Кварка развитие языка (расширяемый как-никак) или только развитие транслятора?

Эти направления для меня выглядят не вполне сопоставимыми. Развитие языка - несколько обтекаемая формулировка. Что это такое? Добавление новых ключевых слов? Переделки движка? Привязка грамматики к текущим особенностям аппаратуры и ОС? Генерация некоей вычурности, чтобы регулярно создавать эффект "развития"? Все это мне видится совершенно лишним, и создающим общий эффект "я такой странный, такой странный, что лучше не трогайте меня, а то я буду громко апеллировать к тому, что меня не понимают из-за моей странности". При этом "развитие транслятора" на деле заключается в реализации тех технических характеристик, которые оказались востребованы при выполнении предыдущей серии проектов, а критерии "развития" - успешное выполнение следующей их серии

Вот жене на НГ подарил в числе прочего HDD на 1 Тб. Старый остался в том же десктопе. Она попросила поставить бекап личных документов со старого диска по расписанию. Первым движением было поставить nnCron+nnBackup. Скачал. Под Вистой не идет. Все, bye-bye, и неужто я буду разбираться, почему оно там не работает, что патчить и какие логи смотреть? Скачал что-то бесплатное, с графическим интерфейсом, оно на ура бекапит и каши не просит. Да, "стрррашные мегабайты" дистрибутива, "надоевшие единообразные окна", "куча места в памяти". Ну и что? А spf не запустился. Поэтому все "стандартности де-факто" и "развитости языка" идут лесом. И я не буду разбираться, что именно там не работает.

Ближе к теме, плииз.

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

Использую кварк с самых первых бета-версий. От версии к версии постепенно расширялся лексикон работы с графикой - сначала появились 2D примитивы, потом появилась возможность использования 3D через OpenGL API. Параллельно расширялись лексиконы математики и примитивов, добавлялись новые управляющие конструкции. Были "открыты" некоторые внутренние механизмы - доступ к дополнительным стекам, переменным. И конечно же было исправлено множество багов и недочетов. Было написано множество библиотек - но они в разнобой лежат на форуме и у других пользователей.

Так ведь не об этом речь "Приехать из Петербурга в Москву" - это заменить Невский, Эрмитаж, коняшек Клодта и музей Пушкина на Мойке на Арбат, Кремль, Останкинскую башню. А не "давайте посчитаем станции по пути, число шпал и узнаем номер вагона". Это уже технические детали реализации. А чтобы понять, откуда они взялись, почему такие, и правильно ли это, надо вычленить основные характеристики "программ вообще", и "программ на Форте" в частности. Какие они становятся? Чем отличаются от предыдущего поколения? Какие ожидания на будущее? Именно от программ, а не, скажем, "ой, как бы хорошо, если бы была визуальная среда разработки".

по поводу приложений и их характеристик можно глянуть например
[url]
http://www.quorus.ru/_img/_newstape_67.pdf [/url] стр.28.

или через гугль - "Павел Анни. Многопотоковые системы на архитектуре sparc."

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

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

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

А можно эту же аналогию расшифровать прямым текстом?

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

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

Да легко Многие программисты уподобляются водителю из анекдота, который едет в тумане за габаритными огнями впередиидущей машины, и удивляется, почему она вдруг остановилась. А ее водитель ничем не может помочь, потому что он уже приехал к себе в гараж Это происходит примерно так - читаются новости из мира "большого программирования", оттуда собирается некий образ "перспективных технологий". И все это хочется срочно притащить в Форт, потому что... ну непонятно почему - оно как красивая машинка, которую очень хочется покатать по полу. Результат, как правило, одинаковый - много флейма на этапе обсуждения, потому что все на этом этапе и заканчивается, несмотря на то, что приведенный рабочий код и примеры бенчмарков в такой ситуации были бы прямо-таки убийственными аргументами.

Причем и этого мало. Бенчмарки тоже бывают разными. Бывают, например, такие, которые специально подбираются, чтобы показать привлекательность некоей идеи. Несколько странно - вообще-то идеи служат результатом анализа возникшей проблемной ситуации, а не примеры ситуаций подбираются, чтобы демонстрировать, что идея весьма хороша. А когда автор слишком прикипает к своей идее, она оказывается жизнеспособной только пока автор прилагает усилия к ее существованию. Не "продвижению", а элементарному существованию. Проще говоря, пока он сам пишет какие-нибудь "конвейеризованные многопоточные древовидные мини-апплеты", они и существуют. Перестанет писать - ни у кого больше к этой теме интереса не проявится. Тут можно надуться и сказать "они бяки", причем с Фортом такое сделать куда как просто - "фортеров мало, каждый в своем углу, объединяться [под моим мудрым руководством] не хотят, и вообще в программировании глубокий кризис". Вот и получается, что сиюминутные блестящие программистские игрушки мешают подняться над ситуацией и отстраненно проанализировать, что же именно надо писать, и в какую сторону изменять характеристики программ.

Тут надо еще раз отметить, что оценки "оо, да, надо срочно IDE", или "все пишут на Ruby, это перспективно" соответствуют обсуждению машинок с соседским мальчиком. А у того "свои машинки". Вот и получаются, что самые распрекрасные идеи, имеющие подспудную цель "похвалиться игрушкой", вызывают не вал благодарных последователей, а... похвальбу другими игрушками

Я не буду сейчас пытаться сформулировать "как правильно", но для затравки дам припомненную информацию, которую я прочитал на неплохом сайте компании, занимающейся разработкой ПО. Там, в частности, их игровое отделение, когда составляло перспективные планы, ориентировалось на информацию от издателей (барабанная дробь): "делайте "3 в ряд". ВСЕ! Не "RPG на С++ с эльфийской магией и четырехэтажным подвалом с гоблинами", не "чтобы там были элементы ActiveX", и даже не "под Symbian". А просто - 3 в ряд. Вот это, на мой взгляд, подходящий пример той оценки рынка, из которой можно вытянуть что-то путное.

Было бы здорово, если бы были расширины коммуникационные возможности QUARKа: поддержка tcp-соединений. Сейчас мы имеем две
формы: в виде DLL и консоль с GL окном в виде exe модуля. Например дав команду 4000 LISTEN поднимаем tcp-сервер, который
слушает 4000 порт и получив например GET запрос раскодирует его и подает в буфер для EVALUATE. Ну и в обратную сторону, чтобы
QUARK мог бы поднять сокет и коннектиться к произвольному серверу.
Не гонясь за эффективностью, для эксперимента можно попробовать сделать следующую форму QUARKа, похожую на Протон, но имеющую
только одно GL-окно и несколько кнопок/контролов - загрузить файл, запустить tcp-сервер, установить коннект, сохранить состояние.
В Лазарусе есть необходимые сетевые компоненты, вот их бы и интегрировать и обвязать с существующим QUARK dll.
Мне кажется это дало бы возможность строить на основе кварка различные мониторинговые, диагностические, управляющие системы
используя его хорошие графические средства.