LINUX.ORG.RU

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

 , , ,


4

3

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

FAQ

1. Где скачать?

Релиза еще не было. Идет разработка, темы посвящены ей. Есть сделанный на LabVIEW прототип (его работа показана в примерах).

2. Почему не открыт код LabVIEW-прототипа Метапрога?

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

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

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

4. Чем плохи LabVIEW или MyOpenLab?

LabVIEW пропиетарный, а MyOpenLab - хоть и опенсорсный, но какой-то недоделанный (пытался у себя запустить - выдало джава эксепшоны). Да-да, опенсорсный «клон» LabVIEW написанный на джаве! LabVIEW хотя бы на C++, а это все же меньшее зло. Обе эти системы даже не сделаны «сами на себе» в графике. Они даже не пытаются претендовать на универсальную замену всем текстовым языкам, хотя LabVIEW могло бы, если бы не тупость копирастов. Эти системы написаны на текстовых языках, их код (даже если б LabVIEW был опенсорсным) невозможно редактировать, ни разу не обращаясь к текстовым языкам. Метапрог изначально предполагает полный отрыв от текста и текстовых языков, за исключением Си как бэкенда. И то пользователям никогда не придется иметь дело с текстовым Си за исключением блоков сишных вставок (для особых случаев типа арифметических операций, ассемблерных вставок итп).

5. Почему как бэкенд выбран именно Си?

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

6. В Си указатели и ручное управление памятью. Это же так сложно!

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

7. А как же браузерные и игровые скрипты и прочие ситуации, где ручное управление памятью ненужно и даже опасно?

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

8. Почему в Метапроге будут предпочитаться бинарные форматы и чем это лучше?

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

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/

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

9. А как будет обеспечиваться совместимость со старыми файлами, сетевыми протоколами итп, если будет изменен тип?

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

Примеры

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

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

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

Прокручиваемая и выделяемая строка с автопереносом

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

https://pastebin.com/SWJJwvvC

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

Скрины подфункций в следующем примере.

Тот же пример, но покрасивее

Что можно сделать для большего удобства? Убрать инициализацию, подвязку коллбэка на закрытие окна и главную петлю гтк в подддиаграму «главное окно»:

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

На сей раз не поленюсь сделать скрины и объяснить их суть.

В подфункциях есть три вида контейнеров с данными: константа (стала, constant), контроль и индикатор (сверху вниз):

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

Значение константы задается прямо в диаграмме. В Си константа превращается в объявление переменной с инициализатором. Контроли и индикаторы в теле подфункции превращаются в терминалы, к которым можно подключаться в «вызывающей» функции.

Сама подфункция «главное окно»:

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

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

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

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

Подфункция для подцепки асинхронных функций:

https://i.postimg.cc/3r0rYVCS/image.png

Добавить объект в контейнер:

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

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

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

Делаем лейбл (и любой другой нужный виджет) прокручиваемым:

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

Как видим, сишные функции успешно уходят под капот и программировать в графике становится намного проще. Из этого получается такой код:

https://pastebin.com/16bq1Jbs

Этот код делает ровно то же самое, что и предыдущий, а различия - чисто косметические, связанные с уборкой функции под капот и некоторыми доработками транслятора диаграмм в Си.

Каст типов и тактическая победа над нуль-терминированными строками

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

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

Беззнаковое 32-битное, означающее размер массива (темно-синий провод) кастуется в знаковое 32-битное (светло-синие провода и пустая константа, задающая тип). Функция gtk_text_buffer_set_text в качестве размера строки берет беззнаковое, а не знаковое, как принято - видимо, чтобы через "-1" говорить, что строка нуль-терминированная. Но из-за этого вместо 4 гб строки туда можно подать лишь 2 гб - аж в 2 раза меншье! Что за люди?

Тем не менее, с нуль-терминированными функциями в текстовых полях покончено - и это победа!

https://pastebin.com/hQRMSZ1s

Также там был изменен текст. В остальном пример соответствует скринам выше.



Последнее исправление: CYB3R (всего исправлений: 7)

Ответ на: комментарий от metaprog

тем, что твое говно нагенерит вот такую лапшу

struct struct1 {
    int element0;
    struct {
        int element0;
        char element1;
        int element2;
    } element1[4];
    struct {
        char element0[2];
        float element1;
    } element2[4];
};

