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

Какие примеры? Ты о чем? Картинки? Это не примеры это херня.

Я тоже вот язык изобрел вот пример:

1234567890LDFJ*#

И это полный аналог опенофиса я тут написал, дада, верьте мне.

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

Ты хоть знаешь чем отличается массив от списка?

А вы не пробовали разумно оценить свои знания и умения, и понять, что если за 70 лет тысячи (а то и миллионы) гениальных людей писали текстовый код (а иногда и графические языки) и так и не смогли сделать «серебряную пулю», значит у вас нет вообще никаких шансов?

Но из серьезных графических - только пропиетарное Лабвью с его ограничениями. Идиоты из NI имели десятки лет и целую команду специалистов, но даже не сделали Лабвью «само на себе»! MyOpenLab - у меня даже не открылось, крашится с Java Exception (автор даже не ставил цели сделать его «само на себе»). Никто еще не подходил к графическому программированию серьезнее меня.

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

Перенесешь сишный код на Метапрог. Дебажить утечки с сегфолтами в графике будет куда легче.

До вечера воскресенья сей товарищ не знал, что у C есть рантайм, не знал, что такое quicksort, а вы от него отличия массива от списка просите.

Дебажить утечки с сегфолтами в графике будет куда легче.

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

Но из серьезных графических - только пропиетарное Лабвью с его ограничениями

Может быть это как-то связано с мертворожденностью графического программирования общего назначения? В National Instruments сидят не идиоты, они оценивали свои силы и средства.

сей товарищ не знал...

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

Какие еще списки? struct?

страшно представить как на своей метаподелке он будет балансировать деревья. Очень хочу на этого мутанта посмотреть.

когда воплощу указатели на функции

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

Какие еще списки? struct?

Я аж в голосину.

Исходники? Они в бинарном формате и завязаны на транслятор, сделанный в Лабвью. А так скрины я показал, сгенерированный код показал.

В National Instruments сидят не идиоты, они оценивали свои силы и средства.

Идиотов хватает везде, верите или нет?

хоть вы и критикан

Discussio mater veritas est.

Какие еще списки?

Приведу (не дословную) цитату вашего любимого Линуса: «Каждый, кто хоть раз пробовал программировать на C, первым делом после Hello, world пытается релизовать связанный список».

Вы же хвастались, что «просмотрел ту книгу по диагонали - и все понятно», ЕМНИП в «той книге» реализация связанного списка где-то в первой половине (могу ошибаться, давно было)…

Особенно на некоторых форумах, мда.

Попробуйте выразиться по-сишному что такое связанный список. Наверняка я его 100 раз реализовывал в Лабвью, но не знал что это так называется.

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

Ну все. Теперь он очередную очивку в резюму напишет :D

Резюме тролля 80lvl разве что.

Кто делал Unreal Urinal Engine? Майкрософт?

https://dnnrz1gqa.blob.core.windows.net/portals/Images/Engine/Blueprints/User...

Цикл while тоже через задницу: для их реализации нужна локальная перменная counter. Они даже дополнительную схемку сделали чтоб было очевиднее чем их «графическая» unreal engine - ну не идиоты? Скепсис некоторых людей по поводу графического подхода еще можно понять, когда они видят что-то подобное.

Но в Лабвью циклы куда красивее и очевиднее (почти та же схема):

https://i.postimg.cc/MHGbLyyN/while.png

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

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

Никто еще не подходил к графическому программированию серьезнее меня.

а как же Дракон ?

Дебажить утечки с сегфолтами в графике будет куда легче.

может лучше пойти по пути плюсов и раст: чтобы утечки с сегфолтами просто не возникали?

плюсов

утечки с сегфолтами просто не возникали

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

раст

утечки

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

а как же Дракон ?

Могу ответить за ТС: он написан не на себе и в нём можно вставлять текст, «это жи несерьёзно!»

В плюсах даже в хорошо написанном коде регулярно встречаются

сегфолты

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

а течёт нещадно вообще по-умолчанию.

у рукожопов только если

Раст вообще никак не спасает от утечек

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

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

Какие деревья? Мы тут программированием занимаемся, а не садоводством!

