https://i.postimg.cc/RFyhQn8x/image.png

Какое-то месиво из стрелочек, хардкоженых циферок и непонятных символов. Если б «аффтар» не рассказал, что это, якобы, «превращать нуль-терминированную строку в нормальный массив с известным размером.», яб не понял. Ты сам то потом вспомнишь что там происходит?

3. Почему не Дракон, MIT App Inventor, Unreal Blueprints?

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

а твои нечёткие украинские подписи не текстовые?

+1. я даже после того как он рассказал ничего не понял. и это какой то простенький helloworld. я даже не понял что такое «нормальный массив». это что то типа struct { size_t length; char *start; };. афтар выложи лучше Cшный код будет понятнее ей богу даже если он криво сгенерирован твоей утилитушкой.

https://i.postimg.cc/RFyhQn8x/image.png

https://www.youtube.com/watch?v=r8uCWl2LliI

не люблю ссылки на видево но на этот раз решился посмотреть и не пожалел. очень точно описывает впечатление от «кода» афтара.

Так-то миникс сейчас очень популярная ОС, с вероятностью 40-50% она прямо сейчас запущена у вас на ПК. И вообще, хватит приводить Таненбаума в пример, он был прав по большинству вопросов. Если бы вы почитывали иногда lkml, проблемы монолита частенько всплывают там.

А сейчас есть помощь в подсказках по гтк и нюансам Си. Не от тебя, конечно.

Готовенькое всем, видите ли, подавай.

Данные из строки копируются в массив и сохраняется длинна? В текстовом представлении это выглядит так:

char arr[128], *s = "Hello World!", *p = arr;
int n = 0;
while((*s+1) && (*p++ = *s++)) n++;

Так-то миникс сейчас очень популярная ОС, с вероятностью 40-50% она прямо сейчас запущена у вас на ПК

Ты про Intel ME? А где еще миникс есть? На ARM?

Если бы вы почитывали иногда mailing lists, проблемы монолита частенько всплывают там.

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

Есть и другой подтекст сравнения ООП с микроядерной архитектурой ОС: ООП, наверное, лучше всего будет ложиться именно на микроядерную архитектуру. Но практика с Линуксом показывает, что моноядро лучше.

«Правильные строки» есть тут кстати. https://developer.gnome.org/glib/stable/glib-Strings.html

Я уже показал скрин. Там данные вообще не копируются. Сохраняется старый указатель, но еще добавляется информация по длине массива.

Кстати, arr у тебя длиной 128. А если строка больше?

Кстати, там про завтипы и алгтипы было: они просто позволяют писать код, в котором гарантированно не будет ошибок. Если какой-нибудь условный readFile :: String -> IO String обернуть в optional :: Applicative f => f a -> f (Maybe a) и если так сделать для всей стандартной библиотеки (для хаскеля реализовано во всяких safe-prelude или intro), то можно гарантировать отсутствие неявных ошибок в коде.

Так правильнее...

char arr[128], *s = "Hello World!", *p = arr;
int n = 0;
while((*p++ = *s++) && *s) n++;

И винда тоже, кстати, мироядерная, насколько я знаю - разве она лишена проблем?

Кек. Чукча не читатель, чукча писатель :) Винда – лютый монолит, но при этом NT вполне себе в ООП-стиле работает – везде передаются объекты, а не текст. Да и Linux на самом деле тоже написан с использованием многих практик ООП, иначе бы на первый год разработки всё схлопнулось бы.

Опять же, ограничение на 128. Лучше не избавляться от *s, вместо этого лучше всего лишь просмотреть какое из его значений «0» и сделать вывод о длине строки.

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

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

По гтк есть отличная документация доступная онлайн, если что-то не понятно, то исходники открыты.

Ты не стесняйся, создвай темы с непонятными тебе вопросам в Си и гтк, тебе всегда ответят и без стеба.

Там данные вообще не копируются.

Тогда получается это аналог?

char *s = "Hello World!", *p = s;
size_t n = 0;
while(*s++) n++;


// length(Hello World!) == 12
printf("length(%s) == %zu", p, n);

А если строка больше?

segfault.

Си по критерию качества программ бесспорно выигрывет

Если бы это было бы так, то код для космических ракет, банковских систем и военки бы писался на нем. Это не так. Там, где нужна скорость, C оптимален – быстрее писать, чем на ассемблере (и кроссплатформенность получше), и при этом оверхед пропорционален используемым фичам. А для качественных (в смысле более читаемых и безопасных) сишечка уступает вообще почти всем неэзотерическим языкам (ну написанный дебилами от программирования код на C++ или обфусцированные вещи на жс мы не берем в расчет).

