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)

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

Многим программерам (в том числе мне) неприятно смотреть на паттерн матчинг на экран и более. Многие сразу «спагетти код» и всё.

Ещё пример. Компания пишет проприетарную программу, где нужно, чтобы функционал расширялся плагинами от сторонних разработчиков. Веб-сервисы с rest api не подходят, т.к. нужна работа без интернета. (нечто подобное в фотошопе, 3д максе...) И здесь условное p->parse() необходимо, т.к. на этапе компиляции НЕ известно, какие протоколы будут реализованы в плагинах.

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

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

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

ибо топит за идентификаторы на украинском

Вранье! ОП за мультиязычность.

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

Я просто разместил объяву.

Я тоже так думал, что просто разместил, потом прочитал твой ответ про ссылку с ЛОРа, подумал, что таки автор. :)

hobbit ★★★★★
()

Здравстуйте.

У меня возник вопрос, а что насчет метапроги и кодогенерации? Просто работаю в области АСУ и там у нас ребята замутили кучу тулз, которые генерят уже готовый код по каким-либо спецификациям и описаниям, причем из всего этого https://ru.wikipedia.org/wiki/IEC_61131-3 генерится именно ST, а не графические языки, поскольку текстовой формат сгенерить легче всего. На описание всего этого все можно посадить какого-нибудь бывшего студента или какую-нибудь другую макаку. В итоге получаются готовые объекты автоматизации, а высококвалифицированному специалисту/программисту остается лишь описать технологию и всевозможные аварийные ситуации.

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

Как генерить картинки на метапроге? В каком виде это представлено в исходнике, какой-то xml или бинарный формат? И если это возможно сгенерить, то сгенеренная метапрог-программа не превратиться в паутину линий и блоков в случайных местах на холсте?

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

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

У меня возник вопрос, а что насчет метапроги и кодогенерации?

DSL -> metaprog ИЛИ metaprog -> DSL? Первый вариант не особо нужен, так как metaprog не ограничен практически.

Как генерить картинки на метапроге?

Да как угодно, планируются свои блоки со своей отрисовкой, очень настраиваемая среда.

В каком виде это представлено в исходнике, какой-то xml или бинарный формат?

Исходники будут в своем бинарном формате.

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

Как генерить картинки на метапроге?

Думаю это вполне может выглядеть как программирование материалов в Blender. https://i.stack.imgur.com/NIeM5.png

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

DSL -> metaprog ИЛИ metaprog -> DSL? Первый вариант не особо нужен, так как metaprog не ограничен практически.

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

Да как угодно, планируются свои блоки со своей отрисовкой, очень настраиваемая среда.

Насколько прозрачно все это будет?

Исходники будут в своем бинарном формате.

Т.е. о выше описанном сценарии можно зыбыть и забить, т.к. бинарный формат.

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

Макака в экселе набивает по строго определенным правилам таблицу с описанием объектов автоматизации, из этой таблицы генерится код

А, нужно генерировать из таблицы код для metaprog'a. Понял.

Т.е. о выше описанном сценарии можно зыбыть и забить, т.к. бинарный формат.

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

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

А почему оно должно таким сделаться? Как нагенерируется.

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

Есть ещё 1С.

Функция обИзвлечьСсылку(Зн) экспорт
    Перем С;
    Если обЭтоПримитивныйТип(Зн) Тогда
        Возврат Неопределено;
    КонецЕсли;
    С=Новый Структура("Ссылка", Неопределено);
    ЗаполнитьЗначенияСвойств(С, Зн);
    Возврат С.Ссылка;
КонецФункции

Лексеры не любят русский, они не умеют в склонения.

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

А для схем вообще не требуются склонения кстати. Это же «отдельные вещи».

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

Да как угодно, планируются свои блоки со своей отрисовкой, очень настраиваемая среда.

Что значит: очень настраиваемая?

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

Ребят, вот на моем экране (может у вас не hd монитор?) все эти картинки очень мелкие, даже всматриваться не стал. Масштабирование в вашей системе предусмотрено, чтобы вторые очки не надевать?

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

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

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

Без понятия когда, ОП тоже не особо может сроки определить.

Ребят, вот на моем экране (может у вас не hd монитор?) все эти картинки очень мелкие, даже всматриваться не стал. Масштабирование в вашей системе предусмотрено, чтобы вторые очки не надевать?

Дизайн будет изменен, просто на картинках версия на labview, там есть некоторые трудности...

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

Тут идея не в мышевозне, а в расширении формата кода.

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

А почему оно должно таким сделаться? Как нагенерируется.

Текст намного легче генерить, чем вводить дополнительные правила и эвристики, чтобы сгенеренная программа на метапроге в итоге в графическом виде выглядела бы понятной.

Или метапрога будет настолько интелектуальной, что сама расставит блоки и нарисует линии так, что будет хорошо читаемо/смотрибельно?

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

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

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

Как emacs, только вместо лиспов будет графика.

Ладно, ответы на свои вопросы посмотрю, больше писать не буду.

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

Жду прототип метапроги, который могут пощупать и оценить все.

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

Жду прототип метапроги, который могут пощупать и оценить все.

