LINUX.ORG.RU

История изменений

Исправление shpinog, (текущая версия) :

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

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

На Си много готовых библиотек и чтоб не заморачиваться с собственным компилятором (по крайней мере, на данном этапе), ведь Си называют «кроссплатформенным ассемблером»: простой и быстрый.

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

В Лабвью тоже есть все это, в том числе аналог структур (кластер), но не хватает юнионов. Правда с переменными немножко другая история: там всю работу по передаче данных делают проводки и сдвиговые регистры (в циклах - в диаграмме поиска решений уравнения есть два таких).

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

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

Ты про пейнт или гимп? Я про то что ты пытаешь сделать шаблонизатор Си, где в качестве шаблонов выступают блоки и проводки.

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

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

Но я вижу это, вместо визуального программирования.
Тебя попросили решение квадратного уравнения, в итоге из этого скриншота я вижу 95% информации которая никакого отношения к решению не имеет.

В итоге получается что решение на си (не более 32 строк) или на питоне (не больше 16 строк) где в обоих случаях для решения достаточно подключение 1 библиотеки, что составляет 1 строку. В твоём примере на фоне решения, которое ещё не понятно работает ли для всех корней, я вижу 95% мусора в виде непонятно чего.

Исходная версия shpinog, :

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

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

На Си много готовых библиотек и чтоб не заморачиваться с собственным компилятором (по крайней мере, на данном этапе), ведь Си называют «кроссплатформенным ассемблером»: простой и быстрый.

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

В Лабвью тоже есть все это, в том числе аналог структур (кластер), но не хватает юнионов. Правда с переменными немножко другая история: там всю работу по передаче данных делают проводки и сдвиговые регистры (в циклах - в диаграмме поиска решений уравнения есть два таких).

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

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

Ты про пейнт или гимп? Я про то что ты пытаешь сделать шаблонизатор Си, где в качестве шаблонов выступают блоки и проводки.
Когда я слышу «визуальное программирование», я понимаю это как метод разработки программ со своим уникальным подходом и инструментарием.

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

Но я вижу это, вместо визуального программирования.
Тебя попросили решение квадратного уравнения, в итоге из этого скриншота я вижу 95% информации которая никакого отношения к решению не имеет.

В итоге получается что решение на си (не более 32 строк) или на питоне (не больше 16 строк) где в обоих случаях для решения достаточно подключение 1 библиотеки, что составляет 1 строку. В твоём примере на фоне решения, которое ещё не понятно работает ли для всех корней, я вижу 95% мусора в виде непонятно чего.