Редактировалось 17 раз(а), последний 2024-03-29 00:13:41

User108, а с чего ты это взял?




мидитируешь что-ли на HiAsm?

Редактировалось 19 раз(а), последний 2024-03-29 00:13:41

Во-первых, на данный момент вопрос не совсем корректен. Сам по себе HiAsm - это просто редактор схем. Конечную программу собирают кодогенераторы, входящие в состав пакетов. На данный момент есть три основных типа:
1) Объектный CG - пакеты Windows(язык Delphi), PocketPC(язык С++)
2) CG на базе макросов - FASM(язык Assmbler). Подробнее о качестве кода этого пакета может рассказать tsdima
3) Потоковый CG(или FTCG) - пакеты WEB(языки PHP, JavaScript, HTML), Modules(языки C++, JavaScript)

И именно в предалах каждого из способов кодогенерации стоит проводить сравнение и не с языками Дельфи или Ассмемблером, а с исключительно теми языками, которые испольщуются в данном конкретном пакете:
1) Объектный CG - самый худший из существующих способов кодогенерации. Выразить в цифрах качество нельзя, поскольку оно сильно зависит от элементов используемых в схеме. Зависимость примерно такая: чем больше в схеме элементов, выполняющих достаточно мелкие задачи(Math, StrCat, If, For и прочие), тем больше ухудшается качество получаемого в данном пакете приложения. Тесты на строках(использование элемента For и StrCat в циклах от 100тыс итераций) давали примерно 10-15кратное ухудшение работы приложения по параметру "Скорость".
2) Работает несколько быстрее, чем 1) однако точные данные может предоставить только автор
3) Потоковый CG генерирует код практически не уступающий по качеству тому, что мог бы получиться при ручном кодирование. Примеры можно посмотреть в разделе WEB на форуме. Тестовый пример с элементами For и StrCat в пакете Delphi2 давал результаты по скорости работы такие, какие вообще в состояние предоставить данный язык программирования.

По размеру кода все пакеты дают примерно одинаковые результаты, т.е. размер хоть и больше того, каким мог бы быть, но всего лишь в 1.5 - 2 раза. Иногда и меньше.

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


   Хороший вопрос... В своей практике приходилось сталкиваться с мнениями, что настоящими программистами становятся те, кто начинает программировать на С++ Однако если человек не понимает, что программирование это не клацанье по клавишам, а работа головой и умение мыслить логически, то как раз для него имеет смысл с какого языка начинать.
   С какого языка начинать, посоветовать не могу - уважающий себя программист должет знать их все. Или во всяком случае большинство. Степень сложности по убыванию примерно такая: Assembler, C++, Delphi, C#, Basic.


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

Важно ли качество кода, или же всё таки важно качество готовой программы, как уже писал Дилма в посте выше..

Помнится очень-очень давно я делал WML редактор, который до сих пор валяется в upload, должен сказать, с того времени много воды утекло, и огда я нашёл схемку у себя на компутере, октрыл.. и ужаснулся.
Связи не понятны, компоненты даже не выровнены, повсюду таймеры и прочая фигня, которая стала ненужной, после открытия чудо-принципа хаба- последовательность.. я выкинул из схемы больше половины компонент, и о чудо, схема стала читабельней, а программа быстрей (наверно )

Поэтому качество кода, думаю, на прямую зависит от познаний и умений рисования в среде...

Редактировалось 17 раз(а), последний 2024-03-29 00:13:41

Редактировалось 17 раз(а), последний 2024-03-29 00:13:41

Это скорее не HUB а IndexToChanel, да и то с натяжкой

это не так. Современный уровень программирования как раз и сводится к тому, что программист при ручном кодирование фактически только и определяет последовательность вызова методов и задает связи между объектами приложения. Хороший тому пример C# - язык, в котором существуют почти только одни объекты и где ты "понимаешь все что напрограммировал" только по описаниям интерфейсов этих объектов. Никакого понимания происходящего на самом деле там нет и быть не может. Скажем один GC(сборщик мусора) чего только стоит. В HiAsm же тем, кому надо что-то понимать доступны магические комбинации Ctrl D, Ctrl F, а так же прыжки по всем модулям в рамках исходного файла по Ctrl Enter.


1) Читабельность схемы зависит исключетельно от культуры граффического программирования каждого конкретного человека. В HiAsm уже очень давно существуют элементы контейнеры, которые позволяют избавляться от сотен элементов на рабочем поле путем разбиения приложения на логические части.
2) В языках ЯВУ существует точно такая же культура написания кода со своей спецификой, соблюдение или несоблюдение которой делает код программы либо читаемым, либо нет.


Тоже не верно. Это выводы, сделанные на основе работы со стандартным древним пакетом. Пакет WEB при желании позволяет рисовать схемы со вставкой подпрограмм, имеющих свои имена с последующим вызовом их из любой точки схемы. Про Hub - вставку в линк между двумя элементами уже придумали делать в два клика. Это только вопрос времени.

User108, думается мне, что все же будущее в массе своей за системами визуального проектирования. Просто сейчас они только только начинают появляться, но потенциал уже достаточно мощный и в отличие от простых языков тут продумывание и реализация каждой возможности занимает не один день. Кроме того поскольку графический язык полностью включает в себя базовый язык ЯВУ в виде InlineCode элементов, то сравнение вообще теряет всякий смысл.

Редактировалось 17 раз(а), последний 2024-03-29 00:13:41

в это даже верить не надо - это следующий логический шаг Цитата из первого поста:

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

Редактировалось 17 раз(а), последний 2024-03-29 00:13:42

А вот как это интересно мы скажем, если не знаем каким макаром получено "в Turbo Delphi - 18.4 Кб"
Больше на вранье похоже

Редактировалось 17 раз(а), последний 2024-03-29 00:13:42

Угу новая... Называется .NET