anonymous
()
Ответ на: комментарий от metaprog

Не те данные будут, структуры с разным pack отличаются. В ядре linux такие структуры кстати активно используются!

Deleted
()
Ответ на: комментарий от Deleted

Да.

=) Я только ждал когда же наш уважаемый ТС доберётся до кернела. Было бы весело. =)

Но пока надежда есть, умоляю... Не спугните! =)))

Moisha_Liberman ★★
()
Ответ на: Да. от Moisha_Liberman

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

anonymous
()
Ответ на: комментарий от anonymous

Нет. =)))

Боюсь его бы забанили в очередной раз ещё до комментария. Как только он бы первый сырец увидел и подумал только откомментировать. Вот именно в этот момент. =))) На подлёте, так сказать.

Moisha_Liberman ★★
()
Ответ на: комментарий от Deleted

Это типа разные бинарные интерфейсы? Как неанонимные структуры от этого страхуют?

Хммм, может и вкручу таки неанонимные структуры. Когда будут с этим проблемы. Пока, как ни странно, все работает штатно.

metaprog
() автор топика
Ответ на: комментарий от metaprog

Нужны не анонимные, а те самые, которые объявлены для либы. struct1 неанонимная, однако она не тоже самое, что widget. Хотя кому я это все говорю...

anonymous
()
Ответ на: комментарий от metaprog

Потому что gtk структуры не используют packed, если бы использовали - все бы вылетало. Но такие структуры много где используются.

Deleted
()
Ответ на: комментарий от metaprog

Захотелось высказаться. ТС, не натыкайся на грабли, на которые уже наступил. Столько больших тредов, к тебе было куча вопросов, многие из них повторяются. Чтобы вопросы анонимусов не были однотипными, заведи FAQ и закрепи это в шапке. Анонимус не прочитает все треды, он прочитает шапку и очередной раз «а чем не устраивают альтернативы?». В ШАПКЕ должны быть комментарии или ссылки вида «не устраивает LabVIEW потому, что проприетарный», «не устраивает ДРАКОН потому, что ...», «не устраивает Unreal Engine Blueprints потому, что ...». В шапке нагляднее, чем искать ответ в куче постов, оффтопа и по делу.

С анрилом это вообще детский сад. Обзывать огромный работающий продукт, где объём работы сопоставим со строительством замка - urinal только потому, что отдельная подсистема (не самая важная) сделана не так, как тебе нравится - скотство. Unreal прекрасно может делать свою работу - создание игр - ВООБЩЕ без блюпринтов. У эпиков всё вращается вокруг игр, а не визуального программирования.

Почему тогда мои примеры все равно работают?

Создание программ «хоть бы компилировалось и запускалось» - это уровень зелёного новичка или «одноразовый скрипт на выброс». С таким подходом не создают серьёзное ПО.

Вот аналогия. «С» компилятор превращает сишный код в исполняемый файл с ассемблером. (LabVIEW/Метапрог) превращает диаграммы в сишный код. Разработчики компиляторов сильно заботятся о качестве «выхлопа», программисты потом говорят «ага, здесь условный gcc сгенерировал вот такой асм код, а условный clang - такой, гораздо хуже». И это важно даже для сишников, которые вообще не прикасаются к асму. Код, который генерируется твоими диаграммами - это «еда для компилятора». Он не предназначен для чтения людьми. Тебе уже указали на твой замкнутый круг - кроме тебя никто писать метапрог не будет, так как фанбои визуального программирования - новички, которые не в состоянии писать серьёзное ПО. А умеющие писать серьёзное ПО увидят нечеловеческий код на С и просто посмеются с тебя. Либо пройдут мимо.

Для серьёзного результата и диаграммы, и генерируемый сишный код должны выглядеть красиво и информативно.

Кстати, можно посчитать сколько раз люди заявляли о том, что твои диаграммы непонятны. Страшная цифра. Я заявляю, что для подавляющего большинства людей схемы Unreal Engine Blueprints нагляднее, красивее и удобнее, чем твои схемы из LabVIEW. И не urinal-urinal, а задаться вопросом «как я могу рисовать мои схемы на GTK так же красиво, как в UE, но без описанных мною недостатков». Все современные тулкиты (гтк один из них!) позволяют настраивать красивости очень гибко. Use the google, Luke! Правда, нужно много усидчивости, чувство вкуса и подход не «мне норм», а «как это сделать привлекательным для людей».

