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

Это не в языках. Почти во всех языках можно создать сколько угодно сущностей. Но в самих языках они тоже есть. И в более высокоуровневых Хаскеле и Питоне (хоть и никогда не любил Питон) их меньше чем в Си.

В любом языке с массивами можно такое сделать.

Можно, и никто не делает. Т.к. потеря гибкости никому не нужна.

Иногда это оправданно.

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

Нет.

Да.

О чём и речь. Потом оказывается что нет

...

Да.

Просто С легкий язык, на нем много ерунды пишут, так как «начинающие».

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

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

Есть куча скринов и компилируемого кода для демонстрации. Хотя, конечно, это не сравнить с работающим прототипом. К сожалению, Лабвью платное и среди линуксоидов мало котируется, смысла его выкатывать нет. Придется для полноты ощущений ждать альфы.

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

Ничего нет. Проходи мимо.

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

при том что судя по задаваемым вопросам ты далеко не системный программист. когда страустрап делал свою надстройку над C каковой по сути являлся первый интерпретатор C++ -> C думаю он обладал явно большим запасом знаний.

Не трогай дерьмо, и оно вонять не будет. Ему уже 4 треда объясняют, а он прям по методичке «Правила демагога» шпарит. Бесполезно.

интерпретатор C++ -> C транслятор C++ -> C

извиняюсь за опечатку

Иди на три буквы, первая из которых «х». Эх, если б не правила...

А еще Страуструпп отгрохал целый талмуд по ООП. Еще бы, он кандидат наук или как его там. Но я лично считаю эту дребедень лишней и даже вредной. Как говорил Галилей, эксперимент - критерий истины.

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

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

Для чего существует ООП? Оно проще? Для чего С++, если есть чистый Си? Он проще? Если да, то освоить его должно быть проще, но в реальности С++ неимоверно сложнее в освоении чем чистый Си. Если даже сам Страуструпп оценивает свое знание С++ на 8 из 10 (из вики), то ООП явно сложнее. И для компиляции и выполнения «железом» ООП-код тоже сложнее. Так зачем учить и осваивать ООП?

Близится 4 мая, а концепт твоей «визуальной среды» был обещан до 3 мая. Успеешь за оставшиеся часы?

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

А для железа он проще?

Осталось меньше 2 часов. Часики тикают.

Говорить, что ООП сложное потому, что С++ сложный - это как говорить, что все ноуты говно потому, что винда - говно. ООП не ограничивается С++, как и ОС не ограничивается виндой. Вообще, пример С++ неудачный. С++ - это один из самых сложных (в плане количества особенностей языка) ЯП в мире. И переделать, чтобы всё с нуля и правильно не получится - потеряется совместимость на уровне исходников и ЯП станет никому не нужным.

99% С++ разработчиков используют своё подмножество языка, а не все фичи, и им норм. Тот же Qt для С++ - на нём можно писать проект любой сложности (под силу далеко не каждому), и при этом использовать 30% возможностей языка.

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

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

да проще чем другие ООП языки (тот же python) не говоря уже о вебдаунистических технологиях пихаемых ныне повсюду. если ты говоришь о фичах самого языка perfomance hit настолько незначителен что им можно пренебречь на фоне современного железа и современного жирного софта. тем более к примеру методы в C++ по умолчанию даже не virtual что позволяет избежать вставки в объекты класса малюсенькой таблички с pointer'ами, одним словом на perfomance он ориентирован и вряд ли какой то другой ООП язык может сравниться с ним по производительности. если ты говоришь о производительности STL то ты можешь наклепать конечно более эффективный код с pointer'ами и malloc наделав при этом кучу багов.

C прост в изучении и написании hello world. Язык прост и логичен. Python сложен для изучения целиком но прост в написании скриптов из готовых библиотек для чего не нужно знать весь язык а в большинстве случаев только основы. C++ для профессионалов время которых стоит дороже чем полсекунды процессорного времени о чём говорить вообще считаю абсурдным на фоне других современных языков джавы, python'а, javascript'ов от которых загибаются мощнейшие компы под тяжестью тонн оопического говнокода.

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

Зависит от задач.

зачем вы сравниваете python и C++. у них разные области применения.

https://pics.me.me/good-luck-with-that-writing-device-drivers-with-javascript...

Хром и нода jit'ят js в машинный код + нашлись извращенцы, что пихают js в ардуину! даже не в одноплатники а-ля малинка, а схема, что не тянет ОС, где код пишется на js!

С учётом этого драйвера на js вполне возможны. Но слава Богу, что это никому не нужно кроме кучки извращенцев.

Сколько раз писали, что тормозит не js, а DOM и кривой код. Правда, в js и питоне объекты сделаны на основе словарей. В результате сишное и с++ное person->name в жс и питоне person.name де-факто превращается в что-то типа

std::map<std::string, std::variant> person;
name = person["name"];
person["hi"]();

Qt очень сильно понижает порог входа для С++ для разработки полезных программ. Даже в таких областях как быстрый обмен данными между разными потоками без дедлоков.

Плюс есть куча десктопного легаси, где чёрт ногу сломит а-ля фотошоп, 3д макс. Хотя почти любой огромный десктопный и не только софт пишется на С++. Ядра и драйвера - это уже царство сишки.

И что же это за мастера С++ и какие проблемы они решают, что им платят такие космические зарплаты?

концепт AMP будет устаканен в течение недели

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

Неделя прошла. «Спецификаций» и чего-либо еще нет. Торжественно объявляю тебя пи брехуном.

Бесспорно С++ лучше питонов, джав и другого говна, даже как пользователь программ замечаю. Но это все же меньшее из зол. Чистый Си лучше http://harmful.cat-v.org/software/c /

