Не очень я все же понимаю, что можно описывать в плане визуальной составляющей. Тут видимо без примера не обойтись.


Netspirit, завязывать пора. Честно. Либо тема просто не читается, либо, как сказал один товарищ - "мы с вами в разных плоскостях находимся". А если по русски - я ему про Фому, а он про Ерёму. Я выше писал только про разработчиков среды и пакета, только про перспективы для разработчика, только о том, почему одни решения плохи для разработки, а другие хороши. Пакет может быть популярным даже будучи написанным на Assembler, да даже на Brain Fuck его написать можно при желании и сделать популярным у пользователей. Дальше-то что?


Потеря аудитории пакета, который использует Pascal под капотом - это вопрос времени. Как именно это происходит - я выше тоже писал.


Потому что это две сущности, которые в идеале не должны быть связаны вообще никак и в идеале должны разрабатываться абсолютно разными командами. Если у разработчика не будет данной установки в голове, то он начнет пились среду под свой пакет, а это не правильно. В экосистеме HiAsm обязательно должно должна быть консольная версия, GUI версия, WEB версия и пакеты, которые все эти три утилиты смогут открыть, показать и собрать. И никак иначе.


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


А тут много людей, которые хотя бы пытались что-то делать на пакете C#? Я наверное не сильно ошибусь, если предположу, что больше половины тут пишущих и не открывали его ни разу. Да и не сделали бы это будь там и возможностей вдвое больше по причинам выше названным.


Я бы тут еще добавил: для пакета (не для среды, а именно для пакета) важно выбирать популярный язык с кучей библиотек и фреймворков еще и для того, чтобы у его разработчиков не стояло задачи реализовывать все самостоятельно, как мы это делали в свое время для пакета Windows. Разработчик пакета должен по возможности брать готовые решения, оборачивать их в элементы и добавлять в пакет.

--- Добавлено в 2021-01-15 00:45:09


andrestudio, вот смотрите как выглядит, например, экосистема nodejs - у него помимо собственных библиотек из коробки есть несколько огромных репозиториев npm и yarm. Репозиторий это место, куда тысячи разработчиков заливают свои библиотеки, причем доходит аж до того, что библиотека может состоять всего из одной фукнции в пару строк кода. Далее любой другой разработчик может установить эту библиотеку одной командой

npm -i <имя библиотеки>

После этого все установленные библиотеки обновляются так же одной командой. Т.е. вы как разработчик найти там сможете абсолютно все для абсолютно всего. Вышла новая версия MySql - в течении недели двух там уже будет драйвер с её поддержкой. Вышел TLS 5.4 - его поддержка там появится в течении пары дней. Добавили ботов в Telegram - библиотека с поддержкой всего API там будет лежать уже в течении месяца, а возможно даже её туда сам Дуров зальет еще до анонса этой фишки. Вам ничего не надо искать, не надо ничего ставить - вы выполняете одну команду для обновления и ваш пакет начинает работать с новыми версиями или получает новый функционал, к которому останется приделать только обертку. Такие репозитории сейчас есть не только у nodejs и их в том или ином виде сразу делают для всех новых языков, потому что сегодня язык это ни что - библиотеки к нему это все. И чем более популярен ваш язык, тем больше очевидно кодовая база готовых библиотек, тем быстрее они там появляются и тем качественнее их код за счет модерации со стороны сообщества. Вы можете сколько угодно набирать разработчиков, которые клепают компоненты для вашего пакета, но если у вас нет за плечами огромной кодовой базы, собираемой по всему миру в одно место - вы безнадежно отстанете рано или поздно, либо качество ваших решений будет под больших вопросом, потому что делать их будут не профильные специалисты, а code review там будет отсутствовать как класс, т.е. баги, глюки, не точное следование спецификациям или неполная их поддержка станут неотъемлемым атрибутом вашего пакета.

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