Да, именно так и представляю некоммерческий проект. HiAsm, предполагаю, так и создавался - сначала Dilma реализовал идею, выложил, сделал форум, её подхватили и присоединились. Вот в этом месте и находятся те 10-20-100 прораммистов со всего мира (или не находятся), а не ходишь с объявлениями своей идеи по профильным форумам в поисках сколько человек возьмут её реализовывать, в надежде на статистику.

Редактировалось 1 раз(а), последний 2021-01-13 16:51:02

Всё очень печально! И всё понятно...
1. Автору темы обидно что его труды небыли добавлены в платформу Hiasm.
2. Нехватка времени это когда нет желания, а желания нет когда никто не оценил!!!!(и не имеет значения-материально оценили или просто хотя бы поблагодарили за проделанный труд) хотя материальная оценка предпочтительнее для большинства людей. Потому как приходя в продуктовый магазин когда покупаешь продукты СПАСИБО не принимают!
А приходя домой жена спрашивает, ты сегодня заработал что-нибудь дети жрать хотят. А ты им говоришь Даааа мне сегодня ВОООООТ такое спасибо передали! Садитесь поужинаем!!!!

Так вот если бы разработчики могли хотя бы что-то с этого иметь они сами бы перешли на нужный и актуальный язык программирования чтобы как можно больше привлечь пользователей и потенциальных клиентов которые оценят их труд.

Да мы все любим халяву!!!!!! Но всему есть предел.
DILMA придумай возможность как на этом можно заработать хотя бы чуть чуть кто этого хочет. И популярные языки появятся!

--- Добавлено в 2021-01-13 17:32:21

Жалко проект бросать в пучину! Он мне тоже сильно помог.

Редактировалось 1 раз(а), последний 2021-01-13 17:32:21

Конечно такого не бывает в реальности.


Ну подождите - исходники HiAsm до 5й версии не были никогда доступны, кто и чего там подхватил и куда присоединился?) Или вы ставите знак равенства между средой и пакетом к ней? Разве такое можно делать? Да и с чего вы решили, что разработчики элементов к пакету появились на следующий день после выкладывания HiAsm? Даже ваш профиль на форуме зарегистрирован спустя 4 года после появления этого форума. И форум появился не сразу, потому что вначале был долгий и утомительный процесс постинга среды на популярных в то время файловых помойках, заняло это все не один месяц и на платформу сначала пришли пользователи, а только потом разработчики, а вы тут говорите - сегодня сделал, завтра получил сотню контрибьютеров. Ну-ну.


Это не всегда так. Можно что-то делать и без оценки кого бы то ни было, если это что-то используется каждый день в твоей собственной работе. Так появилось очень много софта, да историю того же nginx почитайте, к примеру, или git. Просто есть набор ключевых решений, одни из которых поднимают вероятность успешности вашего продукта, а другие снижают его. Выбор популярного языка и популярной платформы сильно повышают вероятность успеха, в то время как выбор не популярного языка или платформы его сильно снижают. Зачем сознательно идти на понижение этих вероятностей и увеличение рисков, надеясь на то, что у тебя хватит сил и времени тащить продукт самому или привлечь для этого людей из не самой многочисленной категории - вот это мне не понятно.

Идею HiAsm подхватили, присоединились к обсуждению и развитию самого популярного пакета.
Нигде не указывал на сроки, только на последовательсноть.
- "Долгий и утомительный процесс постинга среды на популярных в то время файловых помойках" = "выложил, сделал форум"
- "а только потом разработчики" = "Вот в этом месте и находятся те 10-20-100 прораммистов"

А то, что исходники были закрыты - ну, так и работали над тем, что было открыто - пакетом, или идеями/пожеланиями для среды.
Как и говорил - сначала автор идеи самостоятельно разрабатывает начальную версию, затем её публикует, и если она стаёт популярной - её подхватывают другие. И ради этого даже могут быть готовы изучать язык, предложенный автором.

Редактировалось 3 раз(а), последний 2021-01-13 18:35:23

