я думал ты на нём сидишь

Это явно что-то более ядреное, наверника бутират.

http://2014.metkere.com/07/spiderdrugs02.jpg

Пауков берут человеческие наркотики?

Я ж не буду пробовать героин, чтобы критиковать его?

Когда люди критикуют героин, то либо тупо пересказывают пропаганду в стиле «испорченный телефон», либо залазят в википедию или ещё куда-то и ИЗУЧАЮТ воздействие героина на людей, можно поверхностно или детально, сравнивают с другими веществами. Опыты уже проведены множество раз, надо лишь изучить их чтобы критика была обоснованной, а не пересказом.

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

Аналогия - не аргумент

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

Вот да.

Извини, но ты не прав.

На пальцах
Для «отрисовки» текстов необходим только шрифт. Для самого примитивного GUI потребуются дополнительные элементы+шрифт (кнопки, заголовки окон, пункты меню и др. без текстовых надписей не обходятся).

Был такой кратковременый «период» — псевдографических интерфейсов (сейчас, как пример смотри mc, nmtui). Думаю они не сильно проигрывали в плане производительности и размера приложениям cli, но да «графика» красивей.

Это явно что-то более ядреное

Если человек на опиатах (героин в частности), то мышление «как программировать» не меняется, всего лишь «к чёрту программирование, лучше ещё дозу». Если же на психоделиках, то уже другое мышление. Последние вредят физическому здоровью меньше, чем водка. А психическое здоровье - другой вопрос. Я ни за что не агитирую.

Вдохновение для новых идей вполне можно найти просмотром вдохновляющих картинок и/или слушанием подходящей музыки. Не говоря уже про медитацию.

Для «отрисовки» текстов необходим только шрифт. Для самого примитивного GUI потребуются дополнительные элементы+шрифт (кнопки, заголовки окон, пункты меню и др. без текстовых надписей не обходятся).

Я это знаю не по наслышке, довольно долго воевал с гтк, а сейчас шарю нуклеар. В Лабвью с этим проще: сразу гуй из коробки, вся логика вертится вокруг гуя.

псевдографических интерфейсов

Это как Нортон коммандер в ДОСе?

Это как Нортон коммандер в ДОСе?

Да.

слушанием подходящей музыки

https://www.youtube.com/watch?v=3gIaoKDpv2A

Это как Нортон коммандер в ДОСе?

Он самый... «и компания» — всех не перечислить. Это было в 90-х годах прошлого века в ДОСах, до «нашествия» windows.

Я это знаю не по наслышке, довольно долго воевал с гтк, а сейчас шарю нуклеар. В Лабвью с этим проще: сразу гуй из коробки, вся логика вертится вокруг гуя.

ты меня не понял. я констатирую тот факт, что GUI (любой и в любой системе) сам по себе ведёт к росту кода приложения и его «торможению» — такова плата за прогресс снижение порога входа для пользователя.

Торможение должно быть минимальным, а с графическим ускорением - нулевым. Надеюсь на нуклеаре получится.

Не, поциент ни разу не палится

к разработе приобщить будет нелишним

к разработе приобщить

разработе

Штирлиц как никогда был близок к провалу.

Надо же, нашел опиську - докопался.

Как там концепт Антиметапрога на реде? устаканен?

<не ну, я туплю сегодня ещё больше вчерашнего>

Не могу я мысль свою тебе донести... Я не утверждаю

<выходит из треда>

Ты лучше в своем болоте порядок наведи.

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

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

Он один скрин своей задумки показал:

Metaprog: универсальная графическая среда программирования [в разработке] часть 4 (комментарий)

Какие-то вопросы еще остались?

У тебя память как у рыбки что ли? Неудивительно, что ты не можешь осилить даже Си. Вопрос был: что ты предлагаешь добавить в концепцию графического программирования, чтобы она стала применима в общих, а не частных случаях.

- Указатели - не ответ. Они не упрощают разработку, это лишь средство низкоуровневой работы с памятью.

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

- Опенсорс - не ответ. Сам по себе опенсорс не добавляет ничего к идее разработки и не позволяет программисту сократить количество действий для описания алгоритма.

- Само графическое программирование - не ответ. Ты не можешь добавить графическое программирование в графическое программирование.

Где ответ на мой вопрос?

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

что ты предлагаешь добавить в концепцию графического программирования, чтобы она стала применима в общих, а не частных случаях