И я.

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

А, нужно генерировать из таблицы код для metaprog'a. Понял.

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

Насколько легко такой процесс будет организовать? В случае текстовых языков программирования, выше приводил в качестве используемых ST и Си это делается без проблем. А что в случае метапроги?

Вопрос скорее к ТСу, а не VarfolomeyKote4ka. VarfolomeyKote4ka решил, что поведусь на лозунги «будет как емакс, только без скобочек и вообще будет круто», вот не надо этого.

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

что поведусь на лозунги

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

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

Потому что идиоты из NI даже не пытаются толкнуть Лабвью как систему общего назначения. В отличие от моих намерений.

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

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

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

Потому что идиоты из NI даже не пытаются толкнуть Лабвью как систему общего назначения. В отличие от моих намерений.

Тонко намекну — они как раз не идиоты.

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

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

P.S. Это краткая аннотация содержимого этого и предыдущих тредов.

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

Потому что идиоты из NI даже не пытаются толкнуть Лабвью как систему общего назначения. В отличие от моих намерений.

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

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

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

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

Файл какого-либо формата, который может набить человек, с декларативным описанием объектов -> программа, которая этот файл обрабатывает -> заготовка программы на метапроге, которая попадет к специалисту

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

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

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

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

Ну твоих-то до послезавтра мы точно не увидим? А за мои не переживай, окда?

Причём учти, что это ж будет только спецификация на Core-систему, которая тяготеет к упрощению (изначально планировалось 8 различных типов блоков, теперь будет всего три). И я уже даже знаю, что ты на это скажешь: «текстовщина». Но эта «текстовщина» как раз и будет основой более высокоуровневых блоков в дальнейшем. А в плане изоморфности бэкэнду она как раз вполне равносильна твоим кердыперды на лабвью.

А что будет дальше, зависит только от твоих дел, а не слов, ибо в противном случае продолжения от меня ты тоже не увидишь – как сказал тот же Глюк-Казан (автор спецификации AntiRS) Базисту (автору RS), «какой смысл мне допиливать AntiRS, если ты на свой RS забил ещё в противозачаточном состоянии?»

P.S. И да, от прослойки в виде графвиза было решено отказаться, ибо red-expr вполне самодостаточны и как формат хранения данных, и как IDL, хотя графвиз в качестве экспортного формата - вай бы и нот, но это уже на будущее.

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

ZUI — это была такая дефолтная оболочка прошивок семейства Lenovo Zuk для внутрикитайского рынка, пока их не модернули с производства в пользу Moto.

Для автора даже Zuk слишком дороги, так что сомневаюсь, что он проникся тем интерфейсом настолько, чтоб портировать его на лабвью.

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

Ну твоих-то до послезавтра мы точно не увидим? А за мои не переживай, окда?

Я и не обещал специфкаций. Вообще. Анонсировал только релиз альфы, и то «в далеком светлом будущем» с перспективой в несколько месяцев. По срокам ничего обещать не буду, чтобы не было ситуаций из разряда «не так сталося, як гадалося».

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

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

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

metaprog
() автор топика

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

По одной фразе уже все понятно об уровне компетентности ТС

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

объектных моделей и прочей отвергаемой мной ерунды

Вообще-то, все графические тулкиты (инструменты для создания графического интерфейса пользователя) явно или не очень используют ООП в том или ином виде. GTK и GLib сильно завязаны на GObject. GTK - пример кода в ООП стиле на Си. Всё это «кнопка», «текстовое поле», «окно программы» - это всё абстракции, только очень удачные и устоявшиеся. Динамическая типизация иногда необходима. Для этого в GLib создали тип Variant. GLib - это то, что находится «под капотом» GTK.

Вот так вот - простой hello world на GTK неявно, «под капотом» использует эти вот все

сферических абстракций в вакууме, динамической типизации, объектных моделей

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

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

Анонсировал только релиз альфы

релиз альфы

Вголосинушку. /0. Вообще-то сначала идёт альфа, потом бета, затем релиз-кандидаты, а потом уже релиз. Это так, для справки и общего развития (с одноклеточного до двуклеточного).

Есть, правда, ещё пре-альфа, и в твоём случае она, похоже, будет вечной.

Я и не обещал специфкаций. Вообще.

«Релиз» (пусть даже альфы) без спецификаций — пук в лужу и усилия на ветер. Ибо в таком случае тем, что ты выпустишь, пользоваться будет всё равно невозможно, равно как и глобально понять, что твоё кердыперды умеет в целом. Ты много знаешь ЯП, на которые нет спецификаций? Да даже на тот же брейнфак есть. И на различные части лабвью тоже, ага.

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

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

Построишь ли реально полезную на практике систему

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

Я там увидел в каком кривом зеркале ты видишь мой концепт.

Но ты ведь за все 4 треда не потрудился внятно его объяснить, одни лозунги и пространные фразы в духе «все три-два-разы, а я Д’Артаньян».

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

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

Читай книги. Книги. Книги. На одних интерактивных справках далеко не уедешь.

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

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

