Ага, это же как раз сокращение кода!

Просто поддиаграммы и все тут. Незачем придумывать лишние концепты типа классов.

Просто поддиаграммы и все тут. Незачем придумывать лишние концепты типа классов.

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

Уважаемый, вы согласны с тем, что если ваш визуальный «код» будет изоморфен коду на СИ, то сложность топологии поникуда не денется? Она будет одинакова при для двух изоморфных представлений.

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

Возможно, вам будет близка идеология, которую исповедует группа авторов suckless.org — те еще гордецы, но, строительством вавилона не страдают. посмотрите на их код.

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

Можно будет просто разложить при нужде функции на категории по типу терминалов (аргументов). И все тут классы.

если функция работает с двумя и больше структурами, к какому классу ее относить?

Но она же работает со структурами, а не с классами.

Свой ответ начну с вопроса: что такое «изоморфен»? Подоступее пожалуйста. Получив на это ответ, продолжу свой ответ.

Именно. Это был ответ на:

Ну вот считай, что «класс» — это множество функций для работы с какой-то абстракцией, состояние которой представлено в виде структуры

Ну так это не ответ как бы, нужно сделать и структуры и классы...

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

Можно будет просто разложить при нужде функции на категории по типу терминалов (аргументов). И все тут классы.

Ты теоретизируешь или из практики берешь такие изречения? Посмотри на библиотеки для GUI. 99% функций относятся к модификации или запросу к состоянию одной абстракции. Где их две — там как-то решают вопрос, к чему ее относить, но это, в основном исключения. если у тебя основная масса функций работает с парой абстракций причем симметрично — ну сгруппируй их в библиотеку работы с парой. Никто тебя не заставляет ее в конкретный класс насильно впихивать. Поэтому если язык поддерживает классы их стараются именно для такой группировки и использовать. Плюс еще какие-то «плюшки» как побочный эффект даются — видимость, инкапсуляция, наследование... Но это уже на любителя. Замыканий достаточно.

Свой ответ начну с вопроса: что такое «изоморфен»? Подоступее пожалуйста. Получив на это ответ, продолжу свой ответ.

Прошу прощения, что вопросом на вопрос

Вы в каком классе?

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

Пускай в первом.

Хммм, все же как ты видишь классы в Метапроге?

Я в Лабвью соединяю функции проводниками - и они работают. А изоморфные они или нет я понятия не имею:)

Владимир

Вроде в gtk вы будете разрабатывать аналог редактора LabVIEW.
Представляете объем работы /не к тому что не осилите/?

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

Забей, театр одного актера. Автор уже слился, вместе со своими друзяшками\подружками\виртуалами. Осталось дождаться пока ему станет скучно и надоест.

Хм. попробую для первоклашек. Самому интересно, смогу ли я своим детям объяснить.

Изучаем изоморфизм на примерах:

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

Но вот новое задание для Пети и Вовы: нарисовать самолет. Петя рисует реактивный самолет Ту 154, а Вова — винтовой Ан-2. Марья Петровна понимает, что на обоих рисунках — самолеты, но Ту 154 не изоморфен Ан-2, хотя у них много общего. Это потому, что если ниточкой выложить рисунок Tу-154, из него будет трудно получить рисунок Ан-2. Нужно откуда-то брать второе крыло (Ан-2 же биплан), а также винт и шасси (Петя нарисовал Ту-154 в полете). Т.е. не каждая точка ниточки, которая соответствует фюзеляжу станет фюзеляжем в другом рисунке и наоборот, тоже самое можно сказать про плоскости, винт и шасси.

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

В нормальных языках вообще нет проблем с переименованием лексем - IDE справляется с этим мгновенно.

Это частный случай изоморфизма - топологический изоморфизм. Вообще изоморфизм определить очень сложно, но я себе его представляю как «a изоморфно b на множестве c» означает, что из a можно получить b и из b можно получить a с помощью последовательного применения преобразований из множества c. Скорее всего это не совсем так, поправьте меня, математики.

Если для первоклассника - синхронные операции блокируют (останавливают) выполнение программы до своего завершения, а асинхронные - нет, таким образом позволяя выполнять несколько асинхронных и одну синхронную операцию одновременно.

Читал только в оригинале. Но вообще это шутка была.

Это частный случай изоморфизма - топологический изоморфизм. Вообще изоморфизм определить очень сложно, но я себе его представляю как «a изоморфно b на множестве c» означает, что из a можно получить b и из b можно получить a с помощью последовательного применения преобразований из множества c. Скорее всего это не совсем так, поправьте меня, математики.

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

Думаю так будет понятнее с сервером и асинхронностью!

#include <glib.h>
#include <gio/gio.h>
#include <stdio.h>

void stream_flush_finish(GObject *source_object, GAsyncResult *res, gpointer user_data)
{
	// Получаем результат от g_output_stream_flush_async
	g_output_stream_flush_finish(G_OUTPUT_STREAM(source_object), res, NULL);
	
	// Получаем заготовленный сокет
	GSocket *socket = user_data;
	
	// Закрываем ввод/вывод у сокета, это нужно для браузера...
	g_socket_shutdown(socket, TRUE, TRUE, FALSE);
}