Мы вроде обсуждали разработку среды и выбор языка для нее, а не поддержку среди пользователей.


Netspirit, либо я потерял нить беседы, либо вы что-то перемешали все в кучу. Давайте еще раз кратко о чем речь шла выше:

Среда
- делать новый HiAsm на Delphi или FreePascal - плохо
- делать новый HiAsm на более менее популярном языке и фреймворке к нему - хорошо
- делать в нативе только под Windows - плохо
- делать в нативе под Windows\MacOS\Linux - хорошо
- делать под WEB - вероятно еще лучше (WEB приложение всегда можно сделать нативным за 1 день)
- делать отдельно под натив и под WEB - идеально
- стандартизовать визуал - нет смысла
- стандартизовать формат хранения - можно и нужно
- стандартизовать архитектуру базовых элементов пакета, работающих с примитивами - хорошо
- делать закрытый продукт - плохо
- делать Open Source - идеально
- делать на голом энтузиазме - хорошо
- делать с привлечением внешнего финансирования - идеально

Основной пакет
- делать пакет для запуска приложений в Windows - плохо
- делать пакет для запуска приложений в Windows\MacOS\Linux - хорошо
- делать пакет для запуска приложений в Android/WEB/IoT - идеально
- выбирать для пакета FreePascal - плохо
- выбирать для пакета более менее популярный язык и фреймворк к нему - хорошо

Dilma, моё высказывание заключалось в том, что при добавление тех же полиморфных контейнеров, пришлось добавить в SHA дополнительную конструкцию, т.е. поддержку нескольких BEGIN_SDK/END_SDK под один контейнер. Т.е. визуал повлиял на формат описания схемы. Сможет ли старая версия, в которой ещё не были добавлены полиморфные контейнеры, нормально открыть схему с такими? Сомневаюсь.

Давайте расставим все по полочкам, ибо дискуссия уходит в никуда. С самого начала у меня была цель обсудить с сообществом то, как должен бы выглядеть выглядеть визуал в гипотетически будущих версиях среды, составить из этого спецификацию требований. Раз уж она есть, можно сделать ее публичной, пусть желающие помочь в разработке либо те, кто хочет создать свою версию среды, имеют перед собой готовые требования, построенные на мнении сообщества. Что в этом бессмысленного? Не пойму вашей логики (с) Барщевский

Редактировалось 2 раз(а), последний 2021-01-13 20:32:07

Dilma, в любом случае тебе огромное спасибо! (хоть у нас и было много разногласий) Не считаю что много потерял а считаю что много приобрёл (опыт, знания никогда не помешают).

zhorik5, спасибо за заботу, вероятно тут ещё не всё потеряно. Может я тут просто под ногами путаюсь

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


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

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


Это безусловно.


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

Редактировалось 4 раз(а), последний 2021-01-14 11:31:38

Не согласен, это и пытался высказать, хоть и аргументируя личными предпочтениями. А также реальным положением дел: пакет на Delphi пользовался популярностю, активно использовался, обсуждался, дорабатывался. Пакет на C# - нет. Соответственно, и среда - после перевода на C активности на форуме не добавилось. Стала бы открытой на Free Pascal - получила бы неспешное эволюционирование благодаря разработчикам популярного пакета, а также низкому порогу вхождения языка для новичков. А ведь пакет Delphi до сих пор более популярен. Даже пусть и потому что более полный (не могу сравнить с C#.NET) - он более полный только потому что было кому его наполнить. А на "популярных фреймворках/языках" - нет, один Nic тащит. А среда на C, как ты сказал, вообще до сих пор неюзабельна. По той же причине.


Не согласен.

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

С остальным - более-менее согласен.

