Вверх ↑
Этот топик читают: Гость
Ответов: 1729
Рейтинг: 66
#16: 2016-10-28 18:09:42 ЛС | профиль | цитата
Сделать ребрендинг проекта, собрать группу энтузиастов, обсудить архитектуру и структуру проекта, сделать бесплатную альфу, оформить стартап на кикстартере, выпустить платный релиз, получать деньги. Если интересует могу подробнее написать.

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

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


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

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

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

0
Ответов: 1761
Рейтинг: 158
#17: 2016-10-28 18:53:03 ЛС | профиль | цитата
Хоть я достаточно давно не принимаю активного участия в развитии проекта и пакетов, тоже бы хотел высказаться. Вообще, да, какая-то унификация интерфейсов должна быть, но её не совсем получится реализовать. Возьмём, к примеру, вызов кодогенератора. Если на бэкенде будет один способ вызова, то на Андроиде - другой, через jar, например. С компиляцией та же история.

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

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

0
Ответов: 1841
Рейтинг: 362
#18: 2016-10-28 19:47:30 ЛС | профиль | цитата
sаmakacd писал(а):
Вообще, да, какая-то унификация интерфейсов должна быть, но её не совсем получится реализовать. Возьмём, к примеру, вызов кодогенератора. Если на бэкенде будет один способ вызова, то на Андроиде - другой, через jar, например. С компиляцией та же история.

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

Редактировалось 2 раз(а), последний 2016-10-28 19:52:23
карма: 1
0
Ответов: 1841
Рейтинг: 362
#19: 2016-10-28 21:00:30 ЛС | профиль | цитата
Естественно будет не просто (как будто что-то бывает просто в нашей жизни ) и не стоит брать сразу несколько популярных ЯП и делать базовые кодогены.
Начинать с одного, наиболее популярного-удобного-быстрого с динамической типизацией (для упрощения), да хоть на том же JS (хотя я его и не люблю, но что поделать ).
Главное, чтобы был задел на будущее относительно расширяемости.
В общем, модульность==расширяемость==масштабирование во всём (дада, поэтому был выбран java для среды, он прям весь такой модульный и можно добавить Kotlin, Scala, штототам_на_jvm , хотя долго думал над JS с вебом, НО ).
ИМХО всё конечно, куда же без ИМХО

Редактировалось 5 раз(а), последний 2016-10-28 21:12:27
карма: 1
0
Администрация
Ответов: 15262
Рейтинг: 1498
#20: 2016-10-28 21:37:21 ЛС | профиль | цитата
CriDos писал(а):
Кодогенератор должен быть отдельной единицей исполнения, которую можно автономно запустить с необходимыми аргументами и выполнить целевую задачу - сгенерировать код.

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

CriDos писал(а):
А в вашем скриптовом FTCG/RTCG/FUTURECG нужно разбираться

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

CriDos писал(а):
Я Вася Пупкин и я очень хорошо знаю ТРЕБУЕМЫЙ_МНЕ_ЯП, для моего любимого ЯП есть и профайлеры, отладчик, крутая IDE, он работает на моём ЛЮБИМОМ_УСТРОЙСТВЕ.

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

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

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

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

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

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

Редактировалось 1 раз(а), последний 2016-10-28 21:42:05
карма: 21
0
Ответов: 1841
Рейтинг: 362
#21: 2016-10-28 22:27:53 ЛС | профиль | цитата
Dilma писал(а):
Странное описание единицы исполнения. Если КГ принимает на вход схему, а выдает код, то он должен знать все о пакете, о элементах в нем, о том, как распарсить схему, и с этими знаниями он просто становится консольным hiasm. Если же КГ ничего этого не знает (как сейчас), то мне не понятно, что это за аргументы, с которыми его можно запускать? КГ без реализации CGT интерфейса как отдельная единица бесполезен чуть более, чем полностью. Опять таки же либо я не понял из данного описания, что именно он должен превращать в код.

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

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

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

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

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

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

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

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

Редактировалось 2 раз(а), последний 2016-10-28 23:05:56
карма: 1
0
Администрация
Ответов: 15262
Рейтинг: 1498
#22: 2016-10-28 23:20:49 ЛС | профиль | цитата
CriDos писал(а):
Знание о пакете, элементах, схеме - всё это должно входить в базовый КГ.

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

CriDos писал(а):
Тем не менее, это дополнительное звено (лишнее или нет - хз) при использовании КГ

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

CriDos писал(а):
которое не позволит использовать весь потенциал моего_будущего_пакета

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

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

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

CriDos писал(а):
В общем, уже понятно куда я веду

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

CriDos писал(а):
Задача стоит в том, чтобы данную технологию можно было использовать везде, буквально

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

CriDos писал(а):
Масштабы огромны, но что поделать, ещё вся жизнь впереди, нужно же себя чем-то занять