Пока что:

  1. Критика аналогов визуального программирования, да и вообще все частые вопросы в шапке, а не где-то в глубине тредов. Иначе очередной анонимус и не только замучает вопросами, на которые ты уже ответил.
  2. Результат не в виде «еды для компилятора», а в виде сишного кода, который приятно читать человеку и компилятор не даёт ни единого ворнинга. Иначе к разработке (а не только обсуждению) метапрога никто не подключится.
  3. Красивый рендеринг диаграм. Иначе типичный человек, увидев интерфейс метапрога, скажет «фи, ничего не понятно».
  4. Для реализации ПО нужно понимание, что конкретно оно должно делать. Для понимания этих процессов нужно RTFM, без вариантов. Даже джин из лампы из параллельной вселенной не даст тебе нужного ПО, если не знаешь матчасти и не можешь сформулировать требования.

    Даже пример. Типичный аутсорс. Заказчик не читал маны и не очень корректно ставит задачи. Менеджер за счёт знаний и опыта превращает хотелки заказчика в реализуемую форму. Без манов человек даже не может описать, что он хочет от ПО на формальном непротиворечивом языке.

arturianec100
()
Ответ на: комментарий от arturianec100

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

Вот если бы меня смотивировали написать программу, где простые диаграммы генерирую простые скрипты а-ля «web crawler на питоне» или «одноразовая задача на баше» + возможно «вот лапша на баше, опиши мне человеческим языком - что делает этот скрипт», я бы сделал. Гораздо быстрее, чем метапрог на метапроге. Создание гуя для cli утилит за 5 минут было бы полезно. А если это никому не нужно - зачем???

arturianec100
()
Ответ на: комментарий от arturianec100

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

и это печально, потому что если бы он генерировал не «нечеловеческий код на С», а например, «нечеловеческий код на лиспе», например этом http://lush.sf.net (который компилируется в тот же С, и через FFI позволяет прозрачно подключать любые С библиотеки, позволяет смешивать лисповый и си код) — то все эти проблемы с компиляцией и каноничной правильностью кода можно было бы решить в зародыше, компилируя автомагически за счёт лисповой магии.

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

Вот аналогия. «С» компилятор превращает сишный код в исполняемый файл с ассемблером. (LabVIEW/Метапрог) превращает диаграммы в сишный код. Разработчики компиляторов сильно заботятся о качестве «выхлопа», ...

ну например, превращал бы он диаграммы в лисповый код. или в XML, который парсился бы потом каким-то лиспом типа txrlisp (забутсрапился,примеры — см. про JSON и XML, awk). да хоть tcl/tk генерировал бы, блин.

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

