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

--- Добавлено в 2016-10-28 18:27:28



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

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

Редактировалось 1 раз(а), последний 2016-10-28 18:27:28

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

На счет ребрендинга не соглашусь. Как показала практика, текущее название легко запоминается. Так же считаю, что платный HiAsm не нужен, ибо загнётся, даже с Kickstarter. Считаю, что куда выгоднее найти инвесторов. Мы на своей конторе так много проектов подняли и получили многотысячную аудиторию и неплохой доход.

Редактировалось 1 раз(а), последний 2016-10-28 18:53:54

Моя идея очень проста.
Кодогенератор должен быть отдельной единицей исполнения, которую можно автономно запустить с необходимыми аргументами и выполнить целевую задачу - сгенерировать код.
Кодогенератор ничего не знает про среду, инопланетян, котиков.
Кодогенератор должен лишь принять аргументы, из которых можно достать путь к файлу с данными и возможные параметры.
Базовая версия кодогенератора должна предоставлять юзеру весь необходимый функционал для работы с файлом данным и пакетами.
Базовый функционал кодогенератора должен быть реализован по определённому стандарту (для унификации).
Для чего нужна унификация? Например, для создания нескольких базовых кодогенераторов.
Я Вася Пупкин и я очень хорошо знаю ТРЕБУЕМЫЙ_МНЕ_ЯП, для моего любимого ЯП есть и профайлеры, отладчик, крутая IDE, он работает на моём ЛЮБИМОМ_УСТРОЙСТВЕ.
А в вашем скриптовом FTCG/RTCG/FUTURECG нужно разбираться, функционал несравненно уступает моему любимому ЯП, скрипт пишется максимум с подсветкой синтаксиса и мечтать о всяких IntelliSense не стоит, шаг влево-вправо и всё просто упадёт
Вот было бы круто и очень удобно, если бы у вас был кодогенератор на моём_любимом_яп со всем необходимым базовым функционалом.
В общем, думаю вы уловили суть данного душераздирающего рассказа, эх...

Редактировалось 2 раз(а), последний 2016-10-28 19:52:23

Естественно будет не просто (как будто что-то бывает просто в нашей жизни ) и не стоит брать сразу несколько популярных ЯП и делать базовые кодогены.
Начинать с одного, наиболее популярного-удобного-быстрого с динамической типизацией (для упрощения), да хоть на том же JS (хотя я его и не люблю, но что поделать ).
Главное, чтобы был задел на будущее относительно расширяемости.
В общем, модульность==расширяемость==масштабирование во всём (дада, поэтому был выбран java для среды, он прям весь такой модульный и можно добавить Kotlin, Scala, штототам_на_jvm , хотя долго думал над JS с вебом, НО ).
ИМХО всё конечно, куда же без ИМХО

Редактировалось 5 раз(а), последний 2016-10-28 21:12:27

Странное описание единицы исполнения. Если КГ принимает на вход схему, а выдает код, то он должен знать все о пакете, о элементах в нем, о том, как распарсить схему, и с этими знаниями он просто становится консольным hiasm. Если же КГ ничего этого не знает (как сейчас), то мне не понятно, что это за аргументы, с которыми его можно запускать? КГ без реализации CGT интерфейса как отдельная единица бесполезен чуть более, чем полностью. Опять таки же либо я не понял из данного описания, что именно он должен превращать в код.


Рискну предположить, что разбираться надо в ЛЮБОМ скрипте. И если вы лично знакомы с каким-то ЯП, то это вовсе не значит, что все остальные создатели элементов с ним так же будут знакомы.


А тут уж совсем не понятно - ну если Вася знает ЯП, любит его, у него есть любимый профайлер, отладчик и IDE и он работает на его любимом устройстве, то зачем ему HiAsm и уж тем более КГ?

CriDos, честно скажу - в 2003 году на момент написания первой версии HiAsm у меня тоже был любимый ЯП под названием Delphi. Тогда я не предполагал делать конструктор для массового использования и тогда не было особого выбора на чем писать(кроме Delphi) - либо совсем уж унылый Visual Basic, либо абсолютно не дружественный к разработке GUI приложений Visual Studio (Borland C++ мы не берем в принципе, т.к. очевидность того, что эта надстройка над C++ долго не проживет была еще тогда). Сегодня, когда перед вами уже есть готовый продукт со всеми своими минусами и плюсами, когда накоплен обширный опыт его использования для решения тех или иных задач, когда вам доступен широчайший выбор сред и инструментов, следовать аргументам "это мой любимый ЯП, IDE и что-то там еще" ну крайне, мягко говоря, глупо.

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

--- Добавлено в 2016-10-28 21:42:05