Для бекенда для Метапрога лучшего варианта чем Си не знаю.

какие космические зарплаты? труд уборщика дороже в 10 раз того процессорного времени которое затратится на C++ программу в сравнении с тем что на быдлокодит этот школьник pointer'ами на C. с учётом повсеместного засилья вебдаунизма даже джава выглядит performance oriented технологией. да я в курсе что тормозит dom, и ещё css3 и прочие свистопердящие онемацеи в электронах и т.д. говнофреймвёрках. глазам своим не верю что в век засилье жырных фреймвёрков, джав, питонов и прочих многотонных выжирающих память софтовин кто то завёл разговор о производительности C++ который уже во времена начала работы страустрапа был не актуален.

C++ никак не может быть лучше или хуже питонов так же как отвёртка никак не может быть лучше молотка а грузовик лучше мотоцикла.

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

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

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

а всё потому что на C пишется системный софт системными программистами относительно высокой квалификации и тестируется всё это дело очень хорошо потому что используется много где в том числе корпорациями. ты сильно разочаруешься в C если узнаешь что первые версии ядра linux написанные финским студентом падали постоянно в kernel panic?

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

а что у тебя на плюсах падает?

а что у тебя на плюсах падает?

Мне вот проще сказать что не падает %)

ты можешь убить месяц на клепание этого гуя на C

Но GUI делается в glade, плюс там еще удобное подключение сигналов чисто для С!

Для чего существует ООП? Оно проще?

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

• ООП — namespace isolation
• Функциональное — работа с массивами, списками
• Реактивное — интерфейсы пользователя, и может ещё что-то
• Императивное — связка между всеми этими вот

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

На чистом Си нету никакой изоляции пространства имён, кроме static. Да и вообще с пространством имён у Си наверное хуже всего в мире. Анонимных функций нету — придумывать имена нужно для всяких затычек.

Я сужу языки программирования по программам, на них написанным.

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

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

говорят, после примерно 30,000 LOC в C начинаются реальные проблемы с пространством имён. но это ещё не самое страшное. огромное количество ошибок в C это отсутствие гарантированной инициализации сложных структур (constructor).

ты сильно разочаруешься в C если узнаешь что первые версии ядра linux написанные финским студентом падали постоянно в kernel panic?

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

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

отсутствие гарантированной инициализации сложных структур

удваиваю

начинаются реальные проблемы с пространством имён

А ещё прикол в том, что нельзя сделать

enum x {
   X_ONE
};

struct x {
};

Т.е. блин приходиться

enum x_enum {
    X_ONE
};
struct x_struct {
};

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

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

Сделать разделяемую библиотеку Метапрогом не получиться или будет не тривиальной задачей?

Кстати, как насчёт выложить исходники на bitbuket.org? Там есть приватные бесплатные репозитории, к которым Вы можете допустить только тех, кого хотите. И сделать репозиторий открытым, если будет нужно.

Думаешь я в жизни не сталкивался с джавой? Чего только стоит андроид. Си по критерию качества программ бесспорно выигрывет, а вот всяких С++ и джава ексепшонов я наловил, как старый кот мышей.

Этот пример показывает как низкоуровневый Си позволяет допиливать софт практически до совершенства, не оглядываясь на всякие идиотские абстракции и объектные модели

аххаха. идиотские абстракции как раз таки и созданы для удобства допиливания. представь что у тебя есть класс Matrix в котором энкапсулировано низкоуровневое представление матрицы и операций с ней. этот класс может быть протестирован независимо от остального кода и использоваться с тем же удобством как и машинный тип данных учитывая operator overloading в C++. на каком то этапе разработки ты обнаруживаешь более быстрый алгоритм для транспонирования этой матрицы и можешь с лёгкостью поменять этот класс не опасаясь что это приведёт к необходимости изменений в остальном коде программы т.к. характеристикой класса интересующими использующий его код являются исключительно его public методы. если же у тебя нет этой абстракции вполне возможно что новый алгоритм потребует другой структуры данных и тебе придётся менять весь код. почитай книгу Bruce Eckel «Thinking in C++» что бы разобраться а не тупо обсирать. там такие вещи очень хорошо описаны. и довести до ума программу на ООП гораздо проще чем без него.

Я либо открываю код под GPL, либо не открываю. Код лабвью-прототипа не открываю потому что п. 2 FAQ.

Библиотеку типа .so, .ko и .dll? Думаю будет несложно... когда руки дойдут до этого, но это уже будет после раскрутки Метапрога.

т.е. ты предпочитаешь писать в стиле

if (!( dirp = opendir(argv[1]) )) {
  perror("opendir(3)");
  return 2;
}

вместо обработки exceptions в одном месте? или просто игнорируешь проблему, пущай её идёт дальшь dirp == NULL и падает в segfault?

идиотские абстракции как раз таки и созданы для удобства допиливания

Только самая главная моя претензия к ООП - сложность в освоении - никуда не девается. Читай что-то да учись все время, ведь даже сам Страуструпп оценивает свое знание С++ на 8/10. ООП - хороший выбор для любителей вечно учиться да читать, но я не из таких.

представь что у тебя есть класс Matrix в котором энкапсулировано низкоуровневое представление матрицы и операций с ней. этот класс может быть протестирован независимо от остального кода и использоваться с тем же удобством как и машинный тип данных учитывая operator overloading в C++. на каком то этапе разработки ты обнаруживаешь более быстрый алгоритм для транспонирования этой матрицы и можешь с лёгкостью поменять этот класс не опасаясь что это приведёт к необходимости изменений в остальном коде программы т.к. характеристикой класса интересующими использующий его код являются исключительно его public методы. если же у тебя нет этой абстракции вполне возможно что новый алгоритм потребует другой структуры данных и тебе придётся менять весь код.

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