непонятно всё: сам сгенерированный человеконечитаемый код для робатофф (и дело не в сложности неочевидных моментов си (хотя в тех же лиспах lush, txr lisp их меньше — а в неудобочитаемости сгенерированного); полезные сценарии и юзкейзы, чего этот (LabVIEW/Метапрог) должен уметь; полезные приёмы для разработки, которые этот (LabVIEW/Метапрог) должен уметь из коробки, обеспечивающие удобство. типа ну вот это я написал на обычном С за два часа, а на (LabVIEW/Метапрог) намалював за пару минут (потому что там это делается быстрее и удобнее), и сразу заработало. пока что выходит наоборот — рисовать и проводками соединять медленнее и менее очевидно. нету ни наглядности, ни скорости разработки в этой среде, ни удобства, увеличивающего скорость разработки.

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

ну, даже допустим окошко с кнопкой компилируется и запускается (ценой 500 варнингов, лол). почему это проще и нагляднее чем писать текстом — тоже непонятно.

например, в том же http://lush.sf.net GUI на лиспе, который называется OGRE в примерах окошко с кнопкой тоже очень просто выглядит (или здесь). вон, даже игрушку на SDL написали. для отрисовки диаграмм там тоже есть.

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

anonymous
()
Ответ на: комментарий от anonymous

и при этом такой текстовый DSL может прозрачно отображаться на «графический» DSL (ещё бы узнать, что это такое, в случае (LabVIEW/Метапрог) ).

metaprog, DSL это язык описания предметной области. твоя предметная область — непонятна. и её язык тоже. не важно, графический он или текстовый. вот ДРАКОН тоже графический, и они говорят там про два альтернативных синтаксиса, текстовый и графический. LabVIEW тоже, при этом прочитав мануал в общем понятно назначение блоков и УГО.

что хотел сказать автор, нагородив лапшу из проводов умеющую кодогенерироваться в си — непонятно. может быть, вся эта лапша наглядно поблочно упростилась бы. если бы были понятные блоки и подсистемы, способ перевода этих УГО в си. что транслируется, куда транслируется. что там происходит с типами. с готовыми библиотеками и их хедерами.

anonymous
()
Ответ на: комментарий от arturianec100

вообще теоретически там ещё одна интересная фишка есть, про асинхронные процессы и dataflow. только она же опять в этих примерах не используется, и непонятно чем отличается этот dataflow (LabVIEW/Метапрог) например, от того же drakon-editor, в котором dataflow и асинхронности нет — примеры это не показывают.

вообще, в каком-нибудь Plan 9 можно графику и векторные диаграммы и скриптом из консоли рисовать: plan9-tutorial/graphics.md.

текстовым, да. пошагово отрисовали график и диаграмму — круг красный, с осями координат. нарисуй круг, ога.

что мешает вот эту circuit bending «мнемосхему» в (LabVIEW/Метапрог) каким-то подобным скриптом отрисовать?

circuit bending хотя бы звучит. и сразу понятно, наглядно и очевидно — что это такое.

думаю, даже если автор metaprog запишет летсплеи ютубовы про свою поделку (LabVIEW/Метапрог), и покажет как он в этом работает — всё равно непонятки останутся.

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

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

мы же тут извелись уже все в ожидании.

anonymous
()
Ответ на: комментарий от arturianec100

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

ну пусть возьмёт какой-нибудь текстовый Plant UML, например. и нарисует юзкейзы диаграмм прецедентов, картинками. типа вот это делает юзер, когда вызывает абстрактную фичу (LabVIEW/Метапрог). вот эти сценарии эта среда моделирования должна уметь. вот эту фигню я делаю в старом LabVIEW, и она делается долго/сложно/медленно/непонятно/неудобно. а вот эта вот фигня в (LabVIEW/Метапрог) получается гораздно быстрее/проще/понятней не только автору — за счёт этого вот юзкейза и прецедента.

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

ну вот как-то так рандомным образом оно может быть и взлетит. если выдержки хватит.

тащем-та, shut up and show me the code

anonymous
()
Ответ на: комментарий от arturianec100

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

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

карту бы нарисовал, что ли. юзкейзами диаграммы прецедентов в PlantUML, например.

или просто описал бы словами. текстовыми.

anonymous
()
Ответ на: комментарий от Deleted

не используют packed, если бы использовали - все бы вылетало

Можно коротко и по-русски что это такое?

metaprog
() автор топика
Ответ на: комментарий от arturianec100

Чтобы вопросы анонимусов не были однотипными, заведи FAQ и закрепи это в шапке. Анонимус не прочитает все треды, он прочитает шапку

Завести FAQ действительно надо, дошли бы руки:)

Unreal прекрасно может делать свою работу - создание игр - ВООБЩЕ без блюпринтов. У эпиков всё вращается вокруг игр, а не визуального программирования.

Конкретно графическое программирование там реализовано убого, и вообще там, насколько я понимаю, нельзя все от начала до конца сделать в графике. Но мне его приводят как какой-то пример из области настоящего графического программирования. Убогая «графичская» надстройка над текстовым программированием, как Дракон и практически все кроме Лабвью. Так что в контексте обсуждаемой темы оно не Unreal, а Urinal.

Создание программ «хоть бы компилировалось и запускалось» - это уровень зелёного новичка или «одноразовый скрипт на выброс». С таким подходом не создают серьёзное ПО.