Естественно, я в курсе что такое "пакет" и "среда". Непонятно, почему так настаиваешь на отличии одного от другого. Речь идёт о том, что разрабатывают разработчики. Был открыт пакет - разрабатывали пакет, была бы открыта среда - разрабатывали б её. Как только она стала открытой, вопрос наличия разрабатчиков и стал здесь обсуждаться. В контексте что "язык C - это хорошо", а по факту жизнь среды продолжает теплиться только вокруг Delphi. Да, пакета, но и на C# есть пакет - и где его популярность исходя из популярности языка, на котором он написан? Набежали новички, желающие учить популярный язык, набежали опытные разработчики "популярного языка", увидев там "перспективы", недоступные в Delphi?
С чего мной делался вывод: раз пакет Delphi до сих пор популярен, а пакет C# нет, то может и среда v5 была бы популярной, будь она на Delphi, а не на C?

Редактировалось 6 раз(а), последний 2021-01-14 13:13:53

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

• Законченность компонентной базы (т.е. полнота решаемых спектров задач пользователей)
• Удобство использования компонентами
• Документация по компонентам, примеры и кол-во топиков в сети с уже решенными типовыми проблемами
• Доступность в поставке со средой из коробки
• Простота настройки пакета (кол-во шагов от установки SDK, если нужно, до запущенной схемы)

Уже пять пунктов, и ни один из них про язык. Язык пакета здесь скорее как ядровой элемент - косвенно или напрямую влияет сразу на несколько из этих факторов. И язык может быть как бустером в популяризации пакета (проще вносить в него новые фичи и фиксы, что проще с более популярными и распространенными языками), так и тормозом (в случае с умирающими языками).
Поэтому если сравнивать популярности пакетов, то начинать надо совсем не с языков, но не забывать про них. Пакет Windows популярен, на мой взгляд, как раз потому, что доступен из коробки, решает большую часть типичных задач, уже подробно разобран на форуме и имеет примеры. Можно ли сказать то же про C#? Вряд ли. Чтобы его установить, нужно уже качать что-то стороннее, вроде бы даже что-то конфигурировать (тут поправьте меня, если что), а это уже сильно повышает порог входа для пользователя.
Но вот разработчиков под пакет Windows уже вряд ли найдешь. Скорее всего, уже все, кто хотел, и так на форуме есть, а может и скоро уйдут. В итоге на том развитие пакета остановится, новичков в язык приходят на порядки меньше, чем в популярные языки.

Она может и теплится, но только по остаточному принципу. Такой же простой альтернативы ведь нет? К тому же нельзя забывать про скорость развития. С нынешней скоростью развития пакет на базе delphi никогда не будет поспевать за потребностями пользователей. Сейчас он как-то успевает только потому, что популярности особо нет. Это хорошо заметно на open source проектах, у которых мало контрибьютеров: пока проект мало известен, все хорошо, все успевается делать, а как только пакет пиарится, сразу прилетает куча issue, pull request, и бывает даже проект загибается из-за этого. И пакет на базе delphi ждала бы наверняка такая же судьба, т.к. достаточно разработчиков на умирающем языке внезапно не возьмется изнеоткуда, а с более популярным языком шансов выжить было бы куда больше.

Спорное утверждение. Хоть я и простой пользователь и всякими медальками не блещу однако ~ > 30 компонентов за год сумел сделать (многие портированы из VCL, а сколько было до этого и не считал) и они бы были в HiAsm, но, есть только одна причина, видимо добовлятель, прибовлятель, попровлятель, доброжелатель короче орденоносец просто делал вид что этого он не замечает (и что, я так просто свои бессонные ночи должен в помойку слить? ). А теперь Assasin умножите это хотя бы на 10 таких andrestudio (хотя бываю и под эшафе, но это в качестве разгрузки, можно понять) Нехилая скорость развития кабы никто не мешал

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


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 там будет отсутствовать как класс, т.е. баги, глюки, не точное следование спецификациям или неполная их поддержка станут неотъемлемым атрибутом вашего пакета.

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

Редактировалось 2 раз(а), последний 2021-01-15 00:47:45

Я думаю, если сделать HiAsm таким, что на нём можно будет деньги зарабатывать (фри ланс), тогда люди сами потянутся к HiAsm - у. И популярность сразу повысится.

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