Вероятность достижения цели тем ниже, чем огромнее ее масштабы.
карма: 21
0
Ответов: 1841
Рейтинг: 362
#23: 2016-10-28 23:38:44 ЛС | профиль | цитата
Dilma писал(а):
Вероятность достижения цели тем ниже, чем огромнее ее масштабы.

Если попытаться всё и сразу сделать.
А так, по моим оценкам вполне достижимые.
Dilma писал(а):
Слишком общая и слишком абстрактная информация выдается.

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


Технология (от др.-греч. τέχνη — искусство, мастерство, умение; λόγος — «слово», «мысль», «смысл», «понятие») — совокупность методов и инструментов для достижения желаемого результата
Это ли не HiAsm?...
карма: 1
0
Администрация
Ответов: 15262
Рейтинг: 1498
#24: 2016-10-29 00:18:17 ЛС | профиль | цитата
CriDos писал(а):
Это ли не HiAsm?

CriDos, что такое HiAsm там же в википедии и написано:
Википедия писал(а):
При разработке от пользователя не требуются знания языков программирования[1] и особенностей функционирования операционной системы, что позволяет создавать приложения, управляя их моделью с помощью интуитивно понятного графического интерфейса.

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

Редактировалось 1 раз(а), последний 2016-10-29 00:29:12
карма: 21
0
Ответов: 1841
Рейтинг: 362
#25: 2016-10-29 00:53:46 ЛС | профиль | цитата
Dilma писал(а):
Я уже с пару десятков раз наверное писал, что hiasm не пригоден для написания игр

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

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

Редактировалось 2 раз(а), последний 2016-10-29 00:59:13
карма: 1
0
Ответов: 1841
Рейтинг: 362
#26: 2016-10-29 09:42:35 ЛС | профиль | цитата
Меня надеюсь все поняли (сарказм)
В каком направлении я иду, странные и безумные идеи, мысли.
А что на счёт вашего вектора развития HiAsm?
Что в будущем ожидает HiAsm и что в ближайшее время? Возможные планы?
Ведь все мои идеи и мысли появились лишь потому, что я изначально не видел в чём будущее HiAsm, как его будут развивать, и будут ли вообще развивать.
Dilma, напишите нам, каким Вы хотите видеть HiAsm сейчас и в будущем...

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

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

Редактировалось 6 раз(а), последний 2016-10-29 09:58:40
карма: 1
0
Администрация
Ответов: 15262
Рейтинг: 1498
#27: 2016-10-29 11:55:58 ЛС | профиль | цитата
CriDos писал(а):
Схема более понятна, на то она и схема

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

CriDos писал(а):
Почему бы технологии HiAsm не выйти за рамки текущего понимания HiAsm? Быстрее, сильнее, лучше, понятней, гибче, удобней

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

CriDos писал(а):
А что на счёт вашего вектора развития HiAsm?

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

Визуальный редактор для Arduino


Очевидно - HiAsm для этих целей был бы куда более интересен

Поэтому я не вижу смысла хвататься за разработку того, что принципиально нового никому не даст.
карма: 21
2
Голосовали:CriDos, tig-rrr
Ответов: 1841
Рейтинг: 362
#28: 2016-10-29 13:23:02 ЛС | профиль | цитата
Dilma писал(а):
К сожалению это далеко не всегда так.

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

А кто хватается?)
Я уже пару лет как подбираю инструменты, ЯП, изучаю историю и возможное развитие в будущем, слежу за разными группами комьюнити и пытаюсь адаптировать текущие пакеты и КГ
Беру уже готовое.
Качественные и проработанные инструменты, технологии, ЯП, которые позволят эффективно разрабатывать как среду, так и компоненты под среду.
Терпения у меня хватит ещё на много лет поисков и изучения
Хотя, последний рабочий набор, меня более чем устраивает.
Тут уже ничего не поделать, такая у меня модель мышления.
Плохо это или хорошо - покажет время.
карма: 1
0
Администрация
Ответов: 15262
Рейтинг: 1498
#29: 2016-10-29 13:55:21 ЛС | профиль | цитата
CriDos писал(а):
В целом согласен, но "не всегда так" можно применить к чему угодно

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

CriDos писал(а):
Я уже пару лет как подбираю инструменты, ЯП, изучаю историю и возможное развитие в будущем, слежу за разными группами комьюнити и пытаюсь адаптировать текущие пакеты и КГ

Ну если только подготовка занимает пару лет, то разработка займет лет 10, а 10 лет в IT это целая эпоха, к концу работ как раз нужно будет начинать с начала
карма: 21
0
Ответов: 1841
Рейтинг: 362
#30: 2016-10-29 14:22:00 ЛС | профиль | цитата
Dilma писал(а):
Ну если только подготовка занимает пару лет, то разработка займет лет 10, а 10 лет в IT это целая эпоха, к концу работ как раз нужно будет начинать с начала

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