Брехня. Линукс в 1991 таким и был, увечной пародией на юникс, и только потом уже его постепенно допилили до чего-то более-менее юзабельного. Примерно так же будет и с Метапрогом. Для начала - минимально необходимый функционал для переноса кода Метапрога «сам на себя», а потом, когда уже другие смогут подключиться к разработке, - все остальное.

metaprog
() автор топика
Ответ на: комментарий от anonymous

Ты инвалид и не можешь зарегистрироваться или залогинитья? Боишься, что забанят за оскорбления и оффтоп?

metaprog
() автор топика
Ответ на: комментарий от metaprog

«Нет ты» (с)

Ну, раз ты, всеж, инвалид и не способен думать сам, учиться не хочешь, то вот тебе подсказанька. https://ideone.com/dFax18 Смотри выхлоп результата.

anonymous
()
Ответ на: комментарий от anonymous

Кстати то, что в этом примере Shit result result: 0.000000 это тоже совпадение. Там может быть любой мусор. Хотя «они жи одинаковые!!111», «варнинги нинужны!!!!111», да ведь?

anonymous
()

Тред не читал. Чем это лучше, не знаю, MIT AppInventor 2? Там на выходе готовые андроидные софтины получаются...

anonymous
()
struct {
struct {
struct {
struct {
unsigned long int element0;
} *  element0;
} element0;
unsigned long int element1;
struct {
} *  element2;
} element0;
struct {
} *  element1;
} *  metaprog_instance_1408056545511792641_junction_3644609089020270593 = gtk_window_new(metaprog_instance_1408056545511792641__variable_5923075890728034305);

охлол. Эта лалка GtkWidget чтоль так размотала? А нахера? А чем не устроил GtkWidget?

anonymous
()
Ответ на: комментарий от anonymous

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

kremator666
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от anonymous

Транслятор прост как двери, вот и расписывает все из типов, полученных через castxml. От замены анонимной структуры на GtkWidget хоть что-то изменится в конечном итоге (то есть. в скомпилированном бинарном файле)?

metaprog
() автор топика
Ответ на: комментарий от metaprog

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

Кстати как твой «Транслятор» размотает вот такое?

struct data {
	struct data *next;
};

struct data * create()
{
	struct data *result = (struct data *)calloc(1, sizeof(*result));
	result->next = (struct data *)calloc(1, sizeof(*result));
	result->next->next = (struct data *)calloc(1, sizeof(*result));
	result->next->next->next = (struct data *)calloc(1, sizeof(*result));
	return result;
}
как он размотает struct data?

anonymous
()
Ответ на: комментарий от metaprog

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

Брехня у кого-то другого. Линукс в 1991 мало что умел, но автор сразу хоть и очертил себе узкую задачу и не собирался выносить код за пределы i386, но к решению задачи подошёл фундаментально.

Ты тут JFF копипастил неоднократно. Неужели ты пропустил тот кусок, где Линус через юзнет запрашивал текст стандарта POSIX? Как ты думаешь, для чего он его искал — вместо туалетной бумаги, что ли?

Обрати внимание — Линус реализовал стандарт POSIX, а не сказал «глупый стандарт, я буду его игнорировать и вызовы придумаю сам». Именно благодаря этому подходу его детище развилось и вышло за пределы i386, возможно, неожиданно для автора.

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

hobbit ★★★★★
()
Ответ на: комментарий от anonymous

MIT AppInventor 2

Ого! ТС, посмотри на вот эту схемку, например. Ещё красивее, чем в Лабвью и чем-то похоже на твои рисуночки. И опенсорсное, с апачелицензией. Заточено под андроид, но опенсорс же, допилить можно.

Хотя стоп... Оно же на Java, ты такое не хочешь...

hobbit ★★★★★
()
Ответ на: комментарий от hobbit

чем в Лабвью и чем-то похоже на твои рисуночки.

Как один их контриьбютеров AppInventor2 я протистую против такого сравнения!

anonymous
()
Ответ на: комментарий от hobbit

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

kremator666
()
Ответ на: комментарий от kremator666

Люто плюсую. Примерно так же делаю и Метапрог.

metaprog
() автор топика
Ответ на: комментарий от hobbit

Весьма похоже на Stratch (кстати, от того же MIT). Эти поделки похожи больше на текст, чем на графику. Идеологически от текстового программирования оно ушло недалеко, разве что не ручками все прописываешь, а какие-то выпадающие менюшки. Но все равно там текст. Кстати, как думаешь, почему текстовое программирование не заменилось таким вот полутекстовым-полувизуальным программированием?

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