Сишный бекенд, возможность прямо в графических диаграммах оперировать сишными функциями и данными. Тебя такой ответ устраивает?

Сишный бекенд, возможность прямо в графических диаграммах оперировать сишными функциями и данными. Тебя такой ответ устраивает?

Бекенд не имеет ровном счетом никакого отношения к простоте разработки. Ты просто обводишь Си в прямоугольнички, и получаешь тот же язык, только в виде графики. Он по-прежнему сложен для создания больших программ. У тебя есть идеи, которые позволяют избавиться от большинства рутины, связанной с рисованием множества ненужных прямоугольничков и переходов, до которых машина может сама додуматься?

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

Пусть она тебе не нравится, но что можешь предложить лично ты?

По управлению памятью? Предупреждения о malloc без free например. Или двухчастные функции (одна функция с malloc, другая обязательная часть с free). В графике можно много чего еще придумать. Все диктуется практикой, а не сферической теорией в вакууме.

Ну давай уже, показывай свою «реальность». Я что есть показываю.

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

Предупреждения о malloc без free например

Умеют все современные компиляторы Си.

В графике можно много чего еще придумать. Все диктуется практикой, а не сферической теорией в вакууме.

Иными совами идей у тебя нет, и ты надеешься, что они появятся в процессе?

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

Правда что в реде до сих пор нет сетевого функционала?

Идеи появятся в процессе, так как я же сам тоже программирую. Идеи, диктуемые практикой, а не теорией.

Я тебе секрет раскрою - в Си тоже нет сетевого функционала. В Си вообще нет никакого функционала кроме того, что предоставляет ОС.

Есть библиотеки, умеющие сеть. А в реде?

Нету отдельных операторов для сокетов. А так «родной» прозрачный HTTP-клиент есть, возможность системные либы подключать для сырых сокетов тоже есть. Но мне возможность использовать сокеты как first-class objects нравится куда больше, так что подожду до 0.7.

Идеи появятся в процессе, так как я же сам тоже программирую

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

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

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

Библиотеки - не языковые конструкции. Это стандартизированный комплект поставки. И да, в Си нет стандартных сетевых библиотек. Что там в Реде я не знаю.

Отдельные операторы для сокетов? И для текстового редактора специальные операторы есть, а для майнкрафта с блекджеком и шлюхами в одну строчку оператор будет? Вспомнилась книга Линуса:

Unix характерна тем, что она утверждает некоторые базовые ценности. Это
цельная и красивая операционная система. Она избегает особых случаев. В Unix
есть понятие процесса: процесс -- это  все,  что  что-нибудь делает. Простой
пример. В Unix команда оболочки, которую  вводят, чтобы  войти в систему, не
встроена в операционку, как в DOS. Это просто задание. Ничем не отличающееся
от остальных. Просто это задание читает с  клавиатуры  и пишет на монитор. В
Unix все, что что-то делает, -- процесс. А еще там есть файлы.
     Простота структуры Unix всегда поражала меня, как и  большинство  людей
(ну  по  крайней  мере  -- нас, хакеров). Почти  все,  что делается  в Unix,
выполняется  с  помощью  шести  базовых  операций  (называемых   "системными
вызовами", потому что они представляют из себя вызовы системы для выполнения
тех или иных действий), А уж из этих шести  базовых  вызовов можно построить
почти все на свете.
     Одной из фундаментальных операций Unix  является  "операция  порождения
(fork)".  Выполняя "fork", процесс создает свою точную копию. Таким  образом
вы получаете две идентичные копии. Порожденная  копия чаще  всего  выполняет
другой  процесс  --  заменяет  себя  новой  программой. Это  вторая  базовая
операция. Оставшиеся четыре вызова -- open (открыть), close  (закрыть), read
(читать)  и write (писать) --  предназначены для доступа к файлам. Эти шесть
системных вызовов представляют  собой простые операции, из которых и состоит
Unix.
     Конечно,  есть еще куча других системных вызовов, которые  осуществляют
детализацию. Но если  вы  поняли шесть базовых -- вы поняли Unix. Потому что
одна  из  прелестей  Unix в  том, что  для создания сложных  вещей  не нужны
сложные интерфейсы. Любого уровня сложности можно достичь за  счет сочетания
простых  вещей.  Для  решения  сложной  проблемы нужно  лишь  создать  связи
("каналы" в терминологии Unix) между простыми процессами.
     Уродство,  когда  для  любого  действия  у  системы  есть   специальный
