Именно это и есть цель.
Работа (мне представляется) делится на две части: а) создание более полного графического языка б) разработка более крутой системы компиляции под этот более полный язык.


Это два разных вопроса. Из "цели" не следует какой либо вывод о "разделении". Как мне кажется.
И было это к совершенно конкретному поселку; "не должно быть не деления на пакеты"


Смотрел плохо. Голый язык - никому ведь нафиг не нужен. Ты же не сможешь два на два умножить. Во-первых, ты "двойки" не введешь. А во-вторых - вывести "четверку" не сможешь.
Физическое устройство (например, ввода/вывода) - и ты имеешь набор API (в котором еще и пьяный ежик ... сломает) на каждой конкретной платформе (ось+процессор).
Framework для до-диеза, или для Явы - это что такое по-твоему...
Те же самые составляющие языка, без которых его использование бессмысленно.

Сверх-простой пример: MathParse.
Вспоминаем, что просто арифметические операции - нам же нафиг не нужны. Поэтому %<Number> - штатная лексема этого нашего скриптового микроязыка. Вот оно тебе - API ввода, неотделимое от языка арифметических выражений.


------------ Дoбавленo в 08.49:

А чего только про четвертый пункт
Там так про все можно...

Хотя одно обобщающее замечание можно было бы все таки сделать... Фредерик Брукс на основании своего опыта сделал вывод, что порой увеличение количества исполнителей не сокращают, а увеличивают сроки разработки.
Читайте классику, коллеги.

Просто этот пункт - наиболее яркий пример того, что писававший не понимает о чем пишет.

[offtop]началось

Слава богу тут есть телепаты, а то прямо даже не знаю как бы пришлось объяснять что я имел ввиду, а так раз и всё сами поняли [/offtop]

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

hitman249, ознакомьтесь все таки с классикой: Фредерик Брукс "Мифический человеко-месяц или как создаются программные системы"
Просто на всякий случай.
Не, ну и конечно же никто не против против Вашей работы.
Можете считать, что ничего и не начиналось - мало ли кто чего думает. Результаты всегда более убедительны, чем "думает"

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

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

Второй нюанс, все залипли на мышкотаскании. Когда я предложил добавить немного текстовой интерактивности то многие высказались отрицательно.
Хотя более менее опытные всё таки догадываются что когда проект вырастает до 1000+ компонентов, всё чем начинает заниматься программист это бесконечное ручное протягивание связей, сквозь контейнеры. Я именно из-за этого вообще забил делать на hiasm-е чтото серьёзное.
Режим располовинивания в IDE не предлагать, он не работает через десяток контейнеров.

Итого:
Что сейчас реально требуется это
Основной пакет
И пакет для создания группы компонентов к биндингам на библиотеки для этого пакета.
Репозиторий компонентов биндингов с включёнными к ним либами.

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

Если говорить честно, то меня не интересует "все сообщество". По нескольким причинам:

• 99% этого сообщества понятия не имеют о надежности программирования. Имеются в виду технологии, после которых код будет работать всегда, независимо от погоды на марсе.
• 99% этого сообщества не очень понимают, что такое Real-time требования к программному продукту.
• 99% этого сообщества не имеет очень дикое представление о реальной "себестоимости" некой алгоритмической задачи. Это представление не соответствует реальности на 1.5-2 порядка.
• 99% этого сообщества крайне безответственно. И не представляют себе жизни без включения в свой продукт "библиотек" сомнительного качества. Например ОС.

Первое требование меня интересует в первую очередь (с другими хоть как-то можно бороться чисто административными методами). Просто по причине того, что я - руководитель отдела разработки на предприятии, которое выпускает встроенные системы. И наш заказчик привык покупать железо, и оценивать качество по аналогичным критериям. И для него является дикостью рекомендация: перезапустить изделие, если оно вдруг заглючит.
Именно дикостью, несмотря на то, что 99% IT-сообщества считает это вполне нормальным.

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


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

Есть такой закон природы (как мне кажется) - после некоторого критического размера проекта, категорически необходимо менять стиль разработки. Программировать "сверху", а не снизу. На маленьких объемах - "шанхаестроение" эффективно. На больших - нет.

Так вот, наша беда не в том, что мы недостаточно хорошо поддерживаем "шанхаестроение", а в том -- что почти никак не поддерживаем работу "сверху".
Это мое мнение такое.