код для космических ракет
Это не так.

Вот как? И что там юзают?

Ada

Как ни странно, монолитные линукс и винда захватили мир, а микроядерный миникс только в Intel ME тихонько сидит, Hurd вообще на обочине...

Пруфы?

Ты реально это сам в гугле набрать не можешь? https://www2.seas.gwu.edu/~mfeldman/ada-project-summary.html

у нас в клинике тамограф стоит GE, там тоже ада, как инженегры из этого GE рассказали.

Это не пруфы. Вот к примеру марсоход ихний на VxWorks и программы на нем на С.

В 2000х у них спутник был на Commmon Lisp запрограммирован. Используется много чего! А не только Ada.

VxWorks и программы на нем на С.

пруфы?

был на Commmon Lisp запрограммирован. Используется много чего! А не только Ada.

Используется много чего! А не только C, да.

https://en.wikipedia.org/wiki/Comparison_of_embedded_computer_systems_on_boar...

Это не пруфы.

Пруфы. А твоя ссылка не доказывает что все ракеты на Ada.

А твоя ссылка не доказывает что все ракеты на C.

Поехавший что ли? Я это и не доказывал. Прочти комментарии выше.

Поехавший чтоли? Где я доказывал что ВСЕ ракеты на Ада?

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

ты бот чтоль?

Так текстовое программирование тоже захватило мир, и самые популярные представители ГП типа Лабвью не имеют и доли от (небольшого) успеха микроядра. Заставляет задуматься.

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

Текстовое программирование, может быть, по-своему прекрасно, но меня оно не устраивает.

Ого! Прогресс.

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

Например то, что я уже задолбался предлагать — пусть диаграммы будут диаграммами, но внутренний формат их представления оставить текстовым. Это сразу снимет с тебя бремя писать свою VCS и ещё дохрена всего. Да и вообще — если какой-то левый чувак может просто посмотреть потроха твоей диаграммы в виде plain text, это сразу снимет кучу вопросов, понизит порог доверия и создаст предпосылки, чтобы этот чувак стал твоим союзником, а не наоборот.

А у меня вопрос по п.2 FAQ

Я никак не могу понять причин не открывать исходники. Хотелось бы услышать, таки, разумное объяснение. Потому что:

Он весьма глючный,

И что?

прожорливый по памяти,

И что?

зависит от пропиетарного LabVIEW

И что?

вряд ли кто-либо из здешней публики будет контрибутить

Это не более, чем предположение. Но если исходники не открыть, то «контрибутить» точно никто не будет.

Уверенно поддерживаю!

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

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

И визуальные средства просмотра этих бинарных файлов не помогут - если ошибка в программе просмотра файлов, то будет сегфолт, а не «диаграмма файла».

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

Лабвьюшный прототип все равно будет отброшен после раскрутки Метапрога (то есть, когда Метапрог будет сделан «сам на себе»). И после раскрутки код будет открытым.

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

если ошибка в программе просмотра файлов, то будет сегфолт

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

http://zone.ni.com/reference/en-XX/help/371361R-01/glang/flatten_to_string/

http://zone.ni.com/reference/en-XX/help/371361R-01/glang/unflatten_from_string/

Что-то подобное будет и в Метапроге.

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

В ООП, судя по всему, такой же оверхед по передаче данных между объектами. Микроядра - это ООП от операционных систем.

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

Визуальное программирование никак не спасает от невнимательности.

В С++, Java, и, возможно, в Swift и JS, если методы НЕ виртуальные, то никакого оверхеда по сравнению с Си не будет. Если же методы виртуальные, то есть небольшой оверхед на таблицу виртуальных методов. При этом в сишке часто эту фичу велосипедят сами через выбор нужной функции по указателю прямо во время выполнения программы.

А вот питон, php, js с магией, perl5 и прочая скриптота даёт оверхед из-за key-value структур данных.

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

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

И, кстати, больше никакого ручного проставления всяких скобок, ";" и прочих текстовых разделителей.

ручного проставления всяких скобок

Они нужны для компактности кода, Metaprog: универсальная графическая среда программирования [в разработке] часть 4 (комментарий) насколько компактнее текстовый вариант тех схем! Надо что то с этим придумывать...

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

Я никак не могу понять причин не открывать исходники

Причина одна - их нет. Автор троллирует и пытается развести на донат, попутно заманивая неосведомленных для написания этой поделки. Сам он естественнно руки марать не хочет. Да и знаний у него явно не хватает для таких вещей.