Ребрендинг делать нет смысла, т.к. и название, и иконка полностью узнаваемы. Иконку может быть освежить, да и только. Никаких платных релизов. Максимум это отдельные сборки для коммерческого использования с фишками, которые актуальны для бизнеса. Очевидно, что без дохода в том или ином виде активное развитие проекта не возможно, но монетизизовать его можно (и нужно) так, чтобы это устроило всех.

Редактировалось 1 раз(а), последний 2016-10-28 21:42:05

Знание о пакете, элементах, схеме - всё это должно входить в базовый КГ.
Не в масштабах HiAsm, конечно, зачем же столько знать маленькому КГ
Среда формирует файл данных json, со всеми параметрами схемы, например, как в моей модели данных, симулирующую среду HiAsm 4 - http://pastebin.com/ByYxXTWX
Этих данных достаточно для генерации кода пустой схемы пакета Windows, но сам я не могу пока их генерировать, приходится с помощью каллбеков выдирать из HiAsm4.
Т.е. по сути, среда сделала большую часть работы, да, информации передаётся больше, но и функциональная нагрузка меньше на ГК.
В общем, это уже техническая часть вопроса, которую если что можно отдельно обсудить.

Тем не менее, это дополнительное звено (лишнее или нет - хз) при использовании КГ, которое не позволит использовать весь потенциал моего_будущего_пакета (тут я это говорю от 3-го лица, типа ).

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

Если данную технологию с лёгкостью можно будет интегрировать в системы любой сложности, это откроет совершенно новые возможности для HiAsm.
Например, интеграция в популярный Unity3D, как плагин\отдельный инструмент в популярную IDE MSVS, IntelliJ, что-то ещё, и сделать его полезным и для программиста (я уже хочу его и купил бы с удовольствием, если бы было что-то подобное).
А как просто, точно и удобно управлять сложными, хитрыми, быстрыми механизмами такой системой, но для этого нужно возможность интегрировать технологию в инфраструктуру вашего предприятия/компании/государства.
В общем, уже понятно куда я веду

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

--- Добавлено в 2016-10-28 23:05:56


Это всё понятно, но тут немного о другом.
Я стараюсь абстрагироваться от любого ЯП.
Например, в моей компании есть питонисты, жабисты, но нету ни одного C++/Delphi, хотя мы бы очень хотели интегрировать вашу технологию в наш продукт, но нас категорически не устраивает ваш RTCG, потому что нам нужно добавить типизацию к точкам элементов, и вон там нужно чтобы всё прыгало и бегало.
Но нам придётся нанять ещё человеков только для того, чтобы написать себе КГ и ещё запилить себе как то скриптовые элементы на плюсах/delphi, а потом ещё поддерживать это всё
Жаль, что у вас нет базового КГ на питоне, java, что-то_там_ещё, или доступного API, а сделать свой КГ под ваш инструмент ну очень и очень сложно без API...
Мы логику КГ сами бы написали под наш продукт, ведь у нас первоклассные спецы Python и Java есть, которые отлично знают архитектуру нашего проекта.
В общем, технологию нужно сделать привлекательной со всех сторон и для всех.
Что-то во мне заговорил "эффективный менеджер" и надо закругляться.
Возможно я ошибаюсь, возможно

Редактировалось 2 раз(а), последний 2016-10-28 23:05:56

Так это и есть консольная версия конструктора. Правильнее такой модуль называть транслятором, а не КГ, поскольку на входе ему дается схема, на выходе получается код, и не вводить людей в заблуждение.


Сейчас: Среда->Язык ГК(RTCG)->Код целевого языка
Ваше видение: Среда->Язык ГК(мой любимый ЯП)->Код целевого языка
Где тут дополнительное звено, простите? Видимо я не был до конца понят в предыдущем сообщении или имело место не внимательное чтение


Скорей всего это не так.


И вновь недоумение - каким образом особенности реализации КГ помогают встраиванию в сторонние среды?? Если стоит задача встроиться куда-то, то 90% времени у вас уйдет на то, чтобы написать редактор или адаптировать существующий. Если редактор пишется заново, то его можно написать под любой КГ, если адаптируется существующий, то под него уже будет КГ, реализация которого может быть абсолютно любой, т.к. работать с ним будет только редактор. Либо опять таки же я не до конца понимаю, что и в каком виде вы собираетесь встраивать.


Может кому-то и понятно, но мне нет. Причем абсолютно. Слишком общая и слишком абстрактная информация выдается.


Понять бы еще, в чем технология заключается


Вероятность достижения цели тем ниже, чем огромнее ее масштабы.

Если попытаться всё и сразу сделать.
А так, по моим оценкам вполне достижимые.

К сожалению, более подробно сейчас описать не могу.


Технология (от др.-греч. τέχνη — искусство, мастерство, умение; λόγος — «слово», «мысль», «смысл», «понятие») — совокупность методов и инструментов для достижения желаемого результата
Это ли не HiAsm?...