Скорее мешает, в Python добавили TypeHint, и в PHP, у JavaScript есть TypeScript. Объекты тоже создают проблемы, иногда их лучше не применять.

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

Харе демагогию разводить. Ты знаешь, как расшифровывается DOM?

у JavaScript есть TypeScript.

Благо, JavaScript не имеет ничего общего с этой редкостной парашей, мешающей использовать современные ФП-ориентированные конструкции ES6. Типизированных массивов, буферов и вьюшек во вменяемом JS более чем достаточно.

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

Харе демагогию разводить.

Де она?

Ты знаешь, как расшифровывается DOM?

Да, но я если честно забыл уже как называется альтернативный способ работы с документами. Там не нужно всю страницу обрабатывать. https://github.com/PuerkitoBio/goquery тут используется к примеру.

Типизированных массивов, буферов и вьюшек во вменяемом JS более чем достаточно.

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

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

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

«Не знав, не знав, та ще й забув». SAX он называется, но это ж вообще не то. Ты ж даже не понял, к чему я пример с DOM привёл.

DOM — Document Object Model. И используется она в первую очередь в браузерах, ибо всё, что представлено на странице, наиболее естественно представлять в виде объектов. И дело здесь совершенно не в том, что HTML имеет XML-подобную структуру. Даже если бы формат был совершенно другим, более естественного представления, чем в виде объектов со своими свойствами, методами и событиями (которые изначально, кстати, задумывались как частный случай свойств, чем-то напоминая эти ваши унылые GTK-коллбэки), нельзя было бы придумать.

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

Современными средствами JS структуры с любым тайпчекингом реализуются на раз-два. Вылезай из криокамеры уже.

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

Ты ж даже не понял, к чему я пример с DOM привёл.

Крюгер, прекращай.

наиболее естественно представлять в виде объектов

Как и графика естественнее текста, да, странно что ты это не хочешь признавать. Я вообще про то что SAX много где лучше будет DOM'a. Ну в DOM действительно удобно юзать объекты, НО есть задачи где эти объекты и ООП нинужно совсем.

Современными средствами JS структуры с любым тайпчекингом реализуются на раз-два. Вылезай из криокамеры уже.

Какими именно средствами?

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

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

ТСу только об этом не говори :)

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

Такие дела. Выйдет что-то, что можно собрать и поработать — будем обсуждать.

чем квалифицированней разработчик в АСУ, тем он дальше от мышевозюкания и ближе к работе с текстом.

ТСу только об этом не говори :)

hobbit ★★★★★
()
Последнее исправление: hobbit (всего исправлений: 1)
Ответ на: комментарий от rebforce

Ты много знаешь ЯП, на которые нет спецификаций? Да даже на тот же брейнфак есть. И на различные части лабвью тоже, ага.

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

Читай книги. Книги. Книги. На одних интерактивных справках далеко не уедешь.

Ничего не знаю, для программирования в Лабвью я в книги не втыкал, а софт делаю, при этом весьма сложный. Как же так? Как же я смею это делать, не прочитав дюжину талмудов по ООП, code style и прочей порнографии?

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

GTK и GLib сильно завязаны на GObject

Какая-то тупость эти объекты, я б все это реализовал по-другому. Мне в гтк они мороки добавляют.

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

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

Вообще-то, все графические тулкиты

Нет, есть к примеру Nuklear!

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

Как и графика естественнее текста, да, странно что ты это не хочешь признавать

Ты предлагаешь писать Hello World как массив пикселей, а не как print "Hello World"? Окей, только не говори больше никому, что это естественнее.

Я вообще про то что SAX много где лучше будет DOM’a. Ну в DOM действительно удобно юзать объекты

Единственная ситуация, в которой SAX действительно лучше DOM — это ситуация парсинга огромного размера строго структурированных XML/XHTML-документов с целью вычленения из оных данных по определённым правилам. Всё. DOM здесь проигрывает по производительности, да и вообще использование оного чисто для парсинга — это стрельба из пушки по воробьям.

А вот когда мы имеем дело с интерактивными вещами вроде страницы в браузере, тогда DOM и показывает себя во всей своей мощи. Когда атрибуты элемента автоматически переводятся в свойства объекта (причём это соответствие далеко не всегда однозначно) и наоборот, когда с элементом предполагается как-то взаимодействовать и его состояние изменяется в динамике.

В общем, SAX и DOM — вещи скорее взаимодополняющие, нежели конкурирующие, но тем, кто забивает гвозди микроскопом и использует лабвью для чего угодно, кроме того, для чего оно предназначено, этого, разумеется, не понять.

НО есть задачи где эти объекты и ООП нинужно совсем.

В таких задачах и Мегапрога тоже не нужна.

Какими именно средствами?

Ликбез по JS/ES6 за свой счёт проводить не собираюсь.

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

Ты предлагаешь писать Hello World как массив пикселей

Ты предлагаешь писать каждый пиксель Hello World как массив объектов?

это стрельба из пушки по воробьям

А потом все логает!

В таких задачах и Мегапрога тоже не нужна.

Оч аргументированно.

Ликбез по JS/ES6 за свой счёт проводить не собираюсь.

Слился.

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