И когда HiAsm в языки программирования записался, ничего непонятно
Dilma, тогда это нужно срочно поправить

andrestudio, если для вас программирование - это набивание кода в редакторе, то беспокоится не о чем - можно считать, что автор ошибся.


и что там нужно поправить?

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

Помоему весь парадокс визуального программирования состоит в элементах подобных IC.
Например:
1. Человек ничего не знает о программировании, начинает работать в HiASM, рисует, рисует... и тут возникает задача, которую он не может решить с помощью стандартных элементов. Нужно использовать IC, но для этого необходимо знать язык программирования. Следовательно в дополнение к изучению одной среды разработки (графической) ему необходимо выучить еще и язык (и возможно еще одну среду разработки - классическую). Получается, что самым коротким путем к поставленной задаче является изучение языка программирования и классической среды разработки.
2. Предположим человек уже умеет программировать. Что он может получить от HiASM? Быструю разработку небольших приложений? - Ну так небольшие приложения он и в классической среде быстро набросает. Что дает ему использование IC? - Ничего, т.к. сложный код ему будет удобнее разрабатывать в привычной ему среде, а не в подобии блокнота. Получается что написание сложного кода в классической среде и последующая вставка в IC графической среды - это двойной труд, проще весь проект осуществить в классической среде.

Делаем вывод:
Чтобы устранить (или сгладить) этот парадокс необходимо чтобы либо код в элементе IC тоже писался графически как в мультиках, но на более простых (примитивных) элементах, позволяющих написать код любой сложности, либо сделать написание кода на каком либо макро языке едином для всех пакетов (для этого надо его придумать), изучение которого не составит большого труда и будет не сложнее изучения графических элементов среды.
Есть еще вариант, сделать написаниее кода в IC более удобным, как в классических IDE (+ тесная интергация с графической средой), чтобы при изучении языка программирования, по крайней мере не изучать еще одну IDE.

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

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

Это позволит создать законченный конечный комплект базовых (иначе - платформенно-зависимых) кубиков, созданных скриптовыми средствами

Любой другой кубик (элемент по-нашему) - делается средствами HiAsm

После этого можно будет дать адекватные ответы на вопросы твоего коллеги, которые ты приводил. И только после этого можно будет назвать HiAsm языком программирования. Это - качественный скачок. Плохая кодогенерация - плохой язык, хорошая, значит хороший.
А уже лишь количественные различия.
Между прочим, соревноваться по качеству с FPC - вовсе не сверхзадача

Pirr, ну я просто балдею от тебя . Ты уже определись что тебе нужно наконец Без труда не выловишь и рыбку из пруда. У тебя уже синдром "программиста" и потенциал для этого имеется. Вскоре твои потребности возрастут, что ниминуемо тебя посадит за изучения яву, ну а посля когда ты вкуришь что к чему там и как тогда и сможешь определится а не лить тут море мутной воды.

andrestudio, честное слово - задрал уже как Тузик грелку.
Заглянувший за заднюю сторону зеркала, ты наш.
Ну ты один только там был, а остальные - тупые
Так ты еще раз загляни, на этот раз - ЯВУ. И расскажи, какой из них тебя не дурит

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

и задрал, и задолбал поэтому 3 часа тишины

andrestudio, в отличие от вашего "кукареканья" господин Pirr, хотя бы ставит себе в труд провести хоть какой-то анализ ситуации и дает в своих постах А) проблему Б) ее следствие В) варианты решения. Если в ответ на это будут посты вида "ну я просто балдею от тебя" - придется отправляться на скамейку аутсайдеров.

Теперь по теме

Не совсем полное "следовательно". Если человек изначально был настроен на то, чтобы решить свою задачу всенепременно и именно в том виде, в котором он изначально хотел - то да, наверно HiAsm не самый лучший выбор для этого(на сегодня). Но есть и другие люди, которые хотят решить задачу не имея столько времени и знаний как человек из первой категории и готовые поступиться некими идеями ради получения хоть какого-то результата. Есть и другое НО - изучить визуальную среду типа HiAsm можно за пару дней, неделю максимум. Свой первый язык без посторонней помощи пользователь будет изучать месяцы(если не больше). Мне кажется это не сравнимые затраты времени и сил, чтобы можно было вот так просто говорить


по п.2. - да, сегодня это так. Визуальная(полностью) среда это не площадка для больших проектов и в аннотации об этом ясно сказано. Чтобы исправить этот момент нужно работать и еще раз работать.



У вас оно все просто получается - дать некие нано кубики, из которых строятся обычные элементы - но как интересно на практике достич того, чтобы схема из таких кубиков хотя бы примерно была столь читаема как и код? Основной постулат графического программирования гласит "чем более узкую задачу решает элемент, тем в большей степени его графическое представление проигрывает текстовому". Верно и обратное - чем больший функционал лежит на каждом элементе схемы(и чем больше связей между ними), тем более наглядным будет выглядеть графическое представление. Как сделать схему из микро элементов не монстрообразной?
Простой пример:

это схема фактически на микро элементах - каждый компонент выполняет одну, две операции. А вот аналог ее в коде:
две строки фактически...

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


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


Мммм..дааа... удручающе.
Тогда, выхода нет, нужно только наращивать количество элементов и увеличивать круг решаемых задач.

в данном случае ситуация была бы иная, если бы существовал элемент типа MathParse, позволяющий не только читать из элементов массива(матрицы), но и писать в них. Скажем вот такой строкой
------------ Дoбавленo в 12.00:

видимо побольше надо давать не решаемых задач в примерах


выход нужно искать только тогда, когда мы определимся чего хотим получить - полный аналог текстовому программированию или среду для решения подавляющего числа задач, возникающих у простых пользователей. Я до сих пор исходил из второй предпосылки и не вижу пока необходимости развивать и поддерживать первую, потому что позиционирование HiAsm как альтернативы любой иной среде(VS.NET, Delphi и т.д.) требует и гораздо большей затраты времени, и гораздо большего числа участников.

Dilma, если у меня не начнется болезнь "программирования на тексте" к 20 годам, то можете расчитывать на меня, я никогда не забуду того, как помог мне HiAsm в подростковом возрасте, ведь именно на нем я "написал" первую, хоть как то более функциональную программу(Installer) на нем, к тому же меня тянет познавать язык программирования еще с самого детства(с 7 лет), но только в 13 появился выход в интернет поэтому только тогда я наткнулся на вас на каком то вопросе про программирование на mail. Сначала испугался( ) HiAsm-а Уж больно он выглядел "устрашауще" но потом делать было нечего и я, НЕ как традиционный "хеллоувордщик", написал простенькую программу для запуска exe по Edit-у и с кнопкой "найти файл" А потом потянул мой первый успех к вам на форум. Такова моя история, так что я, когда изучу делфи, к вам на помощь, пока не найду работу, а потом буду ловить минуты "кайфа" и опять на форум

Assasin, когда господин andrestudio, со скамьи штрафников вернется в строй ты ему объясни, что человеку, который к чему-то стремится никак не может помешать знание N-ного числа сред и языков, и даже наоборот - позволяет с гораздо более раннего возраста что называется "входить в курс дела". Я в свое время понял, чем буду заниматься все оставшееся время только тогда, когда увидел как преподаватель рисует формочку для калькулятора в редакторе Visual Basic (своего компа к сожалению не было в то время).


как говорится у всех бывает, но не у всех проходит...

У нас просто не получается.
У нас нет альтернативы, чтобы отвечать некому "andrestudio" про то "настоящий язык программирования", так, чтобы за свой ответ не было стыдно.
Простая идея (собственно она во всех ЯВУ именно такая), но вовсе не реализация.
Последнюю вообще можно делать разными способами, и какой из них более "помогает думать" - это может быть предметом дискуссии. Не говоря уж о кодинге.


Всю жизнь занимаюсь тем, что опровергаю постулаты
Пока получалось
Данный же постулат НЕ ПРЕДПОЛАГАЕТ "рекурсивного замыкания нашего визуального представления о контейнере"
Если мы разработаем таковое замыкание, сей постулат можно будет выкинуть в корзину.
Пока да - нельзя.
Так я вроде и не предлагаю неправильную последовательность работы.
Сначала разработать, а уже потом - выкинуть.


1) Мне таковая монстрообразной не представляется. Это субъективное понятие - у нас тут разногласия еще с Fifteens начинались. Мне лично, таковые схемы помогают думать. Например, я сразу интересуюсь, как попадает в индекс во второй ArrayRead. А в коде найти аналогичную "опечатку" - мне значительно сложнее. Не вопрос, найду конечно. Только не надо говорить что это сверх-просто, когда таковых не 8 строк, а 100 раз по 8
2) Поместить ее в нужный контейнер, и пользоваться только им, никогда во внутрь не заглядывая. Например, сделать ее одним из методов объекта VECTOR.
Т.е., пользователь на HiAsm должен уметь создавать объектные типы, которые передаются в потоках "пультиком управления".
Сам создавать элементы типа Matrix, Фиг_его_знает_какой_Stream, и т.п..


И что, даже если две. Хотя их 8.
Собственно, я приводил свою "статистику": число строк полного кода примерно соответствует числу требуемых элементов
Мне не кажется таковое соотношение признаком "монстрообразности"
А еще можно не идти по неверному пути andrestudio, а заглянуть еще раз "за зеркало", и посмотреть во что превращаются эти 2 строки НА САМОМ ДЕЛЕ

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

Galkov, всегда поражался вашими способностями писать много

так на 100 строк кода будем иметь три листа элементов и если это реализация алгоритма(скажем отрисовка фрактала в цвете), то схема получится с таким переплетением связей, что проследить-то отдельный поток труда не составит, а вот общий смысл понять - увы.


и как это может выглядеть? примерно хотя бы.