интерфейс. В Unix -- все наоборот. Она предоставляет строительные блоки,  из
которых можно создать что угодно. Вот что такое стройная архитектура.
     То  же  самое  с  языками. В английском 26  букв, и с  их помощью можно
написать  все.  А  в китайском для  каждой мыслимой  вещи --  своя  буква. В
китайском  вы сразу же получаете в свое  распоряжение  сложные вещи, которые
можно комбинировать ограниченным образом.  Это больше напоминает подход VMS:
есть   множество  сложных   вещей   с  интересным  смыслом,  которые   можно
использовать только одним способом. И в Windows то же самое.
     В Unix, напротив, основная идея: "Чем меньше, тем красивее". Здесь есть
небольшой  набор простых  базовых  строительных  блоков,  из  которых  можно
строить бесконечно сложные конструкции.
     Именно  так, кстати, обстоит  дело  и в физике. Эксперименты  позволяют
открыть фундаментальные законы, которые,  как предполагается, крайне просты.
Сложность  мира  возникает  за  счет  множества  удивительных  взаимосвязей,
которые можно  вывести из этих простых законов, а не из внутренней сложности
самих законов.

До меня никто не делал графическую среду программирования общего назначения. Ни в одной книжке не написано как это делать. Единственно верный путь - практика. И у меня не в теории, а на практике получается работающий софт в Лабвью, теперь надо сделать Метапрог, чтобы на нем делать то же самое, но уже со значительно более широкими возможностями, умноженными на сишный бекенд.

До тебя графических сред были десятки. И у всех у них были ограниченные области применения, потому что графику рисовать долго, контрпродуктивно и неудобно для больших проектов.

Изучив «вражеский» лагерь текстовых языков ты мог бы понять, как попытаться скрестить лучшее из них и графики, но все, что ты делаешь - это просто обводишь Си в прямоугольнички. Само по себе это не имеет ценности и не решает никаких задач по улучшению существующих подходов к разработке ПО.

Ну а поскольку ты воинственный ламер, неспособный самостоятельно учиться чему-то новому, то твой потолок - рисовать наскальную живопись в лабвью.

графику рисовать долго, контрпродуктивно и неудобно для больших проектов

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

твой потолок - рисовать наскальную живопись в лабвью

Которая еще и работает!

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

сомневаюсь что прям половина хотя бы уже потому что украина меньше рашки, скорее всего меньше половины

русскоязычных к разработе приобщить будет нелишним

так для чего тогда все эти оказiдники и початки. я не знаю может у кого есть родственники с украины или кто там часто бывает поймут, но вот лично мне это ни о чём не говорит а «початок» вообще звучит комично. если уж ты их собираешься приобщить думаю имеет смысл писать эти названия, если уж по английски тебе сложно, хотя бы по русски которым ты, как видно из этой темы, прекрасно владеешь.

Ну код лабвьюшного прототипа я все равно не открываю, так как контрибутить в него желающих не вижу. Так что и на русский названия в нем переводить не буду, тем более в Лабвью нет мультиязычных строк. А в «настоящем» Метапроге, сделанном «сам на себе», будут уже мультиязычные строки и языковая пробелма решится сама по себе.

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

Умеют все современные компиляторы Си.

это какие опции надо применить к примеру для gcc? сильно сомневаюсь что прям любую утечку сможет найти учитывая как пойнтер может использоваться разными ф-циями в одной выделяется память другие его используют и в третьей free которая вызывается из if с каким то условием указывающим что память больше не нужна.

мне кажется ты не имеешь никакого представления о том как malloc и free используются в реальном ПО потому что пишешь исключительно helloworldы. для общего случая что нужно free а что ещё рано необходима поддержка в runtime и на этапе компиляции информации для этих предупреждений просто недостаточно.

Метапрог - проект немаленький

Очень маленький.

Которая еще и работает!

Ну, всякое говно на бейсике тоже работает.

это какие опции надо применить к примеру для gcc

https://developers.redhat.com/blog/2017/02/22/memory-error-detection-using-gcc/

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

Нужно искать утечки этим чудо-приборчиком:

Еще один аппаратный мониторинг

Почему бы и нет, загрузку памяти показывает:)

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

Ты дурачок или прикидываешься?

В С есть готовый код который можно заюзать, и его много, очень.

Сколько гигабайтов озушки нужно будет для запуска?