metaprog
() автор топика
Ответ на: комментарий от hobbit

П. С.: почему-то в МИТе не удосужились даже сделать свой AppInventor (или Scratch) «сам на себе», хотя при желании могли бы. Это ж не шарашкина контора и не один разработчик, работающий в свободное время - могли бы допилить до универсального ИДЕ на все случаи жизни, после чего отбросить джаву за ненадобностью. Но не стали. Что за люди?

metaprog
() автор топика
Ответ на: комментарий от metaprog

Есть такие понятия - «ABI совместимость» и «совместимость на уровне исходного кода». Первое есть только в языках, компилируемых в машинный код (С, С++,Rust...).

Пример. Человек написал программу, используя условный гтк. Разработчики условного гтк решили сделать новую версию - условную гк 4.0 и изменить поля внутри условного GtkWidget. Но api оставили таким же. Значит, сломали abi, но оставили совместимость на уровне исходников.

Какие следствия? Компилируем программу, линкуя с гтк3 - работает на гтк3, но undefined behaviour и вылет на гтк4. Не трогаем исходники программы, но линкуем с гтк4 - работает с гтк4, но ub на гтк3. Всё потому, что разработчик писал

void myfunc(GtkWidget* widget)
, а не
void myfunc(struct {...}* widget)

Если же делать анонимные функции и линковать с гтк4, то програма уже не будет работать ни с гтк4, ни с гтк3.

arturianec100
()
Ответ на: комментарий от metaprog

Пока не дойдут руки до FAQ, каждый второй анониус будет писать «непонятно зачем нужен этот той метапрог!!!».

arturianec100
()
Ответ на: комментарий от arturianec100

А ещё есть паттерн «d-pointer», который помогает сохранять abi, но это только на совести разработчиков библиотеки.

arturianec100
()
Ответ на: комментарий от hobbit

Прочёл самый первый пост самой первой темы и самый первый пост этой. Больше пока не осилил. Теперь тем более не понимаю, чем аффтарский концепт, помимо бездарной трансляции в Си вместо более подходящих для этого языков вроде того же Red (да хоть бы и HTML5 для начала) или даже той же жабы, не просто отличается, а **выгодно** отличается от того же AppInventor(2).

Зато по самому первому посту ещё той темы понял, что у товарища весьма искажены представления о программировании в целом. Феномен RAD в девяностых-нулевых развился исключительно потому, что пролетариат ойтишного труда задолбало вручную выставлять графические элементы. И скорость накидывания этих самых графических элементов - это, блджад, **единственное**, в чём RAD-поделки себя как-то оправдывают. Скорость же имплементации **логики** от представления оной не зависит совершенно. Текст ли, графика ли - всё зависит от того, насколько хорошо реализованы, и какие реализованы вообще, уровни абстракции. И вот в том случае, когда они реализованы на самом деле хорошо, графическое представление может **ВНЕЗАПНО** оказаться помехой для производительности разработки.

Вот в качестве примера можно привести поистине охренительную платформу для создания и обработки звука - Pd (Pure Data). Человеку, который действительно полностью освоил эту платформу, нафиг не нужны все эти DAW за сотни нефти (разве что Reaktor, да и то не факт). Уровень абстракции весьма чётко сбалансирован, как и стандартная библиотека. Реализации достаточно стабильны и разнообразны. Всё хорошо. Авторам надо памятник при жизни ставить. Но есть один момент: этот язык сугубо визуален. Нет способа описать связи объектов (без мусора в виде координат и лейблов) чисто текстовым DSL, что во многих случаях было бы гораздо компактнее, да и в ядрёной консоли/эмбеддеде юзабельнее. В итоге приходится мышевозить там, где уровень абстракции и так достаточен для того, чтобы этого не делать.

И вместо эпилога хотелось бы привести известную цитату: «сделай инструмент, которым может пользоваться каждый идиот, и со временем только идиоты и будут им пользоваться». Думай... те. ©

anonymous
()
Ответ на: комментарий от metaprog

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

P.S. «И тебя вылечат…»

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.