CriDos, что такое HiAsm там же в википедии и написано:

А вот ваша задача - встраивание в Unity, MSVS, IntelliJ и т.п. - как мне кажется уже очень далека от этого. Я уже с пару десятков раз наверное писал, что hiasm не пригоден для написания игр, т.е. вставка его в Unity3D не имеет никакой практической ценности. А уж в MSVS, IntelliJ и подавно - кто целевой пользователь таких продуктов? Если человек, без знания ЯВУ, то зачем ему MSVS, IntelliJ? Если человек со знанием ЯВУ, то зачем ему HiAsm и тем более зачем он ему встроенный в IDE?

Редактировалось 1 раз(а), последний 2016-10-29 00:29:12

Только HiAsm - да, не пригоден, но при комбинированном подходе - вполне: https://docs.unrealengine.com/latest/INT/Engine/Blueprints
Хотя метод построения схемы отличается визуально и функционально от HiAsm, свою задачу выполняет так же хорошо как и HiAsm, упрощает построение логики и абстрагирует тебя от всех сложностей C++, но и не лишает тебя всех прелестей оного.

Схема более понятна, на то она и схема
Библиотека элементов - хочешь вставь элемент прямиком в код, хочешь, создай схему в существующем проекте, схема после сборки соберётся в единицу трансляции и вуаля, если нужен новый элемент, прямо тут и сейчас добавь его и используй дальше.
Из других участков кода, ты можешь взаимодействовать с "кубическим" кодом как с обычным, в общем, комбинированный подход.
Но согласен, здесь требуется дополнительный разбор полётов, насколько это может быть полезным при разработке, как будет проходить тестирование, сборка проекта из различных систем сборок и насколько востребованно и позволит ли увеличить эффективность написания кода.
Но зато, это сможет привлечь новых пользователей, которые пока незнакомы с ЯП, учатся, либо просто им нужно быстро что либо сделать.
В общем, вариантов много
Почему бы технологии HiAsm не выйти за рамки текущего понимания HiAsm? Быстрее, сильнее, лучше, понятней, гибче, удобней
Так что да, я не придерживаюсь классической идеи развития HiAsm, возможно из-за этого у нас недопонимание возникло.

Редактировалось 2 раз(а), последний 2016-10-29 00:59:13

Меня надеюсь все поняли (сарказм)
В каком направлении я иду, странные и безумные идеи, мысли.
А что на счёт вашего вектора развития HiAsm?
Что в будущем ожидает HiAsm и что в ближайшее время? Возможные планы?
Ведь все мои идеи и мысли появились лишь потому, что я изначально не видел в чём будущее HiAsm, как его будут развивать, и будут ли вообще развивать.
Dilma, напишите нам, каким Вы хотите видеть HiAsm сейчас и в будущем...

--- Добавлено в 2016-10-29 09:57:19

Хотелось бы также узнать мнения и мысли форумчан относительно текущего вектора развития и возможного будущего.

Редактировалось 6 раз(а), последний 2016-10-29 09:58:40

К сожалению это далеко не всегда так.


Потому что есть такая поговорка - за двумя зайцами погонишься, ни одного не поймаешь.


Есть две основные и главные задача: сделать так, чтобы HiAsm работал везде(Windows, MacOS, Linux) и сделать пакет, который так же будет собирать везде работающие приложения. Сегодня в тренде WEB и мобильное направления - их поддержать нужно обязательно. Не маловажным является и направление электроники (Arduino к примеру), которые очень сильно снизили порог вхождения в сферу микроконтроллеров и их программирования - тут тоже программирование без знания языков является крайне актуальным, а тот же модульный arduino ложиться на эту парадигму просто идеально:


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

В целом согласен, но "не всегда так" можно применить к чему угодно

А кто хватается?)
Я уже пару лет как подбираю инструменты, ЯП, изучаю историю и возможное развитие в будущем, слежу за разными группами комьюнити и пытаюсь адаптировать текущие пакеты и КГ
Беру уже готовое.
Качественные и проработанные инструменты, технологии, ЯП, которые позволят эффективно разрабатывать как среду, так и компоненты под среду.
Терпения у меня хватит ещё на много лет поисков и изучения
Хотя, последний рабочий набор, меня более чем устраивает.
Тут уже ничего не поделать, такая у меня модель мышления.
Плохо это или хорошо - покажет время.

В данном случае речь идет о том, что графическое представление тем лучше, чем меньше элементов использует и чем больше функциональности вложено в один элемент. И соответственно наоборот. Отсюда имеем целую сферу областей, где HiAsm не применим по определению.


Ну если только подготовка занимает пару лет, то разработка займет лет 10, а 10 лет в IT это целая эпоха, к концу работ как раз нужно будет начинать с начала

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