void stream_write_finish(GObject *source_object, GAsyncResult *res, gpointer user_data)
{
	// Скажем GIO что мы получили результаты от g_output_stream_write_all_async
	g_output_stream_write_all_finish(G_OUTPUT_STREAM(source_object), res, NULL, NULL);
	
	// Так как вывод может и не отправлятся а сохранятся в структуре, прикажем GIO
	// точно-приточно отправить все данные клиенту...
	g_output_stream_flush_async(G_OUTPUT_STREAM(source_object), 0, NULL, stream_flush_finish, user_data);
}

gboolean incoming(GSocketService *service, GSocketConnection *connection,
                 GObject *source_object, gpointer user_data)
{
	// Получаем объект для вывода данных (к клиенту)
	GOutputStream *stream = g_io_stream_get_output_stream(G_IO_STREAM(connection));
	
	// Получаем сокет из нашего соединения, он нам понадобиться потом
	GSocket *socket = g_socket_connection_get_socket(connection);
	
	// Говорим GIO что нам нужно отправить Hello! асинхронно, а как он отправит, пусть
	// вызовет stream_write_finish
	g_output_stream_write_all_async(stream, "Hello!", 6, 0, NULL, stream_write_finish, socket);
	
	return FALSE;
}

int main(int argc, char **argv)
{
	// Создаем Event Loop!
	GMainLoop *loop = g_main_loop_new(NULL, FALSE);	

	// Создаем TCP сервер, он уже есть готовый
	GSocketService *service = g_socket_service_new();
	
	// Говорим ему слушать порт 8080, открыв страницу localhost:8080 в браузере мы
	// попадем на наш сервер... Открывать стоит из Firefox, так как он понимает 
	// не только HTTP но и чистые данные, которые мы будем отправлять
	g_socket_listener_add_inet_port(G_SOCKET_LISTENER(service), 8080, NULL, NULL);
	
	// icoming будет вызывать при подключении
	g_signal_connect(service, "incoming", G_CALLBACK(incoming), NULL);
	
	// Активируем наш сервер
	g_socket_service_start(service);
	
	// Запускаем Event Loop (и сервер тоже получается!)
	g_main_loop_run(loop);
	
	return EXIT_SUCCESS;
}

Владимир

Всему есть предел ...
Не обижайтесь, но пока все похоже на https://www.youtube.com/watch?v=lw4FIa8lIRI Будни младшей группы №7 МДОУ детский сад №97

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

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

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

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

Ну ОПу явно надо добавить в metaprog изоморфинно-биекционную парадигму программирования, а то как пустословить собсна?

Да, прошу прощения, сохранение структурных свойств, конечно же, обязательно. Но когда речь идет про «фигуры» вы подразумеваете гладкие многообразия? в этом случае, например, любая линия в двумерном пространстве (без пересечений) изоморфна любой другой такой же, да. Не важно, это контур маленького Чебурашки или большого крокодила Гены. Если для вас важны пересечения (как узлы графа, например), то, конечно, вы их тоже будете «биектить». Но это еще не структура. Под структурой обычно подразумевается свойства операций, если вы сравниваете алгебры или группы.

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

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

Вы же ещё даже простейшие алгоритмы не можете написать на метапроге

Линус не мог даже gcc запустить на своей системе на момент своей первой публикации по линуксу.

(кстати, в чём заключается мета?)

Мета по-украински «цель».

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

Линус не мог даже gcc запустить на своей системе на момент своей первой публикации по линуксу.

Я думаю на этом можно заканчивать тред.

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

Конечно!, и для более широкого adoption, типичная последовательность хоткеев будет выглядеть как-то так:

int main() { printf("Hello world!\n"); return 0;}

Смешно смотреть на завистников))

Разработка ж на этом не заканчивается, а только начинается.

Лучше сами поучаствуйте после релиза, приобщитесь, глядишь и зависить пропадет!

Как можно будет реализовать автоматический free после malloc? У тебя были/есть мысли? Вещь полезная по моему!

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

\LaTeX пока еще держится в разных проявлениях для набора формул. Быстрее получается именно текстом.

\sum_{i=1}^{\inf}\frac{1}{i}

Сколько мышкой будете возить?

Оно мне надо? Пилить никому не нужный язык, зависящий от проприетарной IDE, на котором простейшие алгоритмы хрен напишешь?

Быстрее получается именно текстом.

Ну так им писать и нужно будет, специальный блок для матана, ну!

зависящий от проприетарной IDE

Ну во первых отвязка от LabVIEW одна из первых целей!

на котором простейшие алгоритмы хрен напишешь?

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

Ну нехорошо над человеком уж настолько издеваться, это даже не весело.

Я просто спросил! Сам не особо представляю как это можно реализовать в его архитектуре, пусть заодно продумает... Там как в С++ с деструкторами можно, а можно и как нибудь круче...

вопрос

Почему на gtk? И на какой версии?

тут не текст, тут круче!

-Чем круче? -Чем текст!
Надеюсь это не шизофрения автора, и весна скоро пройдет вместе с обострением на ее фоне.

Почему на gtk?

Тут и GObject, GLib, GIO. А что вместо этого взять?

И на какой версии?

gtk(3/4)

Короче, изоморфизм это соответствие блокам блок-диаграммы строчек текстового кода? Правильно? Ох уж не люблю я эти заумные формулировочки...

-Чем круче? -Чем текст!

Разве текст с картинками не круче просто текста? Во первых во всех IDE идут по этому пути, добавляют к тексту всякие штуки...