ОП, посмотри на glib кстати! Поизучай ее! https://developer.gnome.org/glib/stable/glib-Singly-Linked-Lists.html https://developer.gnome.org/glib/stable/glib-Doubly-Linked-Lists.html

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

УМВР.жпг

Неполный список сегфолтов (не непойманных исключений, а сегфолтов), которые я регулярно вижу (или видел) в C++ (Qt)

1. Plasma 4 (где-то раз в месяц)
2. Plasma 5 ранних версий пару раз в месяц
3. KWin определенной версии сегфолтился при каждом запуске с моей видюхой (свалил с кед из-за этого)
4. Kdenlive старых версий вообще через раз на любом серьезном проекте, новых версий - изредка (все баги тут я репортил)
5. KDevelop регулярно (раз в неделю) до какого-то там по счёту глобального реврайта
6. Куча разных приложений на Qt сегфолтится при завершении (первое, что приходит в голову - Albert, но при желании могу ещё примеров назвать)

а течёт нещадно вообще по-умолчанию.

у рукожопов только если

А как вы понимаете, что у вас память течет или не течет? Вы все приложения через valgrind прогоняете? Вот у меня ощущение что Plasma текла через неделю работы нещадно, и до прогона через статанализ с последующим суровым Valgrind мой код тоже течёт (возможно, я рукожоп, не спорю)

Раст вообще никак не спасает от утечек

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

Ладно, с «вообще никак» я переборщил, ибо для простых кейсов без заимствований утечек действительно не будет, но уж точно не гарантирует их отсутствия https://doc.rust-lang.org/nomicon/leaking.html

Мне кажется, все в этом треде занимаются трепом :)

Ну вот, уровень идиотичных амбиций спадает, скоро может быть и все прелести текста в качестве хранилища будут осознаны :)

Стоп, сишные вставки я обещал с самого начала. Ничего не поменялось.

Зачем вообще линкед листы? Почему не массив указателей? А точнее массив из кластеров с указателем и длиной массива:

struct {
int array_size;
byte * array_pointer;
} string_list[];

RTFM or GTFO. Это написано в любой книжке «Программирование для чайников». Надоел такой тупой и толстый тротлинг.

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

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

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

Скорость доступа, вставки, изменения и прохода по списку не совпадает с этими характеристиками у массива. Нужно это для того, чтобы вместо говнокода (типа GMail) (который вы так люто ненавидите) писать нормальный код (вроде ядра Linux). RTFM.

Разная с чем? Почему не массив указателей? Или даже массивы указателей на массивы указателей итд?

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

Это мой последний message в этом топике.

«Никогда не говори никогда»...

Реализуйте linear-time zero-copy safe insertion для массива указателей, массива указателей на массивы указателей и так далее.

Linear относительно количества вставляемых элементов, конечно.

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

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

Вообще тебе полезно будет прочитать это:
https://developer.gnome.org/glib/2.60/glib-data-types.html

Ну а лучше вообще это все:
https://developer.gnome.org/glib/2.60/

Для регистрантов в таких тредах спасает только игнор основных участников :)

А, теперь понятно. Можно быстро вставлять элемент. Хорошая идея если что.

А лучше сесть и прочесть хотя бы http://broiler.astrometry.net/~kilian/The_Art_of_Computer_Programming%20-%20Vol%201.pdf

(Не уверен, как там с копирайтом, лучше всё-таки купить официально книжку)

Именно так мы и получили современный веб.

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

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

По такой логике на десктопе вообще приложений не должно быть

А причем тут приложения и онлайн книжки/форумы (веб)?

Никогда книги не покупаю. Зачем вообще свято чтить копирайт? Чтоб бабло нести копирастам?

https://falkvinge.net/wp-content/uploads/large/The Case For Copyright Reform ...

При том, что современный веб - именно что приложения с тоннами JS.

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

Потому что не все хотят побираться по форумам на еду, некоторым хочется иметь стабильный доход со своей цифровой деятельности. К сожалению модель «free source, paid service» работает не всегда.

Ну а конкретно в данном случае - это нарушение закона, и в цивилизованной Европе вам бы уже пришёл штраф.