Если я еще и не высказался отрицательно, то высказываюсь сейчас.
Тут вот в чем дело, hitman249: ваши соображения (которые я услышал) - это соображения Писателя. А я - Читатель.
Текстовое "вседоступность" не только снижает понимаемость Ваших мыслей другими, но и провоцирует на ошибки. И затрудняет их обнаружение альтернативными тестерами.
Это я Вам говорю как профессиональный Читатель. По жизни я прочитал кодов значительно больше, чем написал.

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

---

Ну и главное: в чем Ваша сверх задача, hitman249
Вот свою я обозначил (позже будет - за счет чего). А Вашу - до конца не понял. Неужели: сделать аналогичное сегодняшнему по пользовательским характеристикам, зато свое.....

CriDos, исходя из последних сообщений, мой пост сейчас вообще не в тему
Как Вы будете реализовать зум в программе? Просто смотрел скриншоты бэкграудов компонентов и точек и пришла в голову мысль, что здесь используется только растровая графика. Или это не так?

это плохо, сытый голодного не поймёт.


отрицательно, текстовуха не приносит видимых изменений по сравнению с текущим вариантом.
по задумке текстовуха должна помочь автоматически прокладывать связи от компонент-точка -> компонент-точка
возможно автоматически создавая компонент в месте получателе и тут же его линкуя.
как это всё протягивалось и создавалось ЧИТАТЕЛЬ никогда в жизни не увидит и не узнает, он увидит всё в точности как сейчас.

1 - реалтайм не нужен, ни Windows ни Linux ни FreeBSD не умеют реалтайм, т.е. его даже негде запустить.
2 - себестоимость с текстовухой ниже
3 - надёжности в HiAsm не будет
Надёжность возникает только тогда когда новые компоненты полностью перестают писаться и все созданные компоненты тестируются десятками лет и неоднократно полностью переписываются(кстати говоря многие компоненты только на 10 год и переписываются не раньше).
Такое может сработать только в парадигме микроконтроллера "измерил - сделал действие". Там компонентов много можно не делать.


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

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

Тут кстати до кросспакетности будет ближе.


А меня вообщем-то интересует.

Ладно, поприкалываюсь (обещаю - последний раз) над Писателем

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

Вы даже не поняли слова "себестоимость".

Она уже есть.
И это даже не мое мнение, а мнение моих программистов, которые до меня про HiAsm ничего не слышали.
Да, под словом HiAsm я понимаю технологию, а не глючность (или нет) какого-то конкретного пакета, или элемента


Вообще ничего непонятно. Чувствуется рука Писателя (пишет только для себя).
И уж тем более - нафига все это.
Например, как это (вышеперечисленное) поможет сделать саму среду HiAsm (или другой проект аналогичного уровня сложности) на этом "симбиозе".
Такое же глючное и будет

Масштабирование у меня уже реализовано в одной из старых версий (проверял кое что), и в дальнейшем проблем по его внедрению не вижу.
А так, растр+сглаживание отдельных частей объектов, например, точек (тип Dot).
В результате, картинка в масштабе должна быть не хуже в сравнении с векторной, а производительность и гибкость в разы лучше.

p.s. Сейчас кстати, занимаюсь настройкой инструментов под OS X Mavericks, тот ещё геморрой
------------ Дoбавленo в 08.25:
Ну что-же, после недолгих мучений, таки удалось запустить проект на OS X Mavericks почти без изменений.
Хотя удалось именно запустить, т.к. некорректно работает рендер, рисует только 1 раз (при запуске), так же появилась проблема с отрисовкой *.ico формата иконок
В общем, будем разбираться

Очень зря, одно не может отказаться от второго, но второе портит первое == не надёжность.


Заканчивайте уже это.
Я вообще себя больше к архитекторам отношу.

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


При моей архитектуре появляется возможность исправления ошибок одновременно во всех компонентах использующих эту ошибку, основанных на пакете SDK.
Также есть большой платцдарм для создания более продуктивного кодогенератора.
И становится возможно подключать внешние библиотеки.
Централизованная отладка это поверьте то ради чего стоит и по потеть.

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

CriDos, а можно скриншот с масштабированием?

sаmakacd, перенёс старые наработки масштабирования+мелкие изменения в новую версию, собственно вот:
b40_scale.png
DevProject_b40_scale_x32.exe

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

Редактировалось 3 раз(а), последний 2021-05-22 06:21:20